In this Lesson, the Following Topics are Discussed:
- Development with Cloud Integration.
- Technical Implementation.
- Development Cycle for Creating integration flow.
- Versioning of your integration flow.
- Developer test with real Deployment and Debugging of your integration flow.
- Developer test with Simulations of your integration and components.
Development with Cloud Integration
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 the following in particular:
- 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 time outs.
- 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 up-to-date 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.
Resources on a Tenant
The resources for a Cloud Integration implementation are limited.
Development Cycle for Creating Integration Flow
In the related exercises, we follow the principle of building professional integration flows.
To Create a Development Cycle, the Following Steps Must be Carried out in Order:
- Understand your use case.
- Configure the SAP BTP subaccount and the Integration Suite.
- Find the list of required API with all its metadata, such as credentials, headers, and more.
- Start in the Cloud Integration with an empty template.
- Modeling your processes.
- Build the integration flow bit by piece.
- Repeat the steps.
- What comes next?
Here are explanations about the steps:
- Understand your Use Case
Collaborating with the artifacts, the use case is thoroughly analyzed and the ISA-M 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 will be 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 this is not the case, you should 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 may initially seem simple, but it may 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.
- Simulation of integration flows.
- Test with real deploying and debugging. This approach is used in the exercises.
Both topics are examined in more detail below.
- 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 will be discussed in detail later. Once the testing is successful, the integration flow should 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.
Versioning of your Integration Flows
It`s important to version the development state periodically to allow for the possibility of reverting back to a previous version if necessary.
Procedure to Version Integration Flow:
- Start in your editable integration flow.
- Choose the Save as version button on top right.
- Enter a meaningful comment.
This approach is used in the exercises.
Procedure to Switch to Former Version:
- Start at your package.
- Mark your artifact (integration flow) in the list of available artifacts.
- Go to the column Version.
- Choose the version number.
- Choose a former version.
- Choose the symbol to change back to former version.
Developer Test with Real Deployment and Debugging of your Integration Flow
Before examining the integration flow, it needs to 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 will wait for an incoming message. Cloud integration offers a trace log level that provides insight into the processing of each integration flow component.
To Perform a Developer Test, the Following Steps Must be Carried Out in Order:
- Start at your integration flow.
- Choose the Deploy button.
- Choose a spot in the white space outside the integration flow swim lane.
- Choose the Deployment Status in the Integration Flow configuration area.
- If your integration flow is successful deployed, you will see a Navigate to Manage Integration Content link.
- Choose this link to jump to Monitor Artifacts → Overview → Manage Integration Content.
- Change the log level to trace.
- Deploy again if you use a timer starting event. Otherwise, send a message to the endpoint.
- If you deploy again, come back to Monitor Artifacts → Overview → Manage Integration Content.
- Here, choose the Monitor Message Processing link.
- In the new window, choose Monitor Artifacts → Overview → Monitor Message Processing. Choose the last message on the message list and choose it.
- Choose the Trace link to jump directly to Monitor Artifacts → Overview → Monitor Message Processing → Message Processing Run.
- Explore the trace of your flow.
This approach is used in the exercises.
Developer Test with Simulations of your Integration Flow and Components
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
In the DeDelayedDelivery_Process, we want to check through a simulation whether the ProductID is set correctly in the Modify_setProductIDAsProperty.
To Perform Developer Tests with Simulations, the Following Steps Must be Carried Out in Order:
- Choose a place on the line in front of the Splitter_iterateOverProducts component.
- Set the starting point via the context menu.
- Add the input message as a payload (content).
- Choose the line after the Modify_setProductIDAsProperty component.
- Set the end point of the simulation.
- The simulation navigation bar is now active.
- Start the simulation with the Start button of the navigation bar.
- Choose all envelopes between the start point and the endpoint to explore the results.
- After the testing, choose the Clear button of the navigation bar.
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.