Use Case: Integration Broker Point-to-Point Transformation

Outbound Request or Post to a Third Party

This diagram illustrates an outbound point-to-point request or post to a third party.

The following steps are performed in this scenario:

1. A user in the PeopleSoft system triggers publishing of a point-to-point integration to a third-party system.

2. Within PeopleSoft Integration Broker, a transform on the outbound routing generates the third-party ABM. The method used to translate the data values depends on the transaction. This table lists the transaction types and the necessary transformation action.

   Transaction	Action
   Dynamic key add-request	If the transaction is an add-request, the transform creates a new common key (GUID) and uses the appropriate form of the populate XRef XPath extension function to put the new common key, corresponding PeopleSoft key, and third-party key in the PeopleSoft cross-reference framework.
   Dynamic key lookup	If the transaction is not an add-request, the transform looks up the key using the appropriate form of the lookup XRef XPath extension function with the PeopleSoft keys as input. If a common key does not exist, the developer determines whether to create a new common key, generate an error, or return an error message in the reply message if the integration supports it.
   Dynamic key delete request	For asynchronous notification (request-only) integrations that delete a keyed entity, developers may choose to leave the cross-reference values in place for historical purposes or, if desired, they may choose to delete the cross-reference values. To mark the PeopleSoft keys for deletion, the transform uses the appropriate form of the deleteXRef XPath extension function with the PeopleSoft keys as input.
   Static value lookup	If the transaction uses a domain value map, a transform on the outbound routing looks up the common value using the appropriate form of the lookupDVM XPath extension function with the PeopleSoft value as input. If a value is not found, the developer determines whether the transform supplies the PeopleSoft values by default, omits them, throws an error, or returns an error message in the reply message if the integration supports it.

3. The third-party ABM is routed to the third-party system for processing.

Integrations supporting response messages have these additional steps.

1. The third-party system processes the request, formats the reply message, and then returns it along with the common key or value.

2. Within PeopleSoft Integration Broker, asynchronous request-reply operations have a transform to look up the PeopleSoft keys using the appropriate form of the lookup XRef XPath extension function with the third-party key as input. The PeopleSoft keys are then put into the PeopleSoft ABM. Synchronous operations do not require this lookup because the PeopleSoft application already knows the PeopleSoft keys from the initial request.

   Transaction	Action
   Asynchronous request-reply operation using dynamic key value	Requires a transform program to look up the PeopleSoft keys using the appropriate form of the lookupXRef XPath extension function with the third-party key as input. The PeopleSoft keys are then put into the PeopleSoft ABM.
   Synchronous operations using dynamic key value	Lookup is not required because the PeopleSoft application already knows the PeopleSoft keys from the initial request.
   Asynchronous request-reply operation using DVM value	Requires a transform program to look up the PeopleSoft value using the appropriate form of the lookupDVM XPath extension function with the third-party value as input. The PeopleSoft keys are then put into the PeopleSoft ABM.

3. The PeopleSoft ABM reply is returned to the originating PeopleSoft application.

Inbound Request or Post from a Third Party

This diagram illustrates an inbound point-to-point request or post from a third-party.

1. A user in the third-party system triggers publishing an integration to a PeopleSoft system.

2. In this example, the request is sent in the third-party ABM format.

   Note: In many instances, the third-party may be aware of the PeopleSoft ABM format and perform a transformation before sending the message; in this case, no transform is required.

3. Within PeopleSoft Integration Broker, a transform on the inbound message performs the following actions based on transaction type:

   Transaction	Action
   Dynamic key add request	If the transaction is an add-request, the transform leaves the PeopleSoft keys blank in the ABM and passes the third-party key along for use in the handler.
   Dynamic key lookup	If the transaction is not an add-request, the transform looks up the PeopleSoft keys using the appropriate form of the lookup XRef XPath extension function with the reference key in the third-party ABM as input.
   DVM lookup	The transform on the inbound routing looks up the PeopleSoft values using the appropriate form of the lookupDVM XPath extension function with the reference key from the third-party ABM. If a value is not found, the developer determines whether the transform supplies the PeopleSoft values, omits them, throws an error, or return an error message in the reply message if the integration supports it.

4. Within PeopleSoft Integration Broker, a transform on the inbound message performs the following actions based on transaction type.

5. The PeopleSoft Inbound handler processes the message.

   Transaction	Action
   Dynamic key add request	If the transaction is an add-request, it creates the PeopleSoft keys and then uses the appropriate form of the populate XRef API to add the PeopleSoft keys and the corresponding UniqueGUID to the PeopleSoft cross-reference framework. If the keys cannot be created or added to the framework, an error occurs or a message is returned in the reply message if the integration supports it.
   Dynamic key lookup	If the transaction is not an add-request, the message is processed with the PeopleSoft key values from the ABM. If the PeopleSoft key values not found, an error occurs or a message is returned in the reply message if the integration supports it.

Integrations supporting response messages have these additional steps:

1. The PeopleSoft application processes the request and the PeopleSoft inbound handler formats the ABM reply and returns it along with the common key or value.

2. No key translation is required in the transform, so the EBM reply is then returned to the third-party system along with the common key from the ABM reply.