The connector for TPI enables an integration broker to exchange business objects with TPI Server versions 3.0.3 and higher.
The connector implements business object handling, event polling, and event notification. The application-specific component of the connector generates business objects that it sends to the integration broker; it also responds to business object requests from the integration broker. It generates logging and tracing messages that it writes to a file or the connector console, or sends to the integration broker.
The TPI connector uses the following components:
The TPI connector runs in the same process space, using the same Java Virtual Machine, as the TPI Server.
The connector communicates with the TPI Server by using the DocumentListener interface and the InterchangeEventListener interface. It processes inbound TPI documents to create business objects that it passes to the integration broker. It processes request business objects to create document streams that it passes to the TPI Server. Figure 1 illustrates the TPI connector architecture.
Figure 1. TPI connector architecture
In addition to loading the connector configuration properties, the init() method performs the following tasks at startup:
The terminate() method shuts down the connector and the TPI Server.
During event notification, the TPI connector uses the file system to persist meta-data for unprocessed events. It also archives processed events, labeling them with their status.
The connector for TPI uses a callback method, documentArriving(), for event notification. This method is provided through the DocumentListener interface. When the TPI Server receives a document from a trading partner, it calls the documentArriving() method to notify the connector of the inbound document. The notification contains the meta-data necessary for the connector to retrieve and process the document. This includes the following information:
This constitutes the event meta-data. The connector places the event meta-data in an event list in memory, and writes a copy of the event to a file in the event directory with the .event extension for backup and recovery.
Each time the connector polls the event list, it retrieves the oldest event, based on time of arrival to the connector. The connector retrieves the document from the In directory, and uses the trading partner configuration file to determine the document's MIME type.
The connector passes the MIME type to the DataHandler class to create an instance of the appropriate data handler. The connector then calls the data handler to convert the document to a business object. Each data handler uses different criteria to determine the business object name. After the business object is generated, the connector checks for a subscription to the business object. If a subscription exists, the connector passes the object to the subscribing business process. (For subscription information specific to your integration broker, refer to the broker's implementation guide.)
By default, the TPI connector processes only one event at a time. However, it is capable of processing multiple incoming events simultaneously in order to improve performance. In this situation, each event is allocated to its own thread, and the threads execute simultaneously.
Use connector-specific properties to enable parallel processing; see Connector-specific properties for more information.
When a connector retrieves an event from the event list, it changes the extension on the corresponding event file to .inprogress until processing is complete, at which time the event file is moved to the archive directory. When restarting after a connector failure, the connector processes all inprogress events according to the EventRecovery property setting. If EventRecovery is set to Reprocess the connector reads the event directory and restores all inprogress events to the event list. Optionally, the connector can be configured to ignore or fail inprogress events.
The connector maintains an archive directory, where it stores processed events. After an event is processed, the event file is renamed with one of the following extensions:
All request business objects processed by the TPI connector must contain a configuration child object. This object contains information required by the connector and the TPI Server to process the object. This includes the sender ID, receiver ID, and document type.
When the connector receives a business object, the doVerbFor() method calls a data handler to convert the business object to an appropriately formatted stream. The data handler is called based on the MIME type listed in the trading partner configuration file for the ReceiverID and DocumentType values. TPI parses EDI and XML documents for SenderID, ReceiverID and CycloneID. The data handler outputs a document stream which is written to a file in the document out directory. The connector passes a document object, which references the file, to the TPI Server by calling the sendDocument() method in the TPI Server API. The sendDocument() method returns the unique document ID generated by the TPI Server.
If the WaitForMDN connector property is set to true, the connector then waits for the TPI Server to indicate that it has received an MDN from the trading partner. Optionally, the WaitForMDN property can be overridden on a per business object basis by populating the WaitForMDN attribute in the child meta-object. Once an MDN is received, the doVerbFor() method returns a status code (success or error) to the integration broker. If the WaitForMDN property is set to false, the connector does not wait for the TPI Server to return an MDN.
The connector has been internationalized so that it can support double-byte character sets, and deliver message text in the specified language. When the connector transfers data from a location that uses one character code set to a location that uses a different code set, it performs character conversion to preserve the meaning of the data.
The Java runtime environment within the Java Virtual Machine (JVM) represents data in the Unicode character code set. Unicode contains encodings for characters in most known character code sets (both single-byte and multibyte). Most components in the WebSphere business integration system are written in Java. Therefore, when data is transferred between most WebSphere business integration system components, there is no need for character conversion.
To log error and informational messages in the appropriate language and for the appropriate country or territory, configure the Locale standard configuration property for your environment. For more information on these properties, see Appendix A, Standard configuration properties for connectors.