Business processes are not simple by any means. Even though a single integration point can transfer data objects from one application to another but there is no single API that can map a single business process. A business process is mostly complex and require more than one integration point in recursion to actually perform data integration in a business process. For instance, if you are willing to sync orders, there are multiple processes involved in it:
• Is your customer list being up to date?
• Is your product list being up to date?
• Do you have proper invoicing defined and from where?
• Do you have automated shipment details updated?
• Are you showing proper prices for the order?
• Are your taxes applied correctly?
• Have you updated the inventories for the orders placed updated? Etc.
There are innumerable number of steps and at any level of complexity can be there based on your own business need. Hence if you think a touchpoint (a unit of integration) as a single unit there could be different level of dependency, ordering of execution and its types. Hence syncing an entire business process is not a very easy task.
In the above figure, it is depicted how an ideal scenario of an order synchronization can be when dealing with complex scenarios or process. The order process triggers customer and item update as its pre-requisite to ensure the products, its prices as well as customer lists are up to date, then it triggers the order update. Once an order is synchronized, it is not an end of this, the process continues to update inventories again and processes the invoices and shipment details and finally processes the status of delivery of the order in the web.
Process chaining mentioned as best practices from the post , is a mechanism to define the type of dependency in a workflow to execute a business integration. There are a number of dependency types which can be defined to solve a particular integration problem. Let us take an example of our enterprise solution called “APPSeCONNECT” and how it solves this problem.
Pre / Post – Touchpoint
A pre or post touchpoint executes the child processes independently with the full operation performed. The pre – touchpoint will execute itself before the main process is executed, while the post task is the reverse.
The above image depicts how the chaining can include the process one and process 2 as pre- touchpoint during its execution while the process 3 and process 4 after its own execution. As both the input and output remains completely separated, there is no as such dependency created between the touchpoints.
Acknoledgement Touchpoint
We consider a touchpoint as acknowledgement, when we must deal with the output of the main task. Here the main task executes independently, thereby creating output, and the same output is used to execute the acknowledgement touchpoint.
In this scenario, the Process 1 is executing as main task and produces output from the push operation, but the same is used to execute the Process 2 and Process 3. You can say each of the processes (Process 2 and Process 3) does not require to execute its own get operation rather it uses the output of the main task. We considered them as acknowledgement task because the processes which are child are generally used to acknowledge the execution of main task.
Input Touchpoint
The input touchpoint shares the input of both the processes. If there is a requirement where you need to send the same input that you get from the main touchpoint and use it to execute one or more touchpoint, you can use Input touchpoint to process the same.
In the above figure it is depicted how the Get method of main touchpoint uses the same input and executes the process. It is sometimes a requirement to process the same file to execute two or more touchpoints. In such a case, we can use input touchpoints to do the same.
In-Process Touchpoint
In-process touchpoints are those where the main touchpoint needs to be halted during execution of child touchpoints. In case of in-process touchpoint execution, the main touchpoint first gets the data from the source location and then halts itself to execute the child input touchpoints. During the execution of child touchpoints, the main touchpoint’s input file is available and the process can make use of them.
Here in the above figure, the main touchpoint is put to a halt after its get operation, and waits until all the In-Process child processes are executed. The main touchpoint is resumed again when all the child processes are finished its execution.
APPSeCONNECT also provides visual representation of process orchestration, and hence one can easily identify the process steps and tweak according to its own need.
Conclusion
For any business where most of the business application acts as silos, it is important to have an integration such that the data between these silos can represent a meaning and seamlessly work together. To represent a business process for your organization it is very hard to implement when there is no possibility of chaining. If an integration provides feature to create dependencies between these silos, you can use the most out of the business processes and create a meaningful integration.
APPSeCONNECT is a smart and robust integration platform that can connect all your Ecommerce stores, CRM, POS, Marketplace accounts and back office ERP and help them talk to each other.
You may also like:
APPSeCONNECT Integration – Technical and Conceptual Details
What is a hybrid integration solution?
Plugin Model of APPSeCONNECT – Infinite possibilities for ISVs
