Dynamic Interface on Cloud Integration - part 1

[nunocpereira3]

Last year at SAP TechEd, I was fortunate to showcase some of our self-developed innovations at Ferring (in case you missed it, you can see the recording here: https://www.sap.com/events/teched/virtual/flow/sap/te24/catalog/page/catalog/session/172357859067500...). One of them was an implementation of a dynamic interface.

This weekend I finally had some time to at least start sharing our approach with the community. 

I’ll break this article into:

• Problem/Context (this link)
• Our approach
• Git into Partner Directory
• Generic iflow
• Automated unit testing
• Limitations and Future plans

Problem/Context

Nowadays we have many requests for new interfaces (mostly xml based) where some simple transformation needs to be applied and then sent to a target (via SFTP, HTTP, AS2, etc). I think this is a very common request that can become a pattern. Together with the team we discussed that we will be able to become more agile when receiving such simple requests, and not need to assign a developer to create new interfaces for every new scenario that would fall into this pattern.

Example

Let's say you have xml below coming from S4 and you want to apply different transformations to it depending on it's content and also send to different target urls according to some content rules.

Example one for APAC region:

<?xml version="1.0" encoding="UTF-8"?>
<root>
    <process>CreateBatch</process>
    <region>APAC</region>
    <prod_date>20240730</prod_date> <!-- format of dates in S4 is yyyymmdd -->
    <quantity>1000</quantity>
    <batch>1</batch>
    <batchplant>CH01</batchplant>
    <country>SG</country>
    <material>12345678901</material>
    <!-- other fields not relevant for this demo -->
</root>

Example 2 for EMEA region

<?xml version="1.0" encoding="UTF-8"?>
<root>
	<process>CreateBatch</process>
	<region>EMEA</region>
	<prod_date>20240730</prod_date> <!-- format of dates in S4 is yyyymmdd -->
	<quantity>1000</quantity>
	<batch>12345</batch>
	<batchplant>CH01</batchplant>
	<material>12345678901</material>
	<country>CH</country>
	<!-- other fields not relevant for this demo -->
</root>

Let's assume that we need to have the following rules / requirements

Ok, we've got our requirements, how would you implement them?

If I think in cloud integration terms, perhaps creating an iflow that would extract the required fields and have all these routers with different XSLT transformations for each router to finally send it to the different urls. This would lead to an iflow specific to this particular scenario, which in the end after several requests like this becomes hard to maintain all these independent iflows.

In this part we've explored the motivation for developing such a generic iflow. In the next part we'll have a look at the architecture followed and we would detail the implementation for this specific demo scenario.

In the meantime you can think and comment of your own approach to this problem