Understanding Sending and Receiving Messages
To send and receive messages you use PeopleCode to:
Send request messages from PeopleSoft Integration Broker to other systems.
Receive response messages from other systems.
Manipulate message content.
You can also send messages directly to the integration gateway, thereby bypassing processing on the integration engine.
Note: The code examples in this topic are for illustrative purposes only and are not intended to be used in a production environment.
Before you can define PeopleCode to generate, send, receive, and process messages, you must define the message in PeopleSoft Internet Architecture.
Note: Once you create PeopleCode, you must also define nodes, services and service operations to implement a complete integration.
The integration engine uses asynchronous request processes and synchronous request processes to manage outbound and inbound messages. These processes examine the messaging elements that you create to determine how to treat each message.
Outbound Message Processing Flow
This section discusses message processing flow for outbound messages. In this section, the term process is used, and refers to either the integration engine's asynchronous request process or its synchronous request process, depending on the type of integration you are preforming.
Outbound messages you send go through the following steps.
The application triggers the sending PeopleCode that you developed.
The PeopleCode program populates and sends the message by using an asynchronous or synchronous method.
The method that the PeopleCode uses to send the message triggers a request process in the application’s integration engine.
The process searches the outbound routings that are associated with that service operation to determine the valid target nodes for the message.
The asynchronous process examines only asynchronous routings, and the synchronous process examines only synchronous routings. If for synchronous processing, a valid single outbound routing cannot be found, the sending method returns an error.
Note: Only active routings are considered for processing.
For each outbound routing that it finds, the process submits the message to the local gateway, along with transaction information about the node and the target connector that should be used to send the message.
The local gateway transmits the message to the specified target node through the specified target connector.
If this is a synchronous message, the process waits for the target node to pass a response message back through the gateway, then returns it to the calling PeopleCode method.
Inbound Message Processing Flow
Each received message goes through the following steps:
The application’s gateway receives a request message from a remote node or gateway, which specifies the application as its target node.
The gateway submits the message to the application’s integration engine, which searches for any inbound request routing parameter which has the same alias name as the external operation name passed in.
If a matching routing alias name isn’t found, the integration engine returns an error message through the gateway to the sending node.
If a routing alias name is found, the integration engine invokes either the asynchronous request process or the synchronous request process, as appropriate, to handle the message.
Note: Any inbound routing alias that is found must have the proper permissions for that service operation for the process to proceed.
The process accesses the service operation that matches the routing alias name and passes the message to the service operation's handler associated with receiving PeopleCode.
The asynchronous request process invokes the service operation's handler OnNotify event PeopleCode.
The synchronous request process invokes the service operation's handler OnRequest event PeopleCode.
If this is a synchronous transaction, the process waits for the receiving PeopleCode to generate and return a response message, then passes it back to the sending node through the gateway.