Dynamic Interface on Cloud Integration - part 4

[nunocpereira3]

I’ll break this article into:

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

As with any interface, this generic iflow is split in three parts:

1. The receiver protocol
2. Transformations
3. The sender

Receiver

To receive the data from our consumers we support AS2, HTTP, AMQP adapter, AdvancedEventMesh adapter. I'll not show here all details but lets go through some of the most interesting parts.

If you remember from part 2, the url for our scenario was:

https://<cloudintegrationrturl>/http/TestpackageNUPE/FER_DynamicInterfaceTransformAndRoute/NUPEBPAPOC

By configuring our receive as above (with the * wildcard), we allow any interfaceid to come as part of the request. How do intercept which interface id have we received? Using a content modifier as below

Transformations

With this key id, we have everything we need not to check which configuration exists for this on partner directory. This can be achieved by querying the Partner Directory API as done below:

def service = ITApiFactory.getApi(PartnerDirectoryService. class , null);
    if (service == null) {
        throw new IllegalStateException("Partner Directory Service not found");
    }
    def messageLog = messageLogFactory.getMessageLog(message);
    if (messageLog != null) {
        messageLog.addCustomHeaderProperty("FER_InterfaceID", interfaceId);
    }
    try {
        def lookupRules = service.getParameter("LookupRules", namespace + interfaceId, String. class);
        if (lookupRules != null) {
            def decodedBytes = Base64.getDecoder().decode(lookupRules)
            String lookupRulesText = new String(decodedBytes, "UTF-8");
            logMessage <<= "Found lookup rules [${lookupRulesText}] for partner id [${namespace+interfaceId}]\n";

Then we parse the lookupRules file loaded and we iterate all rules there one by one. I'll save you from those details, it's just groovy code. 

After complete iteration we'll have the final parameter set and values and the payload was transformed already according to the respective rules.

If something goes wrong (an exception is thrown), or if we want to see the details of all lookups and transformations and intermediate payloads we can enable debug or trace into the iflow. In any of these cases we'll then dump a TraceLog file into the MPL as attachment so that it can be checked later on by our support team.

String logLevel = message.getProperty('SAP_MessageProcessingLogConfiguration').logLevel.toString()
        if (logLevel in ['DEBUG', 'TRACE'] || (traceLog!=null && !"".equals(traceLog))) {
            logMessageAsAttachment = true;
        }
    } catch (Exception ex) {
        logMessageAsAttachment = true;
        throw ex;
    } finally {
        if (logMessageAsAttachment && isLoggingOnErrorEnabled) {
            String logMessageStr = logMessage.toString()
            message.setProperty("log", logMessageStr)
            messageLogFactory.getMessageLog(message)?.addAttachmentAsString('TraceLog', logMessageStr, 'text/plain')
        }
    }

Sender

Now we can optionally have a process direct step (depending on the configuration files defined) pointing into a custom iflow

This can be very handy whenever the target requires a non-standard delivery approach (fetching special tokens or nounces, etc). If that's the case we can still leverage all transformations done before and use the process direct just to develop the delivery part.

If the target is quite standard, it will likely fall into something our generic iflow already supports. For sending the data we support the following adapters: HTTP, IDOC, AdvancedEventMesh, AMQP and SFTP. Others can be added later if needed but for now, we had no need to enhance it further.

In this chapter we covered everything from "runtime" perspective, meaning picking the configurations from partner directory and executing according to the payload that was supplied. On next chapter we'll talk about unit testing

As usual, feel free to provide ideas or suggestions based on your experience