15.2 Design guidelines

---

15.2 Design guidelines

Figure 15-1 shows the Runtime pattern and Product mapping for the Message Connection variation of the Exposed Direct Connection application pattern across enterprise boundaries, using WebSphere Data Interchange for Multiplatforms.

Figure 15-1: Exposed Direct Connection——Message Connection— WebSphere Data Interchange Product mapping

This product mapping uses IBM WebSphere MQ V5.3.1 as the transport mechanism between WebSphere Application Server, WebSphere Data Interchange, and iSoft Peer-to-Peer Agent.

WebSphere Data Interchange V3.2 with CSD1 is used to adapt each type of message/document to partner requirements. The product mapping uses iSoft Peer-to-Peer Agent V3.1.2 to adapt MQ messages and documents to the AS2 EDI protocol for secure and reliable transport of messages and documents with business partners via the Internet.

15.2.1 Electronic Data Interchange

Electronic Data Interchange (EDI) is widely accepted by companies all over the world as the way to electronically exchange business data. Business documents such as purchase orders, invoices, shipping notices, and price catalogs are exchanged between companies in a structured and computer-processable format.

Organizations are recognizing the value of many years of investments in EDI. Rather than replacing existing solutions, they are extending and evolving their EDI transactions. These existing EDI solutions are considered an integral part of a multi-modal B2B gateway or hub alongside XML, Web solutions, and portals. By integrating B2B and EDI technologies, event-driven or process-driven integration models can be supported using the existing EDI solution.

Advantages of EDI

The market is driving every business to act smarter and quicker and to be more visible. Much of this can be achieved using EDI. Even better, EDI can give companies a better knowledge of their markets, because it opens up possibilities to collect and analyze information from the EDI transactions they are generating.

Among the most visible benefits of adopting EDI are:

• Reduction of data entry errors

• Reduced cycle time

• Minimization of paper use

• Improved relationships with your business partners

• Information in electronic form is more easily shared throughout the organization

• Improved inventory management

EDI transmission

EDI is a concept. It does not define any techniques or point to any specified product or service. An EDI transmission can basically be divided into two logical parts: the message itself and the communication.

Message standards

Since the idea of EDI is to have a standardized message, a number of different standards have been developed and established over the years. The most commonly used message standards are:

• ANSI ASC X12 - US standard

• EDIFACT - standard recommended by the United Nations, used mainly in Europe

• UNTDI - UK retail standard

• ODETTE - European automotive industry

• Others, such as HIPAA, VICS, VDA, UCS, and so forth

Communication

Transportation of the EDI file over a network can be done in many ways. Any network and any protocol can be used as long as it fits the needs. Three types of communication are:

• Value Added Networks (VAN) communication

  Using a value added network for the transmission of files is traditionally seen as the most secure way of communication. Apart from doing pure communication, a VAN also provides value adds such as built-in security, restart and recovery facilities, archive capability, 24x7 availability, and notification of message arrivals.

• EDI over the Internet

  The initiative to move toward securely transmitted EDI messages over the Internet is known as EDI INT. Presently there are two main EDI INT initiatives, known as applicability statements AS1 and AS2, which describe how current Internet standards can be used to achieve VAN functionality.

  • AS1 uses MIME (Multipurpose Internet Mail Extensions) and SMTP (Simple Mail Transfer Protocol).

  • AS2 uses MIME and HTTP (Hypertext Transfer Protocol) for process-to-process real-time EDI.

  The Internet solutions are often considered much cheaper than traditional VANs, but Internet solutions often leave it to the user to add functionality to achieve adequate security, reliability, and other features that are included in a VAN.

  IBM Business Exchange Services - Internet transfer is an example of Internet communication.

• Message queuing

  Message queueing (MQ) connects commercial systems in today's business. It provides assured, once-only delivery of data in any format.

  IBM WebSphere MQ is an example of this.

While the use of EDI technology is widespread, technology changes and evolution have resulted in the use of many types of B2B communication infrastructures. Besides the traditional VAN-based EDI communication, AS1 and AS2 Internet protocols are still tied more or less to traditional EDI communications. More recently, Web services-based technologies also became available for use in the B2B area. While this technology is still maturing, it is clear that a flexible B2B solution should handle multiple communication techniques.

The Internet is widely perceived as being much less expensive than a VAN, but this is not necessarily the case. VANs generally provide valuable services, such as TPA management, service-level administration, security, and store-and-forward capability. The Internet requires you to manage these elements yourself, which means the total costs are not always lower than a VAN.

Elements of an EDI solution

As well as obvious components of an EDI solution, such as application programs and systems, VANs, and trading partners, a complete and flexible solution should include the following important elements:

• Translators

  A universal problem in integration of applications is the conversion of shared data from one format to another. Common data fields—such as names, addresses, and numbers—often have different formats across disparate systems. The traditional approach to EDI implementation is to place the function that converts application data to the EDI standard directly into the business application. This approach is less effective because a separate program is required for each transaction as well as for each trading partner. In addition, it is difficult to keep up with new versions of standards because programs must be modified every time a trading partner adopts a newer standard or version of the standard.

  This approach has changed with the introduction of third-party translation software, also known as mappers. The translator is responsible for mapping application data to the specific EDI format and vice versa. This translation software is implemented in either a centralized engine or in an adapter. It must handle primary EDI standards as well as different and evolving versions of each standard.

• Batch enveloper/de-enveloper

  Typically, because VAN charges are based on each transaction sent, enterprises have been driven to find ways to reduce the number of transactions and to compress more information into each. Consequently, EDI messages are sent in large batches, which can then be grouped from, or split out to, several divisions or areas of an enterprise.

  Enveloping batch messages involves placing the EDI standard header and trailer around transactions in preparation for sending. When the envelope is complete, the package can then be sent to a trading partner through a VAN. Similarly, batch transactions must be de-enveloped when they are received from the VAN.

• Message router

  Once the EDI message is de-enveloped, it can be divided into function groups. Each function group may relate to a different division or area of the business. A mechanism is needed to sort messages destined for different groups and deliver them to the appropriate target applications. This means there is a requirement to fan in and fan out messages. Message transformation may also be required to get the message into the correct format for the end applications.

• Trading Partner Agreements (TPA)

  A TPA is an agreement related to the exchange of information in electronic transactions. The term includes a particular agreed-upon standard for business documents, as well as communications and business protocols, the service-level agreement, and more. TPAs can also be extended to include business events. For example, if an event occurs in one organization that might affect processes in a second organization, the TPA can specify that the second organization be alerted to the event.

15.2.2 WebSphere Data Interchange

IBM WebSphere Data Interchange for Multiplatforms fulfills the core role of EDI Broker in the IBM EDI solution, shown in Figure 15-2.

Figure 15-2: The IBM EDI solution

In the context of a typical enterprise integration architecture, WebSphere Data Interchange performs the specialist EDI validation, transformation, and exchange functions, and propagates the resulting transformed information either internally or externally. Internal propagation of transformed information may be via a message broker, a process broker, direct to the business applications, or any combination of those depending on the needs of the enterprise. External propagation of transformed information or receipt of information may be via a specialized dedicated VAN gateway, an Internet B2B gateway, directly to a trading partner, or any combination of those interfaces depending on the nature of the trading relationship between the enterprise and its trading partner.

See also 5.2.5, "WebSphere Data Interchange" on page 106 in Chapter 5, "Node types and Product descriptions".

15.2.3 The iSoft Peer-to-Peer Agent

iSoft's Peer-to-Peer Agent (P2PAgent) allows you to exchange documents between trading partners over the Internet in a secure and reliable way. The P2PAgent program can accept data from internal applications in a number of ways.

A traditional way of passing data to the agent is by delivering files to a given directory. The agent can filter through these files using a number of selection criteria to determine what to do with a given file. Also, when a file has been sent, you can choose to rename the file or to delete it. Simply preserving the file may result in the file being sent multiple times. The file system can also be used to store received files. You can configure the agent in such a way that the original file name (as it was named by the sender) is preserved, or that the file name is generated. This last option can avoid files being accidentally overwritten.

A more recent addition to the product is support for WebSphere MQ. The P2PAgent can retrieve messages from an inbox queue. It considers each message as a separate entity that should be sent to the correct destination trading partner. Also, when the agent receives documents from trading partners, it can store the received document as a single message in a queue. By default, such a message will be prefixed with an MQRFH2 header that contains meta-data information, such as the trading partner that had sent the document and the target trading partner ID. The MQRFH2 header is constructed in such a way that this information is also available to JMS clients in the form of message properties.

Further internal data delivery mechanisms include support for SMTP and HTTP. A received document or a received receipt can be delivered as an e-mail to a configured e-mail address via an SMTP server. HTTP communication for sending documents is used, for example, in a multi-machine setup of iSoft's P2PAgent. But if your internal applications can hand over EDI documents via HTTP, then they can hook into the P2PAgent directly.

Since the P2PAgent program is an AS2 client program, it is no surprise that the agent supports HTTP and HTTPS for sending and receiving documents via the Internet. The agent is also an AS1 client, which means that it needs to support SMTP for sending and receiving documents as an e-mail attachment.

Figure 15-3 summarizes the support for the different techniques to move data to and from the agent.

Figure 15-3: Inbound and outbound communication options

15.2.4 Integrating iSoft with WebSphere Data Interchange

Figure 15-4 shows the source application can pass outbound data to the EDI translation engine and WebSphere Data Interchange via a queue, using JMS (or the standard MQ API) with WebSphere MQ V5.3.1. Based on the setup of WebSphere Data Interchange, the translation engine then generates an EDI document in a queue, where it is picked up by the iSoft P2PAgent.

Figure 15-4: Integrating iSoft with WebSphere Data Interchange

For inbound communication, the iSoft P2PAgent drops the EDI document in a queue, where the translation engine retrieves it. The translation engine then produces a new document in an internal format and stores it as a message in a queue. The source application retrieves the inbound message using JMS.

---