Developing Integration Content

Cloud integration is a subscription service, which means that graphical modeling and processing of the process steps, among other things, occur on the subaccount where you registered for the service. The consumer and provider subaccounts are located in the same region, such as eu10 (Frankfurt), and communication occurs directly via the browser. Therefore, all content displayed in the browser is delivered as an HTML data stream. The URLs for different levels are provided below, and in all cases, we are located in the eu10 region. The cloud integration URL begins with the subdomain of your subaccount, followed by the specific domain and the context path.

• URL of your subaccounts (No. 1): https://emea.cockpit.btp.cloud.sap
• URL of the Integration Suite (No. 2): https://.integrationsuite.cfapps.eu10-003.hana.ondemand.com/shell/home
• URL of the Cloud Integration (No. 2): https://.integrationsuite.cfapps.eu10-003.hana.ondemand.com/shell/design

When working, this means:

• All the available capabilities are used via the browser.
• The browser decides on the presentation. Therefore, SAP recommends the latest Chrome browser.
• The browser sets timeouts.
• A poor network connection may lead to greater time delays in the response.
• You can work with any device as long as the screen is large enough, an updated Chrome browser is available, and there is a stable internet connection.

• You need at least the PI_Integration_Developer Role Collection.

As mentioned at the outset, the core of the system is the Camel integration framework. SAP enhances the Camel framework with a graphical client and various security features. The complete implementation is a Java application and comprises the following components:

The first component (No. 1), is your browser, which accesses the implementation via the Cloud Integration URL to create and manage the integration flow. The second component (No. 2) is the graphical interface.

Once the integration flow is created, and if it is deployed as a Java application on the runtime (Cloud Foundry, Kyma), (No. 4) messages can be transmitted using the sender component (No. 3) and received using the receiver component (No. 5).

A load balancer (IP5) is connected to the sender input (No. 3), and interestingly, it does not go directly to the runtime.

In the related exercises, we follow the principle of building professional integration flows.

Let's learn about these steps in detail.

1. Understand the use case:

   Collaborating with the artifacts, the use case is thoroughly analyzed and the SAP Integration Solution Advisory Methodology is applied to address all requirements.

2. Configure the SAP BTP subaccount and the Integration Suite:

   Provide relevant role collections to the integration developers, enabling them to work on the appropriate Integration Suite. This is coordinated with the administrators.

3. Find the list of required APIs with all their metadata, such as credentials, headers, and more:

   If all APIs are listed in an API Business Hub Enterprise, obtaining the necessary URL and parameters is completed. However, if not, you can plan enough time to obtain this data and test the interfaces.

4. Start in the Cloud Integration with an empty template:

   Create a package with a meaningful name. Here is a proposal for name conventions: Naming Conventions.

   To start, select the integration flow artifact, and an empty template is created automatically. If an incoming message is needed, it can be simulated using a Timer event to start and a Content Modifier to simulate the message. This approach facilitates faster and easier development cycles.

5. Model your processes:

   It can be difficult to establish clear criteria for process development. Sometimes, a process can initially seem simple, but it can later be broken down into multiple individual processes. It is important to consider that the process must be understood by the specialist staff in the future. In the exercises covered in this training, we focus on implementing one process. However, it is possible to outsource API calls to separate processes with their own error handling.

6. Build the integration flow bit by piece:

   There are various ways to develop integration flows depending on the use case. For the practical exercise, it is recommended to start with the API calls. Once the connections are established, it becomes easier to determine the required input and output. Unlike XI or PI with its XI message protocol, there is no internal format in cloud integration. Thus, it is important to consider the internal formats and transformations needed. The help section for each integration flow component can be used to find the appropriate configurations. This process is also demonstrated in the exercises covered in this course. After configuring a component, it is essential to debug and verify that the output meets our expectations. Generally, there are two ways to test our integration flow:

   These are:

   • Simulation of integration flows.
   • Test with real deployment and debugging. This approach is used in the exercises.

   These topics are discussed in more detail later in the course.

7. Repeat the steps:

   Iterate through the steps until your integration flow functions as intended.

8. What comes next:

   Test the process; various testing procedures are discussed in detail in the subsequent topics. Once the testing is successful, the integration flow is transported to the production subaccounts. Continuous monitoring of the processing or implementation of alert management to respond to unforeseen events is the responsibility of the administrators and will not be addressed separately here.

It is important to version the development state periodically to allow for the possibility of reverting to a previous version if necessary.

Before examining the integration flow, it must be deployed in the monitoring environment. The graphical model is converted into a Java application and placed in the runtime, allowing the integration flow to be started. If the deployment is successful, the integration flow will execute immediately if a timer event is used, or it will wait for an incoming message. Cloud integration offers a trace log level that provides insight into the processing of each integration flow component.

Simulating individual parts or the entire integration flow can be helpful to verify if values are correctly set in a content modifier or if a script or mapping is executed as expected. However, not all integration flow components are supported for simulation.

Here is the list of supported integration flow components: Simulation of an Integration Flow

Creating an integration flow involves using a graphical editor in the remote cloud integration application. Simulations can be conducted on individual parts or the entire integration flow to verify that values are correctly set in content modifiers, scripts, or mappings. Once the integration flow is complete, it is versioned and deployed, resulting in the creation and deployment of a Java application in a runtime. The integration flow can then be executed. The development process can be approached as a cycle, where the placement and configuration of components, debugging using trace log levels, and testing are repeated until the desired result is achieved.