Explaining the Development Cycle

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 takes place 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. That's why SAP recommends the latest Chrome browser.
• The browser sets timeouts.
• With poor network connection, there may be greater time delays of 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 sufficient 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, 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.

Here are explanations about the steps:

Understand your Use Case

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

Configure the SAP BTP subaccount and the Integration Suite

The next step involves providing integration developers with the relevant role collections, enabling them to work on the appropriate Integration Suite. This is coordinated with the administrators.

Find the List of Required API with all its Metadata, Such as Credentials, Headers, and More

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

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 will be 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.

Modeling 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 of this training, we focus on implementing one process. However, it is possible to outsource API calls to separate processes with their own error handling.

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. 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 deploying and debugging. This approach is used in the exercises.

Both topics are examined in more detail next.

Repeat the Steps

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

What Comes Next?

The first step is to test the process, and various testing procedures are discussed in detail later. Once the testing is successful, the integration flow is be transported to the production subaccounts. A 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 back 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 either execute immediately if a timer event is used, or it waits 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 useful 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

The process of 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 cycles, where the placement and configuration of components, debugging using trace log levels, and testing are repeated until the desired result is achieved.