13 Understanding Messaging Queue Adapters

This chapter contains the following topics:

13.1 JD Edwards EnterpriseOne and Messaging Queue Systems

JD Edwards EnterpriseOne supports both Microsoft and IBM message queueing systems. If your system can implement the messaging protocols and produce and consume XML documents using the formats discussed in this document, you can use a messaging queue adapter to send information to and receive information from JD Edwards EnterpriseOne. The messaging adapters for JD Edwards EnterpriseOne are Oracle products that can be licensed and installed independently from JD Edwards EnterpriseOne.

13.2 Data Exchange Between JD Edwards EnterpriseOne and a Messaging Queue Adapter

The JD Edwards EnterpriseOne messaging adapters, adapter for MSMQ and adapter for WebSphere MQ, enable you to connect any third-party application to JD Edwards EnterpriseOne for sending and receiving messages. The messaging adapter monitors an inbound queue for request and reply messages, performs the requested services, and places the results on outbound queues. The messaging adapter also monitors JD Edwards EnterpriseOne for specified activities and then publishes the results in an outbound message queue. All messages transported through the messaging system are in the form of XML documents. The required elements for formatting XML documents are discussed in the Using XML chapter.

See Formatting XML Documents.

13.2.1 Sending Information to JD Edwards EnterpriseOne

Third-party applications can send information to JD Edwards EnterpriseOne. These inbound transactions are called Z transactions. XML CallObject is used for processing Z transactions. The XML CallObject process flow, jde.ini file configuration, and elements specific to XML CallObject formatting are discussed in the XML CallObject chapter.

See XML CallObject.

13.2.1.1 Inbound Process Flow

A typical flow for processing Z transactions is:

  • The adapter picks up a message in XML format from the message queue.

  • The XML document is passed into the jdeXMLCallObject Application Programming Interface (API).

  • The session manager validates user and password.

  • The JD Edwards EnterpriseOne server processes the message by parsing the XML document.

  • Each requested business function is called separately or within requested transaction boundaries until all calls are processed.

  • Transactions are added to the JD Edwards EnterpriseOne database.

  • Output data and error messages are merged back into the XML document and a new response document is created.

  • The adapter places the response XML document in the queue.

    The response can be an error or success XML document.

See Understanding Z Transactions.

13.2.2 Retrieving Information from JD Edwards EnterpriseOne

Third-party applications can retrieve information from JD Edwards EnterpriseOne. These outbound transactions are called events. You can use a message queuing system (MSMQ or WebSphere MQ) to receive events. The messaging queue adapter provides a layer over existing functionality. JD Edwards EnterpriseOne supports these three kinds of events:

  • Real-time events

  • XAPI events

  • Z events

To receive guaranteed real-time and XAPI events, you must set up a real-time event queue. In addition, you must set up your events and configure your system to receive guaranteed events. The Using Guaranteed Events chapter discusses how the system processes events and provides information for configuring your system to receive guaranteed events. The Real-Time Events Reference guide provides information for creating real-time and XAPI events. You can create custom XML documents. To create custom XML documents, you can find or create a business function to accomplish the required task, or you can retrieve an XML template.

See XML Transaction.

See XML Format Examples (Events).

See Understanding Guaranteed Events.

See Creating MSMQ Queues.

See Creating WebSphere MQ Queues.

See "JD Edwards EnterpriseOne Application Real-Time Events Overview" in the JD Edwards EnterpriseOne Applications Business Interfaces Implementation Guide.

13.2.2.1 Z Event Processing

A typical flow for processing outbound Z events is:

  • An outbound message is triggered by an event; for example, entry of a sales order.

  • Subsystem processing starts processing the transaction and calls the outbound notification function.

  • The outbound notification function sends a net message, and the kernel picks up the message and calls the outbound notification function for the event type.

  • The messaging adapter reads the message and calls the appropriate API.

  • The adapter uses the record key from the JDENET message.

  • An XML response document is created.

  • The XML document is placed in the outbound queue.

13.2.2.2 Enabling Z Events Interface Table Processes

To send JD Edwards EnterpriseOne transactions to a messaging queue system such as IBM's WebSphere MQ or Microsoft's Message Queuing system, you can use JD Edwards EnterpriseOne Z event functionality. An interface table (also called Z table) is a working table where data is collected for sending to a third-party application or system.

13.2.2.3 Outbound Table Adapter Function

You use the OutboundZTableAdapter function to send a message from an outbound interface table to a messaging adapter queue. The function is invoked from the kernel dispatch function, which then sends the net message data that contains the parameters from the interface table subsystem Universal Batch Engine (UBE). This example shows the outbound table adapter function:

void OutboundZTableMessageAdapter(MsgData *pMsgData)

The parameters define the records and the transaction type to be used to cross-reference the tables that contain the data to populate the message that is sent to the message adapter queue. The messaging-specific OutboundZTableAdapter parses the net message data and calls the XML Interface Table Inquiry API to fetch the records from the interface table and format the results into an XML string.

You must set up JD Edwards EnterpriseOne to initiate the outbound interface table process. The format of the outbound interface table message has an XML based format.

13.2.2.4 Outbound Notification

The outbound notification function is called by the standard generic Outbound Subsystem batch process UBE and provides notification that records have been placed in the interface tables.

This function passes the key fields for a record in the JD Edwards EnterpriseOne Outbound Transaction interface tables to the outbound adapter. With these key fields, you can process the information from the database record into a message queue. This example shows an outbound notification message:

void MessageNotificationName(char *szUserID, char *szBatchNumber,
char *szTransactionNumber, double mnLineNumber,char *szTransactionType,
char *szDocumentType, double mnSequenceNumber )

This list provides the required input parameters:

  • User ID - 11 characters.

  • Batch Number - 16 characters.

  • Transaction Number - 23 characters.

  • Line Number - double.

  • Transaction Type - 9 characters.

  • Document Type - 3 characters.

  • Sequence Number - double.

This information is sent in a JDENET message:

  • Environment Name - use JD Edwards EnterpriseOne APIs to retrieve environment from the subsystem batch process.

  • User ID - key to interface table record.

  • Batch Number - key to interface table record.

  • Transaction Number - key to interface table record.

  • Line Number - key to interface table record.

  • Transaction Type - tie to an interface table.

  • Document Type - (optional).

  • Sequence Number - (optional).

The key information in the JDENET message packets is used by the outbound adapter to retrieve the record from the interface table. The transaction type enables the adapter to be generic and enables the adapter to process other transactions in the future. The transaction type maps to the F47002 table to determine the interface tables.

13.2.3 XML Interface Table Inquiry API

The XML interface table inquiry API (jdeRetrieveTransactionInfo) receives an XML string that includes the table record key and returns an XML string for outbound processing.

The messaging adapter calls the API. The API parses the XML string. Based on the transaction type, the API goes to the F47002 table to determine from which interface to fetch records. The F47002 table has a record for each table associated with the transaction type. Using JDB database APIs, XML Interface Table Inquiry then uses the index found in the XML string to fetch records from the interface table and returns the results in an XML string.

13.3 Management of the Messaging Queue Adapter Queues

The messaging adapters accept input and produce output by reading and writing to messaging queues. You create specific queues for the messaging adapter to use. You must specify the names of these queues in the jde.ini file on the JD Edwards EnterpriseOne server so that the messaging adapter can find them. The adapter configuration specifications are defined within the jde.ini initialization file that is read upon startup of the JD Edwards EnterpriseOne server. Typically, the system administrator configures the jde.ini file settings, but you might need to change the settings or verify that the settings are correct.

When you install a message adapter, you are asked to create several message queues. This table lists the queues and platforms that reside on the JD Edwards EnterpriseOne server and provides recommended names based on the platform:

Queue MSMQ Platform and Recommended Name IBM i Platform and Recommended Name NT Platform and Recommended Name UNIX Platform and Recommended Name
Inbound <computer name>\inbound INBOUND.Q INBOUND.Q INBOUND.Q
Outbound <computer name>\outbound OUTBOUND.Q.XMIT OUTBOUND.Q.XMIT OUTBOUND.Q.XMIT
Success Not applicable SUCCESS.Q SUCCESS.Q SUCCESS.Q
Error <computer name>\error ERROR.Q ERROR.Q ERROR.Q
Default Response Not applicable DEFRES.Q DEFRES.Q DEFRES.Q

Important:

Queue names for IBM Websphere Message Queue must be all upper case.

Note:

The queue names in the jde.ini file must correspond to the queue names on the server.

13.3.1 Inbound Queue

The inbound queue stores all inbound messages to JD Edwards EnterpriseOne. After the message is processed, it is removed from the queue. The install suggests calling the queue INBOUND.Q. You must specify the queue name in the QInboundName setting in the jde.ini file.

13.3.2 Outbound Queue

The outbound queue stores the outbound messages from JD Edwards EnterpriseOne. The install suggests calling the queue OUTBOUND.Q. You must specify the queue name in the QOutboundName setting in the jde.ini file.

13.3.3 Success Queue

The success queue stores successfully processed messages in JD Edwards EnterpriseOne. These messages contain return code information for the business function calls and default or calculated parameter information. The messages remain in the queue until you remove them. The install suggests calling the queue SUCCESS.Q. You must specify the queue name in the XML document within the returnParms tag. If you do not specify a success destination queue within the XML document and you leave the QErrorName blank in the jde.ini, the message is not written to any queue.

13.3.4 Error Queue

The error queue stores processed messages that are in error in JD Edwards EnterpriseOne. These messages contain return code information for the business function calls, default and calculated parameter information, and error information. These messages remain in the queue until you remove them. The install suggests calling the queue ERROR.Q. You must specify the queue name in the XML document within the returnParms tag. If you do not specify a failure destination queue within the XML document and you leave the QErrorName blank in the jde.ini, the message is not written to any queue.

13.3.5 Default Response Queue

The default response queue stores the processed messages into JD Edwards EnterpriseOne. These messages may be error or successfully processed. The messages contain return code information for the business function calls, default or calculated parameter information, and possibly error information. These messages remain in the queue until you remove them. The install suggests calling the queue DEFRES.Q. You must specify the queue name in the QErrorName setting in the jde.ini file. If you do not specify a success or failure destination queue in the XML document, the queue you set in the jde.ini file is used as the default queue for the message. If the QErrorName setting is also blank, the message is not written to any queue.

Note:

The commands for creating these queues along with a discussion of other queues are provided in the applicable configuration document.

13.4 Configuration of the jde.ini File to Support Messaging Queue Adapters

The JD Edwards EnterpriseOne messaging adapters use settings in the MQSI section (for IBM) or the MSMQ section (for Microsoft) of the jde.ini file to start, to monitor queues, and to send error messages. The names of queues are case-sensitive. The jde.ini file can be modified for messaging queues and for JD Edwards EnterpriseOne UBE queues. Refer to the appropriate Messaging Adapter Installation documentation for more information about setting up queues and the jde.ini file settings. The queue names you use must correspond with the queue names you have set up on the server.