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.