15.3 Development guidelines

---

15.3 Development guidelines

When installing and configuring a WebSphere Data Interchange environment, we need to make a distinction between a development environment and a runtime environment. In the development environment, users will create maps and profiles. The runtime environment is the environment where the translation and distribution of EDI messages will occur. The runtime platform may be different from the development environment platform.

15.3.1 Development environment

The development environment consists of the WebSphere Data Interchange Client on a number of Windows machines and a DB2 database accessed via ODBC, as shown in Figure 15-5. The database itself can be local or remote. It can even be on a non-Windows platform, such as AIX.

Figure 15-5: WebSphere Data Interchange development environment

Development machines that need access to the WebSphere Data Interchange database will need the DB2 Connect™ product to be able to connect to the database.

The WebSphere Data Interchange Client environment is also used to configure several aspects of the runtime environment that are not directly related to building maps. Settings such as partner profiles, queue profiles, and locations and names of files are all set via the WebSphere Data Interchange Client. This functionality of the client might have an impact on an installation and how database access and security is configured.

Given the possibilities for using the WebSphere Data Interchange Client, the installation and configuration of a WebSphere Data Interchange development environment will involve configuration work at the database level and possibly at the WebSphere MQ level.

15.3.2 Runtime environment

The runtime environment for a WebSphere Data Interchange solution can be quite broad, with many complex interactions between WebSphere Data Interchange itself and other applications, as shown in Figure 15-6 on page 326. But in general, WebSphere Data Interchange operates in two modes:

• Batch mode

• Launching the WDIAdapter program

Figure 15-6: WebSphere Data Interchange runtime environment

In batch mode, an automation product launches the ediservr program. This program receives instructions from a command file that contains so-called PERFORM and other commands. The WebSphere Data Interchange Server will then execute these commands, which will usually result in sending, receiving, and translating a number of EDI documents that are ready to process. One reason for doing this in a batch mode is to save costs. Combining several EDI documents into a single EDI transmission document is often cheaper than sending each individual document separately.

When EDI documents are being sent over the Internet, there is no reason to delay transmission. Communication costs for the Internet are normally not measured on a transaction basis. Therefore, a company that uses an Internet connection for EDI communication wants to send EDI documents as soon as they become available. In this situation, the second method of using WebSphere Data Interchange is launching the WDIAdapter program. This program is designed to be started by WebSphere MQ's trigger monitor. As shown in Figure 15-6, when a message arrives in queue from enterprise applications, the trigger monitor will start the WDIAdapter program, which will translate it according to the definitions in the WebSphere Data Interchange database. The translated message is then written on another queue for transmission by an Internet gateway product, such as iSoft or CrossWorldsTPI, or by WebSphere MQ itself.

Given the possible scenarios in a runtime environment, the configuration and installation of the WebSphere Data Interchange Server will usually include database tasks as well as WebSphere MQ tasks.

---