Message structures that come in over a TCP/IP connection may require a certain amount of pre-processing before they can be sent on to a data handler to be turned into WBI business objects.
Take, for example, the HL7 health care data standard. The details of network transmission error detection and correction are handled by the lower levels of most modern network protocols, so the main standard does not include specifications covering these. However many mini and mainframe computer systems, which may be part of the HL7 data flow, operate in communication environments that do not provide sufficient lower layer functionality. In these cases HL7 offers several alternate lower layer protocols, such as the Hybrid Low Layer Protocol and the Minimal Low Layer Protocol, to suit different environments. Messages sent using these protocols must be pre-processed to remove this protocol related information before the main body of data can be extracted.
The PIMO infrastructure in the TCP/IP connector is designed to do exactly this sort of pre-processing. The Production Instruction Meta Object Framework is a highly flexible, general purpose abstraction for effecting business logic processing at the connector level. The PIMO infrastructure is capable of a wide-range of operations, and is used, in differing forms, in other adapters. In the TCP/IP connector, it has been customized specifically to take care of these pre- and post-processing issues.
The PIMO Framework uses a set of specially designed meta objects to do its work. At the top of the adapter's PIMO hierarchy is the BIA_MO_Tcpip_MapSubscriptions object. The graphic BIA_MO_Tcpip_MapSubscriptions shows what this object looks like in the Business Object Designer. This object designates both the inbound (event pre-processing) and outbound (service call request post-processing) paths that data will take. It contains two objects, the BIA_MO_Tcpip_MapSubscriptions_In and the equivalent Out object, each of which contains a reference to an appropriate PIMO map object. In the case of HL7 object above, the appropriate In PIMO map object might be the BIA_Map_InputMessage_to_LLPMessageList. You can look at BIA_Map_InputMessage_to_LLPMessageList to see what this object looks like in the Business Object Designer.
This PIMO map object serves as the core PIMO object. PIMO objects consist of three basic attributes: Port, Declaration, and Action.
Each Port is made up in turn of two attributes: the IPort and the OPort. These indicate the expected type of the source object (for example, an BIA_InputMessage object, which is the internal wrapper object for event processing) and the destination object (a BIA_LLPMessage List object). The example on page "BIA_MO_Tcpip_MapSubscriptions" shows two input maps chained together, the first separating multiple messages into single messages, and the second stripping away the LLP information from the actual HL7 message. By separating the process into multiple steps, chaining maps can produce more complex types of processing. If chained maps are used, it is essential that the OPort type of step 1 be exactly the same as the IPort type of step 2, and so forth.
The declaration attribute is optional. It contains names for temporary variables to be used during processing. In the example the declaration object contains one such name, "contentText".
Finally, PIMO maps contain Action attributes. Each Action attribute
consists of one or more defined Actions. The Application Specific
Information or ASI for each defined action provides the information the PIMO
needs to invoke the Message Handler, a native Java class designed to perform
the actual data transform that is required. The example ASI from page "BIA_Map_InputMessage_to_LLPMessageList" serves to illustrate the necessary information. It is
as follows:
type=nativeStatic; class=com.im.adapters.tcpip.messagehandlers.LLPMessagingProtocoHandler; method=parseInputMessageToLLPMessages; target=contentText;IPort;Oport |
The ASI contains the following information:
The method at the heart of this set, parseInputMessageToLLPMessages knows how to separate out the LLP specific wrapper data, and then return a list which stores the individual parts of the LLPMessage (the header, the message itself, and the tailer) so that the message (as a BIA_ContentBO) can be handed off to the data handler. A set of these HL7 Message Handlers is included in the TCP/IP installation, but others can be developed as the need arises.
Once again, service call request processing would follow the same stages except in reverse: the PIMO Framework would be used to wrap messages in their protocol specific data before sending them to be forwarded to the remote host.