今天这篇文章准备谈下从企业集成需求到SOA架构思想，再到ESB集成平台建设方面的内容。本篇文章尽量从最简单的问题起源将其，从业务场景需求出发来讲解接口集成和SOA架构思想。

看完本篇文章可以对SOA，ESB，接口集成，企业常见端到端协同业务有一个完整了解。

从业务协同到接口产生

首先要理解一个企业有很多业务流程和活动，比如市场和销售，供应链，财务，生产，研发等，这些业务活动共同来支撑企业从获取到和的需求，到最终交付产品的整个价值链全过程。

为了支撑这个过程往往企业也会划分为不同的业务部门，比如供应链部，财务部，生产部，人力资源部等，各个部门上下游分工协作来完成对整个企业日常经营活动的全部支撑。

从客户提出需求，到最终交付产品给客户，这就是一个闭环的端到端流程，从客户开始到客户结束。这个端到端流程往往先是销售接单，转计划部门，计划部门排计划，需要原材料采购的把采购计划下发给采购部门采购，生产产品的原材料都齐备后，排生产计划发送给生产部门，生产部门进行生产，生产后质量检查，没问题后出库发运到客户手里面。

这就是一个完整的端到端流程。（要详细理解这部分内容可以参考ERP和MRP相关的书籍做详细了解，也可以参考类似业务价值链方面的书籍）。

一个端到端流程要完成可以看到跨越了多个业务部门，上下游协同才能够完成。

要支撑企业的业务运转，企业会建立很多的IT系统，一般企业都是围绕ERP来建立相应的IT系统，即在ERP基础上扩展了外部支撑的多个系统，比如CRM，SCM，MES，PLM，WMS等业务系统。同时可以看到一般扩展的业务系统会有一个主管认责的业务部门。比如CRM归口到市场部，而对于MES归口到生产部，PLM归口到产品研发部门。

一个完整的端到端流程，业务部门之间要上下游协同，那么在实现信息化后就会变成业务部门归口管理的业务系统之间要上下游协同，即业务系统之间需要传递信息和数据，否则端到端流程无法协同起来。

比如我们在SCM系统里面建立的采购订单，但是采购回来的东西收货是仓储部管，对应的系统是WMS系统，而WMS系统收货的时候必须依据采购订单进行收货或确认型号和数量。因此我们就需要将采购订单信息从SCM系统传递到WMS系统。而这种信息传递就是通过两个系统之间的接口来完成的。

即我们常说的，端到端流程往往是连贯的，但是我们建设IT系统的时候往往是分散建立的，那么这些IT系统之间就必须协同起来满足完整的流程需要。IT系统之间的协同就通过系统间定义的接口进行，一个接口往往是业务系统双方共同约定好的技术标准，协议，同时约定好传输数据的格式。

SCM采购系统要传递一个订单信息给WMS仓储管理系统，这个就需要通过接口实现。而接口实现的方法有很多，比如：

通过数据库的DBlink直接连接完成，将数据写到接口表或调存储过程。

通过RPC远程过程调用类方式来完成。

通过Http WS服务来完成，其中包括了SOAP WS也包括了REST WS。

通过文件导入和导出来完成，即SCM先导出文件，然后将文件传递到WMS系统再导入。

通过类似JMS消息来完成，即SCM通过JMS消息机制发送消息给WMS系统。

以上技术实现不明白的可以先放一边，要说明的就是接口本身的技术实现方式有很多种，都可以用来实现两个IT系统之间的接口集成，完成数据传递工作。

在上面了解清楚后，我们再来看接口实现的几个关键问题。

查询接口还是导入接口？

任何涉及到两个系统之间的接口实现都存在两种方式，即要么实现为查询接口，要么实现为导入接口。还是以上例子来说，SCM要传递一个订单信息给WMS系统，那么实现方式有两种。

WMS系统作为接口提供方，实现一个订单导入接口，SCM进行调用。

SCM系统作为接口提供方，实现一个订单查询接口，WMS系统来调用。

这两种接口实现方式都可以，即如果是在A实现查询接口，那么一定就是在B实现导入接口。对于数据源头方往往是提供查询接口，对于数据需要方式提供导入接口。

如果是导入接口，那么SCM系统只要有新订单产生就可以实时调用接口将数据导入给WMS系统，但是如果是查询接口，WMS系统并不清楚SCM系统什么时候产生了新订单，所以只能定时轮询调用查询服务，看是否有新订单产生。因此对于导入接口往往实时性更好。

接口同步还是接口异步？

对于同步还是异步我们来举个例子来说明。比如你点了美团外卖，在外卖小哥将外卖送到你公司楼下有两种处理方法。

其一是电话告诉你，外面放在前台了你自己去取下；

其二是给你电话说在下面等你，直到你去取到外卖再离开。

对于方法1就是异步，对于方法2就是同步。

即在同步场景下，外卖小哥和你建立连接后，这个连接一直要处于等待状态，直到你取走外卖为止；但是如果是异步场景，外卖小哥只要将东西放到前台就返回，不需要和你建立长久等待连接，在这种情况下往往就需要一个传递媒介(前台）。这就是同步和异步最大的区别点。

那同步和异步究竟各有啥优点呢，简单来说

同步：虽然等待，但是可以完全确保送达，等待最终确认信息。

异步：无须等待，即使你当时不在公司（如目标系统宕机）也不影响送达，但是消息传输是否成功需要刚才说到的前台（消息中间件）来保证传递可靠完成。

再简单来说，就是在同步场景下，A和B两个业务系统是直接建立了连接同时连接处于等待状态，直到接收系统接收成功后返回。而对于异常场景下，A和B不直接建立连接，都是和消息中间件建立连接。

实时和非实时

还是上面的场景，如果接口实现为订单导入，那么采购系统一有订单就马上调用导入接口，就是实时触发接口。但是如果采购系统是每2小时处理一次，将这2小时新增加的订单作为一个批次再调用导入接口进行导入，那么就是定时接口。

对于查询类服务同步，如果一个查询人员信息接口服务，业务系统是实时用人员的时候实时查询接口获取最新信息，那么就是实时接口。但是如果是每隔2小时或1天，调用该接口同步增量数据，那么就是非实时接口。

从点对点集成到总线式集成

集成平台简单来说就是将所有业务系统间提供的接口全部统一管理起来的一个平台，举例来说：

一个办公室有5台电脑，这5台电脑要连接起来，你可以每台电脑之间通过网线点度点连接，形成一种网状的连接结果。你也可以将5台电脑全部接入到一个Hub交换机上面，通过交换机来实现5台电脑的连接。同样有5个业务系统要实现集成，接口可以点对点集成，当然接口也可以全部接入到类似交换机的一个软件平台上（集成平台）上面，通过集成平台实现类似Hub的总线式集成。

如果有100台电脑，网站集成的话是n*(n-1)/2，可以看到集成关系越来越复杂，越来越难以管理，但是如果采用Hub集成，那么集成就变得很容易，也很清晰。

对于业务系统间的接口集成也是同样的道理。

再举例来说明，比如有四个人，分别讲中文，英语，法语和日语。那么如果4个人要交流就相对麻烦，每个人都需要懂多门外语，或者自己对语言进行翻译处理。那么这个时候我们就可以将四个人全部接入到一个统一的翻译机，中国人要跟英国人交流的时候，中国人将中文发送给翻译机，翻译机转换为英文后再转发给英国人。那么对于四个人间的交流就很顺畅了。

集成平台实现了总线式集成，除了减少了集成点数量外，重点还做以下几个方面的事情。

对接口传递的数据进行协议转换或数据映射，类似刚才说的语言翻译操作。

对A提供的接口开放给哪些业务系统调用进行控制，即常说的接口安全和访问授权问题。

对于任何业务系统间接口传递的日志数据进行记录，包括输入了什么，输出了什么，方便后续问题排查。

以WMS提供订单导入接口为例，在点对点集成的时候，接口调用为：SCM 调用 WMS接口。在WMS将接入注册到集成平台后，集成平台提供了一个类似的订单导入接口，过程变化为：

SCM 调用 集成平台 =》 集成平台 转发去调用WMS =》 WMS返回到集成平台 =>集成平台返回给SCM

即任何一个接口的调用都涉及到三方，A系统，B系统和集成平台。

同时从上面这个图大家还可以看到，所有接口消费的输入消息和输出消息全部会在集成平台管道上进行流转，也就是说集成平台可以对消息进行拦截和处理。这也是后续集成平台对接口进行安全，日志，协议转化，数据映射，流量控制等各种管控的基础。

接口标准和定义

对于集成平台的使用，除解决原来业务系统之间点对点集成转变为总线式集成的问题外，究竟还能够解决哪些问题。在集成平台实施过程中，最容易碰到的疑问就是对于业务系统间都全部采用了标准的WS服务作为接口标准，那么还使用集成平台有什么样的必要性？

对于集成平台的使用，还包括了如下几个方面的优点。

接口传输日志的记录和后续审计，如果这个不做，那么需要各个业务系统都去做。

接口的安全管理和访问控制，可以做到统一管理并可配置化，业务系统不用关心。

接口的标准化和适配，即使全部采用WS接口服务，也存在如何对WSDL标准化的问题。

消息的1对多分发，消息路由能力，这是个共性能力，往往集成平台可以统一完成。

位置透明和服务代理能力，所有服务调用都只需和集成平台打交道。

当然在采用了集成平台后，也存在一些缺点的地方，比如任何一个接口的集成和实施都涉及到业务系统双方和集成平台三方协同才能够完成。其次就是由于消息需要通过集成平台中转，一定会带来一定的性能损耗。

接口的数据格式和内容

在业务系统之间定义了一个标准的接口后，就需要对接口的数据格式进行定义，对于SOAP WS有标准的WSDL和XSD接口契约文件定义。包括对于Rest接口，现在也有WADL和RAML设计模型。

对于这块的内容在这里先不展开，可以自己搜索SOAP WebService和WSDL相关的文章进行学习。

简单举例来说，一个邮递员通知你到哪里去取你的包裹这个接口，对于WSDL文件中的是说明了取包裹的具体地点和方法名称；而对于XSD文件则定义了包裹里面具体装了哪些东西，是如何装的。当然XSD文件也可以完全嵌入在WSDL文件里面，这样WSDL文件就一并告诉你这两件事情。

任何数据一定有数据结构，而对于接口传递的数据结构本身就是一个树状结构，其一定有一个根节点，在根节点下面有1个或多个子节点，同时子节点项目还可以有子子节点。因此你遇到任何一个数据结构就需要搞清楚这个数据本身是分几层，是1个父亲有两个儿子这种结构（A场景），还是1个父亲有1个儿子，1个儿子又挂了1个孙子这种结构（B场景）。这对理解XSD结构和里面的Collection结构定义相当重要。

举例来说，我们定义一个客户信息，一个客户往往有客户银行账户和客户联系人，那么就是上面说的A场景。当然也可以是一个客户信息，一个客户联系人信息，一个客户联系电话信息，那么就是上面说的B场景，即三层递进结构。这个画个图示往往更加容易理解，在这里先省略掉。

为什么要先定义接口

对软件工程有初步理解的就容易理解，在软件工程中有架构设计，而架构设计中一个重要的工作就是划分组件，并对组件的接口进行设计。

这样做的目的就是在接口设计好后，各个组件就可以开始并发开发工作，相互不影响，只要大家遵循同样的接口规范文件，那么最终开发完成的两个组件就能够集成到一起。

接口先行的目的就是大家遵循同样的标准，那么后续各个组件就能够无缝集成到一起。否则接口实现不一致，那么后续就无法进行集成，导致功能和接口变更。如下图所示：

如果把业务系统比做积木的话，只要我们提前定义好了接口的标准(WSDL+XSD)文件，那么三个积木就可以完全无缝的组装和衔接起来，形成一个完整的整体。

如果ERP提供接口和集成平台接口不一致，那么ERP提供的接口服务注册到集成平台。

如果集成平台接口和SCM接口不一致，那么SCM无法消费成功集成平台提供的服务。

当前集成平台本身还有接口或数据的转换能力，那么就可能如下图

即ERP和集成平台间是三角形的接口，但是集成平台和SCM间是三角矩形接口。SCM和ERP间的接口不标准，也不统一，但是通过集成平台转换和适配，很好地将SCM和ERP两个积木组装了起来。这也是上面我们说的集成平台的的另外一个关键特点，协议转换能力和数据转换能力。

从集成平台到ESB

前面把集成平台，接口的概念讲清楚了那么接着讲下ESB服务总线。如何简单来理解ESB服务总线，如果将业务系统间的接口理解为各个点对点连接的乡间小路的话，那么ESB服务总线就是将这些小路聚合和连接在一起的信息高速公路，而每次接口传递的数据就是在高速公路上飞驰的汽车。

因此简单来说，ESB总线就是将业务系统间的接口找到，将接口转变为服务，然后将服务注册和接入到ESB总线，然后ESB总线将这个接口服务开放给其它业务系统使用，同时对这个接口服务进行统一的管理（安全，日志，路由等）。

而对于集成平台本身是一个宽泛的概念，即对于传统的EAI，数据交换平台，ESB服务总线都可以纳入到集成平台。从集成的类型来看，文件集成，大数据集成，服务集成（ESB总线）也都可以纳入集成平台的概念。

那么对于ESB和传统的EAI和数据交换平台的区别究竟在哪里？

对于ESB平台更加强调了接口本身的服务化，不仅仅是WS来实现，更加重要的可重用。

对于ESB发布的接口有明确的业务含义，而对于EAI或数据交换平台接口更多是底层数据传递。

对于EAI平台更多场景数据都是落地的，而对于ESB平台往往可以做到数据不落地

对于ESB平台由于服务调用可以更加容易做到实时性，而对于EAI和数据交换平台很难做到

因此在ESB实施时候重点是服务的识别，或者说传统接口如何转服务。其次才是服务后期的治理和管控。当前在很多互联网架构下认为ESB平台偏重，因此也出现了类似OpenAPI平台，服务网关等更加轻量的SOA总线平台。去掉了传统ESB里面比较重的协议转换适配，数据映射，服务可视化编排等能力。

集成平台的实施关键内容如何理解？

前面把集成平台和接口的概念理解清楚后，再来理解ESB实施究竟做哪些关键的事情就容易了。对于ESB实施，我们可以参考上面的图来理解，以ERP提供一个导入订单接口服务给SCM系统消费来说明。

首先是集成平台定义好一个标准的接口服务规范和WSDL文件，接口长什么样就全清楚了。

将接口规范下发给SCM，ERP系统，同时集成平台也要使用该规范。

SCM和ERP安装下发的接口规范文件进行接口的开发，ERP开发提供端，SCM开发消费端。

ERP在接口开发好后通知集成平台进行服务接入和注册，将ERP和集成平台两个积木嵌起来。

集成平台接入ERP服务后，发布一个新的代理服务给SCM系统，并通知SCM系统消费。

SCM系统按接口标准对集成平台暴露的接口进行消费，即将SCM和集成平台再串联和集成起来。

以上说明步骤都完成后，一个接口的需求，设计，开发和测试工作就全部完成了，也就是说大家遵循同样的接口标准规范定义，将一个接口完全集成起来了。这也是我们常说的从顶向下的接口设计和开发实施方法。

从接口到SOA架构思想

我们可以来看下SOA本身的定义，即：

SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。

在面对企业遗留IT系统架构的时候，SOA本身实际也是做两个重要的事情，其一是找到各个遗留系统共性的可复用的业务能力；其次就是在构建上层业务流程的时候通过服务组装和编排来完成。这个思想和中台思想完全一致。

我们来举个例子详细说明SOA架构思想：

我们以注册一家新公司来举例，可以看到如果我们要注册一家新的公司，我们需要和银行，政府部门中的工商，税务，质量监督等多个业务部门打交道，最终完成新公司注册的完整过程。

其一：找到可复用服务

而对于各个业务部门就是我们说的业务组件，我们首先就是要看业务组件本身对外提供了什么标准的服务能力出来，即先把各个组件可共享，能够复用的能力识别出来。这些业务组件本身提供很多业务服务能力，在这里我们只列举一些和公司注册相关的能力，如下：

其二：组合和编排服务完成业务

在进行一个新企业的注册流程中，涉及到核名，办理验资报告，领取组织机构代码证等诸多的业务活动，这些业务活动都需要和上面说的业务部门（业务组件）打交道才能够完成。

而要完成整个业务流程，就是将上面业务部门暴露的服务能力基于业务活动的流转进行组装起来，这样就完成了一个完整的业务，如下：

可以看到完成整个企业注册业务流程，本身就是底层的接口服务能力的组合和组装。

如果注册流程中增加了一个验证企业信用要求，那么我们也很容易在原来的业务流程中增加一个活动节点，该活动节点调用银行的信用验证服务能力接口即可。即通过接口服务的灵活组合，组装，能够很容易响应业务流程的变化。

SOA和ESB总线的关系

简单来说，SOA是一种架构思想，这种架构思想核心是找到服务，组装编排服务。对于找到的服务我们希望统一进行管理，那么ESB就是实现服务管理和治理的一个技术平台。

也就是ESB企业服务总线是实现SOA架构思想的一个关键平台。

如上图，找到和管理服务你可以借助ESB服务总线能力来完成，而组装和编排服务你可以借助BPM管理软件来完成。而ESB+BPM也是我们常说的实现SOA架构思想的关键平台。

没有使用ESB能否叫实现SOA架构？

当然可以，只是遗留系统暴露的接口服务没有进行统一的管控和治理，也就是说对于接口服务的治理水平会比较弱，但是只要你暴露的接口服务是粗粒度和可复用的。同样可以共享给上层业务系统或应用使用。正如没有使用BPM，同样也可以实践SOA编排思想，只是你需要通过自己写代码去编排服务，而不是通过BPM软件去可视化编排服务。

反之同样的道理，不用简单理解使用了ESB就是SOA架构。

比如你使用了ESB，接入了一堆没有经过标准化，不符合粗粒度特点的接口，这些接口本身混乱也没有任何服务价值。上层新业务开发也不能使用这些接口服务，那么这个时候你的ESB就仅仅是一个接口平台，也没有实现任何的SOA架构思想。

类似的道理还有我们做微服务也一样，不要简单的认为使用了SpringCloud框架就是微服务了，必须要考虑微服务类似轻量交互，松耦合等关键思想是否实现。

ESB总线需要同时考虑解决集成和解耦两类问题

由于当前ESB总线产品很多是由原有的EAI和消息中间件产品发展而来，因此更多的强调的是服务或消息集成，而弱化了SOA更加重要的一个能力即服务共享。

而实际上SOA需要解决服务+集成两方面的问题。

集成：解决的是业务和流程上的协同问题，服务不一定就能复用

复用：解决的是底层共有组件模块提取后能力开放问题，重点是可复用

从上面图可以看到，对于横向交互协同的接口，更多的是解决跨系统的集成问题，而对于系统中纵向使用的共享能力接口，在共享能力平台化后，则接口服务可重用，更多的解决就是服务层面的问题。

举例来说，一个采购系统导采购订单给ERP系统，这个接口往往并不能复用，但是解决了跨系统集成问题；另外对于MDM主数据提供的供应商查询接口服务，这个接口服务本身就是数据能力平台化后提供出的共享数据服务能力，这个服务可以被外围的SCM，ERP，CMS多个业务系统使用，既解决了系统间集成，更重要的解决了服务重用问题。

你也可以理解，对于服务重用问题的解决，更多都是伴随着共性能力下沉产生的。然而当前大部分企业将SOA简单理解为了ESB和集成平台，更多用SOA去解决集成的问题，而忘记了SOA架构思想的本质仍然是共性业务能力下降，上层应用灵活编排。

SOA关键技术特性

前面基本把SOA，集成平台，ESB，接口这些基本概念讲清楚了，今天重点还是进一步解释涉及到SOA和ESB的时候，一些关键技术特性。其中包括了粗粒度，无状态，位置透明等。

粗粒度

当谈到服务的时候，我们谈的最多的就是粗粒度，这个概念实际上并不容易理解。

我们还是要举例来进行说明，比如你去办理出国签证，你准备好相关申请材料后就到本地公安局的服务窗口，这个服务窗口就是和你到交道的接口，你把申请资料提交过去，2周后你拿到最终的签证和结果。可以看到和你打交道的这个服务窗口相对粗，相对简单，一个输入，一个简单的输出完事。但是要办理完这个事情，公安局内部则需要经过多个部门，多个岗位处理和审核，最终才能够完成，即内部的工作是相对细的，但是这个细节你不用关心也不用知道。这就是我们说的接口服务的粗粒度，即粗是相对内部实现的细来说的。

如果我们把两个业务系统中的数据库表的每个表都作为一个数据同步接口来实现集成，这种数据接口把细节完全暴露了，反而不符合粗粒度接口的定义。即粗粒度接口服务最强调的就是你要什么我就给你什么，你不需要知道还有哪些没给你，也不需要知道我内部如何实现的。

注意，粗粒度服务可能高可复用，也可能不能复用，粗粒度与高可复用性本身没有必然关系。比如我们做了一个供应商查询的数据服务接口，这个接口查询所有供应商字段信息，是一个细粒度接口，但是该接口往往更加容易复用。但是我们也可以做一个基于供应商ID返回供应商信用等级的粗粒度接口，但是这个接口就可能只有1个业务系统在业务场景中需要使用。

无状态

对于WS服务无状态，也是在理解SOA和服务化中的一个关键内容。对于无状态那么自然就是基于有状态和状态保持来说了，因此首先要说明什么是要有状态。

举个例子来说，我们去游乐园游玩，进门的时候要检查我们的门票，进去了后有很多游乐设施，当我们再玩里面的每个游乐设施的时候，就不再需要检查我们的门票的，也计算管理员默认我们进了大门后我们就是有效的买了票的游客。这种场景就要有状态，即一进门我们是有效游客这个状态就一直保持着。当然还有另外一种情况，就是我们验票进门后，在每玩一个游乐项目的时候，管理员要重新检查我们的门票，即管理员并不认我们进大门的时候做的检查，这个状态信息带不过来，那么这种情况下就有无状态。

对于服务调用，本身就是典型的无状态，简单理解就是你上次调用服务输入或输出，产生的任何信息都无法带入到下次服务调用中。比如你上次调服务传递了你的身份，但是你下次调用服务的时候还得传递，否则就不认。

正因为服务无状态，我们在进行集成平台集群化部署的时候相对来说更容易，不需要做任何的状态保持。

位置透明和服务代理

前面我们讲过服务网关是ESB服务总线最轻量的一个实现，仅仅实现了服务代理和安全等基础特性。因此要来理解什么是服务代理能力。

举个例子来说，顺丰快递送货到你们公司，你们公司办公区占了一栋楼6层，这个时候快递只需要将货送到你们前台就完事，而不需要送到你们实际的办公位。那么你们的前台就起到了服务代理的传输中介的作用。即本来顺丰快递应该直接点对点面对你们公司1000个员工办公位，但是现在很简单了，快递只需要面对你们公司的前台一个人即可。

通过服务代理可以看到，1000个员工内部办公位的分布，构造这些信息对快递员是不可见的，是透明的，这就叫做位置透明。即使你内部的办公位分布出现调整也不影响快递员送货。同时可以看到通过服务代理，还有一个好处就是内部的构造和逻辑完全对快递员是黑盒，快递员也不能随意进入到我们内部办公场所，这也就是保证了我们内部逻辑和结构的安全性。（也可以进一步解释为何企业在和外部进行接口服务交互的时候，往往要专门设置一个服务网关，并放置在DMZ隔离区的目的）

高内聚和松耦合

对于松耦合是服务的另外一个关键特性，也是我们进行架构设计和组件划分的一个关键特性。松耦合往往不是真的接口来说的，而是针对两个业务组件来说的，只是通过WS服务接口两个业务组件能够更好的实现松耦合。

当我们在划分完了业务组件后，如果A和B两个业务组件之间有100个接口在进行业务和数据交互，那么这两个组件就是高度耦合，但是如果两个组件之间只有3,5个接口在交互，那么组件之间就是松耦合。松耦合并不是不耦合，而是指两个组件之间的耦合程度很低。

松耦合后，两个组件就不一定必须一起设计，开发和部署，而是可以完全分开设计和部署，然后通过接口服务进行业务协同和交互。因此能够拆分是松耦合的一个关键特性。

其次，对于松耦合的两个组件，当组件A发生变更，故障或问题的时候，尽量不要影响到组件B。这也是松耦合的另外一个关键特性。比如A发送数据给B，当B故障的时候也不要影响到A，这就是彻底的松耦合。但是这种松耦合往往就需要通过消息中间件来完成，通过消息中间件和消息来彻底实现A和B两个组件的解耦。

业务协同场景举例

今天谈下业务，主要还是拿电信行业运营商来举例说明下，关键的业务协同场景。先来说下工程项目的端到端流程，中间可能涉及到的业务系统和关键交互接口说明。这里尽量是把主体流程说清楚，实际的业务比这个当然要复杂的多。

工程项目建设线条

首先当我们要进行工程建设的时候，比如说要在某个省建设5G试点基站和试验局，那么首先就要确定投资计划，并进行项目立项审批和可研。这里面就涉及到计划管理系统和项目管理系统，也可能是一个系统。其关键就是要形成最终的审批通过的立项项目。后续的所有工作都需要基于立项项目进行。

在项目管理系统中形成了立项项目并审批通过后，项目实际的范围，具体建设多少个点等，就会涉及到初步的项目WBS分解和项目预算。因此一个完整的项目信息都包括了项目基本信息，项目WBS分解信息和项目预算信息。

项目信息形成后就涉及到实际的后续招标采购工作了，这个应该容易理解。对于招标系统和采购系统在这里暂且分为两个系统来说。首先说招标，项目招标最终就是要确定项目如何基于WBS更好的分包，分包后进行相应的招标工作，招标完成后最终形成的就是合格的供应商信息，物料和设备信息，分签的合同信息。

所以这里可以看到，招投标完成后往往会形成合格的供应商信息，物料信息，这些信息就需要同步到采购管理系统里面作为采购用。当然如果有了主数据系统，这些基础主数据就先在MDM系统里面形成，然后再分发和同步到采购管理系统里面。因为采购系统做采购订单的时候需要选择供应商和物料。同时我们还需要将招投标结果类信息同步到合同管理系统，合同管理系统根据结果来拟制采购类合同。

这里再简单来说，比如5G招标结果已经处理，分为两个包，华为和中兴各中标一个包，其中华为提供交换和传输设备给1000台，中兴提供基站和动力环境设备各1000台。然后分别跟两家供应商签订供货合同。

前面事情做完后，就开始在采购系统里面做采购订单了。比如向华为下达采购订单。在这里先讲最简单的就是一个采购订单，接收点也一个点。

当我们在做采购订单的时候，我们就需要选择供应商信息，选择物料信息，选择该订单对应的项目，选择该订单对应的合同，选择该订单对应的组织，选择订单的接收地点等各种基础信息。可以看到这些基础信息就需要从招投标，合同，项目管理，ERP等各个业务系统中同步过来。这些是做一张采购订单的基本条件。当采购订单下达给供应商后，就涉及到收货的事情，在这里将采购系统和物流系统分开来讲，即采购系统只管采购订单，而物流系统来管实物和库存的管理。

采购订单生效后，需要将订单同步给物流系统，否则物流系统不清楚按什么来验货。这是采购和物流系统之间最关键的一个接口。对于供应商送货过来后，物流系统就需要进行接收，送检和入库三个关键操作。在这里我们简化为直接做入库单入库来进行说明。

物流系统做入库单，那么就需要先是根据哪个采购订单来进行接收入库，具体的入库数量是否和采购订单数量匹配等。在入库单做好，物资检查清楚后进行物资入库操作。一个物资正式入库，就涉及到物流系统里面的库存操作了，比如入库需要增加对应的物资库存数量，出库需要减少数量等。对应物资正式入库，有个叫法就叫库存记账。意思就是库房正式签收入库，承认收到你的东西并合格了，那么后续就需要依据这个信息给你进行付款。

对应物流系统一般就要管物资的入库，出库，调拨，盘点等相关的操作。因为所有这些操作都会影响到实物库存的变化，而实际实物库存的变化都会影响到最终的财务成本核算。而企业上了ERP后，实际的财务成本核算，应收，应付和总账都在ERP系统里面。因此对于物流系统操作形成的内容，统一叫做库存事务处理，需要将这个信息同步到ERP的库存模块，作为后续财务成本核算使用。

财务线条基础

物流系统接收到货后，后面这个货根据工程建设进度，就需要出库发到工程项目现场进行设备的安装和调试，所有的东西安装调试完成后，整个试验局就开通了。最终安装完成的东西就是客户的资产，因此需要将你所有采购回来的东西形成一个清单（转资清单），转变为客户的资产。即我花了100万出去，这里面就应该有100万全部转成了我后续的资产，这样两边的账才是平的。举更简单例子来说，公司来个新员工，公司花5000买了台电脑，那么这5000就要转成固定资产。这样两边的账才是平的。

工程项目建设如果验收通过了，那么就涉及到要给供应商付款，首先我们就需要提交验收材料和付款申请，启动给供应商付款的流程。

对于实际的付款就涉及到前端的报账平台，我们就需要在报账平台中提交一张采购类的报销单。当然你填写这种报销单的时候也需要选择对应哪个项目，哪个合同，哪个订单，哪次付款，对应的组织，会计科目，业务大小类等很多基础信息，这些信息都是从ERP，合同，项目管理，采购系统中同步过来，这些同步全部涉及到接口。

这个时候你在系统里面建立好报账单，选择对应哪个采购订单，对应的采购接收单，对应的供应商开过来的发票，这三者必须要对应上，才说明完全是一致的，账实完全相符。这个就叫三单匹配操作。这个完成后走报账单审批流程，审批通过后，报账单就会形成应付凭证或叫应付发票（有些付款场景没有发票）。那么这个发票信息就需要导入到ERP的应付模块里面去。

在报账平台建报账单的时候，还涉及到和预算系统打交道，比如我们下个月究竟要报销哪些费用，每个类别预计多少钱，我们首先要进行预算申报。预算申报完成，审批通过后生效。那么我们在提交报账单的时候就要检查，我们报销的费用是否超过了预算，如果超过了，或者没有预算就不允许提供。对于采购类报账，你报销的费用一定不能超过了采购合同的总金额，如果超过就不能报销，必须要先进行预算调整或合同变更才行。

在应付发票信息导入到ERP后，ERP启动进一步的业务规则和逻辑检查，确认这张发票是否可以付款了，如果可以付款就会生成付款指令发给资金系统，资金系统进行付款操作。资金系统在进行付款的时候还需要跟银行打交道，完成实际的付款过程。