Use Case: Integration Broker Transformation in Which a Third Party Uses AIA Middleware

From a PeopleSoft perspective, this use case has an identical flow to the transformation without the AIA middleware. From a third-party perspective, however, it is similar in flow, but not in implementation. In this case, the third-party system integrates with the AIA using their ABM instead of with PeopleSoft software using an EBM. All of the third-party value maps and transforms between the EBM and the third-party ABM are done on the AIA layer using the EBS graphical-mapper and XPath extension functions instead of being done on the third-party system.

Note: This is the model used with AIA PIPs.

Use cases include:

Outbound request or post to a third party.
Inbound request or post from a third party.

Outbound Request or Post to a Third Party

In this use case, a request is sent from the PeopleSoft application to a third party that uses their own AIA middleware to perform message transformation.

Image: Outbound request to a third party that uses AIA middleware

This diagram illustrates an outbound request or post to a third party that uses AIA middleware.

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

Within PeopleSoft Integration Broker, a transform on the outbound routing occurs, generating 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 populateXRef XPath extension function to put the new common key and the corresponding PeopleSoft keys in 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 lookupXRef 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.
DVM 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 common value from the EBM. 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 in the reply message if the integration supports it.

The EBM is routed to the AIA.
Upon receiving the EBM request, the AIA transforms the common key to the third-party key and sends the transformed request to the third party using their ABM.

Integrations supporting response messages use these additional steps:

The third party processes the request, formats the reply message, and returns it to the AIA middleware.
The AIA transforms the third-party key in the reply to the common key and returns the EBM reply to PeopleSoft software.

Within PeopleSoft Integration Broker, asynchronous request-reply operations have a transform program to transform the common key or value and place it into the PeopleSoft ABM. Synchronous operations do not require this lookup because the PeopleSoft application already knows the PeopleSoft keys or values from the initial request.

Transaction	Action
Dynamic key lookup	Transform looks up the PeopleSoft keys using the appropriate form of the lookup XRef XPath extension function with the common key as input.
Dynamic key delete	(Optional) For 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.
DVM lookup	The transform looks up the common value using the appropriate form of the lookup DVM XPath extension function with the PeopleSoft values as input.

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

Inbound Request or Post from a Third Party

In this use case, a third-party application creates a request that is transformed using the third-party AIA middleware and sent to the PeopleSoft application.

Image: Inbound request from a third party using AIA middleware

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

A user in the third-party system triggers publishing of an integration to a PeopleSoft system through the AIA.
The AIA transforms the third-party ABM key and values to the common key and values and routes the EBM request to the PeopleSoft system for processing.

Within PeopleSoft Integration Broker, a transform on the inbound routing transforms the EBM to PeopleSoft ABM using one or more of the following methods depending on the transaction.

Transaction	Action
Dynamic key add	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 key using the appropriate form of the lookupXRef XPath extension function with the common key in the EBM as input. Optionally, this can be done in the PeopleSoft inbound handler using the appropriate PeopleSoft lookup XRef API with the common key as input.
DVM lookup	A transform on the inbound routing looks up the PeopleSoft values using the appropriate form of the lookup DVM 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 by default, leaves them blank, throws an error, or returns an error message in the reply message if the integration supports it.

For synchronous and asynchronous request-reply messages, the following additional steps are performed:

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.
No key translation is required in the IB transform, so the EBM reply is returned to the AIA for routing back to the third-party system.
The AIA transforms the common key and values to the third-party ABM key and values and routes the third-party ABM reply back to the third-party system.