Advanced Queuing

Advanced queuing allows you to send messages between Order Management System and other applications using database-integrated message queuing.

Advanced queuing is made up of the following components:

Queuing Database	The Oracle database used for queue processing.
Queues	An area where messages are stored so that they can be processed in sequential order (first in, first out).
Queue Table	Queues are stored in queue tables in the database.
Message	The actual data, such as an XML message, that is inserted into and retrieved from a queue. The message contains: • control information (metadata) to define message properties used to manage the message. • payload, or the actual data, in the message.
Message log	The Message log tracks XML and transactional messages generated or received by Order Management System.

In this chapter:

• Advanced Queuing Process

- Outbound Process Flow

- Inbound Process Flow

• Advanced Queuing Setup

- JMS Server in WebLogic

- Queuing Database and Queues Configuration

- JMS RESTful Web Service

For more information: See:

• Generic Web Services for more information on the web services available for Order Management System.

• Working with Web Service Authentication (WWSA) for more information on how to define which Order Management System web service endpoints require authentication and the valid web service authentication users for each web service

• Logs for more information on the Order Management System application logs.

• Working with Integration Layer Processes (IJCT) for more information on the processes that transmit data between Order Management System and an external system.

Advanced Queuing Process

Outbound Process Flow

1. A user or a process in Order Management System calls an outbound integration layer process to send information to an external system.

2. If the Communication type setting for the outbound integration layer process (IJCT) is set to Message Queue and the status of the integration layer process is active, the process looks at the queue defined for the process. For an outbound process, the queue indicates:

- the name of the outbound queue to which the integration layer process sends the message for transmission to the external system; this must be a valid queue in the database used for queue processing.

- the name of the XML message generated and sent to the external system.

3. The system sends the message to the outbound queue defined for the integration layer process.

4. An external system uses the JMS RESTful web service to retrieve the message from the queue in order to process the message; see the JMS RESTful Web Service for the correct format of the URL for this web service.

Note: The web service authenticator, JMSQueue, in Work with Web Service Authentication (WWSA), defines the user for basic web service authentication for the JMS RESTful web service when it reads from a queue in the queuing database.

Inbound Process Flow

1. An external system uses an Order Management System web service to send a message to a queue in the database used for queue processing. Note: The target in the message must match the Inbound job name defined on the Integration Layer Process Queue screen in Work with Integration Layer Processes (IJCT). See Generic Web Services for more information on the web services available for Order Management System.

2. If the Communication type setting for an inbound integration layer process is set to Message Queue and the status of the integration layer process is active, the process monitors the queue defined for the process for new messages. For an inbound process, the queue indicates:

- the name of the inbound queue that the integration layer process monitors for new messages to process from an external system; this must be a valid queue in the database used for queue processing.

- the name of the job that processes the message from the inbound queue.

3. If the integration layer process finds a new message to process in the queue, the process picks up the message and processes it using existing functionality.

Note: The web service authenticator, JMSQueue, in Work with Web Service Authentication (WWSA), defines the user for basic web service authentication for the JMS RESTful web service when it reads from a queue in the queuing database.

For more information: See Integration Layer Processes and Web Services for more information on the integration layer processes that use a message queue.

Advanced Queuing Setup

Before you can begin using advanced queuing, you must complete the necessary setup.

• JMS Server in WebLogic

• Queuing Database and Queues Configuration

• JMS RESTful Web Service

JMS Server in WebLogic

1.

During installation of the application, the JMS server for Order Management System was created and configured in WebLogic. In addition, the following JDBC data sources in WebLogic were created and configured in order to connect to the Order Management System database and advanced queuing database: • aqJMSDS • CWDirectCPDS • SerenadeSeamDataSource

2.

In Work with Admin Properties (CPRP), the following properties were set during installation based on the JMS server defined in WebLogic: JMS_QUEUE_FACTORY: Contains the name of the Java Naming and Directory Interface (JNDI) used for queuing; this is the Local JNDI Name as defined in WebLogic. The delivered setting is AqJmsConnectionFactory. Use the following steps to verify the Local JNDI Name in WebLogic: • Log in to the WebLogic Server Administration Console. • On the home page, locate the Services pane and click JMS Modules to advance to the Summary of JMS Modules page. • On the Summary of JMS Modules page, click the name of the JMS module used for Order Management System to advance to the Settings for JMS Module page. • On the Settings for JMS Module page, click the JMS resource used for Order Management System to advance to the Settings for JMS Resource page. • On the Settings for JMS Resource page, select the Connection Factories tab to display the foreign connection factory for Order Management System. The system defaults the Local JNDI Name defined for the connection factory to the JMS_QUEUE_FACTORY property. JMS_SCHEMA: Contains the schema name where all queues are located in the queuing database; this is defined in the properties for the aqJMSDS JDBC data source in WebLogic. The delivered setting is ORDER_MANAGEMENT. Use the following steps to verify the schema name in WebLogic: • Log in to the WebLogic Server Administration Console. • On the home page, locate the Services pane and click Data Sources to advance to the Summary of JDBC Data Sources page. • On the Summary of JDBC Data Sources page, click the aqJMSDS data source to advance to the Settings for aqJMSDS page. • On the Settings for aqJMSDS page, select the Connection Pool tab to display the JDBC connections for the aqJMSDS data source. The system defaults the Properties defined for the connection pool to the JMS_SCHEMA property.

Queuing Database and Queues Configuration

1.	Typical advanced queuing configuration uses the Order Management System database as the queuing database. Make sure the database has open access to use for queue processing.
2.	Queues are delivered for the processes in Working with Integration Layer Processes (IJCT); see Delivered Queues. Use the following steps if you wish to create another queue for a job. For each queue you wish to create in the database: • Use the following SQL command to create a queue table: EXEC DBMS_AQADM.CREATE_QUEUE_TABLE (queue_table => 'process_table', queue_payload_type => 'SYS.AQ$_JMS_TEXT_MESSAGE'); where process_table is the name of the queue table you wish to create. • Use the following SQL command to create a queue: EXEC DBMS_AQADM.CREATE_QUEUE (queue_name => 'process', queue_table => 'process_table'); where process is the name of the queue you wish to create and process_table is the name of the corresponding queue table. Note: the queue name is case-sensitive. • Use the following SQL command to start the queue: EXEC DBMS_AQADM.START_QUEUE (queue_name => 'process'); where process is the name of the queue you wish to start. The queue must be started in order to enable the queue for processing. Recommended queue naming convention: To easily identify the purpose of a queue, use the following naming convention when creating a queue: PROCESS_DIRECTION where: • PROCESS = the name of the Order Management System process that sends or receives the message. • DIRECTION = the direction of the message. - IN = the message is inbound to Order Management System. - OUT = the message is outbound from Order Management System. Example: • CUST_SRCH_OUT = The queue receives messages from the CUST_SRCH process in Work with Integration Layer Processes (IJCT) in Order Management System. • CUST_SRCH_IN = The queue sends messages to the CUST_SRCH process in Work with Integration Layer Processes (IJCT) in Order Management System.
3.	Queue information is delivered for the processes in Working with Integration Layer Processes (IJCT). Verify the following: • On the Integration Layer Process screen, verify Message Queue defaults for the Communication type. • On the Work with Integration Layer Process Queues screen verify the queues that run for the process. The Inbound queue and/or Outbound queue is the name of the associated queue in the database used for queue processing.

Delivered Queues

The following queues are delivered with the application.

IJCT Process	Inbound queue	Outbound queue
CCAUTH_BTH	CCAUTH_BTH_IN	CCAUTH_BTH_OUT
CCAUTH_ONL	CCAUTH_ONL_IN	CCAUTH_ONL_OUT
CUSTOMR_IN	CUSTOMR_IN_IN	CUSTOMR_IN_OUT
CUST_HIST	CUST_HIST_IN	CUST_HIST_OUT
CUST_OUT		CUST_OUT_OUT
CUST_SRCH	CUST_SRCH_IN	CUST_SRCH_OUT
DEPOSITS	DEPOSITS_IN	DEPOSITS_OUT
EMAIL	EMAIL_IN
EMAIL_OUT		EMAIL_OUT_OUT
INVOIC_OUT		INVOIC_OUT_OUT
INVTRAN_IN	INVTRAN_IN_IN
INV_DOWNLD_OUT		INV_DOWNLD_OUT_OUT
INV_INQURY	INV_INQURY_IN	INV_INQURY_OUT
ITEM_OUT		ITEM_OUT_OUT
ORDER_IN	ORDER_IN_IN	ORDER_IN_OUT
PERDEP	PERDEP_IN	PERDEP_OUT
PICK_OUT		PICK_OUT_OUT
PMD_ONLINE	PMD_ONLINE_IN	PMD_ONLINE_OUT
PMT_BTCH	PMT_BTCH_IN	PMT_BTCH_OUT
PMT_ONL	PMT_ONL_IN	PMT_ONL_OUT
PO_OUT		PO_OUT_OUT
RETURN_IN	RETURN_IN_IN
RETURN_OUT		'RETURN_OUT_OUT
SVC_AUTH	SVC_AUTH_IN	SVC_AUTH_OUT
SVC_BALANC	SVC_BALANC_IN	SVC_BALANC_OUT
SVC_DEP	SVC_DEP_IN	SVC_DEP_OUT
SVC_OUT		SVC_OUT_OUT
SVC_REVRSL	SVC_REVRSL_IN	SVC_REVRSL_OUT
VENDOR_OUT		VENDOR_OUT_OUT
WORKFLOW		WORKFLOW_OUT

Viewing Messages on a Queue in the Database

Because messages are placed in normal rows in a database table, if you have access to the queuing database, you can query the table using standard SQL.

Use the following SQL command to view existing messages on a queue:

select msgid, enq_time, enq_uid, qt.user_data.text_vc || qt.user_data.text_lob from process_table qt where q_name = 'process'

 

where process_table is the name of the queue table and process is the name of the queue. Note: the queue name is case-sensitive.

JMS RESTful Web Service

Advanced queuing uses the Java Messaging Service (JMS) as its method to transmit information from the queuing database to an external system. The JMS RESTful web service is used to read from a queue in the queuing database.

The individual URLs for the web service use the following format: http(s)://server:port/JMS-REST/jms/jmsREST/getFromQueue, where server:port identifies the server where the JMS RESTful web service is located.

In the payload, or message data, include the name of the queue to be read as a JSON string; for example: {"queueName":"process"}, where process is the name of the queue.

Basic Authentication

For security, the RESTful web service endpoint requires basic authentication. In the basic authentication header, you must pass the user ID and password that has access to the queue.

You can define web service authentication using the Work with Web Service Authentication (WWSA) menu option. The web service authenticator, JMSQueue, in Work with Web Service Authentication (WWSA), defines the user for basic web service authentication for the JMS RESTful web service when it reads from a queue in the queuing database.

• If the message passes basic authentication, the message will be returned as a JSON string: {"status": "OK", "message": "data"}, where data is the message data.

• If there are no more messages to read from the queue, a status of EOF (End Of File) will be returned: {"status": "EOF"}.

• If there is a failure, the status will return the error condition; for example: {"status": "JMS-232: An invalid user/password was specified for the JMS connection"}.