About SaaS integration
I found an interesting article about SaaS integration: The new, new thing – Next-Gen SaaS Integration.
It talks about SOA based integration of SaaS solutions like Salesforce and Netsuite with an on-premise ERP system for example. The scenario mentioned is completed presales, as I understand it, in Salesforce that would be posted as sales order to an ERP system, requiring additional user steps such as order configuration. This is said to “quickly grow beyond the capabilities of typical integration products.”
I earlier wrote about my practical experiences in SaaS integration: My Life in the Cloud: Going Azure
However this is still a simple scenario. We might assume that order cancellation is not done in the presales system (Salesforce), but in the ERP system, once the order has been created there. I am mentioning this, because as of my experience the “Creation” service for Business Objects is the easiest one and the “Cancellation” service is the most challenging one. Why?
In the creation case, there is no already existing order and delivery business process running. So it is always safe to create a new order – from the perspective of the business process. Of course availability check and credit check play a role from the business perspective. The whole process is fresh and new. In the cancellation case the business process looks a little bit different. It depends on the status of the process as a whole inasmuch it still can be cancelled or not. For example the order may already be in execution – like in production or in delivery – or even delivered. Then it is not so easy to cancel such an order, as you can imagine. It depends on the status of the business process, if it is possible to cancel or not.
Now, if the sales order is in one SaaS system and the execution order in another, how do they interact? They need to exchange the business process status. They need to allow or disallow certain operations depending on the business process progress. There needs to be a resolution in the case of conflicting status.
This question cannot be solved by any intermediate integration tool alone. This may be an inconvenient truth, but it is true.
So yes, SOA helps – because it is necessary to offer the needed service operations to exchange the messages that are necessary. But the key to the solution is the choreography. The choreography defines the allowed messages – and therefore the allowed actions on behalf of each participant – in our case two SaaS solutions. If the choreography is built following the principles of loose coupling, then – yes – the integration can be made.
BPMN 2.0 Choreography modeling certainly can help to design the necessary choreography model. This influences which service operations would be offered by each side and at which point in time which message is or is not sent and which activities are allowed on each side of the business process. I intend to teach how to do this in more detail in Webinars and Seminars in the future.







Social Links