Enterprise content management and business process management are two separate but complimentary solutions. In part one of this two part series, we looked at the need to integrate the two and some business scenarios where you would (and would not) integrate them.
Today, we look at some of the architectural patterns and strategies for integrating your Enterprise CMS with your BPM solution.
In part one (which you can read here) we looked at the need to integrate your business process management system with your enterprise content management system.
You may find very few business processes where content is not involved with business activities and not playing a role in business decision making. Some scenarios identified where integration may be required include:
- Referring content as a link in a business process and update metadata in the ECM
- Create and refer content along with metadata in the business process
There are couple of integration scenarios that might be observed.
- The application interface is enabled via a single stop portal (like WebSphere Portal server, Liferay etc. independent of BPM)
- The ECM is running on its own infrastructure and provides the services as 'content-as-service' over SOAP via standard Registry/ESB infrastructure. See: 5 Things to Consider when Integrating your Content Management System and Portal for more information.
- BPM really will be acting as orchestration layer to enable the process
This would often be the case when the processes are doing heavy-lifting tasks for data and application integration with downstream legacy/COTS applications, and enabling the feature rich functionalities to user is performed by the portal. (As example, IBM Process server (BPM) is being used for orchestration/integration and IBM portal server is used for presentation portal)
- The UI/portal provided by BPM vendor is being used as presentation.
- The BPM (Applian,Lombardi,Pega etc) is being used as orchestration layer and enables integration with downstream systems.
- The ECM is running on its own infrastructure and provides the services as 'content-as-service' over SOAP via standard Registry/ESB infrastructure.
If you notice the only difference is at the presentation/UI layer. In scenario 1, a single stop separate portal application (independent of BPM application) is chosen to make the functionality available to the users where as in scenario 2, a UI layer provided by the BPM vendor is chosen to enable the processes.
In both the above scenario(s), the following integration strategies might be followed depending on the business scenario, BPM product and its extension capabilities.
You can directly consume BPM and ECM services from the portal layer independently and do the mash up/aggregation of services in portal layer. It may not be a good idea to increase the performance overhead by calling ECM services (especially services related to content transfer) directly in BPM layer Instead make the content management service available in the portal.
So you are not integrating the BPM processes and ECM services directly in this approach -- the portal layer is doing all the magic for you..
Soft Integration (SOAP)
All BPM products generally provide some option(s) for building hooks (as example, a smart adapter for Appian, Integration services for Lombardi, Connector for Pega, SCA service module for WebSphere Process Server) to integrate downstream systems exposed via soap.
This integration technique can be adapted accordingly based on which BPM tool you are integrating with. But transferring content over soap/http is little different than transferring standard data (over soap/http). The most preferred way of transferring content over soap/http is 'soap with attachment' or MTOM (especially for large documents).
Now there are couple of things you need to consider:
- BPM vendor(s) may or may not support passing content via 'soap with attachment' or MTOM as a standard.
- Secondly, this heavy weight content transfer soap call should be avoided via BPM layer to reduce performance overhead.
You may need to find a workaround to deal with this kind of situation:
- Any content transfer related activity should be called directly from single stop portal or BPM UI layer without going via the BPM integration channel supported by BPM vendor.
- Other CMS data such as update metadata and operations with no content transfer still can flow via the BPM integration channel supported by the BPM vendor.
Strong Integration (SOAP)
Use the BPM integration channel to bring content and associated ECM data in the process. There might be a downside to this approach related to performance. And also if MTOM or 'soap with attachment' is not supported by the BPM product vendor, then you need to transfer it via byte or base-encoded like types (in fact, this standard type also may not be supported by some BPM vendors).
Pure Java Integration
You can also use the pure Java content management API (like DFC for EMC Documentum, JCR API for Alfresco etc) provided by ECM vendors within the BPM integration module (depending on BPM tool being used). But this approach brings the direct vendor API dependency and tight coupling and that may not be desirable.
- When the UI/portal provided by BPM tools like Appian, Lombardi, etc will be used to enable content management functionality, it might be the case that you need to build a UI component/control to provide rich functionality (like create content) according to business need. Building a custom component in the UI/presentation layer or customizing an existing an UI component is a bit difficult for a BPM provided UI/portal. These BPM tools can be extended mostly by configuration following some framework provided by the tool. It is not easy to introduce code customization in the UI layer (Appian, Lombardi as example) and is also discouraged by some BPM product vendors.
- Transferring/delivering the content using ‘soap as attachment’ or MTOM.
- The need to pass a userid/token in WSDL header to enable SSO.This token will help to get the session in the CMS system. But most of the BPM vendors have made it configurable in the tool. See: 5 Things to Consider when Integrating your Content Management System and Portal for more information.
You can clearly see that it needs to be well thought out to implement the best integration solution between a process and content management solution. Understanding the business scenario(s)/integration need, choosing the right tool set and its capabilities accordingly and integrating them following some proper architectural style/pattern is the key to bring the right business value.
Once again, each business is different and has its own uniqueness. So one technique/style may not suit for all integration situations. You may need to look for options and apply what best suits your situation.
An architecture pattern also should be flexible enough so that it can respond to a business change quickly and adapt that change easily without much rework.
(Editor's Note: Like this article? Then you might also like: 5 Things to Consider when Integrating your Content Management System and Portal)