Dynamic Interface on Cloud Integration - part 6

[nunocpereira3]

I’ll break this article into:

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

I hope our approach have given you some inspiration to try yourself to play around with the APIs and technology that is already there. In this final topic I would like to discuss some limitations and future goals for this interface. But first we start by what is supported already that was not discussed on this blog

• Conversion from receiving format from JSON to XML: On many cases we realized we couldn't use the interface because we received JSON but the interface is ready just for XML, therefore we added a new parameter that once present will transform it as part of an initial step
• Saving most parameters into custom headers: To make support life easier, we log as custom headers many of the parameters used so that they're searchable and easy to check
• Adding static headers present on the parameter files into the dynamic: We found that not only the body but sometimes the headers need to be adapted depending on the rule, therefore we support defining different headers according to different configurations and we inject them into the process
• Multiple http endpoints: We had one case where we had to distribute data into two or more different http urls sequentially so we incorporated that feature.
• Multiple http adapter configurations: If you realize for HTTP adapter, you can't supply some parameters in a dynamic way (such as with SFTP), therefore we need to get all possible router for http to be able to respect whatever combination is supplied on the parameters (Proxy Type, Auth type, etc). If SAP once delivers this mechanism, we only need to change in this iflow and it will be something internal, so our expectation is that no process will be affected 

Limitations

Now we cover some limitations:

• We support JSON as input translating into XML but we don't support converting from XML to JSON as output: We didn't have the need yet but an easy thing to incorporate
• We don't support JSONPath or JMESPath equivalents to XPATH and JSONata or Jolt for JSON transformations: We believe they're not very known by most developers and we rather stick into XML 
• All transformations we do are based on the current payload which might have been already transformed on previous steps of the rule execution. It can be that some of the key fields needed might not be there once you need them cause of a previous transformation: We can implement it whenever required to define on the lookup rules if the rule shall apply to the current or initially supplied XML
• We don't support different user roles: So far only the standard ESBMessaging.send

Future plans

For future, I had an idea to implement some wizard that would create this parameters behind the scenes so that they can be prefilled in a non technical way by our business analysts.

Usually they know the formats (the source XML and the required target XML) and they even have some samples, so I developed a sample UI5 app (still in progress and almost fully generated by Chat GPT 😀), that on left side expects input files (REQ) and their respective output files (RSP). In the middle we have a chat that is determining an XSLT and executing it against all REQ and RSP files provided to assert it works for the supplied samples provided. In this case as it's in development you see the xslt in the middle doesn't comply with the files provided, therefore on the right side you see the red results.

In the end the business analysts could generate a proposal of these files into our integration team where we would just have to validate the configuration files provided and enhance them further if needed.

Of course, all this progress happens behind the scenes (mostly at weekends or at end of the day) therefore the timelines for such things will likely take time and would be experimental.

Anyway, please comment with other ideas, improvements, problems, I'll be happy to hear and improve the process on our side.