Introduction
In v3 processing the customer doesn’t need to implement steps. Our steps are not mandatory for customer to implement. He can do it or leave it. If he doesn’t do anything we execute our default implementation of the message processing.
The method ‘messageProcessing()’ define the step in the processing flow of the inbound message. We call this the message processing pipeline of just pipeline. It consists of 9 steps e.g. methods. All these methods are used in our message processing in the framework.
The new class integrate3 and integrate3Synchronous have the following steps:
- BeforeMessageProcessing (optional in framework). This method can be overwritten by custom class.
- CreateMessage -> (mandatory in framework). This method can be overwritten by custom class.
- BeforeWorkflow -> (optional in framework). This method can be overwritten by custom class.
- ExecuteWorklow -> (mandatory in framework). This method can be overwritten by custom class.
- BeforeMapping -> (optional in framework). This method can be overwritten by custom class.
- ExecuteMapping -> (mandatory in framework). This method can be overwritten by custom class.
- AfterMapping -> (optional in framework). This method can be overwritten by custom class.
- ProcessMessage -> (mandatory in framework). This method can be overwritten by custom class.
- AfterMessageProcessing -> (optional in framework). This method can be overwritten by custom class
Communication Architecture
Communication Architecture of v3 old and new processing is as shown in following diagram:
We can use integrate3 using xml and json where the payload is passed from a client. In this case, we use the message type which corresponds to the payload message node from the caller. We create the message type following the name of the external payload. We can also upload their xdd, wsdl or swagger/openAPI file to create automatically the message type. In this situation, we have the message type which reflects the name of the external message name. But when we call integrate3 from SAP-JAVA module or Agent we use soap version of integrate3 which convert the xml/json and pass as ibean3 to call the integrate3 method. In this case, we pass not the message type name but the sObject name like we do currently. In this case, the logic with the message type will not work. To make it works we need to add a decision case to check that if the message type is not used then we use the sObject name. We can see in the chained record the new formula field which contains the assignment between the message type name and the sObject name. If the field messageType is empty then we have only a value for the sObject. The field sObject always has a valid sObject name! But the field messageType can be empty or null if it is not used.
Workflow: Here what is new is that v3 support workflow for child interface as well which was not there in v2.