PeopleTools 8.51 PeopleBook: PeopleSoft Integration Broker

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 PeopleTools 8.48 overlays the messaging architecture from earlier PeopleTools 8.4x releases.

Messaging Types

PeopleSoft Integration Broker supports asynchronous and synchronous messaging.

Synchronous Messaging	In synchronous messaging, a message is sent to a target system. The sending system must receive a response from the target system before it continues to process additional messages.
Asynchronous Messaging	In asynchronous messaging, a message is sent to a target system. However, the sending system does not need to receive a response from the target system before it can continue processing messages. This type of messaging is also referred to as fire-and-forget messaging.

The remainder of this chapter discusses the PeopleSoft Integration Broker architecture for these messaging types.

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 in the messaging system:

Asynchronous publication of an operation instance

The following table describes the processing steps of an asynchronous publication of a service operation instance in PeopleSoft Integration Broker:

Step	Process
1	The service operation is published and enters the message queue. The instance is written to the PSAPMSGPUBHDR table in the database, but is not yet dispatched. The broker dispatcher process picks up the service operation instance from its queue. During this stage, the service operation instance status in the Service Operations Monitor is New.
2	The broker dispatcher process passes the service operation instance to the broker handler process. During this stage, the service operation instance status in the Service Operations Monitor is Started.
3	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 service operation instance status in the Service Operation Monitor is Working.
4	After the service operation is stored in the publication contact queue, the status of the publication contract in the Service Operations Monitor is New, the service operation instance status is Done, and the publication dispatcher process picks up the publication contract from its queue.
5	The publication dispatcher process passes the service operation instance to the publication handler process. During this stage, the publication contract status in the Service Operations Monitor is Started.

You view service operation instance status information on the Operation Instances page of the Service Operations Monitor. To access the page select PeopleTools, 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 through the messaging system:

Asynchronous publish of a publication contract

The following table describes the processing steps of an asynchronous publish of a publication contract in PeopleSoft Integration Broker:

Step	Process
1	The publication dispatcher picks up the publication contract from the publication contract queue.
2	The publication contract is written to the PSAPMSGPUBCON table in the database, but is not yet dispatched. The publication dispatcher process passes the publication contract to the publication handler process. At this stage the status of the publication contract in the Service Operation Monitor is Started.
3	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 in the Service Operations Monitor is Working.
4	The integration gateway attempts to pass the publication contract to the destination node.
5	The integration gateway passes the status of the publication contract back to the publication handler.
6	The publication handler updates the Service Operations Monitor with the status of the publication contract. The typical statuses that displays in the Service Operations Monitor are: Done. The subscribing node successfully  received the contract. Timeout.  The system timed out before the  transaction processing was completed. Retry.  The system encountered and error.  The retry is automatic. 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.

The Service Operations Monitor may display statuses for publication contracts other than those discussed in this section.

See Asynchronous Service Operation Statuses.

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 following table describes the processing steps of an asynchronous subscription of a service operation instance in PeopleSoft Integration Broker:

Step	Process
1	The service operation enters the message queue. The instance is written to the database, but not yet dispatched The broker dispatcher process picks up the service operation instance from its queue. During this stage, the status of the service operation instance in the Service Operations Monitor is New.
2	The broker dispatcher process passes the service operation instance to the broker handler process. During this stage, the status of the service operation instance in the Service Operations Monitor is Started.
3	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. During this stage, the status of the service operation instance in the Service Operations Monitor is Working.
4	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 in the Service Operations Monitor is Working.
5	Once the service operation is stored in the subscription contact queue, the status of the service operation instance in the Service Operations Monitor is Done. Processing of the subscription contract begins as the subscription dispatcher process picks up the subscription contract from its queue, and the status of the subscription contract in the Service Operations Monitor is New. In this example, at the point when the status of the asynchronous service operation instance is Done, the subscription contract status is New. Asynchronous subscription contract processing is described in the next section.

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

The Service Operations Monitor may display statuses for subscription instances other than those discussed in this section.

See Asynchronous Service Operation Statuses.

Asynchronous Subscription Contract

This diagram shows the flow of an asynchronous subscription contract:

Asynchronous subscription contract

The following table describes the processing steps of an asynchronous subscription contract in PeopleSoft Integration Broker:

Step	Process
1	The subscription dispatchers picks up the contract from the subscription contract queue.
2	The subscription dispatcher process passes the subscription contract to the subscription handler process. At this stage the status of the subscription contract in the Service Operations Monitor is Started.
3	The subscription handler process accepts the subscription contract and runs the notification PeopleCode.
4	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 in the Service Operations Monitor is Working.
5	The subscription handler passes the status of the subscription contract to the Service Operations Monitor. The typical statuses that display in the Service Operations Monitor for an asynchronous subscription contract are: Done. The notification PeopleCode ran successfully. Error. An error occurred.

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.

The Service Operations Monitor may display statuses for subscription contracts other than those discussed in this section.

See Asynchronous Service Operation Statuses.

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 following table describes the processing steps for a synchronous publication of a service operation in PeopleSoft Integration Broker:

Step	Process
1	The integration engine sends the service operation to the integration gateway.
2	The integration gateway attempts to deliver the service operation to the destination node.
3	The integration gateway sends back the status information to the integration engine
4	The integration engine updates the database tables as well as sends the status information to the Service Operations Monitor. The possible statuses in the Service Operations Monitor for a synchronous publication are: Done. The integration gateway was able to deliver the service operation to the destination node. Error. The integration gateway was not able to deliver the service operation to the destination node.

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.

For status information for synchronous integrations to be available in the Service Operations Monitor, you must set the Logging Level parameter in the routing definition for the service operation.

Synchronous Service Operation Subscription

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

Synchronous service operation subscription

The following table describes the processing steps of a synchronous service operation subscription in PeopleSoft Integration Broker:

Step	Process
1	The integration gateway passes an inbound synchronous service operation to the integration engine.
2	The integration engine runs an OnRequest PeopleCode event program.
3	The OnRequest PeopleCode program attempts to update the application data tables.
4	The integration engine updates the database tables as well as sends the status information to the Service Operations Monitor. The possible statuses in the Service Operations Monitor for a synchronous publication are: Done. The integration gateway was able to deliver the service operation to the destination node. Error. The integration gateway was not able to deliver the service operation to the destination node.

For status information for synchronous integrations to be available in the Service Operations Monitor, you must set the Logging Level parameter in the routing definition for the service operation.

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.