Interfacing with OData from the Pega Infinity Platform

From PegaWiki
This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Interfacing with OData from the Pega Infinity Platform

Description Interfacing with OData from the Pega Infinity Platform
Version as of 8.6
Application Pega Platform
Capability/Industry Area Cloud Services

Interfacing with OData from the Pega Infinity Platform
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.

Fig 2.png

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.

Fig 4.png

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.  

Fig 5.png

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

Fig 6.png

passed as input to the PUT method. From the flow, you can use the Save Data Page smart shape to invoke

the REST connector.

Fig 7.png

Fig 8.png

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.

Fig 9.png

Filter values need to be passed as shown in the final request URL:

http://sourcesystemurl:8000/sap/opu/odata/sap/Z_PURCHASE_ORDER2_SRV/PurchaseOrderHeaderCollection?$format=json&$filter=CompanyCode eq+'1000'&$filter=PONumber+eq+'4500000771'

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.  

Fig 10.png

Each of the declare expression–backed properties can be passed as parameters to the data page that calls the REST connector.


By using the above implementation, you can list all the purchase orders and edit the purchase orders.