Get Started With Integration Flow Development (Cloud Foundry Environment)
Get Started With Integration Flow Development (Cloud Foundry Environment)
2019-12-06
Note
These exercises apply for both cases when you use SAP Cloud Platform Integration in the Neo and in the
Cloud Foundry environment.
However, note that at certain steps there are specific things to consider depending on the environment.
Whenever this is the case, it is indicated in this documentation.
A key part of an SAP Cloud Platform Integration project is to develop integration flows. An integration flow
allows you to specify how a message is processed on a tenant. The SAP Cloud Platform Integration Web UI
provides a modeling environment that allows you to design the details of message processing (its senders and
receivers as well as the individual processing steps) with a graphical user interface.
This section shows you step-by-step how to develop and run your first, simple integration flows. In other words,
it gives you an introduction to the tasks of an integration developer. We show you the design of four integration
flows, with increasing complexity.
Note
The first three integration flows are initiated by a timer and don't have a sender. This means that all tasks
related to setting up a sender system to SAP Cloud Platform Integration can be omitted.
The fourth integration flow is initiated by a request from a sender system which is simulated by an HTTP
client.
To complete the tasks, you use the SAP Cloud Platform Integration Web UI.
Before designing any integration flow of this section, you need to create an integration package first and, within
this integration package, create an integration flow. When you have created the integration flow, you add the
steps as described for the specific integration flow exercise.
● The first exercise shows you how to perform a simple smoke test to check whether your tenant cluster is
working correctly and that it processes messages in the expected way. A simple message is created with
the text Hello World! in the message body. The integration flow has no receiver. To check if the message
has been processed successfully, you can go to the monitoring application and check for the message
content there.
More information: Smoke Test Scenario [page 11]
● The second exercise shows you how to extend the smoke test scenario by adding an outbound call to an
external data source. The integration flow requests data exposed by the external component through an
OData application programming interface (API). The message body is created based on that data and, like
in the first exercise, can be displayed by the monitoring application.
More information: Smoke Test Scenario with External Data Source [page 20]
The exercises are designed so that you can do all four of them independently. All steps are described one-by-
one. But you can also start with the first one and, successively, enhance it to derive the second and the thirs
scenario out of the first one.
Note
Prerequisites:
● You have been given access to an SAP Cloud Platform Integration tenant and have integration
developer permissions assigned to your user (authorization group
AuthGroup_IntegrationDeveloper).
● Authorization group AuthGroup_BusinessExpert has been assigned to your user (to allow to assess
message processing log attachments).
● You have set up an e-mail account that you can use as the receiver system for the integration flow (only
required for third exercise with the Mail adapter).
● You have opened the SAP Cloud Platform Integration Web UI (the Web UI URL ends with /itspaces).
Related Information
The SAP Cloud Platform Integration Web UI is your one-stop shop for integration development.
Note that the URL to access the Web UI ends with /itspaces.
When you open the Web UI, the following page is displayed.
● Discover
Here, you can find predefined integration content provided by SAP that you can use out of the box and
adapt to your requirements. As the Getting Started documentation focuses on how to design your own
integration content, we do not go into any more detail on this section.
● Design
This is where you design your integration content. As you progress through the exercise in the Getting
Started documentation, you will spend most of your time in this section. It contains the graphical
integration flow modeling environment.
● Monitor
This is where you can monitor your integration flow. You also use this section to manage additional artifacts
that you need to deploy on your tenant to complement your integration flows (for example, User Credential
artifacts to configure connections using basic authentication).
Design Section
When you go to the Design section, you find a list of integration packages defined for the tenant.
When you select an integration package, you can find the integration flows (and other artifacts) defined for the
package (on the Artifacts tab).
In this Getting Started documentation, we assume that you have not yet defined an integration package for
your integration content. Therefore, the first step is to define an integration package.
Monitor Section
The Monitor section (also referred to as Operations view) has several subsections, each one containing several
tiles. These subsections allow you to perform various tasks that are required for an integration project in
addition to integration content design.
There are other sections and tiles that are required for additional tasks, but these are not required in the
Getting Started exercise, so we will not look at them in any more detail here.
An integration package is used like a folder for your integration content (integration flows, value mappings, and
OData services). You can transport an integration package, for example, if you want to design your integration
content on a test tenant first and then transport it to a production tenant.
1. Open the Web UI using the hyperlink provided to you in the mail from SAP (the links ends with /
itspaces).
2. Go to the Design section of the Web UI.
3. Choose Create.
4. Enter a name and description for your integration package and choose Save.
The integration flow is added to the list of artifacts for the selected integration package.
5. Select the integration flow from the list.
An integration flow template opens that contains the following shapes: Sender (this represents your
sender system), Receiver (this represents a receiver system), Integration Process (this will later contain all
the processing steps that define how a message is processed on the tenant). The Integration Process
shape contains a Start and an End event.
To start modeling, choose Edit. Notice that a palette appears to the left of the integration flow model. This
palette provides access to all integration flow step shapes that you can add to the model.
This is a very simple test to verify that your SAP Cloud Platform Integration is working as expected. You do not
need any receiver system to perform this test.
In this scenario, you create a Hello World text and write it into the message body (scheduled on deployment of
the integration flow). The result is written into the message processing log which you can directly inspect with
the message monitoring application.
Caution
This integration scenario is designed to show how to quickly (without much effort) set up and run an
integration flow without the need to configure and connect to any receiver system. It uses a Script step to
store the message payload in the message processing log (to enable you to easily check in the message
monitoring application if the message was processed without any errors).
Note that this is not according to standard best practice. When designing productive scenarios, don't store
the message payload in the message processing log. This can cause severe issues with memory
consumption. The reason is that tasks such as message processing and message monitoring share the
same memory and CPU which are available on your tenant.
In the course of this exercise, you develop the following integration flow.
To make it as easy as possible for you to develop this first integration flow, you don't need to configure any
sender system. That saves the effort for you to set up a dedicated sender system and to connect it to SAP
Cloud Platform Integration. Instead of this, message processing is triggered by a Timer event, and the inbound
message payload is created within the integration flow, in a dedicated Content Modifier step.
Furthermore, it is also not required that you set up any receiver system. To enable you to check if the message
has been processed correctly, you will configure the integration so that the message payload is written into the
message processing log (where you can easily inspect it using the Monitor application of the Web UI).
1. The Timer event triggers the processing of the message (according to the settings of the Timer's
scheduler).
2. The Content Modifier step creates a message with a simple text content (Hello World!).
3. The Groovy Script step logs the payload of the message (that means, it writes the message content into
the message processing log).
When you have finished the integration flow design, you save and deploy the integration flow.
Related Information
1. Open the integration flow model (Edit mode), select the Sender shape, and choose the recycle bin icon (to
remove the Sender shape).
Note
You can, of course, try out the other settings, which enable the Timer to start message processing
periodically. However, take care when selecting these options and you have added a receiver to your
scenario. For example, in another demo scenario provided in this documentation, the receiver of the
message is an e-mail account, and you don't want your e-mail account to be inundated with
periodically generated e-mails.
As the integration flow has no sender, we use a Content Modifier to create a message from scratch.
1. To add a Content Modifier, go to the palette, choose the Message Transformers icon, and select the Content
Modifier icon.
2. Place the Content Modifier in the model after the Timer Start event.
3. In the Content Modifier properties section, go to the Message Body tab and enter the following string
sequence in the entry field:
Hello World!
With a Groovy Script step, you can configure the integration in such a way that the payload of the message is
written to the message processing log as attachment.
1. To add a Script step (containing a Groovy script), go to the palette and choose the Message Transformers
icon and select the Script icon.
3. Place the Script step shape after the Content Modifier step and connect both shapes.
4. Select the Script step.
The context icons are displayed.
7. Replace this content by the script provided in the coding example below.
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message)
{
def body = message.getBody(java.lang.String) as String;
def messageLog = messageLogFactory.getMessageLog(message);
if(messageLog != null)
{
messageLog.addAttachmentAsString("Log current Payload:", body, "text/
plain");
}
return message;
}
8. Choose OK.
The integration flow model is again displayed.
Save and deploy the integration flow on the tenant to be able to process it.
2. Click Deploy.
A message is displayed that asks you to confirm this action.
Another message is displayed when the validation has been performed and the integration flow
deployment has been triggered.
Note
In case of a modeling error, instead of this message a Validation Failed message is displayed.
Only when you have fixed the error, deployment of the integration flow is triggered.
Open the integration package that contains the integration flow to deploy. Go to the Artifacts tab, click the
Actions button (next to the name of the integration flow which you like to deploy) and select Deploy.
Run the integration flow and check the result of message processing.
When the integration flow has been deployed successfully, the message is processed without any further
trigger (based on the settings of the timer).
1. Go to the Operations view and select a tile under Monitor Message Processing.
If your integration flow has been processed successfully, the status Completed should be shown.
2. Select the integration flow and analyze the details area to the right of the integration flow list.
This shows you that the message has been processed correctly.
This is a very simple test to verify that your SAP Cloud Platform Integration is working as expected. You do not
need any receiver system to perform this test.
In this scenario, you access an OData service and get information about a product (for a specific product ID).
The result is written into the message processing log which you can directly inspect with the message
monitoring application.
Caution
This integration scenario is designed to show how to quickly (without much effort) set up and run an
integration flow without the need to configure and connect to any receiver system. It uses a Script step to
store the message payload in the message processing log (to enable you to easily check in the message
monitoring application if the message was processed without any errors).
Note that this is not according to standard best practice. When designing productive scenarios, don't store
the message payload in the message processing log. This can cause severe issues with memory
consumption. The reason is that tasks such as message processing and message monitoring share the
same memory and CPU which are available on your tenant.
In the course of this exercise, you develop the following integration flow.
Furthermore, it is also not required that you set up any receiver system. To enable you to check if the message
has been processed correctly, you will configure the integration so that the message payload is written into the
message processing log (where you can easily inspect it using the Monitor application of the Web UI).
This is how the integration flow will process the message at runtime:
1. The Timer event triggers the processing of the message (according to the settings of the Timer's
scheduler).
2. The first Content Modifier step creates a message with only one element, a productIdentifier (to
identify a product from the product catalog).
The actual value of the productIdentifier is hard-coded in this step. If you like to process the
integration flow with another product identifier, you need to change the value in this step and re-deploy the
integration flow again. This is the drawback which results from abstaining from a dedicated sender system.
3. The second Content Modifier creates a message header (which we also call productIdentifier) and
writes the actual value of the productIdentifier element into it. This header will be used in the
subsequent step.
4. The Request Reply step passes over the message to an external data source and retrieves data (about
products) from there.
The external data source is represented by the lower WebShop shape.
The external data source supports the Open DataProtocol (OData). For our scenario, we use the ESPM
WebShop, which is based on the Enterprise Sales and Procurement Model (ESPM) provided by SAP. The
demo application can be accessed at the following address: https://espmrefapps.hana.ondemand.com/
espm-cloud-web/webshop/
For the connection to the WebShop, an OData receiver channel is used. To query for exactly one product
(for the product identifier provided with the inbound message), the header that has been created in the
preceding Content Modifier is used.
5. The OData service provides the details of one specific product (according to the product identifier provided
with the inbound message).
6. The Groovy Script step logs the payload of the message (that means, it writes the message content into
the message processing log).
You can then run the integration flow and monitor message processing as described under: Run the Integration
Flow and Monitor the Message Processing [page 29].
Related Information
As the integration flow has no sender, we use a Content Modifier to create a message from scratch.
1. To add a Content Modifier, go to the palette, choose the Message Transformers icon, and select the Content
Modifier icon.
2. Place the Content Modifier in the model after the Timer Start event.
3. In the Content Modifier properties section, go to the Message Body tab and enter the following string
sequence in the entry field:
Sample Code
<root>
<productIdentifier>HT-1080</productIdentifier>
</root>
4. Connect the Timer event with the Content Modifier. To do this, select the Timer event, click the arrow icon,
and drag and drop the cursor to the Content Modifier.
Add a Content Modifier to your model to define a header, which will be used in a later step to filter data from the
external source.
If you remember, our input message has only one field: productIdentifier. This field will contain a product
identifier that we want to use to filter the results from the WebShop application.
To make this number available to the integration framework during message processing, SAP Cloud Platform
Integration provides the option to store the value of productIdentifier from the incoming message either
in the message header or in a data container referred to as an exchange property.
We use the first option, and to prepare the message accordingly we use a Content Modifier.
1. Add a second Content Modifier (after the first one) to the integration flow model.
2. In the properties section of the second Content Modifier, go to the Message Header tab and choose Add.
3. Specify the following parameters:
○ Name: Enter any name, for example, productIdentifier. This is the name of the header that will be
created by the Content Modifier step.
○ Type: Select XPath.
Tip
In this example, you use an XML Path Language (XPath) expression to address a dedicated
element of your inbound message. XPath allows you to address any element in an XML structure
by using a well-defined syntax. The expression //<element name> addresses all elements with
name <element name> in the XML document.
4. Connect the first Content Modifier (which defines the message body) with the second one.
In other words, the Content Modifier creates a header with the name productIdentifier, which will contain
the value of the productIdentifier field of the incoming message.
To call the external data source, add a Request Reply step to the integration flow model and connect this step
with the external system using an OData channel.
Note
Follow this procedure in case you use SAP Cloud Platform Integration in the Neo environment.
Remember
There are currently certain limitations when working in the Cloud Foundry environment. For more
information on the limitations, refer to SAP Note 2752867 .
3. Place the Request Reply shape between the second Content Modifier and the End event in the model.
Furthermore, connect the second Content Modifier with the Request Reply step and the Request Reply
step with the End event.
4. Move the Receiver shape closer to the Request Reply shape (below the Request Reply shape but outside
the Integration Process shape, as shown in the overall integration flow model under Smoke Test Scenario
with External Data Source [page 20]).
5. Connect the Request Reply shape to the Receiver shape (by selecting the Request Reply shape, clicking
the arrow icon, and dragging and dropping the cursor on the Receiver shape).
6. In the next dialog, choose adapter type OData.
Note
This adapter supports different versions of the OData protocol. We select version 2.0.
8. Go to the Connection tab of the OData adapter and enter the following as the Address:
https://espmrefapps.hana.ondemand.com/espm-cloud-web/espm.svc
Tip
This is the endpoint address of the ESPM WebShop's OData application programming interface.
The Query Editor opens, where you can conveniently define the OData query.
The Address field is already populated with the value you just entered
11. Make sure that Remote is selected as the Connection Source, and choose Step 2.
The system connects to the WebShop service and retrieves the metadata from its OData API.
12. Choose the Search icon in the Select Entity field.
Tip
The dollar sign and the curled brackets indicate that we are dealing with Apache's Simple Expression
Language, which is often used in SAP Cloud Platform Integration. In particular, here you see a dynamic
parameter, which has the following effect: The value of the header productIdentifier (which is
identical to the value of the productIdentifier field of the incoming message) is used dynamically
at runtime to define the OData query.
With a Groovy Script step, you can configure the integration in such a way that the payload of the message is
written to the message processing log.
1. To add a Script step (containing a Groovy script), go to the palette and choose the Message Transformers
icon and select the Script icon.
3. Place the Script Step shape after the Request Reply step and connect both shapes.
4. Select the Script step.
The context icons are displayed.
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message)
{
def body = message.getBody(java.lang.String) as String;
def messageLog = messageLogFactory.getMessageLog(message);
if(messageLog != null)
{
messageLog.addAttachmentAsString("Log current Payload:", body, "text/
plain");
}
return message;
}
8. Choose OK.
The integration flow model is again displayed.
9. Save and deploy the integration flow.
Run the integration flow and check the result of message processing.
When the integration flow has been deployed successfully, the message is processed without any further
trigger (based on the settings of the timer).
1. When you have saved and deployed your integration flow, check the deployment status. Go to the Monitor
section of the Web UI and select a tile under Manage Integration Content.
3. Go back to the overview page of the Web UI Monitor section and select a tile under Monitor Message
Processing.
If your integration flow has been processed successfully, the status Completed should be shown.
Create a simple integration scenario that is initiated by a timer, retrieves data from an external source, and
sends the result to an e-mail account (as the receiver system).
A typical challenge addressed by an integration scenario is to retrieve data from a certain source (for example,
product details from a product catalog on a vendor's site) using certain filter criteria. We use the integration
flow described in this section to address such a use case.
In the course of this exercise, you develop the following integration flow:
To make it as easy as possible for you to develop this integration flow, you don't need to configure a sender
system. This saves you the effort of setting up a dedicated sender system and connecting it to SAP Cloud
Platform Integration. Instead, message processing is triggered by a Timer event, and the inbound message is
created within the integration flow, in a dedicated Content Modifier step.
● Update the tenant keystore with the certificates required by the mail server.
● Create and deploy a User Credentials artifact that contains the credentials of the mail account.
1. The Timer event triggers the processing of the message (according to the settings of the Timer's
scheduler).
2. The first Content Modifier step creates a message with only one element: a productIdentifier (to
identify a product from the product catalog).
The actual value of the productIdentifier is hard-coded in this step. If you want to process the
integration flow with another product identifier, you need to change the value in this step and redeploy the
integration flow. This is the drawback of not having a dedicated sender system.
3. The second Content Modifier step creates a message header (which we also call productIdentifier)
and writes the actual value of the productIdentifier element into it. This header is used in the
subsequent step.
4. The Request Reply step passes the message to an external data source from which it retrieves data (about
products).
The external data source is represented by the lower WebShop shape.
The external data source supports the Open DataProtocol (OData). For our scenario, we use the ESPM
WebShop, which is based on the Enterprise Sales and Procurement Model (ESPM) provided by SAP. The
demo application can be accessed at the following address: https://espmrefapps.hana.ondemand.com/
espm-cloud-web/webshop/
An OData receiver channel is used to connect to the WebShop. The header that was created in the
preceding Content Modifier is used to query exactly one product (using the product identifier provided with
the inbound message).
5. The OData service provides the details of this product.
6. Finally, the result of the request is forwarded to an e-mail account using the Mail receiver adapter (the e-
mail server is represented by the Mail_Ser … shape on the right in the integration flow model).
When you have finished integration flow design, you can monitor message processing.
This integration flow introduces you to a number of important aspects of integration development, such as
defining an OData query and using a message header to dynamically query an OData source.
Related Information
Update the Tenant Keystore with the Certificates Required by the Mail Server [page 34]
Create and Deploy a User Credentials Artifact for the E-Mail Account [page 36]
Create the Mail Receiver Channel [page 37]
Monitor Message Processing [page 40]
The tenant keystore contains the key pairs and certificates that are required (on the tenant side) to establish
trusted communication with the connected systems.
When establishing the connection to the SAP Cloud Platform Integration tenant, the e-mail server needs to
authenticate itself against SAP Cloud Platform Integration using a digital server certificate. For this purpose,
the tenant keystore must contain a root certificate that is also trusted by the e-mail server.
You can download the required certificates usually on a dedicated section of the email provider's website. You
might search for server certificate to get more information. However, note that the procedure might differ
depending on the email provider.
To get the e-mail servers' root certificate, you can do the following:
1. Open the website that hosts the mail account you like to address with the Mail adapter.
2. In the browser address field, click the lock icon and select Certificate (Valid) (example for using Google
Chrome).
3. In tab Certification Path doubleclick the uppermost node (which is the root certificate).
The root certificate is stored as file with extension .cer on your computer.
Finally, you need to import the downloaded certificates to the tenant keystore. To do this, open the Keystore
monitor.
1. Go to the Monitor section of the Web UI and select the Keystore tile under Manage Security.
All certificates that are already included in the keystore are displayed. If you have only recently started
working with SAP Cloud Platform Integration, these are the certificates provided by SAP initially when
providing the tenant for you.
2. Choose Add Certificate .
Note
You might also need to change the settings of your e-mail account so that the mail server accepts
connections to remote applications with a lower security level (for example, for Yahoo mail, this is the Less
Secure Apps setting). If you don't do this, the integration flow might raise an error during processing.
Note
If you don't upload the required root certificate to the tenant keystore and try to execute the integration
flow (when having finished its design), message processing will fail with the following error message
starting with:
Sample Code
Deploy a User Credentials artifact that contains the user name and password for your receiver mail account.
1. Go to the Monitor section of the Web UI and select the Security Material tile under Manage Security.
3. As Name, enter the User Credentials name that you specified in the Mail receiver adapter, and as User
enter the e-mail account user name (also specified in the fields From and To in the Mail receiver adapter).
Also provide the password of the mail account.
Note
Storing the user name and password in a separate artifact increases the security level of integration
development.
4. Choose Deploy.
Add a Mail receiver channel to enable the integration flow to send messages to an e-mail account.
1. First, add a second receiver to represent the e-mail account. In the integration flow model (in Edit mode),
select the Participants entry from the palette and select Receiver.
2. Place the Receiver shape on the right side of the model, outside the Integration Process shape.
You can rename the shape to Mail_Receiver (for example).
5. In the Mail adapter properties section (below the model), go to the Connection tab and specify the
following Mail adapter parameters.
The figure shows example settings, which are explained further below.
As you use a Timer event to trigger the message processing, the integration flow is processed as soon as it is
deployed.
1. To check whether the processing has been executed correctly, go to your e-mail account. You should find a
mail with the following content:
2. Finally, check how the message was processed by opening the Monitor section of the Web UI.
3. Choose a tile under Monitor Message Processing and you should find your message with the integration
flow name.
4. Open the integration flow in Edit mode, click the first Content Modifier and on the Message Body tab
change the value of the productIdentifier to HT-2001 and redeploy the integration flow.
5. Once the integration flow has been deployed successfully, you should receive an e-mail with details about
another product.
Create a simple integration scenario that is initiated by a sender (using the HTTPS sender adapter).
With the following steps, you can easily modify and extend the previously built integration flow with the email
receiver (Timer-Initiated Scenario with a Mail Receiver).
The figure shows the integration flow model that you get as a result of this exercise.
In the modified integration flow, an HTTP client instead of a Timer event triggers message processing.
Furthermore (to simplify the design), we have merged the steps processed by two different Content Modifier
steps in the previously built integration flow into one Content Modifier step.
Note
As a prerequisite to execute this integration flow in the Cloud Foundry environment, you need to authorize
the sender system (HTTP client) to call the integration flow endpoint. For that purpose, you create a service
instance on SAP Cloud Platform and generate service key credentials (which can then be used by the HTTP
client to call the integration flow endpoint).
1. The HTTP client (represented by the Sender shape) sends an HTTP request to SAP Cloud Platform
Integration through an HTTPS sender channel. The HTTPS request body, which is in JavaScript Object
Notation (JSON) format, contains a product identifier.
2. The JSON-to-XML converter transforms the request body into XML format (which can be processed in the
following step, the Content Modifier).
3. The Content Modifier creates a message header (which we also call productIdentifier) and writes the
actual value of the productIdentifier element into it. This header is used in the subsequent step.
In this exercise, you use one Content Modifier to create the header and to write the message body.
4. The Request Reply step passes the message to an external data source and retrieves data (about orders)
from there.
The external data source supports the Open DataProtocol (OData). For our scenario, we use the ESPM
WebShop, which is based on the Enterprise Sales and Procurement Model (ESPM) provided by SAP. The
When you have finished the integration flow design, you can send the message through the HTTP client.
Related Information
You perform these steps to authorize the sender (HTTP client) to call the SAP Cloud Platform Integration
integration flow endpoint.
Note
You need to perform these steps only in case you use SAP Cloud Platform Integration in the Cloud Foundry
environment.
These steps imply that you create a service instance on SAP Cloud Platform and generte a service key for it.
The credentials which you get as a result can be used by the HTTP client to call the integration flow endpoint.
In the context of this scenario, you can think of the service instance as a technical user that can be associated
with the sending system's (HTTP client's) request.
You perform the following steps using SAP Cloud Platform Cockpit.
3. Choose Next.
4. Enter the below command in the entry field.
Sample Code
{
"roles":[
"ESBMessaging.send"
]
}
With this command, you associate the service instance with the role ESBMessaging.send which is
required to call an integration flow endoint.
With this step, you generate credentials to communicate with a service instance.
The sender application (HTTP client) uses these credentials (clientid and clientsecret) to access the
SAP Cloud Platform Integration integration flow endpoint.
You need to copy the values of clientid and clientsecret to your clipboard or to a text editor for later
reference.
These values specify the credentials of the user associated with the sending application.
Add an HTTPS sender channel to enable the integration flow to receive HTTP requests.
Note
If you choose the information icon, the version of the integration flow component is displayed.
Do not confuse the version of an individual integration flow component with the software version of
SAP Cloud Platform Integration. An integration flow component gets a new version each time a new
feature is added to it by SAP. Let's imagine a situation where you started modeling an integration flow
some time ago and now want to continue working on it. Let's assume that SAP has updated the
software in the meantime. A new version of an integration flow step or shape that you have used is now
available, containing a new feature. You can continue to use the old component version, but if you want
to use the new feature you need to update to the new version.
3. Click the arrow icon and drag and drop the cursor on the Start event.
The list of available adapter types is displayed in a dialog.
Add a JSON-to-XML converter to convert the HTTP request, which is in JavaScript Object Notation (JSON)
format, to XML for further processing.
With the HTTP client, we send a POST request with a request body in JSON format. To enable the subsequent
steps to process the message, it needs to be converted to XML first. To perform the required conversion, you
can use the JSON-to-XML converter.
1. In the palette, select the Message Transformers entry and then choose Converter.
Set up an HTTP client using Postman and send the HTTP request.
You can now send the POST request to the integration flow.
1. Specify the same authentication settings as for the GET request above.
Sample Code
{
"productIdentifier": "HT-1080"
}
3. Copy the value of the CSRF token (obtained from the GET request above) to the clipboard.
4. Add a header to the request.
In the Key field, enter X-CSRF-Token and in the Value field, enter the value of the CSRF token from your
clipboard.
5. Send the request.
You should get the details of the product with productIdentifier HT-1080.
6. Go to the e-mail account specified in the Mail adapter. You should have received an e-mail like this:
7. Place another POST request with a body containing productIdentifier HT-2001, and you receive details of
another product.
8. Finally, check how the message was processed by opening the Monitor section of the Web UI.
Choose a tile under Monitor Message Processing and you should find your message with the integration
flow name.
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.