Summa

To maximize their benefit, SaaS solutions need to integrate with existing enterprise systems. Depending on the business requirements and the integration capabilities of the chosen SaaS product, the integration approach may not be trivial. While a comprehensive API offered by SaaS is a must-have, in most cases a custom SaaS integration layer will be needed to comply with SOA principles and to facilitate integration with existing systems.

In this blog post I will provide an overview of capabilities that a typical SaaS integration layer should provide, and identify integration products that best fit those capabilities.  Let’s start with a diagram that depicts what a SaaS Integration layer may look like and how it interacts with existing systems and the SaaS solution:

 SaaS integration projects are not much different than typical integration projects. Unless the integration requirements are very simple, it makes more sense to use an integration product as the foundation of the SaaS integration layer, instead of custom-building such a layer. In most cases there may be a standard integration product used within your organization and more than often, this same product should be used for integrating your SaaS solution. An Enterprise Service Bus (ESB) is often a good integration product that will address most of the integration needs. In other cases, the SaaS Integration layer may be comprised of one or more integration products. Because there is no one-size-fits-all integration product you should consider a solution that will need to address most of the following integration needs:

Transformation

This is perhaps the most basic need that your integration layer will need to provide. One of the main goals of the SaaS Integration layer is to abstract and hide details about the SaaS solution from existing applications. One of such details to be hidden is the SaaS data model. The integration layer will be responsible for transforming from the SaaS data schema to the enterprise schema and the other way around. More than often this is accomplished through the use of a canonical or intermediate schema.

Transport protocols

Support for multiple transport protocols is a must. This is an area where good ESB products commonly excel. The supported protocols should range from message queues (e.g. WebSphere MQ, JMS) through HTTP/S, S/FTP, file directories to other less frequently used ones such as TCP. A good integration product will provide retry capabilities and easy customization of certain parameters such as encryption protocols and credentials (e.g. certificates) and timeout intervals.

Workflow

Most ESB products often provide basic workflow capabilities. If there is a need to support complex business workflow, an ESB may not be the best integration product or will need to be completed with a BPM (Business Process Management) product. BPM solutions are better equipped to handle long running transactions (i.e. workflows that require a manual/offline step) thus requiring the persistence of transaction state within the BPM system. They are also better suited to perform conditional steps based on the completion of previous steps (e.g. only complete transaction if required approvals are received).

Bulk data load capabilities

If there is a need for a heavy load of bulk load capabilities, a third integration product should be considered: ETL (Extract, Transform and Load) tools. Keep in mind that ETL solutions are often ideal for direct database-to-database data loading. Very frequently a SaaS solution will not allow direct access to their underlying database and in almost all cases will be hosted by a 3^rd party (i.e. the SaaS provider) in the “cloud”. In some cases the SaaS system may already provide basic data load capabilities which may be sufficient. If that is not the case, ETL products can help significantly, especially if the data transformation is very complex.

Compensation

Most services in a SOA (Service Oriented Architecture) integration do not provide the ability to rollback transactions across services. The common approach to provide this capability is through compensation paths. A compensation path may delete a record that was recently inserted as one of many steps from a transaction that spans across multiple systems. BPM solutions provide support for compensating transactions through the WS-BPEL 2.0 standard which includes definitions for compensation handlers. The question to ask here is “what happens if the compensation handler fails”? In my opinion handlers for compensation handlers should rarely be implemented.

Identity Correlation

The SaaS solution as well as the existing system will most likely have their own identifiers. Most integration use cases will require correlating these identifiers. This correlation can be delegated to either end system (e.g. the SaaS system, or one of the existing systems). It is important to keep in mind that there may be additional systems with their own identifiers brought into the picture later on. Because of this, a good practice is to create a cross reference database that is independent from the end systems and the SaaS integration layer (or existing integration layer), and then to expose this cross reference database as a service to other systems, i.e. to allow establishing new cross references, or to query for existing ones. This approach reduces the need to carry multiple IDs throughout the integration flows.