- SAP Managed Tags:
The migration tool that helps you to migrate integration scenarios from SAP Process Integration / SAP Process Orchestration to SAP Integration Suite is based on a set of integration flow templates. When you run through the migration wizard within the Cloud Integration editor, the template which fits best to your source integrated configuration object will be identified. If no such template exists yet, a default template is proposed so that at least the mappings and schemas are automatically uploaded when generating the integration flow.
Right now, not all scenarios are supported, we are constantly working on increasing the scenario coverage by adding more templates with upcoming software updates. For a list of supported templates, check out the Supported Templates documentation.
In this blog, I would like to explain the enhancements that we did improving the readability and supportability of the generated integration flows.
As an example, let’s take a look at the P2P_SYNC_0001 template which is applied to synchronous scenarios between a sender and a receiver system including mappings for both the request message and the response message.
As you can see, we have added a content modifier step called Maintain Headers. In this content modifier step, we actually create the standard headers SAP_Sender, SAP_Receiver, and SAP_MessageType.
When generating the integration flows, SAP_Sender and SAP_Receiver are automatically set based on the business component names in the integrated configuration object. The SAP_MessageType is not automatically mapped with the service interface name since this may be misleading, however you have the option to manually maintain this either using the service interface name, the underlying message type or any value identifying the integration scenario.
This actually improves the supportability in the message monitor allowing you to search your messages based on those headers.
For the mappings, we have defined local integration processes. This way, the readability of the integration flow model is better. Furthermore, it’s easier to add the sequence of mappings when automatically generating the integration flow, but it’s also more convenient for you to manually add further mappings to the sequence of mappings.
For the main integration process as well as for the local integration processes, we have added exception subprocess pools so that you have the option to set up your own exception handling.
Hopefully those enhancements add value to the generated integration flows. If you have further ideas how the templates can be improved, please let us know, we are more than happy to learn from your experience when running migration projects. So, simply add a comment below this blog post.
Right now, not all scenarios are supported, we are constantly working on increasing the scenario coverage by adding more templates with upcoming software updates. For a list of supported templates, check out the Supported Templates documentation.
In this blog, I would like to explain the enhancements that we did improving the readability and supportability of the generated integration flows.
As an example, let’s take a look at the P2P_SYNC_0001 template which is applied to synchronous scenarios between a sender and a receiver system including mappings for both the request message and the response message.
1. SAP headers
As you can see, we have added a content modifier step called Maintain Headers. In this content modifier step, we actually create the standard headers SAP_Sender, SAP_Receiver, and SAP_MessageType.
When generating the integration flows, SAP_Sender and SAP_Receiver are automatically set based on the business component names in the integrated configuration object. The SAP_MessageType is not automatically mapped with the service interface name since this may be misleading, however you have the option to manually maintain this either using the service interface name, the underlying message type or any value identifying the integration scenario.
This actually improves the supportability in the message monitor allowing you to search your messages based on those headers.
2. Local integration processes
For the mappings, we have defined local integration processes. This way, the readability of the integration flow model is better. Furthermore, it’s easier to add the sequence of mappings when automatically generating the integration flow, but it’s also more convenient for you to manually add further mappings to the sequence of mappings.
3. Exception subprocesses
For the main integration process as well as for the local integration processes, we have added exception subprocess pools so that you have the option to set up your own exception handling.
Hopefully those enhancements add value to the generated integration flows. If you have further ideas how the templates can be improved, please let us know, we are more than happy to learn from your experience when running migration projects. So, simply add a comment below this blog post.
1 Comment
| User | Count |
|---|---|
| 24 | |
| 20 | |
| 20 | |
| 19 | |
| 14 | |
| 12 | |
| 9 | |
| 8 | |
| 7 | |
| 7 |
