Understanding Messaging

This chapter discusses:

Asynchronous messaging.
Synchronous messaging.

Note. For compatibility with previous PeopleTools releases, the PeopleSoft Integration Broker services-oriented architecture introduced in PeopleTool 8.48 overlays the messaging architecture from earlier PeopleTools 8.4x releases.

Asynchronous Messaging

This section discusses the PeopleSoft Integration Broker asynchronous messaging architecture.

Brokers, Contractors and Queues

The Publication Broker, Publication Contractor, and Subscription Contractor services are the primary application server elements required for asynchronous messaging. The Publication Broker service routes the workload to both contractor server processes, as illustrated in the following diagram:

Brokers, contractors, and queues

Publication Broker	Acts as the routing mechanism. When an asynchronous service operation arrives in its queue, the Publication Broker service runs the defined routing rules. If the service operation needs to be published to a remote node, it routes the service operation to the Publication Contractor service. If the service operation is subscribed to on the local node, then the Publication Broker routes the service operation to the Subscription Contractor service. Routing involves submitting either a subscription or publication contract to the appropriate contractor, followed by an asynchronous call to the contractor service notifying it that work is waiting in the queue.
Publication Contractor	References the publication contract submitted by the Publication Broker service and performs an HTTP post of the publication service operation to the integration gateway. When the integration gateway sends a reply indicating that it received the publication service operation, the Publication Contractor service updates the publication contract with the status of subscription processing (Done or Retry).
Subscription Contractor	References the subscription contract submitted by the Publication Broker service and runs the appropriate notification PeopleCode. Then it updates the subscription contract concerning the status of the subscription processing.

Messaging System Server Processes

The application server offers six server processes to handle asynchronous service operations. They work in pairs to provide three primary services:

Service	Server Processes
Publication Broker	Broker Dispatcher (PSBRKDSP) Broker Handler (PSBRKHND)
Publication Contractor	Publication Dispatcher (PSPUBDSP) Publication Handler (PSPUBHND)
Subscription Contractor	Subscription Dispatcher (PSSUBDSP) Subscription Handler (PSSUBHND)

Dispatchers and Handlers

Each of the Publication Broker, Publication Contractor, and Subscription Contractor is comprised of two individual server processes that work together to handle incoming requests. One server process functions as a dispatcher, while the other functions as a handler.

This relationship is analogous to the way that the application server handles workstation connections and requests. To handle the incoming client requests, the application server has a listener and a handler (or a pool of handlers). The listener receives the incoming requests and then routes them to an available handler.

Typically, one listener serves many handlers. The relationship between the dispatcher and the handlers is analogous to the relationship between the Jolt Server Listener (JSL) and the Jolt Server Handler (JSH). In the case of the application messaging server processes, the dispatcher functions as the listener, and the handler as similar to the JSH.

For the services discussed in this section (Publication Contractor, Subscription Contractor, and Publication Broker) there are at least two server processes: a single dispatcher and one or more handlers. The PSxxxDSP server process is the dispatcher, and the PSxxxHND server process is the handler.

Note. The xxx represents BRK, PUB, or SUB. For example, in the case of the Publication Broker, PSBRKDSP is the dispatcher and PSBRKHND is the handler.

This diagram shows the messaging server processes grouped by their functions in the messaging architecture:

Dispatchers and handlers

Asynchronous Service Operation Publication

This section discusses:

Asynchronous publish of a service operation instance.
Asynchronous publish of a publication contract.

Understanding Asynchronous Service Operation Publication

This section describes the flow of an asynchronous service operation publication through PeopleSoft Integration Broker, as well as the status of the service operations as they appear in Service Operations Monitor.

Asynchronous Publish of Service Operation Instances

This diagram shows an asynchronous publish of a service operation instance:

Asynchronous publication of an operation instance

The processing steps of an asynchronous publication of a service operation instance are:

The service operation is published and enters the message queue.

The Broker Dispatcher process picks up the service operation instance from its queue. During this stage, the status of the service operation instance is New.
The Broker Dispatcher process passes the service operation instance to the Broker Handler process.

During this stage, the status of the service operation instance is Started.
The Broker Handler process accepts the service operation instance, reads the data, and runs the routing rules to determine where the publication needs to be delivered.

The Broker Handler process then writes a publication contract in the PSAPMSGPUBCON table and notifies the Publication Contractor service that it has an item to process. During this stage, the status of the service operation instance is Working.
After the service operation is stored in the publication contact queue, the status of the publication contract is New, the service operation instance status is Done, and the Publication Dispatcher process picks up the publication contract from its queue.

You view service operation instance status on the Operation Instances page of the Service Operations Monitor. To access the page selectPeopleTools, Integration Broker, Service Operations Monitor, Monitor, Asynchronous Services, Operation Instances.

See Monitoring Asynchronous Service Operation Instances.

Asynchronous Publish of Publication Contracts

This diagram shows the flow of an asynchronous publication contract:

Asynchronous publish of a publication contract

The processing steps of an asynchronous publish of a publication contract are:

The Publication Dispatcher process passes the publication contract to the Publication Handler process.

At this stage the status of the publication contract is Started.
The Publication Handler process accepts the publication contract and attempts to deliver the service operation to the integration gateway.

At this stage, the status of the publication contract is Working.

If the publication contract is successfully delivered to the destination node, the status is Done (refer to step 6c in the diagram).

If an error occurs during this stage, the status is Error.

If the system times out before the transaction is completed, the status is Timeout (6a in the diagram).

If the delivery fails, the Publication Handler process retries the delivery, and the status is Retry (refer to step 6b in the diagram). When service operations have Retry status, the service operations are not resent until an internal ping is successful. This ping is similar to a node ping. The Publication Contract Dispatcher, as part of its on idle processing, pings a node that is in Retry status and verifies if the connection is reestablished. When the ping is successful the Publication Contract Dispatcher resends the service operation. The service operation goes back to the Publication Handler process and returns to Working status.

You can view the status information for the publication contract using the Publication Contracts page in the Service Operations Monitor. To access the page, select PeopleTools, Integration Broker, Service Operations Monitor, Monitor, Asynchronous Services, Publication Contracts.

See Monitoring Publication Contracts.

Asynchronous Service Operation Subscription

This section discusses:

Asynchronous subscription of a service operation instance.
Asynchronous subscription contracts.

Understanding Asynchronous Service Operation Subscription

This section describes the flow of an asynchronous service operation subscription through PeopleSoft Integration Broker, as well as the service operation status at each stage of the process.

Asynchronous Subscription of Service Operation Instances

This diagram illustrates the flow of an asynchronous service operation subscription through PeopleSoft Integration Broker:

Asynchronous subscription of a service operation instance

The processing steps are:

The service operation enters the message queue.

The Broker Dispatcher process picks up the service operation instance from its queue. During this stage, the status of the service operation instance is New.
The Broker Dispatcher process passes the service operation instance to the Broker Handler process.

During this stage, the status of the service operation instance is Started.
The Broker Handler process accepts the service operation instance, reads the data, and runs the subscription routing rules to determine if the service operation needs to be processed locally.

The Broker Handler process then writes a subscription contract in the PSAPMSGPUBCON table (the subscription contract queue) and notifies the Subscription Contractor service that it has an item to process. During this stage, the status of the service operation instance is Working.

Once the service operation is stored in the subscription contact queue, the status of the subscription contract is New, the service operation instance status is Done, and the Subscription Dispatcher process picks up the subscription contract from its queue. In this example, at the point when the status of the asynchronous service operation instance is Done, the subscription contract status is New.

You view service operation instance status on the Operation Instances page of the Service Operations Monitor. To access this page, select PeopleTools, Integration Broker, Service Operations Monitor, Monitor, Asynchronous Services, Operation Instances.

See Monitoring Asynchronous Service Operation Instances.

Asynchronous Subscription Contract

This diagram shows the flow of an asynchronous subscription contract:

Asynchronous subscription contract

The processing steps are:

The Subscription Dispatcher process passes the subscription contract to the Subscription Handler process.

At this stage the status of the subscription contract is Started.
The Subscription Handler process accepts the subscription contract and runs the notification PeopleCode.

In the example shown in the diagram, the notification PeopleCode then uses the service operation data to update application data tables. However, the notification PeopleCode can use the service operation data as input to look up information, create and publish another service operation, and so forth. At this stage, the status of the publication contract is Working.

If the notification PeopleCode runs successfully, the status is Done (refer to step 6a in the diagram). If an error occurs during this stage, the status is Error (refer to step 6b in the diagram).

To view status information for subscription contracts, use the Subscription Contracts page in the Services Operation Monitor. To access the page select PeopleTools, Integration Broker, Service Operations Monitor, Monitor, Asynchronous Services, Subscription Contracts.

See Monitoring Subscription Contracts.

Synchronous Messaging

This section discusses synchronous messaging in PeopleSoft Integration Broker.

Synchronous Service Operation Publication

This diagram illustrates using PeopleSoft Integration Broker to consume a synchronous service operation:

Synchronous service operation publication

The processing steps are:

The system makes a SyncRequest ( ) call to PeopleSoft Integration Broker.
PeopleSoft Integration Broker sends the service operation to the integration gateway.
If the integration gateway can deliver the service operation to the destination node, the process is successful and the status is Done.

If the process in unsuccessful, the status is Error.

For PeopleSoft Integration Broker to shoe the status, logging on the routing definition for the service operation must be set.

You can view the status information for the invocation in the Service Operations Monitor using the Synchronous Services page. To access the page select PeopleTools, Integration Broker, Service Operations Monitor, Monitor, Synchronous Services.

Synchronous Service Operation Subscription

This diagram illustrates providing a synchronous service operation through PeopleSoft Integration Broker:

Synchronous service operation subscription

The integration gateway passes an inbound synchronous service operation to the integration engine.
The integration engine runs an OnRequest PeopleCode program.
The OnRequest PeopleCode program attempts to update the application data tables.

If the program runs successfully, the status is Done. If the OnRequest PeopleCode program fails, the status is Error.

For PeopleSoft Integration Broker to shoe the status, logging on the routing definition for the service operation must be set.

You can view the status information for the publication in the Service Operations Monitor by using the Synchronous Services page. Access this page by selecting PeopleTools, Integration Broker, Service Operations Monitor, Monitor, Synchronous Services.