Use Case: Integration Broker Transformation Without AIA Middleware

Outbound Request or Post to a Third Party

This diagram illustrates an outbound 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 an AIA supportive integration to a third-party system.

2. Within PeopleSoft Integration Broker, a transform on the outbound routing generates the EBM. 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 and the corresponding PeopleSoft keys into the PeopleSoft cross-reference framework.
   Dynamic key lookup	If the transaction is not an add-request, the transform looks up the common 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, the transform looks up the PeopleSoft values using the appropriate form of the lookupDVM XPath extension function with the PeopleSoft values as input. If a value is not found, the developer determines whether the transform supplies the PeopleSoft values by default, leaves them blank, throws an error, or returns an error message in the reply message if the integration supports it.

3. The EBM 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 lookupXref XPath extension function with the common 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 common 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 values using the appropriate form of the lookupDVM XPath extension function with the common value as input. The PeopleSoft keys are then put into the PeopleSoft ABM.

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

Inbound Request or Post from a Third Party

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

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

2. The EBM is routed to the PeopleSoft system for processing.

3. Within PeopleSoft Integration Broker, a transform on the inbound routing 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 common 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 common key in the EBM as input. Optionally, this can be done in the PeopleSoft inbound handler through the appropriate PeopleSoft lookup XRef API with the common key 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 common value from the EBM. If a value is not found, the developer determines whether the transform supplies the PeopleSoft values, omits them, throws an error, or returns an error message in the reply message if the integration supports it.

4. 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 common key to the PeopleSoft cross-reference framework. If the keys cannot be created or added to the framework, an error occurs or an error 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 keys from the ABM. If the PeopleSoft key values are 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 returns the ABM reply to the PeopleSoft inbound handler.

2. The PeopleSoft inbound handler formats the EBM reply and returns it to the third-party system with the common key.

3. Optionally, if the third-party system uses the PeopleSoft cross-reference framework to persist their key mappings, asynchronous request-reply operations need to look up the third-party keys using the appropriate form of the lookup XRef web service with the common key from the EBM reply as input.