分享:系统集成怎么做,做接口还是用ESB

标签:BPM集成ESB

访客:125799  发表于:2013-03-01 16:26:12

 

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

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

l  实现业务自动化;

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

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

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

目标

目标描述

 写接口

 ESB

自动化

尽可能减少人工操作,降低出错率

 可以

 可以

开发效率

开发包括:适配器、处理逻辑的开发、系统间格式转换、界面、安全性等多方面的开发

集成组件不能重用,其次对于标准产品还要写代码来做集成

 集成组件可以在不同的系统与客户之间重用,对于诸如SAPORCALE之类的通用产品ESB本身就提供集成组件,有的ESB组件还提供表单生成工具来简化集成的UI

IT敏捷性

IT敏捷性有几个标准:支持重用、支持组件化的更换等。

在重用方面,实际上,过去很多银行的核心系统是以账务处理为中心的,今天很多银行开始向以客户为中心转移,这使得大量银行需要更换他们的IT系统,其中有的银行并没有足够的预算来实现这种更换,他们就在多个账务系统之上添加了一层逻辑。

支持组件化的更换可以使得企业的IT架构的总成本大幅度的下降。实际上,一个企业里,几乎每年都需要更换系统,如果系统与系统之间是紧耦合的话,那么更换一个系统意味着就需要去变更相关所有的系统,这会大幅度增加IT成本。

 不支持

支持

高可用

高可用包括跨系统事务,高并发,日志,错误跟踪,调试,变更管理等。

不支持

支持

复杂应用

批处理,订阅,统一主数据

 不支持

支持

集成模式

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

集成方式

描述

优点

缺点

系统集成节点

流程系统提供与第三方系统集成的节点,比如:调用Web Service的节点,当流程执行到某个阶段的时候,流程引擎调用Web Service。这些系统集成节点通常还可以扩展,比如:SharePoint集成节点,Dynamics集成节点等等。

操作简便。

在生产环境几乎不可用。系统集成绝不是调接口这么简单,更关键的是要保证集成的高可用。节点上调用接口的方式存在严重的不稳定可能性,比如网络断了,操作系统升级,密码变更等都可能造成调用失败。

调用第三方ESB

流程引擎与第三方的ESB集成,第三方ESB再与业务系统进行集成。常见的第三方ESBWeb SphereBizTalk等。

功能强大,能够集成各种系统。

系统响应比较慢,比如一个用户要审批一个表单,表单里有一些数据是从外部系统来的,那么整个访问过程是:IIS->流程引擎->ESB->MQ->业务系统,这里至少要跨越4个进程。其次,问题是价格比较昂贵。

内置ESB

流程系统内置ESB,内置的ESB与业务系统进行集成,再这里保障集成的安全性、稳定性和可追溯性。流程引擎再与内置的ESB对接来实现系统集成。

响应速度高,与流程引擎集成紧密,可以保障集成的高可用。

不如专业的ESB功能强大。

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

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

运行环境

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

l  流程引擎HOST在其他系统的进程里,比如:IISSharePoint等。

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

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

前端集成

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

开发模式

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

开发目标

描述

流程开发

场景:要开发一个审批采购订单的流程,采购订单中包含明细表,每条明细里面有非常复杂的计算关系,每种物料都有自己的定价策略,每个审批人都有不同的字段读写权限。这是一个典型的系统集成场景,不同流程管理产品对于这种场景的支持能力是完全不同的。

通常国内一流的流程管理产品在这方面非常卓越,一般工作量都控制几个小时以内,比如:H3 BPM Suite实现这样的场景只需要10分钟就能完成,包括:流程设计、表单生成和权限控制,其中不需要写任何一行代码。

适配器开发

场景:客户新增了一个新的业务系统,如何来添加一个针对该系统的适配器。也许会有人说,让新的业务系统提供一个Web Service就好了,其实并没有那么简单,比如:在B2B应用中,客户到供应商也是通过Web Service来交换数据的,但是他们交换的是XML,这里其实需要的是XML的解析器,而不是调用Web Service那么简单。某一个适配器可能要调用多个业务系统,他们之间不是完全一一对应的关系。比如:获取ERP采购订单的场景中这个ERP可能采用外挂程序来计算税。

适配器开发是否方便非常考验ESB的能力,为了简化适配器的开发难度,ESB要提供大量的基础接口,比如:局部/全局锁,局部/全局缓存,事务管理,集群支持,日志管理,监听服务,后台作业服务,同步/异步/回调支持,会话管理,配置管理等。

安全性

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

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

BPM里的ESB的其他基础功能

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

增值服务

对于具备ESB能力的流程系统,很多厂商在其中研发了大量的增值模块,比如:SAP ConnectorMaster Data ManagementSWIFT等。

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

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

总结

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

文章来源:奥哲H3 BPM

评论(3)

您可以在评论框内@您的好友一起参与讨论!

    1. 刘锦波 一个问题,我是客户,我要的是符合要求的可操作的业务流程,这个业务流程是如何做出来的,我需要关心吗,我最好不关心,你告诉我这个业务流程:1、能不能做,2、多久,3、报价,4、再来一个如何。

      因此是否SOA/ESB之类的系统总体架构设计,BPM这类的生产力系统工具软件购买,不是甲方企业要完全承担的,应由乙方购买承担以后,分摊进各个项目中?

      回复[1] 2013/03/02 10:25

    1. 徐蕊 平台化的基础

      回复[0] 2013/03/01 16:33

    1. 姜稳 内容很多,信息量很大。我想问奥哲BPM是否有替代OA的一些模块或功能?

      回复[0] 2013/03/01 16:33

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");