Knorr
Associates rewrites its data-management app with .NET
technology to satisfy current customers - and attract new
ones.
by Edmund X. DeJesus
MAY 2002
The old rule of thumb says, “If it ain’t
broke, don’t fix it.” It’s an especially good rule in
computer development— and engineering in general—because
it keeps you from making unnecessary updates to products
that already work fine. The trick is to know when to
ignore the rule. For example, if keeping a product
unchanged costs you customers—or prevents you from gaining
new ones—that’s a hint that it’s time for an update. One
such product is DataPipe from Knorr Associates Inc.
(Butler, N.J.). Knorr, a company that acquires and manages
environment, health, and safety (EHS) data for
organizations, launched their product in 1979 as a Unix
app, which later ran on the first PCs to collect and use
data. This base product grew to include over a hundred
modules to handle many aspects of EHS data collection,
including waste, storage, recycling, medical tests, and
Occupational Safety and Health Administration (OSHA)
requirements. As you can imagine, a Unix app running on
PCs was a tough sell, so in the mid-1980s Knorr took a
gamble and created a version for the recently released
Microsoft Windows platform. This new model—a complete
rewrite from the ground up— took advantage of the modular
architecture and graphical user interface (GUI) Windows
offered. That’s how DataPipe was born, and its Windows
incarnation has served Knorr well for over a decade.
With a winner like DataPipe, why change it?
It’s those customers: They always demand improvements to
the products they use. For example, Knorr’s customers
wanted access to a variety of databases, such as Oracle,
DB2, SAP, and PeopleSoft. Hospitals, factories, and other
organizations with EHS systems to maintain often work with
a multitude of databases, all handling separate pieces of
the total picture. One reason for overhauling DataPipe was
to acquire input from all those data stores and assemble
it into a coherent whole.
In addition, Knorr began to serve a more
global customer base. Organizations—including those either
based in non-English-speaking countries or based in the
U.S. but with global offices—needed their
non-English-speaking users to use the same modules as
their U.S. counterparts. The new DataPipe had to handle
many languages—and multiple language character
sets—to meet the needs of these global customers.
Another reason to update DataPipe was to
give users a more generalized interface. Customers based
on a wide spectrum of platforms—including desktop
workstations, laptops, and handhelds—needed to use
DataPipe modules and exchange data with those devices.
Although there are a number of possible solutions to this
interface issue, the most common one is to create a Web
interface. As long as the user’s platform has a browser
and a Web connection, they can use the application.
With all these special requirements,
Knorr’s developers needed a powerful set of tools to get
the job done. Knorr was comfortable with a variety of
underlying systems, including Unix and Windows, and could
choose any development environment that seemed best. In
fact, developers looked at many other development choices,
including C, CORBA, and Smalltalk. They carefully
considered IBM’s VisualAge for Java as a leading
candidate. However, at the time they examined it, they
felt that Java was weak in the database area. Knorr
finally settled on .NET because these technologies allow
what they hoped to accomplish. Moreover, the tools are
powerful enough to simplify and speed their development
efforts.
Go Beyond the Browser
The transition to a Web-based application
is not without its drawbacks. Sure, it makes things easier
on IT; with a Web-based app, all the code can reside on a
Web server and no one has to deploy the app to a thousand
machines. Unfortunately, a standard Web browser interface
isn’t as rich as a Windows GUI. “Web applications are all
very basic. They don’t do much, and the forms are very
simple,” notes Peter Singer, vice president
of product development. Knorr needed more from the
application such as on-the-fly field validation or a
parent record that could interact with hundreds of
reference and child tables. Clearly, a client heftier than
a browser would be necessary to accomplish all this
processing.
DataPipe developers preferred to preserve a
rich interface, so they adopted a hybrid approach. The
client machine requires only a Web browser—at first. After
establishing communications with the server-based host
program, the software downloads to the client
automatically. This software establishes a Global Assembly
Cache on the client, which proceeds to download any other
software necessary for the chosen operation, and to pull
together the data required for the task. Microsoft
Internet Explorer is the chosen browser to initiate the
extra activity.
This sophisticated “thin-to-thick” client
strategy augments the browser’s functionality. “ASP.NET
may have lots of controls, but it doesn’t compare with the
Windows GUI,” comments Singer. Developers couldn’t just
use Web forms to implement this strategy; they turned to
user controls and put processing power at the interface
level.
The ability to access a variety of
databases was also not as straightforward as Microsoft,
IBM, or Oracle would have you believe. Knorr had targeted
several databases to satisfy customer needs, including SQL
Server, DB2, and Oracle. “The problem is that there’s not
much code in common,” according to Norman Dotti, president
of Knorr. DataPipe developers had to write specific code
to access each one of the targeted databases; this is
transparent to the user, and to the rest of the DataPipe
code. The database interface is constructed so that any
DataPipe module can access the required details without
knowing the specifics of the target database.
DataPipe uses a three-tier architecture
(see Figure 1). Its Web services-accessible back-end
database is independent of the other data stores DataPipe
interacts with. The front end offers users powerful forms
customization capabilities. For example, users can change
labels and other output formatting without affecting the
underlying database.
Speaking in Tongues
The new DataPipe app supports multiple
languages by translating form text automatically. Its Form
Designer tool allows users to select from several
different languages to view data. This enables both a
German and English user to look at the same data in their
respective languages.
In addition, DataPipe’s back end supports Unicode, so that
multiple language character sets are possible. This means
that global customers can create their own labels in their
own language using the character sets they prefer. This
simplifies learning to use DataPipe and truly expands the
number of potential users.
DataPipe developers have found that .NET
affords a wide variety of useful technologies, including
Web services, back-end database connectivity, and ASP.NET
controls. “It makes life easier working with data sets,”
says Singer. The system uses XML to handle data sets;
developers found it simple to read a form, persist the
properties, and bring it back to the database.
The connectivity inherent in .NET has been significant to
the DataPipe project, considering the number of
third-party databases involved, the many modules available
for the product, and the support of users necessary. “You
could build these things yourself if you wanted, but it
would be fragile if you needed to make changes,” notes
Dotti.
The Knorr team used Visual Studio .NET for
several areas, including Windows Forms, middle-tier
components, Web services, and Windows services
development. The Windows services development offered a
lesson in the variety of .NET technologies available to
solve certain problems, such as tracking the number of
users. ASP.NET seemed to offer three methods to accomplish
this. Although one used Internet Information Services (IIS)
and another used Web services, neither worked with the Web
farms. A third method performed the task in SQL Server,
but this didn’t work with the other databases that
DataPipe had to support. Developers finally wrote the
necessary code themselves using VB.NET. “This way, for
example, you can have one machine running Web services and
track who’s accessing that,” explains Singer.
Developers used COM+ for database
transactions. They found its handling of commit and
rollback—as well as its ability to use multiple
tables—invaluable.
Take Advantage of Visio
The DataPipe development team thoroughly
exploited Microsoft Visio Enterprise Edition for a variety
of tasks. They designed databases by constructing entity
relationship diagrams in a logical,
not physical, level. Visio then converted the logical
types to the correct structures in DB2, Oracle, and SQL
Server. As a bonus, Visio supports Unicode for the
multi-language character sets they wanted to offer (see
Figure 2).
The team also used Visio to incorporate
Unified Modeling Language (UML) into the process. Given a
class structure, Visio developed the interface and came in
handy for designing data sets. Visio integrated well with
Visual Studio and Visio documents were even incorporated
in VB.NET. “Microsoft handles a lot of the plumbing,” says
Singer.
Knorr did hit a few snags using the beta
versions of .NET technologies: The documentation wasn’t as
complete as they’d have liked, and there was always the
nagging doubt that something
that worked in beta might not work the same with the real
product. Happily, those fears didn’t cause significant
problems.
In fact, the developers’ experience with
.NET has inspired them to formulate their own wish list of
features for future versions. Because they deal with so
much data, edit masks on fields would be useful, forcing
the correct format of fields such as phone numbers or
social security numbers. Developers also miss repeater
control, present in VB6 but not in VB.NET, which lets you
specify how many controls you want, then binds them
automatically. Because DataPipe uses complicated data
sets— multiple records from many tables—Knorr developers
would also like the ability to handle more complex data
sets.
Knorr’s experience with .NET has been
overwhelmingly positive. The new DataPipe code is robust
and easy to support. “We’ve had no customer problems,”
says Dotti. “It’s a low-maintenance product.” That’s the
result you want when you fix something.
About the author: Edmund X.
DeJesus is a freelance technical writer in Norwood, Mass.
Reach him at dejesus@compuserve.com.
