Understanding Incoming Requests (Learning PeopleSoft Integration Broker Part 4)
As explained in part 2 of this series, incoming request messages are considered to have two logical parts – credentials and the message body. The integration broker infrastructure does not need to understand the contents of the message body in order to process the message. Only part of the message it is interested in is the credentials.
Credentials is the portion of the request that will be consumed by the integration broker, and consists of information required by the broker to authenticate and route the message.
Credentials
Messages sent into the Integration Broker must contain specific information in order to be processed. Messages received without such info will be rejected and will result in errors being thrown.
Two elements are always required for all incoming requests:
- Requesting Node – this is the name of the node sending the request to the local Integration Broker
- Message Name – the name of the message being sent. This can also be an “external message” name.
Without these elements, the broker will be unable to lookup the associated transaction in the system for the request. When such messages are received explicit error messages will be returned.
Other elements may be also necessary, depending on circumstance. For example, if password authentication is being done for a specific requesting node, then the requests must also include this information as well.
All requests must be able to be resolved to a single transaction in the node transaction table – PSNODETRX. Although this is not a requirement, it is advantageous for incoming messages to also specify the transaction type and the message version. If this information is not included, the integration broker must go to the transaction table and attempt to find a transaction that matches the requesting node and message name given in the request message. Care must be taken when setting up transactions to ensure that the incoming request messages will resolve correctly to a single transaction.
If the request message explicitly includes the requesting node, message name, transaction type and version it is relatively easy for an administrator to verify as to whether a matching transaction exists in the system.
Message Body
The requirements for the message body depend on how the request is being used.
As far as the infrastructure of the integration broker is concerned, the only requirements on the message body be that is is composed of text. Binary cannot be directly handled by the system. However a way around this is to encode the binary in a BASE64 string. Since such a string is simply composed of ASCII text, the string can be transported like any other text.
In fact, this is commonly done in the system for asynchronous messages that are sent between two different PeopleSoft nodes. Such messages can be quite large, and it is desireable to make the message as small as possible to reduce strain on the system. Before the outgoing request is built, the pub/sub system takes the XML and compresses it. The result of this is a binary ZIP stream. This stream is then BASE64 encoded, and is added to the outgoing request. The receiving PeopleSoft system reverses the procedure: upon receipt of the message the message body is BASE64 decoded, unzipped, and the resulting XML is then processed. The BASE64 message bodies can be seen being transported across gateways by looking at the appropriate gateway logs.
In reality arbitrary data encoded in the message body is really only a possibility when the integration broker is being used as a hub between two third party systems. If the eventual target of the request is a PeopleSoft system, there are further requirements on the content of the body.
