ProcessDirect Adapter

Are you facing high network latency while establishing inter-communication between integration flows in SAP Cloud Platform Integration platform?

ProcessDirect adapter is the solution for you. You can use ProcessDirect adapter to provide direct communication between two integration flows and unlike HTTP/SOAP adapter communication between two integration flows will not be routed via load balancer.

Terms to keep in mind while working with ProcessDirect adapter:

Producer Integration flow:

When the ProcessDirect adapter is used to send data to other integration flow, we consider the integration flow as a Producer integration flow. This is when the integration flow has a ProcessDirect Receiver adapter.

Consumer integration flow:

When the ProcessDirect adapter is used to consume data from other integration flows, we consider the integration flow as a Consumer integration flows. This is when the integration flow has a ProcessDirect Sender adapter.

ProcessDirect Adapter Offerings

• Allow multiple integration developers to work on the same integration scenario
• Reuse of integration flows across integration projects
• Decomposition of Integration Flows

For detailed information on the ProcessDirect offerings, see the Help portal documentation.

Yes, we know you might be using HTTP, SOAP or JMS queue adapters to decompose/split the integration flow into smaller integration flows.

Look at the below comparison chart to see what ProcessDirect adapter offers you over and above all:

 

ProcessDirect adapter improves network latency, as message propagation across integration flows do not involve load balancer. For this reason, we recommend that you consider memory utilization as a parameter in scenarios involving heavy payloads and alternatively use HTTP adapter in such scenarios because the behavior will be the same.

 

Basic Configuration Settings for ProcessDirect Adapter

In this scenario, we are creating a producer and a consumer integration flows with the content modifier, wherein the message body is sent from producer to consumer and it is received via email configured at the consumers integration flow.

In producer integration flow, we are using HTTPS adapter at the sender end and ProcessDirect adapter at the receiver end.

Producer Integration Flow:

1. Select the HTTPS adapter and go to Connection tab.
2. Provide the producer address.
   Note: if your project is not CSRF protected, ensure to disable CSRF Protected checkbox.
3. Select Content Modifier and go to Message Body tab.

Consumer Integration Flow:

In Consumer integration flow, we are using ProcessDirect adapter at the sender end and SFTP adapter at the receiver end.

1. Select the ProcessDirect adapter and go to Connection tab.
2. Use the same endpoint address in Address field as you have provided in producer integration flow at the receiver end.
3. Select SFTP adapter configure the necessary settings.

Additional Tips: In case if you don’t want to configure the receiver, you can also log the output into a script as shown below:

Add the following to the script file: 

The integration developer needs to create the method processData

 This method takes Message object of package com.sap.gateway.ip.core.customdev.util

which includes helper methods useful for the content developer:

The methods available are:

    public java.lang.Object getBody()

                public void setBody(java.lang.Object exchangeBody)

    public java.util.Map<java.lang.String,java.lang.Object> getHeaders()

    public void setHeaders(java.util.Map<java.lang.String,java.lang.Object> exchangeHeaders)

    public void setHeader(java.lang.String name, java.lang.Object value)

    public java.util.Map<java.lang.String,java.lang.Object> getProperties()

    public void setProperties(java.util.Map<java.lang.String,java.lang.Object> exchangeProperties)

       public void setProperty(java.lang.String name, java.lang.Object value)

*/

import com.sap.gateway.ip.core.customdev.util.Message;

import java.util.HashMap;

def Message processData(Message message) {

   def body = message.getBody(java.lang.String) as String;

   def messageLog = messageLogFactory.getMessageLog(message);

   if(messageLog != null){

     messageLog.addAttachmentAsString(“Log current Payload:”, body, “text/plain”);

   }

   return message;

}

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ProcessDirect Adapter Sample Use-cases

In this section you will find some typical scenarios which can be executed using ProcessDirect adapter.

Transaction Processing

Transactional processing ensures that the message is processed within a single transaction. For example, when the integration flow has Data Store Write operation, and the transaction handling is activated, the Data Store entry is only committed if the whole process is executed successfully. In case of failure, the transaction is rolled back and the Data Store entry is not persisted.

Scenario1: A basic scenario for setting transaction type to JDBC for producer and Consumer

In this scenario, the transaction type for producer and consumer are set to JDBC. Consumer with Script component throws an exception which is not caught and hence the database operations are rolled back in both producer and consumer.

Producer Integration Flow:

Consumer Integration Flow:

 

Scenario2: Producer throws an exception after request-reply and transaction type is set to JDBC

In this scenario, transaction type is set to JDBC for both producer and consumer. We have script after Request-Reply step which throws an exception. 2 MPLs will be generated with the status Producer as Failed and Consumer as Completed. In this case database operations are rolled back in producer but not in the consumer.

Producer Integration Flow:

Consumer Integration Flow:

 

Scenario 3: Producer throwing exception after Request-Reply and Transaction set to JDBC for Producer and Consumer set to Not Required.

In this scenario, transaction type is set JDBC for producer and consumer “Not Required”. We have script after Request-Reply step which throws an exception. Two MPLs will be generated with the status Producer as Failed and Consumer as Completed. In this case database operations are rolled back in producer but not in a consumer.

Producer Integration Flow:

Consumer Integration Flow:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Multiple MPLs

Scenario 1: Only Splitter in Producer, without any join/aggregator

In this scenario, the producer and consumer both will have Completed status in MPL logs and there will be three splits of message during the transaction.

Producer Integration Flow:

Consumer Integration Flow:

Scenario2: Iterating Splitter and Aggregator in Producer and Consumer respectively

In this scenario, MPL logs per split will be generated, one for producer and one for each split message for consumers. Due to the default behavior of Aggregator, one additional MPL is generated in the consumer integration flow.

Producer Integration Flow:

Consumer Integration Flow:

Scenario 3: Router in Producer, routing to Direct Adapter via two receivers.

In this scenario, depending on a condition the associated consumer is invoked.

Producer Integration Flow:

Consumer 1 Integration Flow:

Consumer 2 Integration Flow:

Scenario 4: Request-Reply and End Message in Producer and End Event in Consumer

In this scenario, the request-reply in the Producer integration flow forwards the message in the body of Content Modifier 1 to consumer 1 integration flow. In consumer 1, the received message is appended to the body of Content Modifier 1 and is returned to the Request-Reply in Producer integration flow. This message is then forwarded to consumer 2 which is later sent to the SFTP server.

Producer Integration Flow:

 

Consumer 1 Integration Flow:

Consumer 2 Integration Flow: