Understanding Service Operation Queues
This chapter discusses how to:
Add queue definitions.
Apply queue partitioning.
Set permissions to queues.
Rename and delete queue definitions.
Delete queues during upgrade.
Understanding Service Operation Queues
Service operations queues are used to queue service operations for processing.
Adding Queue Definitions
Use the Queue Definitions page (IB_QUEUEDEFN) to add queue definitions to the system. To access the Queue Definitions page, select PeopleTools, Integration Broker, Integration Setup, Queues. The following example shows the Queue Definitions page.
The Operations Assigned to Queue box displays the names of the service operations assigned to a queue. Click a service operation name to open the service operation definition.
You work with the following page elements when you add a queue.
|
Queue Name |
Enter the name of the queue. |
|
Select to archive service operation instances that are assigned to the queue. By default, archiving is not enabled. When you enable archiving, you can archive or delete transactions in the Asynchronous Details component of the Service Operations Monitor. This check box also controls whether the Archive or Delete action is available in the Asynchronous Details component of the Services Operations Monitor. If archiving is not enabled, the system purges the queue entries that have been processed. Note. This setting controls whether archiving is available for asynchronous transactions only and pertains to transactions in a specific queue. |
|
|
Select to enable field partioning and to process service operations unordered. By default, the check box is cleared and inbound service operations that are assigned to a queue are processed one at a time sequentially in the order that they are sent. Select to force the channel to handle all of its service operations in parallel (unordered), which does not guarantee a particular processing sequence. This disables the channel’s partitioning fields. Clear this check box if you want all of the queues’s service operations processed sequentially or if you want to use the partitioning fields. |
|
|
Description |
Enter a description for the queue. |
|
Values are: Run: (default) Service operations that are assigned to this queue are received and processed normally. Pause: Service operations are received but not processed until the status is reset to Run. Note. You can also pause and restart queues in the Service Operations Monitor. |
|
|
Object Owner ID |
From the drop-down list box, select the object owner. The owner ID helps to determine the application team that last made a change to the definition. The values in the drop-down list box are translate table values that you can define in the OBJECTOWNERID field record. |
|
Comments |
Use this area to enter comments about the definition. |
|
Operations Assigned to Queue |
This read-only section lists all service operations that are assigned to the queue. |
|
Include |
Select the Include check box next to a field name to include the field in queue partitioning. |
|
Add Field |
Click to view and select partitioning fields. |
See Also
Pausing, Testing, and Pinging Nodes
Applying Queue Partitioning
This section provides an overview of queue partitioning and discusses how to select partitioning fields.
Understanding Queue PartitioningThis section discusses queue partitioning
Queue Partitioning
By default, all inbound service operations that are assigned to a given service operation queue are processed one at a time, in the order they are sent. Consequently, the sending node can engage in a series of transactions that modify a specific record, and the changes are applied by the receiving node in the correct order. This can be inefficient if the sequence does not matter or if the sequence is relevant only within groups of service operations with the same key values. One solution to this inefficiency is partitioning.
Note. Partitioning applies only to asynchronous messaging.
To maximize messaging efficiency and throughput, you want the system to simultaneously process as many service operations as possible. Because queues enforce service operation sequence, ideally you have a separate service operation queue for each group of service operations that must be processed in order. You can achieve this goal by designating specific fields that are common to the service operations that are assigned to a queue. These fields partition, or divide, the queues into subqueues. PeopleSoft Integration Broker creates these subqueues at runtime.
Each subqueue processes only the service operations for which the designated common fields have an identical combination of values. The service operations within each subqueue are processed in the order that they are sent, so they remain in sequence. Each subqueue works in parallel with the other subqueues—all subqueues simultaneously process their own associated service operations.
You implement partitioning by designating the partitioning fields in the queue definition; no other steps are required.
Note. The more partitioning fields that you designate, the more subqueues are generated. If you designate a combination of fields that are unique for each service operation, all service operations are processed simultaneously, in their own subqueues, without regard to sending order. This is the equivalent of selecting the Unordered check box in the queues definition.
Queue Partitioning Fields
When working with queue partitioning fields, note the following points:
The maximum length of a queue partitioning value should not exceed 60 characters. The system truncates any value longer than 60 characters when you use the PeopleCode SubQueueName property.
Fields of types image and long character aren’t available for partitioning.
When you are partitioning nonrowset-based or inbound messages, tags cannot be mixed case.
Selecting Partitioning Fields
You can partition queues using any combination of:
Database record fields.
Message header fields.
Message XML fields.
Database record fields are the data fields in a PeopleSoft rowset-compatible message. Typically, the more service operations that you assign to the queue, the fewer fields they have in common.
The database record fields that are common to all service operations in the queues appear in the queues’s Common Field list. If only one service operation is assigned to the queues, all of its fields appear on the partitioning list.
To designate a field as a partitioning key, select the check box next to its name.
The message header fields are system-maintained fields that are common to all service operations, regardless of format. If a queue includes any nonrowset-compatible service operations, the message header fields are the only ones that PeopleSoft Integration Broker recognizes as common to every service operation. You can view them as part of the message XML in Integration Broker Monitor. You can also access some of them using equivalent PeopleCode Message class properties, as indicated later in this chapter. The message header fields are:
OPERATIONNAME: This field contains the name of the operation in the PeopleSoft Pure Internet Architecture.
PUBLISHER: This field contains the user ID that is in effect when the service operation is published, that is, the ID of the user who is signed in to the publishing database.
PUBPROC: This field refers to the PeopleSoft process that publishes the service operation.
It is generated when the service operation is published, and it can be the name of a component, an Application Engine program, or an iScript program.
These header fields are always available in the queue’s partitioning field list. To designate a field as a partitioning key, select the Include check box next to its name.
The message XML fields comprise all the fields that exist anywhere in a message, including PeopleSoft common application message attributes (PSCAMA) record fields. Such fields may not be visible in the queues’s partitioning field list, but they are valid for partitioning. Message XML fields can have aliases, allowing for support of mixed-case names.
To designate a message XML field as a partitioning key:
Access the Queue Definitions page (PeopleTools, Integration Broker, Integration Setup, Queues.)
Click the Add Field button.
Enter the tag name of the XML field, or click the Lookup button to search for one.
The value does not have to be in the database.
All names are uppercase by default. You can then add an alias, which can be mixed-case for partitioning.
At runtime, the integration engine searches each message for the first instance of that field tag and uses the value that is associated with it for partitioning. Therefore, if you have common fields in the PSCAMA record that are specific to a batch publish set, you can use those fields.
Renaming and Deleting Queues
You can rename and delete queue definitions using the Queue page (IB_HOME_PAGE3) in the Service Administration component (IB_HOME_PAGE).
The Queues page contains two sections: a Delete section that enables you to delete a queue definition and a Rename section that enables you to rename a queue definition.
To access the page, select PeopleTools, Integration Broker, Service Utilities, Services Administration and select the Queues tab.
When you first access the page, both sections are collapsed. Click the section-header arrow buttons to expand and collapse each section.
The following example shows the Queues page with the Delete and Rename sections expanded:
The top of the page displays a Service System Status field with the current setting, as defined on the Services Configuration page. This setting affects the ability to rename and delete queues.
See Configuring PeopleSoft Integration Broker for Handling Services.
Renaming Queue DefinitionsTo rename a queue definition:
Access the Services Administration - Queues page (PeopleTools, Integration Broker, Service Administration, click the Queues tab).
Click the arrow next to the Rename section header to expand the section.
In the Queue Name field, enter the queue definition to rename, or click the Lookup button to search for and select the queue to rename.
In the New Name field, enter the new name for the queue definition.
Click the Rename button.
Deleting Queue DefinitionsTo delete a message definition:
Access the Services Administration - Queues page PeopleTools, Integration Broker, Service Administration, click the Queues tab).
Click the arrow next to the Delete section header to expand the section.
In the Queue Name field, enter the name of the queue definition to delete, and click the Search button.
Search results appear in the results grid.
In the results grid, select the check box next to the queue or queues to delete.
Click the Delete button.
Deleting Queues During Upgrade
To delete a queue definition in an application upgrade project, first ensure that no live instances of messages are assigned to that queue. Archive or delete any such messages in both the source and the target database. Otherwise, an error message appears during the copy process indicating that the message is in use.