Using Adapter Inbound Security

Objective

After completing this lesson, you will be able to Use and set up an inbound security adapter.

Adapter Inbound Security

In this Lesson, the Following Topics are Discussed:

  • Inbound Security for Adapters.
  • Inbound Security for an HTTP based Adapter.

Inbound Security for Adapters

Two cases need to be distinguished: establishing a secure connection to the load balancer and authenticating at the Cloud Integration tenant where the integration flow is implemented. To establish a secure connection, a Transport Layer Security (TLS) procedure is used over TCP (Transport Control Protocol)-based connections, and certificates are employed. This procedure is used in HTTPS, IMAPS, POP3S, SMTPS, FTPS, and other protocols. In the exercises of this training, we will use the SOAP adapter.

We want to explore the available options for ensuring that only authorized senders can send messages to our integration flow. This topic is referred to as Inbound Security.

  • The certificates required to establish an HTTPS connection between the sender and the load balancer are necessary.

  • The sender's authorization is validated against the integration flow endpoint.

Establishment of the HTTPS Connection

Recall the technical overview discussed in a previous lesson, which shows a Load Balancer between the sender and the endpoint URL of our deployed integration flow. As a result, it is necessary to establish the SSL connection between the sender and the Load Balancer.

The responsibility of importing all the required certificates lies with SAP, as we do not have access to the load balancer in cloud integration.

Authorization of the Sender Against the Endpoint of the Integration Flow

There are also two options available here:

  • Authentication can be performed directly against the remote tenant where the integration flows are deployed.
  • Usage of an authentication client (OAuth) on your own tenant.

Authentication can be performed directly against the remote tenant where the Integration Flows are deployed

This is the most common scenario during development, however, it is not recommended for production use. This option is marked in red as No. 1 in the picture above.

Procedure

  • Create your integration flow sender adapter and choose User Role as Authorization.
  • At User Role, choose the available user roles.
  • The default user role is ESBMessaging.send.
  • Assign the user role ESBMessaging.sendto a Role Collection.
  • Assign your Role Collection to a user at your subaccount.
  • Call the endpoint with a user who is assigned to your Role Collection with the ESBMessaging.send role included.

Note

It is not recommended to use client certificates for authorization. This approach requires importing a client certificate directly into the configuration.

Role Collection, A_sendMessagesToCI with the role MessagingSend assigned to two users.

Note

The role MessagingSend in the context of this situation is equivalent to the role ESBMessaging.send in the Cloud Integration.

You will get a successful call to the endpoint using one of the assigned users.

Set your own User Role at Cloud Integration

You may want to use your own user roles. To set your own user role, navigate to Monitor ArtifactsIntegrationsMange SecurityUser Roles, and set your own role.

Set your own user role, for example, Peter1:

Then, as previously described, you can configure your own user role:

  • Create a Role Collection.
  • Assign your own user role to your own Role Collection.
  • Assign the Role Collection to a user.

Usage of an Authentication (OAuth) Client on your own Tenant

The method of directly calling an integration flow via the role-based approach shown uses personalized users and basic authentication, which are not suitable for productive purposes. For better authentication methods, we need to use a self-configured OAuth2.0 client that can be created on our own subaccount.

To accomplish this, we need to set up a Process Integration Runtime instance on our subaccount, and associate it with the integration flow plan. This instance can then be customized with various client credentials. These correspond to No. 1 and No. 2, marked in blue in the picture above.

You can choose the following grand-types:

  • Authorization Code
  • Client Credentials
  • Password
  • Refresh Token
  • SAML2 Bearer
  • JWT Bearer

Selection of grand types when configuring the local Process integration Runtime instance.

Procedure

  • Create a local Process integration Runtime instance.
  • Configure the appropriate grand-type.
  • Create a key.
  • Use the key parameters for authorization.

The new Process Integration Runtime instance of plan integration-flow.

Sample - Log on with ClientID and ClientSecret

Use the clientID as user and the clientsecret as password.

Sample - Log in with Bearer Token

Use the tokenURL with clientIS as user, and the clientsecret as password to generate a Bearer token.

Use the Bearer token for authentication.

Sample - Log in with OAuth 2.0 Authentication

You can use OAuth 2.0 for authentication, which involves two steps: first, generating a token, and second, using that token for authorization.

Summary

Secure communication involves two steps: establishing a secure connection to the load balancer and authenticating at the Cloud Integration tenant where the integration flow is implemented. This is achieved by using certificates in TCP (Transport Control Protocol) based connections via TSL (Transport Layer Security) procedure. These protocols include HTTPS, IMAPS, POP3S, SMTPS, FTPS, and others. Many protocols such as SOAP, OData, HTTP, also use these secure communication protocols.

Authentication at the endpoint of the integration flow can be accomplished in two ways: direct assignment of a user role to a user or the use of a local OAuth 2.0 client that offers additional authentication options, such as ClientId/Clientsecret, Bearer Token, or OAuth 2.0. These methods are not personalized and are more secure than the first option.

Create an Inbound SOAP Adapter

Business Scenario

To initiate the process by receiving a SOAP message containing the list of ProductIDs, it's necessary to set up a SOAP-type inbound adapter.

Task Flow

In this exercise, you will perform the following tasks:

  1. Log on to the integration flow DelayedDelivery_Process.
  2. Create an Inbound SOAP Adapter.
  3. Save as version and deploy your integration process.

Prerequisites

The task of substituting the timer event with a message start event has been completed.

Outcome After This Exercise

You will get familiar on how to use and configure an inbound SOAP adapter in the integration flow.

What do you Learn Within This Exercise?

You will gain familiarity with configuring and utilizing an inbound SOAP adapter in the integration flow.

Exercise Options

To carry out this exercise, you can choose from the following options:

  1. Live Environment: Using the instructions provided below, you can perform the steps in your SAP BTP account.
  2. Platform Simulation: Follow the step-by-step instructions within the simulation.
  3. Side-by-side: Follow the step-by-step instructions within the simulation and perform the steps in your SAP BTP account simultaneously.

Note

We strongly recommend to perform the steps in the live environment.

Steps

  1. Log on to the integration flow DelayedDelivery_Process via Integration Suite.

    1. Navigate within the Integration Suite Welcome page to Design > Integrations > DelayedDelivery_Package_randomNumber > DelayedDelivery_Process.

    2. Following the status after the last exercise step.

    3. Imagine that the integration flow has been further edited.

  2. Rename the Sender.

    1. Choose the Sender component.

    2. Rename it to Sender_startSOAPMessage.

  3. Create an Inbound SOAP Adapter.

    1. Create and configure an Inbound SOAP Adapter.

    2. Drag the arrow from the context menu of the Sender_startSOAPMessage to Event_startMessage.

    3. Choose SOAP > SOAP 1.x.

    4. Switch to the Connection tab of the configuration bar. Enter the following data.

      Field NameInput Data
      Address/send/message/DelayedDelivery_Process/timestamp (must be unique)
      Service DefinitionManual
      Message Exchange PatternOne-Way (starting asynchronous)
      Processing SettingsWS standard
      AuthorizationUser Role
      User RoleESBMessaging.send
  4. Save as version, deploy, and debug your integration process.

    1. Perform the following steps.

      1. Save as version.
      2. Deploy.
      3. Jump to the Overview > Manage Integration Content.
      4. Set log level to trace.
    2. The process is initiated and waits for an incoming SOAP message. The endpoint to start the process should look like this:

      Code Snippet
      Copy code
      Switch to dark mode
      1
      https://int-cust-demo-store-xxxxxxxxxxxxxxxxxxxt.cfapps.eu10-003.hana.ondemand.com/cxf/send/message/DelayedDelivery_Process/061122
    3. Currently, we do not have the option to send a message to the endpoint.

Allow the Sender to Send Messages to the Endpoint of the iFlow

Business Scenario

We want to enable a channel to send messages to the endpoint, and to do this we need to assign a user the role of ESBMessaging.send, which is part of a Role Collection. Another way to define a role is by using a local process integration runtime, which can be assigned to a user.

Task Flow

In this exercise, you will perform the following tasks:

  1. Check the role ESBMessaging.send at Cloud Integration.
  2. Create a Role Collection at your SAP BTP subaccount.

Prerequisites

You have completed the final step of creating an Inbound SOAP Adapter.

Outcome After This Exercise

You will have configured security for your endpoint which allows your integration flow to receive messages.

What do you Learn Within This Exercise?

You will learn how to implement role-based inbound security for an integration flow.

Exercise Options

To carry out this exercise, you can choose from the following options:

  1. Live Environment: Using the instructions provided below, you can perform the steps in your SAP BTP account.
  2. Platform Simulation: Follow the step-by-step instructions within the simulation.
  3. Side-by-side: Follow the step-by-step instructions within the simulation and perform the steps in your SAP BTP account simultaneously.

Note

We strongly recommend to perform the steps in the live environment.

Task 1: Check the role ESBMessaging.send at Cloud Integration

Steps

  1. Find the configured role ESBMessaging.send at Cloud integration.

    1. Choose MonitorIntegrations and APIs.

    2. Find Manage Security > User Roles.

    3. Open User Roles tile.

    4. The role is defined but not yet assigned to a user.

Task 2: Create a Role Collection in the SAP BTP Subaccount

Steps

  1. Create a Role Collection in your SAP BTP subaccount.

    1. Navigate to the overview side of your subaccount.

    2. Choose the menu entry Role Collections.

    3. Choose the plus icon to create a new Role Collection. Set the name SendMessagesToCI.

    4. Choose the Create button. Use the search bar to navigate to your new Role Collection with name SendMessagesToCI.

    5. Choose the row with your Role Collection.

    6. In the new frame, choose the Edit button.

    7. Choose the list box entries.

    8. To take over the entry for MessagingSend, search for it and select the checkbox in the corresponding role. Only then will the role be applied.

      Note

      The role MessagingSend corresponds to the Cloud Integration role ESBMessaging.send.

    9. Choose the Add button at the bottom right of the mask.

  2. Assign the Role Collection to a user.

    1. Assign in the ID area, a user to this Role Collection.

    2. Choose the Save button.

    3. We now have a defined role MessagingSend that corresponds to the role ESBMessaging.send at No. 1, and an assigned user to this role via a Role Collection at No. 2.

Create an HTTP Client to Send SOAP Messages to an iFlow

Business Scenario

We will now explore three methods to send messages to an integration flow - using Postman, curl, and the Business Application Studio. It is important to be cautious while entering user and password details. Entering an incorrect password three times will result in the user being blocked for an hour.

Note

Choose one of the three options provided based on your working environment for the HTTP client.

Task Flow

In this exercise, you will perform the following optional tasks:

  1. Use Postman HTTP Client to send a message to the integration flow.
  2. Use curl to send a message to the integration flow.
  3. Create an HTTP Client with Business Application Studio.

Prerequisites

The last step has been completed, which involved creating an Inbound SOAP Adapter. As a result, your integration flow has been deployed and now has an endpoint.

Outcome After This Exercise

You now have the capability to send messages to the DelayedDelivery_Process using various HTTP clients.

What do you Learn Within This Exercise?

  • You will learn how to configure and utilize the Postman HTTP client for sending a SOAP message to the DelayedDelivery_Process.

  • Gain knowledge on how to use the curl HTTP client to send a SOAP message to the DelayedDelivery_Process.

  • Gain knowledge on how to create an HTTP client using Business Application Studio for sending a SOAP message to the DelayedDelivery_Process.

Exercise Options

To carry out this exercise, you can choose from the following options:

  1. Live Environment: Using the instructions provided below, you can perform the steps in your SAP BTP account.
  2. Platform Simulation: Follow the step-by-step instructions within the simulation.
  3. Side-by-side: Follow the step-by-step instructions within the simulation and perform the steps in your SAP BTP account simultaneously.

Note

We strongly recommend to perform the steps in the live environment.

Task 1: Option 1: Use Postman HTTP Client to Send a Message to the Integration Flow

Steps

  1. Get the Postman app.

    1. You can download postman API platform from: https://www.postman.com/downloads/ for free.

    2. Choose Workspaces.

    3. Choose the Create Workspace button.

  2. Configure a workspace.

    1. Enter a name and a description.

    2. Choose the Create Workspace button.

    3. To create a collection in your new workspace DelayedDelivery_Process, choose the New button .

  3. Configure a collection within the workspace.

    1. Choose the Collection button.

    2. Rename the collection to DelayedDelivery_Process_Collection. You have now a Workspace at No. 1 and a collection at No. 2.

  4. Configure an HTTP request.

    1. Choose the New button and choose HTTP Request.

    2. Enter your Endpoint URL of your DelayedDelivery_Process.

    3. First change the method to POST.

    4. Choose AuthorizationInherit auth fr..Basic Auth and enter your user and password of this user which has assigned the Role Collection SendMessagesToCI.

    5. Choose the Body tab.

    6. Choose rawXML.

    7. Enter the following SOAP message.

      Note

      It's possible to verify if the Product IDs exist in the database.

      Code Snippet
      Copy code
      Switch to dark mode
      1234567891011121314151617
      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <List> <Product> <ProductID>HT-1000</ProductID> </Product> <Product> <ProductID>HT-1020</ProductID> </Product> <Product> <ProductID>HT-1035</ProductID> </Product> </List> </soapenv:Body> </soapenv:Envelope>
    8. Choose the Save  button and rename your HTTP request while saving. 

  5. Send a Message.

    1. Choose the Send button.

  6. Navigate to Integration SuiteMonitorOverviewManage Integration Content.

    1. Choose Monitor Message Processing.

    2. Choose CompletedTrace.

    3. The process should run smoothly without any errors.

Task 2: Option 2: Use Curl to Send a Message to the Integration Flow

Steps

  1. Get curl.

    1. You can download cURL here: https://curl.se/. On the most systems it is preinstalled.

    2. Open a Terminal/Powershell and enter: curl -h. If it installed you will see something like this:

  2. Save the SOAP payload as a file local on your laptop.

    1. Copy the following payload to a file named soap.xml and save it to a designated folder on your laptop.

      Code Snippet
      Copy code
      Switch to dark mode
      12345678910111213141516
      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header/> <soapenv:Body> <List> <Product> <ProductID>HT-1000</ProductID> </Product> <Product> <ProductID>HT-1020</ProductID> </Product> <Product> <ProductID>HT-1035</ProductID> </Product> </List> </soapenv:Body> </soapenv:Envelope>
    2. Open your terminal in the directory where your soap.xml file is saved.

      Code Snippet
      Copy code
      Switch to dark mode
      1234
      curl -v --user <username>:<password> --header "Content-Type: text/xml;charset=UTF-8" --data @soap.xml < your endpoint url > Sample: curl -v --user xxxxxx:xxxxx --header "Content-Type: text/xml;charset=UTF-8" --data @soap.xml https://int-cust-demo-store-xxxxxxxxxxxx-003.hana.ondemand.com/cxf/send/message/DelayedDelivery_Process/061122
    3. The result is:

    4. Switch to your OverviewMonitor Message Processing monitor.

    5. Choose the Trace option to navigate deeper.

    6. The process should works without any errors.

Task 3: Option 3: Create an HTTP Client with Business Application Studio

Steps

  1. Create a subscription for Business Application Studio.

    1. In your subaccount navigate to ServicesInstances and Subscriptions.

    2. Choose the Create button.

    3. Enter the following data:

      Field NameInput
      ServiceSAP Business Application Studio
      Planstandard-edition
    4. Choose the Create button.

    5. Choose Users and in the Application area, choose SAP Business Application Studio.

    6. Assign the following Role Collections to your user as shown in the following image:

    7. Choose Assign Role Collection.

  2. Open the Business Application Studio on your SAP subaccount.

    1. Choose SAP Business Application Studio at Instances and Subscriptions.

  3. Create a Dev Space.

    1. Choose the Create Dev Space button.

    2. Set a name : HTTP_Client and choose the Basic radio button.

    3. The Create Dev Space button is located at the bottom right corner. It may take some time for the container to be set up. A successful notification displays once your Dev Space is up and running.

  4. Create an HTTP client.

    1. Choose the HTTP_Client link.

    2. On the Welcome page of the SAP Business Application Studio choose FileNew File.

    3. Enter DelayedDelivery_Process.http as name. Hit Enter.

    4. Confirm the location of your file, and choose the OK button.

    5. This is an active editor, and when you start typing in row 1, suggestions for the HTTP method will display. Select POST.

    6. After entering the endpoint URL, the color of the HTTP method changes to magenta indicating that it is a POST request.

    7. Select Authentication in the second row.

    8. Behind the Authorization entry start with BasicBasic Raw Credential (Space Separated).

    9. Enter your user and password separated with a blank.

    10. Post your SOAP message to row 4. Row 3 is empty.

  5. Send the SOAP message.

    1. Choose the Send Request link on top of the page.

    2. The process should run smoothly without any errors.

    3. You may also navigate to your monitor to view the results, if desired.

Remove the ?$top Parameter at Call_fetchLineItem

Business Scenario

We want to remove the stopper at Call_fetchLineItem. The reason is, that it is currently set to a maximum of 2 data records, but our observation showed that at least 1,400 data records are returned.

The following overview picture will help you to understand the iteration process.

How can we enhance the process resilience?

  1. We configure the SOAP adapter to start the process asynchronously, so the sender doesn't have to wait for the process to finish. This behavior is commonly referred to as "fire and forget".
  2. We use streaming in the adapter, when feasible.
  3. Instead of running steps sequentially, we can opt for parallel splitting to make the process more efficient.

Task Flow

In this exercise, you'll perform the following steps in one task:

  1. Remove the ?&top=2 parameter at Call_fetchLineItem.
  2. Version, deploy, and run the process.
  3. Handle large entries in the Monitor.
  4. Check out the configuration of the SOAP adapter.

Prerequisites

You have completed the final step of creating an Inbound SOAP Adapter, and your integration flow was deployed with an endpoint.

Outcome After This Exercise

Your integration flow process is expected to receive additional data records based on the status of the back end system.

What do you Learn Within This Exercise?

You will learn different techniques that can be useful for making API calls.

Exercise Options

To carry out this exercise, you can choose from the following options:

  1. Live Environment: Using the instructions provided below, you can perform the steps in your SAP BTP account.
  2. Platform Simulation: Follow the step-by-step instructions within the simulation.
  3. Side-by-side: Follow the step-by-step instructions within the simulation and perform the steps in your SAP BTP account simultaneously.

Note

We strongly recommend to perform the steps in the live environment.

Task 1: Remove the $top Parameter at Call_fetchLineItem

Steps

  1. Remove the &top=2 parameter at Call_fetchLineItem.

    1. Open the HTTP connection line at Call_fetchLineItem.

    2. Remove the &top=2 parameter.

  2. Version, deploy, and run the process.

    1. Perform versioning.

    2. Deploy your process and change the log level to Trace.

    3. Send a message to your process.

    4. Select one of the 3 available options to send messages as the process takes more than 6 minutes to run.

    5. Check out the data store.

    6. Navigate to MonitorIntegrations and APIsData Stores.

    7. 29 customers need to be notified about the delay in the delivery of the products. Be aware that the results of the customers(ID) could vary.

  3. Handle large entries in the Monitor.

    1. Check out the Overview > Monitor Message Processing. We see the process is running a long time.

    2. Navigate to the Trace for one of the two processes.

    3. With almost 30.000 process steps, it is impractical to manually review everything.

    4. Retrieving log entries via an OData API is possible, and it provides the ability to filter intelligently, which can be helpful when dealing with nearly 30.000 process steps.

  4. Check out the configuration of the SOAP adapter.

    1. Combine the One-Way Message Exchange Pattern with the ES Standard Process Settings, to make the call asynchronous.

      Note

      It is important to be mindful of any API calls present in your process.

Find out, What Happens Next

Business Scenario

We observed that the Data Store contains 29 CustomerIDs, which have a global visibility. This result implies that any external process can access and use these CustomerIDs.

  1. The following step is to verify the products that are already delivered.
  2. The next step is, that the communication data will be retrieved and the remaining customers will be informed via email.
  3. The entire process would also require documentation via another integration flow.
  4. It's important to remember that we need to test the flow as well.
  5. Utilize the OData API to efficiently filter through large volumes of data.
  6. Alerting is another topic that must be addressed in case of any issues during the process.
  7. It is necessary to ensure QoS (Quality of Service) of Exactly Once when informing customers.
  8. And other topics.

Log in to track your progress & complete quizzes