Applying Queue Partitioning
This section provides an overview of queue partitioning and discusses how to select partitioning fields.
This section discusses 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.
Note: For inbound transactions, re-partitioning (re-running of the queue partition logic) could take place as a result of a successful inbound transform if no partition key was passed as part of the request.
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.
You can partition queues using any combination of:
Database record fields.
Message header fields.
Message XML fields.
Database Record 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.
Message Header Fields
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 topic. 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.
Message XML Fields
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 ().
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.