Managing 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.

Note. Beginning with PeopleTools 8.48 queues replace message channels from previous PeopleTools 8.4x releases.

Adding Queue Definitions

This section discusses how to create queue definitions.

Page Used to Create Queue Definitions

Adding a Queue Definition

The following example shows the Queue Definitions page.

You work with the following page elements when you add a queue.

Applying Queue Partitioning

This section provides an overview of queue partitioning and discusses how to select partitioning fields.

Understanding 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.

Selecting Partitioning Fields

You can partition queues using any combination of:

• Database record fields.

• Message header fields.

• Message XML fields.

Note. Fields of types image and long character aren’t available for partitioning. In addition, when you are partitioning nonrowset-based or inbound messages, tags cannot be mixed case.

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 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.

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:

1. On the Queue Definition page, click the Add Field button.

2. 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 in the Service Administration component.

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.

Pages Used to Rename and Delete Queue Definitions

Renaming Queue Definitions

To rename a queue definition:

1. Access the Services Administration - Queues page.

2. Click the arrow next to the Rename section header to expand the section.

3. 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.

4. In the New Name field, enter the new name for the queue definition.

5. Click the Rename button.

Deleting Queue Definitions

To delete a message definition:

1. Access the Services Administration - Queues page.

2. Click the arrow next to the Delete section header to expand the section.

3. 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.

4. In the results grid, select the check box next to the queue or queues to delete.

5. 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.