Jarvis Pizzeria: Using a DM in ICS

This blog is a follow up of Using a DM in PCS, but can also be read as a separate item.

In the previous blog we showed how to embed a Decision in PCS. We described how the hard-coded relationship between a Decision and Process (PCS) can be prevented by using an ICS integration. In this blog we describe step by step how this integration can be developed.

ICS Integration

The integration can be divided into the following steps:

  1. Get the endpoint of the Decision Service
  2. Create the invoke Connector
  3. Create the Integration
  4. Activate the Integration
  5. Test the Integration (using postman)
  6. PCS adjustment to invoke the Integration

Get the endpoint of the Decision Service

We start by making the Decision available in ICS by defining a connector for it. For this we must first determine the REST endpoint of the Decision. Todo this follow the steps below:

    • Open the Decision. Then select the operation that you want to access under Services. In this case, calculateDeliveryTime.
    • Then select the option ‘Payload’ from the hamburger menu.

Additionally

As you can see the url contains a reference ‘versions/LATEST’. It is somewhat confusing but ‘versions’ refer to the snapshots. Reference is therefore made here to the most recent snapshot. We will use this in our integration but Instead of LATEST, the snapshot name can also be used here.

https:///decision-models/DeliveryTime/ versions/DeliveryTime-s1/definition/decision-services/CalculateDeliveryTime/

And then of course it is also possible to use the url of a specific version, as happens from PCS (See previous blog). Then you have to use ‘tags’ instead of ‘versions’.

https:///decision-models/DeliveryTime/ tags/1.0/definition/decision-services/CalculateDeliveryTime/

Create the Invoke Connector

In Integration, we now make the REST Invoke Connector. Do this by choosing the Connections tab in Integration and then clicking the create button.
Below you will find the variables to be entered that is required for creating the connector.

Connection Name DeliveryTime DM
Connection Role Invoke
Connection Type REST API Base URL
Connection URL selected endpoint above minus the last part (CalculateDeliveryTime/)
Description Description of functionality
Security settings username en password

And some screenshots of the result.

Create the Integration

In Integration we now make the REST integration itself. Do this by choosing the Integrations tab in Integration and then clicking the create button.

We have opted for the ‘App Driven Orchestration’. Below you will find the variables to be entered that is required for creating the integration.

Integration Name DeliveryTime DM
Description Description of functionality

Now we take a big step to split up and explain this step. The final result of the integration is as follows:

The first step is the integration interface. The third step is the invoke to the Decision. The second step is the transformation of the data between steps one and three.
Step five concerns the response message of the integration and step four is just like step two a transformation, but here it concerns the transformation of the output formats.

Step 1 Trigger Connection

The screenshot below shows the details of the Trigger Connection

And the request and response json examples:

request:

  • { “distance” : 2, “transport” : “bike” }

response:

  • { “deliveryTime”: 12 }

Step 3 Invoke Connector

The screenshot below shows the details of the Invoke Connection

The request and response json examples:

request:

  • { “Distance” : 2, “Transport” : “bike” }

response:

  • { “interpretation”: 30 }

Step 2 Transformation

The data received at the Trigger must be transferred to the Invoke. This requires the following transformation. The details of the Trigger request are forwarded to the Invoke request.

Step 4 Transformation

The response that is received from the Invoke (the Decision) must be mapped through to the output of the integration. This requires the following transformation.

Step 5 Integration response

At step 1 the configuration of this step has already been completed. No further action is needed here to return the Integration result.

Activate the Integration

Once the integration has been built, activate is so we can start using it.

Test the Integration (using postman)

The endpoint of the metadata can be requested via .

Select this endpoint to view the details.

We need the endpoint URL to test the integration (using postman), so copy it.

Define a POST request in postman, with the selected url as the endpoint. Set the request message and authentication (for example the same user and password as with the connection). And then click on test.

If everything is configured correctly, you will receive 200 OK status and a response.

Outcome of Integration

In the integration, we use a 1-on-1 mapping of the call parameters to the Decision. So by way of illustration, if we Invoke the Decision directly, we should get the same result (In the previous blogs we already described how to do this). As can be seen in the image below, that is the case.

Outcome of Decision

The url refers to LATEST. If we replace this with a snapshot version, we can easily address older versions. For example also the s1 version (see an earlier screenshot in this blog) that is no longer available from an activated version.

PCS adjustment to invoke the Integration

Finally, we still have to adjust the process to make use of the integration instead of the Decision activity.

Open the process and remove the Decision Activity from the process. Also remove the Decision on the Decision tab to prevent unused components from being left behind. Then go to the Integration tab. Select Create → Use integration and select the “DeliveryTime DM” integration. This is now available for the process. Open the process again and put the “DeliveryTime DM” Integration at the place where the Decision Activity was.

Define the input and output mapping of the service as below (similar to mapping of the deleted Decision Activity).

Activate the process, and after that get the Soap endpoint of the process and run a test to see if things will work (for example in SoapUI).

The Soap request

And the outcome of the Process

As can be seen, the outcome of the Decision is passed back to the process via the integration.

This brings us to the end of this post. However, also this story has next level questions. The Decision table that we use currently contains a fixed data set. Can we make this data set variable? We will describe this in follow-up posts.

6 thoughts on “Jarvis Pizzeria: Using a DM in ICS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s