Interfacing with OData from the Pega Infinity Platform
Interfacing with OData from the Pega Infinity Platform
| Interfacing with OData from the Pega Infinity Platform | |
|---|---|
| New URL | https://docs.pega.com/bundle/platform-88/page/platform/data-integration/interfacing-odata-pega-platform.html |
| This article has been moved over to our Pega Community here in order to align with our larger content strategy. Please update any bookmarks or links that you may have to this location. | |
There are no OData-specific service and connector rules in the Pega Infinity Platform. Integration wizards will not recognize OData sources and automatically supply the OData syntax. However, it is possible to integrate to OData systems as if they were standard REST services through the Pega REST integration rules and wizards, with some additional manual development to properly set up the request syntax. The goal of this document is to provide details on the additional work required to use OData functionality through Pega Infinity.
Design approach
You can configure data pages for simple unfiltered lists and single-item GET requests by using the Pega Platform REST integration wizard. The syntax of parameters for OData integration requires some additional work on the Pega Platform side.
For example, you need to return data for a specific purchase order, 23000. To create the following request, create a declare expression to combine the simple input parameter value “23000” with the surrounding syntax “PurchaseOrderHeaderCollection(‘[param value]’).
Likewise, a simple filter by the same purchase order number requires a similar declare expression to set the syntax around the simple input parameter value “23000” as in the previous example:
For an integration with an object with multiple filter parameters available, manual development is required to set the correct syntax for each filter parameter by data type and value, and to assemble the query string based on what parameters are passed for a specific request.
The following section further explores these examples in detail for a PUT request and a GET request with multiple filter parameters.
Process to achieve objective
Implementing PUT request
1) Create a savable data page with data save option set to a REST connector.
The REST connector should have an additional header named x-csrf-token.
The x-csrf-token is obtained from the headers in the response of the GET request.
For the service to send the token in the response headers, include x-csrf-token with value as fetch in the request mapping of the GET method as shown in the following screenshot.
In the response mapping of the GET method, map the value of x-csrf-token from headers on to a clipboard page as shown in the following screenshot.
You should then use this clipboard property to set the request header for the PUT method.
2) The token is valid for a single session. The GET and PUT methods should be invoked in a single session
by the system. To invoke the GET and PUT methods, select Maintain session in both REST connector rules:
the one used for GET and the one used for PUT. Use the same string in the Connection ID field for
both the connectors.
3) The GET request does not need a message body because the parameters are passed as query strings. But the PUT request expects the response of the GET request to be passed as the message body. This message
body can contain the modified values that will be updated in the source system. You can convert the response from the GET
request into a clipboard structure that can be used to display the values on the screen. The user
can modify values, and this modified page property on the clipboard can be converted to a JSON string and
passed as input to the PUT method. From the flow, you can use the Save Data Page smart shape to invoke
the REST connector.
Implementing GET with filter
Each filter value needs to be passed as a separate query parameter. The REST connector that is used
for the filter needs to have the required number of filter parameters as shown in the following screenshot.
Filter values need to be passed as shown in the final request URL:
A single expression to create the entire filter string will not work. You can create each parameter by using a declare
expression that takes in the filter value and appends the syntax.
Make sure the Empty behavior field for each filter parameter is set to skip, so that the filter parameter is not included in the query string if it is empty.
Each of the declare expression–backed properties can be passed as parameters to the data page that calls the REST connector.
Results
By using the above implementation, you can list all the purchase orders and edit the purchase orders.