In addition to IFS standard tasks (Process Enrichment, IFS API, IFS REST Call,…), the Service Task offers access to others Camunda connectors like the http-connector for advanced query functions and behaviors closer to Postman, but at the cost of a certain complexity and with a lack of documentation.

Here is an example of how to use this task to query an SAP backend from IFS Cloud.

_ When you define a task as a Service Task, you need first to define the connector implementation type as ‘connector’.

Then you have to configure this connector as an ‘http-connector’:

_ Like Postman, you can then set parameters of the request in ‘Input Parameters’. The following parameters are available:

This can be used as follows:

_ In return, the response of the query can also be configured to parse all required information. Usually, a response contains the status code, response headers and body.

The Output Parameters allow you to define which information need to be kept and mapped to process variables.

The http-connector can return the following variables:

_ From these standard variables, you can define as many output parameters as desired if you need to extract specific information contained in them by using Expression or Javascript. In this example, I need to parse the x-csrf-token provided in the response header to be able to make a POST query in SAP in the second step of my workflow.

The syntax is the following:

The status code can be useful to continue or to manage exception of the query.

The response can be mapped as well:

/!\ please note that there is a limitation in the size of an attribute managed in BPA. It cannot exceed 2000 characters or it throws an exception (error “An exception occurred in the persistence layer”). That’s why I take only the first 2000 characters with the substring(0,2000) function.

In my case, I only use the response for information and debug, so the 2000 characters limit is not an issue. But if you need to parse specific information from a JSON response, you can also directly map this information with the following expression :  

${S(response).prop("your_attribute")}

_ If everything works fine, you should see in the debug output attributes:

These attributes can be used as any attributes in the following tasks of your workflow. In my example, reinjected for a POST query:

Why use the Service Task rather than IFS REST call ? 

In my case, I need to parse the x-csrf-token in the response header of the first GET query to be authorized to POST or UPDATE in the next query according to SAP API authentication process. And the IFS REST call does not (yet?) provide access to the response header.

And for my second query, a POST one, the status code result is not the same between the Service Task and IFS REST Call. My POST query is successful (code 201) with the Service Task, where the same input parameters with the IFS REST call returns a code 403 (unauthorized).