SAP Cloud Integration Manage Artifacts Of Design Time

Introduction:

In cloud integration, the processes of creating, deleting, or modifying a flow are done manually by entering the package. I will show how to perform these processes through the CPI link. The aim of this blog is to highlight the flexible structure of CPI.

Required:

◉ SAP BTP and Integration Suite 

Cloud Integration Steps:

To demonstrate how all the processes work, I have covered them all in a single flow. This includes flow deletion, updating, creation, and the information we can retrieve related to the flow.

For a more straightforward architecture, I utilized process calls. Based on the type of request, process calls will be executed via the router.

The API we will use: https://{Account Short Name}-tmn.{SSL Host}.{region}.hana.ondemand.com/api/v1/IntegrationDesigntimeArtifacts

1 - The overall view of the flow:

Local Process 1 : POST

Local Process 2 : PUT

Local Process 3: GET

Local Process 4: DELETE

The reason we separate with the router is that some processes require mapping, while others do not.

2 - CM_Headers&Properties:

Our service works with a CSRF token, so we need to obtain the token first. In the initial content modifier, we store the request headers of the service.

Headers:

Properties:

We are storing parameters like Name, Id, PackageId, and Version in properties because we will use them in our services.

3 - HTTP Fetch Token:

A defined user must access CPI as an authorized user. After defining security materials, credentials are provided in the flow.

4 - CM_SetHeaders:

The service's response headers:

Content-type: application/atom+xml;type=entry;charset=utf-8

fetch-cookie : ${header.set-cookie}

cookie : ${header.fetch-cookie.replace("[","").replace("]","").replace("; path=/; secure; HttpOnly","").replace("path=/, ","")}

I defined "fetch cookie" to avoid getting a forbidden error due to cookies in the service.

5-Router:

6 - First Method : POST 

Since our goal is to create a flow using the POST method, here is the body we will send:

{

"Name": "string",

"Id": "string",

"PackageId": "Id of Package"

}

Message Mapping:

We stored the sent fields in properties in the content modifier. In the mapping, we will retrieve them from the properties.

OData V2- Connection and Processing:

Content Modifier:

Let's try it now in Postman.

Authorization:

CPI Technical User 

 

Body:

<Root>

    <Id>TestFlow</Id>

    <Name>TestFlow</Name>

    <PackageId>Testing</PackageId>

</Root>

GET METHOD:

We will obtain information about these artifacts by providing the Id and Version details from within the package.

/api/v1/IntegrationDesigntimeArtifacts(Id='${property.Id}',Version='${property.Version}')

Content Modifier:

Postman :

<Root>

    <Id>TestFlow</Id>

    <Version>1.0.0</Version>

</Root>

 PUT METHOD:

    

Postman:

Body:

<Root>

    <Name>ChangingNameTestFlow</Name>

    <Id>TestFlow</Id>

    <Version>1.0.0</Version>

</Root>

DELETE METHOD:

/api/v1/IntegrationDesigntimeArtifacts(Id='${property.Id}',Version='${property.Version}')

Content Modifier:

Postman:

Body:

<Root>

    <Id>TestFlow</Id>

    <Version>1.0.0</Version>

</Root>

Additional: A Groovy script exists within the subprocess to catch exceptions. I have embedded it into all local processes. Sometimes, error details don't propagate to the exception subprocess in the main flow, so you can embed them into local processes.