集团企业系统集成接口开发中4个关键但容易被忽视的内容

发布时间:

2024-01-22

分享到:


首先简要看看系统集成时接口应用的一类典型场景,例如以ERP系统(财务、供应链、生产等)为核心的系统集成,可能包括主数据管理系统、报销管理系统、司库系统、OA、HR、CRM、MES、PLM等系统,系统较多时也可以使用企业服务总线(ESB)或者接口管理平台更好的管理数据包的收发。在技术层面上,各系统与ERP系统之间通过接口数据的传递实现系统集成,多个系统协作共同实现完整的功能和业务。
具体的,例如主数据管理系统会把客商、项目、成本中心等主数据传递给ERP等系统,ERP系统使用接收到的数据包创建ERP系统中对应的档案数据用于后续的业务处理;再例如报销系统在完成报销的填单、业务和财务审批等内容后,会根据规则产生财务记账凭证数据包并传给ERP系统,ERP系统使用接收到的凭证数据包成功过账后产生正式的财务记账凭证,并将凭证号等信息反馈给报销系统。
无论采用异步还是同步方式的接口,多个系统之间一来一往的数据传递,无论在设计、开发、管理、运维等方面往往都会非常复杂。对集团企业而言,在多系统集成的同时还涉及多组织的系统集成,例如集团统建系统与多家所属企业异构系统的集成,不仅有功能方面的要求,也有集团一体化管控的要求(例如在全集团范围内对财务规则、数据标准等方面的管理),集成的复杂度进一步加剧。
如果接口在设计、开发和管理方面有缺失,接口数据没有能够正确传递,就意味着系统之间业务处理的异常,接口频繁、集中的出现问题直接影响系统使用和业务,严重的甚至会导致项目失败。
下面就系统集成时非常关键但也往往容易被忽视的4点做具体的介绍。
1、接口数据的持久化
一个数据包从源系统发出到被目标系统接收并处理,对这个过程,可能由于网络中断、企业服务总线异常、目标系统服务异常、目标系统服务器宕机等原因,数据包根本没有正确送达目标系统。在日常尽全力保障基础设施可用性的基础上,接口开发时需要注意什么呢?首先是接口数据包的持久化。
此前遇到过经验不足的厂商,对源系统来说,在若干功能点写代码拼出数据包然后调用接口程序直接发给目标系统,如果目标系统没有正确收到数据包,问题就来了。对源系统来说,后续分析接口异常原因时,可能无法知道在什么时间因为什么业务向目标系统传递了什么数据;对目标系统来说,通过接口收到数据包以后做处理,可能由于数据包不符合标准等原因导致异常,既不能完成业务处理也无法把错误信息反馈给源系统,接口出问题后无法分析。
还有一种情况是大批量接口数据处理时,通常系统也都有一个缓冲机制,但当数据量巨大时,如果数据包发送和接收的调度或者负载均衡功能失效,源系统和目标系统可能因为接口负荷太重导致处理异常(例如资源耗尽的系统无响应),可能就会导致数据包的丢失。
所以接口数据首先应该做持久化,即源系统发出数据包之前先在本地存储一份,然后有条不紊的发出;同时,目标系统收到数据包以后也先在本地存储一份,然后再逐条从容做业务处理。总的来说,通过数据包的持久化,任何时候都可以知道源系统发出了什么,目标系统接收到了什么。
关于数据包的持久化还有两点需要注意,第一是产生接口数据包的业务逻辑应做好的规划和实现,例如,如果在业务功能代码中比较随意的写一大段产生接口数据包的代码,一旦接口要调整,对分散在各处的接口数据产生代码做调整将是灾难,任何疏忽都会大大增加接口出现异常的可能性。同时,这些接口数据包产生的业务逻辑需要做规划和固化,可以清晰知道什么业务在什么样的条件下要调用接口,而避免随意的一段代码就承担接口数据处理这么严谨的任务。
第二是仍然是强调接口业务逻辑严谨性,就是应有唯一的编号可以确定一个接口数据包和其对应的业务,例如业务表单的编号,特别是有的表单在业务处理的多个环节可能会产生多种接口数据包,那么应该有机制保障通过唯一的编号回溯产生数据包的场景,通过唯一的编号可以界定和分析源系统到目标系统从数据包产生到完成处理的整个过程。
2、接口数据的监控及再操作
监控是基于接口数据的持久化实现的,在监控功能中,对源系统而言首先可以看到发出了什么数据以及数据的状态,例如某个时点源系统发出了100条数据,但在监控界面上各数据包一直显示状态是“发送中”,没有得到目标系统的任何反馈,此时就可能出现了数据包没有正确送达目标系统的情况,便于管理员及时发现并处理系统或者基础设施的问题。
对数据包的源系统,一旦通过接口监控或者用户反馈获悉数据包发送异常,此时数据包的重发功能就非常重要了,因为按正常逻辑,一个业务在源系统已经到达了一个状态后(例如单据审批完成)才向目标系统发送,相当于业务功能该完成的任务已经完成,此时不能要求业务重新来一遍或者通过干预业务流程本身去发送一个数据包,那么在接口监控功能中,运维人员可以调取当时的数据包执行重新发送的操作,当然,这种重新发送的操作必须经过充分的确认和一定的审批后才能执行,避免推送重复的数据。
对数据包的接收系统,如上文所述,有些情况下,数据包是被成功接收到并持久化了,但完成业务处理时会遇到异常,例如调用ERP系统的标准API对财务记账凭证数据包做过账时,由于种种原因凭证过账时所依赖的一个档案数据此时不存在(如系统中没有某个供应商档案数据),过账就会报错,那么通过监控功能可以看到这种处理异常的信息,运维人员就可以先解决掉问题(如录入或者获得此前缺失的供应商档案),然后通过监控功能的再处理操作重新过账,直到成功过账。
总之,如果没有接口监控和再操作功能,一则很难及时发现接口异常从而严重影响业务,更重要的是,如果没有监控功能,往往是无法排查问题的,导致数据包发出后犹如石沉大海,同时,如果缺少再操作功能,在出现问题后也很难补救,或者补救的时候需要更多的时间和成本。
3、接口状态的定义很关键
依托接口监控功能,通过合理定义的接口数据状态,可以有效描述业务流程的状态,便于用户及时发现问题。例如报销系统向资金管理系统或者司库系统或者直接的银企直连系统推送一笔付款申请,如果报销系统推送数据后就把接口状态改为“付款中”是不合适的,因为数据包很可能因为诸多原因没被正确送达目标系统,用户此时看到付款中的状态就会认为支付已经在处理的过程中,但可能隔了很长时间才发现对方没有收到款,一查发现数据包根本没有送达目标系统,这样定义不准确的状态就会影响业务。
而此类场景,数据包被推送后状态应该显示为“已发送”而不是“付款中”,目标系统成功接收到数据包以后,首先向源系统反馈一个“已收到”的信息,那么源系统收到这个信息后,再把接口状态改为“付款中”。对用户或者源系统的管理员如果发现数据长时间处于“已发送”状态,说明在数据包传递方面可能出现了问题,进而可以及时干预,保障业务的连续性。
4、用户封装后统一的标准接口
成熟的商业软件基本都提供丰富的原厂API支持用户的定制化需求,综上,如果各个系统直接调用API对接是存在一些风险的,所以基本需要用户对API做一定的封装,形成企业自己的一套API,这套API还会包括一系列校验,例如在集团企业中,A企业应用系统的记账凭证数据包只能向集团统建ERP系统中属于A企业的账套过账。
在集团层面应至少对通用的业务和数据标准进行规范,面对纷繁复杂的业务和系统,只有基于一定的标准化才能实现业务和数据的互通互联,标准化和管理是相辅相成的。具体到接口开发方面,要求在集团范围内,同一种业务应该只有一套接口,例如向集团统建ERP系统推送记账凭证的接口、推送项目档案的接口、推送报账单的接口等,这类接口应该由集团总部设计和开发,所属企业直接调用。对接口统一管理的重要性,如感兴趣可以参阅另外一篇文章,链接: 简述集团企业系统集成时统一管理系统接口的重要性
综上所述,其实很多功能应该包括在软件原厂的功能中更好,如果原厂没有相关功能,那么在系统集成项目上应实现这些功能。在没有相关功能的支持下,很难有效保障接口的正常运行,往往一旦出现问题,就是业务和运维工作的灾难,需引起高度重视

版权归原作者所有,如有侵权请联系删除。