This section describes the various application-specific metaobjects needed
for event and request processing.
Message family-specific metaobjects provide information for the GETNXT
call.
- Use the message family for the first attribute. Set the message
family name as the default value.
- Use the message family-stored procedure name for the second
attribute. Set the GETNXT-stored procedure name as the default
value.
- Create one attribute for each successive message family-specific argument,
with the order of these fields matching the order of their corresponding
statements in the GETNXT call.
- Set the key property to TRUE for those attributes that need to
appear in the ID field of the Retek Message Header; the name of the
attribute must be the same as the name of the ID field.
- To identify attributes that represent routing information, add the string
"routing=TRUE" to the application-specific information property of the
attribute; the name of the attribute must be the same as the name of the
routing field.
- To identify attributes representing input parameters, add the string
in to the application-specific information property of the
attribute; set the value that needs to be passed in the GETNXT call for
the corresponding parameter as the default attribute value.
- Set the default value of pollQuantity to the maximum number of messages to
be retrieved from this message family staging table during each poll
cycle.
Example: The following table illustrates the content of a
sample metaobject for the ORDERPHS message family, where fields 4-6 are extra
message family-specific attributes and order_no is the ID field.

For more information on the GETNXT call, see "Creating business objects".
CONSUME metaobjects provide application-specific information for the
CONSUME-stored procedure call for request processing.
- Build the metaobject by defining one attribute for each extra input
parameter in the CONSUME call. The order of attributes must match the
order of the corresponding parameters in the CONSUME call. The names of
these attributes must correspond to routing field names in the incoming
message header in order to ensure that their values are substituted with the
corresponding routing field values in the call.
- Provide a default value for each attribute. This will be used in
the CONSUME call in cases where the Retek Message Header does not contain the
appropriate routing field.
The following is a sample for RDM's CONSUME metaobject. It
shows one supported attribute (for facilityType).

For more information on the CONSUME call, see "Creating business objects".
Thread metaobjects map threads to the message families they service.
Each thread has its own set of metaobjects. The application-specific
information at the business object level contains the list of message family
metaobject names that the thread handles.
Example:
A thread that services the Item, PurchaseOrder, and Vendor message families
has the following metaobjects for the message families:
ItemMO,PurchaseOrderMO,VendorMO
The thread metaobject, for example, Thread1MO, will contain the following
string in its application specific information:
ItemMO,PurchaseOrderMO,VendorMO
The key metaobject allows you to configure the ID attribute as the primary
key for Retek generic business objects to provide more control over the
contents of this attribute and ultimately over the manner the events are
sequenced inside ICS.
Example: The following illustrates the metaobject
definition.

Selecting an attribute as a key in this definition will cause the value of
the corresponding attribute in the Retek Message Header to be added to the
primary key content, as follows:
To configure the connector to use these settings, you need to set the
connector KeyMO property to the name of the metaobject definition.
Results: The effect of these selections on the event
processing sequence are the following:
- If you select only the family attribute, all messages within the same
message family will be processed in the order they have been published.
- If you select the family and type attributes, all messages with the same
message type within the same message family will be processed in the order
they have been published.
- If you select all three attributes, all messages corresponding to the same
entity within the same message family will be processed in the order they have
been published.
ICS maintains the sequencing of business objects with the same business
object type and key values. In Retek business object types, however,
different payload structures are used for the same entity type for Create and
Modify operations than are used for the Delete message type.
For example, for a purchase order the payload type is:
- PODesc for Create and Modify, and
- PORef for Delete
That causes ICS to look at a Create and Delete business object for the same
purchase order as belonging to different entities.
Recommendations: To overcome this problem:
- When using ICS as the broker, you should provide:
- A generic business object that encapsulates data from both application
business object types referring to the same entity type
- Mapping between the application-specific business objects and the generic
business object
- When using WebSphere MQ Integrator Broker as a broker, the only way to
maintain event sequencing on request processing is to handle all request calls
in a single thread.
