Your first iFlow in Cloud Integration: expose a REST API over HTTPS

The simplest iFlow worth building: someone calls your endpoint in Cloud Integration and, behind the scenes, you query a REST API and hand back the result. It is the basis of any proxy scenario: adding security, changing formats, or hiding the real system behind a stable URL.

Client ──HTTPS──▶ [ iFlow RestAPI ] ──HTTP GET──▶ Public REST API
       ◀──────── response ◀──────────────────────

As the target we use https://api.restful-api.dev/objects, a public test API that requires no authentication.

What you need

• A SAP BTP account (a trial works) with Integration Suite and the Cloud Integration capability enabled.
• An instance of the Process Integration Runtime service (plan integration-flow) with the ESBMessaging.send role, plus a service key for it. That is the “technical account” a client will use to call the iFlow.

1. Package and iFlow

In Integration Suite: Design → Integrations and APIs → Create a package (for example, Tutorials) and, inside it, Add → Integration Flow named RestAPI.

The editor opens an empty iFlow with a Sender, an Integration Process (with Start and End) and a Receiver.

2. Sender: who can call

Connect the Sender to Start and pick the HTTPS adapter. On the Connection tab:

Field	Value	Why
Address	/restapi	Your endpoint path: it becomes https://<your-runtime>/http/restapi
Authorization	User Role	Only callers with the role get in
User Role	ESBMessaging.send	The role of the service key from the prerequisites
CSRF Protected	unchecked	So you can call it with a plain curl; reconsider for production

3. Request Reply: call the API

From the palette, add a Request Reply (Call → External Call → Request Reply) between Start and End, and connect it to the Receiver with the HTTP adapter:

Field	Value
Address	https://api.restful-api.dev/objects
Method	GET
Authentication	None (the test API does not require it)
Timeout (in ms)	60000
Request Headers	traceparent (optional: forwards the client’s tracing header)
Response Headers	*

Request Reply is synchronous: the iFlow waits for the API’s answer and carries on with it as the new message body. That is why the client receives the API’s JSON directly.

Where to transform the response? Add a Content Modifier between Request Reply and End. With the body set to the expression ${body} the message passes through untouched; it is the natural place to later set headers, properties or a mapping.

4. Deploy

1. Save and Deploy.
2. In Monitor → Integrations and APIs → Manage Integration Content, wait until the iFlow is Started.
3. Copy the endpoint URL shown in the details: it ends in /http/restapi.

5. Call it with an OAuth token

Using the service key data (clientid, clientsecret, tokenurl), request a token:

curl -X POST "<tokenurl>" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=<clientid>" \
  -d "client_secret=<clientsecret>"

The response contains an access_token. Use it to call the iFlow:

curl "https://<your-runtime>/http/restapi" \
  -H "Authorization: Bearer <access_token>"

You should get back the JSON list of objects returned by the public API.

Security: the service key is a credential. Do not paste it into documentation, screenshots or repositories; in a team, keep it in a secrets manager.

6. See what happened: monitoring

In Monitor → Integrations and APIs → Monitor Message Processing you will see each call with its status (Completed or Failed).

While developing, raise the iFlow’s log level (in Manage Integration Content → Log Configuration) to see the details of every step. Lower it afterwards: storing everything for every message has a cost and may expose data.

Response	Usual cause
401 / 403	Expired token, or a service key without the ESBMessaging.send role
404	Wrong path: the endpoint is /http/ + the Sender’s Address
500	An internal step failed (for example, the API did not answer in time). The details are in the message log

7. Improvement: do not hard-code the URL

Right now the API address is written inside the iFlow. If tomorrow there is a test API and a production one, you would have to edit the iFlow in every environment.

The fix is to externalize the parameter: in the HTTP adapter, write the address as {{ReceiverURL}}. On deployment, Configure asks for the value, and each environment (DEV, TEST, PRD) gets its own without touching the design.

That is exactly the step that lets you transport the iFlow across environments with Cloud Transport Management (CTMS), covered in another tutorial.

Summary

• HTTPS Sender + role: who can call, and on which path.
• Request Reply + HTTP: whom the iFlow calls, and how.
• OAuth token from the service key: how the client authenticates.
• Monitor: where to see the outcome of each call.
• Externalized parameters: the first step for an iFlow that travels across environments.