A Queue Management

The Queue Management feature in the pre-built integration requires:

• An event to produce filtered payload to a file destination to a JMS destination

• That the payload be defined using a standard XSD

• That the files or JMS messages produced by events be sequenced in the order in which the objects are released

Note:

These requirements are leveraged using Agile Content Service (ACS). ACS can to produce payload to a File or JMS destination. The payload is based on filters configured for the ACS Event defined by Agile PLM provided AXML schema definition. In addition, the ACS transmits the messages in the order in which the ATOs are released.

• A queue to manage the order of messages

• A queue monitoring the user interface to enable reordering and resubmitting of unprocessed messages

• A queue that manages the payloads based on the business process for which the message is produced by the event

• A queue controlling mechanism to:

  • Trigger the business flow based on the business process of the message

  • Process the messages sequentially depending on the order specified in the message (the highest order message is picked first for processing).

    A message is not picked for processing unless the processing of the previous message is complete.

    You can reorder the order of the messages not picked for processing.

For more information about the features and functionalities of Queue Manager, and how to use it, see Agile PLM Integration Pack for Oracle E-Business Suite, Design to Release - User Guide. You can find this document at http://www.oracle.com/technology/documentation/agile.html.

A.1 Queue Management Solution

The Queue Management Solution has the following components:

• Queue DB (database): Persists the data related to a queue messages

• Queue Controller: Polls for new event payloads and adds them to the queue DB. The highest priority message for each business process is picked and processed sequentially to trigger its business flow

• Queue Monitoring: The user interface that monitors the queue message status supports reordering of the priorities of the queue messages. It also provides the ability to resubmit unprocessed messages

A.1.1 Queue Controller

A polling strategy on the queue DB addresses the queue management business requirements. The queue controller provides an ECO system to ensure that this polling strategy works in tandem to ensure that:

• All event transmitted files and JMS messages are added to the queue.

• At any time, only one pending message is in the control table.

• After the processing of a message in the control table is complete, it inserts the highest priority queue message from the queue table to the control table.

• In case the integration flow errors out, the queue manager waits until the message is resubmitted or removed.

A.1.2 Queue Schema

To support the queue controller solution flow, the queue manager uses a polling strategy similar to PollingControlTableStrategy. Two tables manage the sequential processing and reordering of messages.

The first table, QUEUE_TABLE, has all the queue messages that are being provided by the event trigger. The QUEUE_CONTROL_TABLE table stores the relevant information of the message from the QUEUE_TABLE, which has not yet been processed.

The queue manager must ensure that the control table has only one message that is not yet processed. When the processing of a message is complete, a pending message from the queue table is inserted into this table to facilitate the sequential processing of the message. Because all pending messages are stored in the queue table, you can reorder them.

A.1.3 Queue Monitor

When a change order is released by ACS, the queue controller picks it up. The queue monitor displays a list of all the change orders that are waiting to be processed. It also enables you to reorder their processing sequence.

For more information about the Queue Monitor, see Agile PLM Integration Pack for Oracle E-Business Suite Design to Release - User Guide.

A.2 User Interface

The following user interface components are available when working with queues:

• Accessing the Process Queue Monitor

• Fields and Attributes

• Filters

A.2.1 Accessing the Process Queue Monitor

The Process Queue Monitor (User Interface) is deployed at your Integration Server and can be accessed through web browser.

The Integration Administrator is provided with its URL, with login ID and password. After you login, you can see a page similar to the one below:

When a Change Order is released, it is picked up by the Queue Controller, which assigns it an Automated Transfer Object (ATO) Number before passing it on for processing. The Queue Monitor displays this ATO number as Reference Number.

Figure A-1 Process Queue Monitor

A.2.2 Fields and Attributes

The Fields and Attributes component includes the Change Order Queue Monitor description.

A.2.2.1 Change Order Queue Monitor

The Changer Order Queue is a tabular display of the released orders lined up by Queue Manager for processing. Each row in this table is a Change Order. The first row denotes the 'first-in-sequence' Change Order, when it is in Pending state of processing.

Figure A-2 shows the process denoters and their functions:

Figure A-2 Process Denoters

A.2.2.2 Queue Operators

This section provides a list of queue operators and their operations.

Figure A-3 shows the Change Priorities page

Figure A-3 Change Priorities

A.2.3 Filters

At any given time, a queue may have hundreds of COs under processing, depending on the size of the organization. Although, the Queue Monitor displays all of them, it gets difficult to find the specific ones that you may require to see quickly.

Queue filters facilitate display of the change orders on the basis of their processing state and further criterion. The tables below list the search criterion of the predefined Saved Search criteria. The bold text indicates the default value or operator.

Figure A-4 Filter All Change Orders

A.2.3.1 Filter 1: All Change Orders

This filter displays the complete list of all change orders in the queue.

Figure A-5 shows the search parameters to be selected to view all change orders.

Figure A-5 All Change Orders

This table shows how to set up a filter to view all change orders:

A.2.3.2 Filter 2: Errored Change Orders Only

This filter displays the change orders with errors.

Figure A-6 shows the search parameters to find change order with errors.

Figure A-6 Change Orders with Errors

A.2.3.3 Filter 3: Pending Changes Only

This filter displays the pending change orders.

Figure A-7 shows the search parameters to view pending change orders.

Figure A-7 Pending Change Orders

This table shows how to set up a filter to view pending change orders:

A.2.3.4 Filter 4: Completed Change Orders Only

This filter displays the completed change orders.

Figure A-8 shows the search parameters to view completed change orders.

Figure A-8 Completed Change Orders

This table shows how to set up a filter to view completed change orders:

A.2.3.5 Filter 5: Changes Errored Within Last Week

This filter displays the changes errored within last week.

Figure A-9 shows changes which errored within last week.

Figure A-9 Changes Errored within Last Week

This table shows how to set up a filter to view change orders that errored within last week:

A.2.3.6 Filter 6: Unprocessed Change Orders

This table shows how to set up a filter to view unprocessed change orders:

Figure A-10 Unprocessed Change Orders

A.2.3.7 Filter 7: All Delete Flags

This table shows how to set up a filter to view all delete flags:

Figure A-11 All Delete Flags

A.2.3.8 Advance Query Abilities

The Advance Query Abilities feature allows you search for queries using advanced search parameters. You can use the advanced query abilities by clicking the Advance Query Abilities button. This button can be used when advanced searching is required and if the pre-defined saved searches do not meet your needs. When this button is pressed, the Add Fields button is added next to the Reset button. Additional fields can be added to your current search criteria.

Example: If the All Change Orders default search criteria was being used, you could also select Change Number from the list below:

Figure A-12 Advance Query Abilities

Then the Change Number is added to your search criteria. The operator and value can then be entered and a search can be performed. The X button can then be used to delete that additional field. Or the reset button can use to reset your criteria back to the Saved Search criteria.

Figure A-13 Search Parameters

In addition to the header search criteria, each column in the table (Reference, Change Number, Release Time, Processed Time, Process Status) has a QBE Line that can also be used as a filter.

A.3 Queue Manager Services

The Queue Manager deploys these services:

• CreateQueueService

• CreateQueueControlService

• QueueProcessorService

• QueueProcessorServiceImpl

• CreateQueueService

  CreateQueueService is implemented as a Mediator Routing service. An adapter service (File/JMS Adapter) polls the destinations for any event payloads. The payload is in the form of aXML files. This service receives message as a binary element (aXML file). For each payload received, the service inserts a new row in the QUEUE table. An adapter service (DB adapter) is used for the same. The Toplink solution generates the required schema from the table for this DB adapter.

• The service uses transformation services to populate any NOT NULL columns in the table.

• OBJECT_REFERENCE is inserted with the file name of the aXML file using the Mediator header transformation extension functions.

• PROCESS_STATUS is pending for the newly inserted row.

• PROCESS_PRIORITY is captured from the file name. (ACS can be configured to append an default order for the file name)

• CreateQueueControlService

  CreateQueueControlService is implemented as a Mediator Routing service. A DB adapter polls on the QUEUE_CONTROL_TABLE table. If no rows are at the pending status, then the CreateQueueControlService invokes a DB adapter service that executes a custom SQL. This SQL identifies the highest priority pending queue message from QUEUE_TABLE table and inserts the same in QUEUE_CONTROL_TABLE table.

  This polling strategy ensures that at any time only one pending message is in the QUEUE_CONTROL_TABLE table. After the pending message is processed and its status is completed, the QUEUE_TABLE table inserts a new pending message in the QUEUE_CONTROL_TABLE table. When the status for a message is completed in the QUEUE_CONTROL_TABLE, the system deletes that row from the table.

• QueueProcessorService

  QueueProcessorService is implemented as a Mediator service that acts as an interface and provides a façade for the QueueProcessorServiceImpl service. A DB adapter polls on the QUEUE_CONTROL table for any pending messages. A pending message in the table is routed to the QueueProcessorServiceImpl service that processes the message. Based on the result from the implementation service, the message status is updated in the control table.

• QueueProcessorServiceImpl

  Figure A-14 QueueProcessorServiceImpl

  
  

The primary task of this service is to invoke the RequestorABCS. The response from RequestorABCS is processed, and the queue is updated with the processing status.

Input: The QueueMessage generated by the Toplink solution in the QueueProcessorService is used as the input for this service.

Output: QueueStatusMessage containing the status and result of processed queue message

This table lists and describes the steps for this process:

A.3.1 Transformations

The aXML payload is transformed to the ABM, which is input for the RequestorABCS. Because the ABM schema is defined on the lines of the aXML schema, this transformation is simpler to do in the JDeveloper XSL Mapper.

A.3.2 Implementation Details

The QueueProcessorServiceImpl is implemented as an asynchronous BPEL process. Calls to the RequestorABCS, DB adapters update queue status and invoke the RequestorABCS. These calls involve some logic (parsing the aXML payload) that cannot be achieved using Mediator.

Note:

The QueueID is used for correlation set between QueueProcessorServiceImpl and RequestorABCS.

A.3.3 Error Management

All errors in the integration flow are handled in the RequestorABCS. Any errors leading to failure of the queue processing is handled in this process. Because of such an error, the queue status and result with failure status is updated in the Queue DB.