Overview

By default, the Transportation and Global Trade Management Cloud application server workload is managed by a set of in-memory event queues; with a configurable number of threads available to process each queue. The Transportation and Global Trade Management Cloud Data Queue infrastructure was introduced to permit a more configurable fine-grained control of various aspects of this internal workload. The Data Queues are database resident queues where a configurable number of "poller" threads retrieve a configurable number of events at a configurable interval and pass them to an "executor" to be processed.

Note: Although the entity names used are similar, Transportation and Global Trade Management Cloud Data Queues do not use Oracle Advanced Queue (OAQ) schema objects for processing data queue events. Oracle Advanced Queueing is not supported and will be removed in an upcoming release.

The internal processes for Inbound and Outbound Integration can now be configured to use this infrastructure.

Note: See Data Queue Manager in the Transportation and Global Trade Management Cloud online Help for coverage on the User Interface used to configure each data queue.

The following figure shows the application server processing of an inbound Shipment Status XML without the use of data queues. The XML message will arrive via one of the supported protocols: HTTP or SOAP Web Service.

1. The XML is stored in the Transmission table with a new unique Transmission number.
2. A New XML topic containing the Transmission number is placed on the in-memory event queue.
3. A listener thread which has subscribed to New XML topics removes the event and passes it to the New XML Workflow to process.
4. Workflow processes the content of the XML, which in this case results in a new status being assigned to a shipment.

Imagine a Transportation and Global Trade Management Cloud implementation scenario that has an inbound interface with a carrier status application where shipment statuses are sent in one batch of 10000 to Transportation and Global Trade Management Cloud. Without Data Queues, the application server in-memory event queues would contain all 10000 Shipment Status transactions in one backlog, therefore competing with all other internal application server processes for resources and process time.

The following figure shows the application server processing where data queues were configured for inbound XML messages. The Inbound Data Queue process can instead be configured to stage the initial 10000 transactions and process in batches of 1000 every 5 minutes.

1. The XML is stored in the Transmission table and the associated Transmission number is stored in a Data Queue Event.
2. At some point in time within the configured interval, a Poller thread will retrieve up to 1000 data queue events and pass individually to the Executor to be processed.
3. The Executor publishes a New XML topic which, from then on, will be processed as with normal in-memory event queues.

The application server processing for Outbound XML messages also uses in-memory event queues to manage workload; one for the building of the XML and another for the physical transport of the message. The use of Data Queues for outbound message works essentially identical to the inbound scenario described above i.e. instead of publishing new build or transport topics on in-memory event queues, data queue events are stored in outbound data queues. The same arrangement of Poller and Executor then publishes the topic to the next step in the process.