BPM是SOA架构的核心组件之一，这意味着集成能力是BPM系统的必须能力，一个没有集成能力的流程管理系统永远无法成为BPM。

　　很多人都认为，做系统集成就是做接口，其实，远远没有那么简单。那么，怎样是正确的思路呢?要回答这个问题我们先讨论下集成的目标

　　实现业务自动化;

　　降低IT架构的总拥有成本;

　　同时，系统与系统之间是松耦合的，可以任意替换其中的组件。

　　基于这些目标，我们来对比下两种方式的优劣势：

　　集成模式

　　现在市场上的流程管理产品的集成能力参差不齐，主要有以下几种系统集成的方式：

　　从实际的应用来看，我们看到绝大部分流程管理产品采用【系统集成节点】这种集成模式。这种模式只能用于做DEMO，一旦上生产环境就会发现是完全不可用的。我们看到，很多客户采用了这种系统之后，不得不再自行开发一个集成程序，专门用于流程引擎与第三方系统的交互，来保障集成的高可用。通常，内置ESB的BPM系统默认能跟第三方ESB集成。

　　所以，客户如果需要选择一款具备集成能力的流程管理产品，那么必须选择一款内置ESB的BPM。从实际来看，除了Lombardi和Oracle BPM以外，国内的流程管理产品的集成能力，大大领先于国外的其他流程管理产品。

　　运行环境

　　集成系统的运行环境至关重要，如果集成组件本身的运行环境都不是高可用的，那么一切都无从谈起。常见的流程引擎运行环境有：

　　流程引擎HOST在其他系统的进程里，比如：IIS，SharePoint等。

　　流程引擎HOST在自己的Service里。

　　我们看到很多中国的二流的流程产品，采用的是HOST在其他进程里的模式，这对于系统集成来说是一个灾难。绝大部分国外的产品和中国的一流的流程管理产品，都采用的是HOST在自己的Service里面。

　　前端集成

　　前面介绍了集成的各种方式，对于最终用户来说，他们关注的还是如何展现，比如是否方便与门户系统集成，统一组织架构，单点登录。通常，主流的流程管理产品在这方面都不存在问题。

　　开发模式

　　我们看到有一些流程管理产品，做一个与SAP集成的流程需要写一段代码，下一次再做一个与SAP集成的流程又要写一段代码，这两段代码80%是一样的，如果每做一个系统集成的流程都要写一段代码，那么开发人员的工作量将非常大。

　　安全性

　　这个是一个重要的指标。安全性包括很多方面，比如：密码安全、数据安全、接口安全、帐户管理等。通常，前面那些都可以通过基础设施，比如：硬件、操作系统等实现，ESB则需要自行实现帐户管理，帐户管理里面有一项重要的功能就是帐户映射。

　　帐户映射管理是指ESB需要记录每个用户与业务系统用户的对应关系，这个映射可能是M:N的关系。比如：一个上海的员工，在发起一个采购订单审批的时候，他只能选择上海公司代码下的物料号，而不能选择北京公司代码下的物料。这意味着，用户在BPM上的账号要映射到ERP的账户上。

　　BPM里的ESB的其他基础功能

　　集群、日志、数据处理(数据映射、数据转换、XPat支持、内联函数和处理脚本支持等)、事务管理、BPEL、适配器、自定义扩展、权限管理、帐户管理、配置传输管理、性能监控、会话管理、监听服务、后台作业管理、字段状态管理、表单支持等。

　　增值服务

　　对于具备ESB能力的流程系统，很多厂商在其中研发了大量的增值模块，比如：SAP Connector、Master Data Management、SWIFT等。

　　这并不是简单的接口调用，而是一个完整的解决方案，比如：跟SAP集成，并不是简单的支持BAPI和RFC即可;跟SAP集成，其实是跟SAP环境集成，通常，SAP还会有大量的外挂程序，要实现跟SAP的集成，不但要实现跟SAP集成，还要实现跟SAP外挂程序的集成。

　　又比如实现主数据大集中，这并不只是技术问题，还需要大量的行业经验才能实现，很显然，金融行业的集中管理的客户主数据跟制造行业的客户主数据是完全不一样的。实施人员需要清楚地知道在某个行业里要把哪些系统的哪些数据进行集中，又分别采用哪种集中模式等等。

　　总结

　　系统集成绝不是调接口，高可用是必须的，否则一切都无从谈起。虽然市场上有很多产品具备一定的集成能力，但是绝大多数只是浅度的集成，根本无法在生产环境中使用。如果客户对流程自动化有要求，那么只能选择具有ESB模块的流程产品。而且这种ESB要能支持复杂的数据结构，比如：订单、XML类型等。