PIMO framework meta-objects

This section describes the PIMO meta-objects.

BIA_MO_Tcpip_MapSubscriptions

Processing in the PIMO is based on a series of transformations ordered by a set of maps. At the top of the map hierarchy is the BIA_MO_Tcpip_MapSubscriptions object.

Figure 26 is an example of what the BIA_MO_Tcpip_MapSubscriptions object looks like in the Business Object Designer.

Figure 26. BIA_MO_Tcpip_MapSubscriptions in the Business Object Designer
A screen shot of BIA_MO_Tcpip_MapSubscriptions.

The pertinent attributes of the example object are as follows:

MO Level Attributes Description
Inbound The set of maps used by PIMO in event mode processing. In Figure 26, three maps are used.
+BIA_InputMessage_CheckComplete Child attribute, which contains the map BIA_Map_InputMessage
_to_InputMessage. See Figure 29 for information about the requirements for BIA_InputMessage_CheckComplete.
+BIA_InputMessage Child attribute, which contains the map BIA_Map_InputMessage
_to_LLPMessageList, used to remove LLP headers and trailers from the main HL7 data. See Figure 28 for information about the requirements for BIA_InputMessage.
+BIA_ApplicationMessage Child attribute, which contains a map BIA_Map_InputMessage
_to_FinalMessage. See Figure 30 for information about the requirements for BIA_ApplicationMessage.
Outbound The set of maps used by PIMO in service call request processing. In Figure 26, two maps are used.
+BIA_ApplicationMessage Child attribute, which contains the map BIA_Map_ApplicationMessage
_to_InputMessage. See Figure 31 for information about the requirements for BIA_ApplicationMessage.
+BIA_ResponseMessage Child attribute, which contains the map BIA_Map_ResponseMessage_to_Final Message. See Figure 32 for information about the requirements for BIA_ResponseMessage.

BIA_Map_InputMessage_to_LLPMessageList

This section describes the attributes and ASI that are used in PIMO maps. A specific map instance--BIA_Map_InputMessage_to_LLPMessageList--is used as an example.

Figure 27. BIA_Map_InputMessage_to_LLPMessageList in the Business Object Designer
A screen shot of BIA_Map_InputMessage_to_LLPMessageList.

The pertinent attributes of the object are as follows:

Map BO Level Attributes Description
Port Each PIMO map has two ports: the IPort and the OPort, defined in the example by the BIA_InputMessage_to
_LLPMessageList_Port. These indicate the expected type of the source object (in the example, a BIA_InputMessage) and the destination object (in the example, a BIA_LLPMessageList).
Declaration A PIMO map may include declaration objects containing names for temporary variables to be used during processing. In the example, the declaration object (a BIA_Map_InputMessage_to
_LLPMessageList_Declaration) contains one such name, "contentText"
Action Each PIMO map has at least one action object (here a BIA_Map_InputMessage_to
_LLPMessageList) that stores information pointing to the actual class and method that does the processing

The ASI contains the following information:

type=nativeStatic; class=com.ibm.adapters.tcpip.messagehandlers.LLPMessagingProtocoHandler; method=parseInputMessageToLLPMessages; target=contentText;IPort;Oport

type =
In this release, this value is always nativeStatic. The present PIMO structure only supports public static methods.
class =
This value is the fully qualified name of the Java class that contains the method. In the example this is com.ibm.adapters.tcpip.messagehandlers.LLPMessagingProtocolHandler.
method =
This value is the method to be called. The example is parseInputMessageToLLPMessages.
target =
This value is where returned data should be stored. In the example, the data is to be stored in the variable contentText created in the declaration attribute.
var1, var2 . . . varx
An open list of parameters to be passed into the method. The order and number of variables on this list must exactly match the order and number of parameters that the method expects. In the example, var1 is the IPort business object and var2 is the OPort business object from the Port attribute.

Map usage rules

This section describes rules you should follow when using maps.

General rules

The following rules apply to all maps:

Inbound rules

The following rules apply to the Inbound attribute:

Outbound rules

The following rules apply to the Outbound attribute:

Bypassing all maps

In asynchronous request processing, you can bypass all maps by setting up BIA_MO_Tcpip_MapSubscriptions so that the Inbound and Outbound attributes are empty (without any children).

Note: For synchronous request processing, the map BIA_Map_ResponseMessage_to_FinalMessage must be plugged in, so you cannot bypass maps in synchronous request processing.

Copyright IBM Corporation 1997, 2005. All Rights Reserved.