What are the Inbound JMS message header format requirements?

Body

When directly putting Maximo Integration Framework JMS messages into an inbound queue, the message header format must contain the custom properties described below to ensure that Maximo can processes these messages.  This is accomplished by constructing an RFH2 header that contains the required custom properties and their values, corresponding to the properties defined with the Maximo external system.

The message properties contain the following properties from the JMS provider and the integration framework, which are set to the string data type.

Header Properties:
JMSMessageID A message ID that is generated by the system.
JMSRedelivered Identifies whether the message was reprocessed.

Custom Message Properties:
MEAMessageID - The message ID that is generated by the integration framework and is unique for each message.
destjndiname - The name of the queue or topic that the message is written to.
INTERFACE - The name of the publish channel (outbound queue) and the enterprise service (inbound queue).
destination - The external system name for outbound messages.
SENDER - The external system name for the inbound messages.

Messages must be created in byte format unless you are running Tpae v7.5.0.1 or later.  With the latest v7.5.0.1 IFIX bundle, you can choose to use text format for your messages.  However, the RFH2 message header is still required in byte format.

The properties that must match those defined in Maximo are destjndiname, SENDER and INTERFACE.

An example of what those properties might look like, depending on your external system and queue jndi names are shown in the following screen shots.
 

The jndi name of the queue this message will be sent to is jms/maximo/int/queues/sqin.  If this jndi name does not match the actual queue jndi name being used to send messages inbound, the message will still process, however if the message fails due to a data related error, the message reprocessing application will not show that any messages exist for this error, which leads to the inability to reprocess messages using the Message Reprocessing application.  In this case, if no matching queue name is found, no messages will be written to the maxinterror table, or, if using a file system for error management, the message is not written successfully to the error folder in the file system.  In this case, the message sits in the original queue and will be reprocessed automatically but there will be no way to correct the data, so you are left with having to delete the message from the queue.

The SENDER property refers to the external system name from which messages are being received.  In this example, the external system name is EXTSYS1.

If the name of the external system does not match an existing and enabled external system, an error is received and the transaction cannot be processed successfully.

The INTERFACE property must also match an existing an enabled enterprise service name, and must be enabled on the same external system as that specified in the SENDER property.  In the example above, the enterprise service name is MYJPASSETLINKInterface.

Remember that the property names must be created in the same case as specified in the examples above, and that the property values for each are also specified in the case in which they have been defined.  If all of these properties are present and specified correctly, the message can be processed successfully from the inbound queue, and can be reprocessed from the Message Reprocessing application if you need to correct the data within the messages.