精华内容
下载资源
问答
  • 系统间接口设计

    千次阅读 2019-05-15 09:14:18
    最近两年一直在和银行、公安、保险、民政等第三方单位之间做接口,写的接口文档不下30份,最初的接口文档漏洞百出,改了又改,丢了不少人,也被批评、埋怨,指责了很多次,久而久之,明白了一个最重要的道理,协作...

    【转载】http://blog.csdn.net/xuepiaohan2006/article/details/46604453

    最近两年一直在和银行、公安、保险、民政等第三方单位之间做接口,写的接口文档不下30份,最初的接口文档漏洞百出,改了又改,丢了不少人,也被批评、埋怨,指责了很多次,久而久之,明白了一个最重要的道理,协作决定接口。双方谈接口时,技术不是最重要的,要兼顾双方技术,成本,工期等等很多因素。但仍有很多技术层面的心得,恰巧上周参与温昱老师的一个性能设计的外训,里面老师讲到了接口设计,正好回来一起整理一下接口设计的经验。主要从3个方面总结一下系统间接口设计:接口定义、接口实现、其他一些注意事项。

     

    一、接口定义

            接口是双方(可能是系统、模块、服务等)之间数据交互的一个标准,定制接口方要想让对方没有疑问,接口考虑到的因素一定要全面,一般情况下,主要考虑3个步骤:

            

            交互机制:如同步请求/应答方式、异步请求/应答方式、会话方式、广播通知方式、事件订阅方式、可靠消息传输方式、文件传输等。

            接口技术:WebService、Scoket、交易中间件、消息中间件、文件方式、共享数据库等。

            接口格式:这个就根据所选技术,实际情况来定义即可。

     

            拿我们(具体行业不便透露)和银行的接口为例(和每个地区银行都不同,以1个为例)

            交互机制:异步请求/应答方式,我们有查控请求时调用银行接口,将请求信息发过去,银行查控完毕后,调用我们接口,将查控结果反馈给我们。调用失败后,会有重试,重试每30分钟一次。

            接口技术:WebService接口,Java开发,xml格式报文,数据采用3DES加密。

            接口定义:具体字段说明,xml格式等略。

            有了这些说明,在对方拿到接口文档后,不出意外(比如对方完全不懂技术,无法看懂)对方都能看懂接口,也能描述清楚,如果回答不上这些问题,恐怕就是有漏洞了。

     

     

     

            这个接口还有很多不完善的,很多地方有更好的选择,还是前面说的,协作决定接口,合适即可。

     

    二、接口实现

            接口定义完成了,开发过程中要考虑的就是非功能层面的了,比如各种约束,像我们这边数据量、并发都较大,需要考虑下面几个情况:

     

            1.高性能,支持高并发,大容量,速度快;

            2.健壮性,防止因大量数据,或大量占用资源导致系统不可用;

            3.可监控,随时看到接口的运行情况,便于及时发现错误及排除故障;

            4.可扩展,两个方面,一是可支持扩展新功能,二是并发增加时支持扩展新硬件。

     

            考虑这些可能会引起接口的改变,比如我们考虑高性能,速度快时,由于我们同时对应30多家银行,每个银行每天大约1000人次查询,单个调用需要3w次,所以改成了支持批量,单次调用最多100人,发送和接收大约5s左右。同时由原来串行改成了并发调用,使用了一个线程池(线程不能太多,可能造成银行接口并发太大导致崩溃)。

            有时主动发起的接口可能不如定时轮询的接口,比如上面我们的接口是主动发起,需要做连接池限制并发,免得并发多了给银行造成问题,后来再其他省改成了完全由我们做服务端,银行定时调用获取要查询的请求信息,虽然有几分钟延迟(依据银行轮询时间决定),但是开发简单不少,考虑的情况也少了不少,接口速度也快了不少。

           考虑可监控时,有很多开源监控组件,比如我们用的JavaMelody,可以监控某个类执行次数。

           考虑可扩展,功能可扩展,比如我们用XML、JSON格式报文,或者其他自定义格式,有一定的规则,千万别用具体含义的参数,一旦增删就会影响接口。

     

    三、注意事项

            1.支持批量,这个一定要有,主要是为了性能考虑,后续数据量大了,再修改支持批量就会导致整个接口修改,所以前期一定要支持批量。

            2.支持部分拆包,比如报文中最好解析报文头就能知道具体业务或能找到处理的逻辑,避免全部解析后才能知道如何处理,比如我们和一个公司做接口(他们制定接口),有10多个实现类,他们文件加密的,必须整体解密后才能读取到用哪个实现类处理,文件大约200M,每次处理5s左右,有3s都在选择用哪个实现类,并发时及其慢,后来改成了前面32个字节标示哪个实现类,后来处理每个包2s左右,性能提升40%多。

            3.安全性,接口的安全控制在逻辑上包括:安全评估、访问控制、入侵检测、口令认证、安全审计、防恶意代码、加密等内容。这个根据实际情况,有些单位要求高,有些无所谓,不涉及互联网的项目,加密为了防止管理员直接看到等,要求不高的Base64就行,或者3DES,高点的通道认证等,再高就根据具体情况来了。

            4.实体文件,FTP等方式传实体文件比较容易,我们用WebService较多,文件较小的一般采用转换成文本(Base64),当文本传输,好处是简单,缺点一是慢,二是文件大了或并发大了,内存可能不够;文件大的,我们一般放到FTP上,然后传给对方FTP上的路径,这个配置比较麻烦。

            5.日志,这个最最最重要,接口的每个环节都要保留详细的日志,可以设置优先级,上线后单独打印到某个文件或者只保留重要的,因为现场出错后只能根据日志分析,很多情况下对方的接口问题对方不承认时,或者出错后对方把责任扔给咱们时,你会发现最可靠的就是日志。

            6.监控,这个也太重要的,但是我们经常忽略,很多时候双方联调测试都没问题,经常一上线就出问题,不外乎数据量大了,并发大了等,此时有一个监控页面,你顿时就会信心倍增。

            7.接口文档编写,一般公司都有自己的接口文档模板,当然我们也有,大部分模板都主要定义个一些步骤,如背景、功能描述、交互机制、安全性……我这整理一下我和各个单位讨论时,碰到的一些文件描述不清楚问题,主要是一些格式定义,字段说明等

           (1)字段类型,一定要统一标准,比如日期、时间格式,不足补0等,如2015-01-0112:01:02。

           (2)实体文件,是Base64之后传递字符串,还是其他规则,或者传递一个FTP上的地址,如果是地址,结束时是否带有斜杠“/”等。

           (3)数值,精确小数后几位,小数点前后位数不足时是否补0等。

           (4)异常,最好有错误码,或者其他信息,以及错误后处理机制等。

           (5)必填项如何校验,代码值是否需要校验等。

           (6)最重要的一点,写完了一定要给别人看看,看看别人是否可以看懂,用词准确,是否有遗漏等。

     

            上面只是一些大体的总结,适合一些web项目等,很多其他模式下的接口都不适用,各个点也都没有深入的研究,后续研究后再加进入吧。

    --------------------- 
    作者:飘寒 
    来源:CSDN 
    原文:https://blog.csdn.net/xuepiaohan2006/article/details/46604453 
    版权声明:本文为博主原创文章,转载请附上博文链接!

    展开全文
  • 导读: ... 大家可以关注我个人公众号,所有分享内容,会在公众号第一时间推送,且阅读排版更好。 愿大家的学习,轻松且愉快。 如果大家觉得有用,希望...其中,我们提到:如果其他外部公司要与自己企业内部的系统有...

    导读:

    原文路径:https://mp.weixin.qq.com/s/FRMMthtA64gaXhBqyTlknw

    大家可以关注我个人公众号,所有分享内容,会在公众号第一时间推送,且阅读排版更好。

    愿大家的学习,轻松且愉快。

    如果大家觉得有用,希望转发关注,谢谢

    导读

    我们在上一篇内容中,简单介绍了中间数据库的交互模式。

    其中,我们提到:如果其他外部公司要与自己企业内部的系统有数据接口,且为了保证安全,不给外部公司访问我们自己数据库的权限,在这种情况下,我们应该以何种方式做系统的数据交互接口呢?

    本篇,我们简单介绍一下:利用文件传输进行数据交互的接口模式。

     

    正文

     

    一、基本工作原理

     

    文件传输的数据交互接口模式,顾名思义,其数据的交互是以文件为载体的,可以理解为:数据发送方的系统将数据写入到一个文件上,再将文件传输给数据接受的方系统;数据接收方系统将读取文件中所承载的数据,并根据数据执行相应的系统功能,从而实现系统间数据交互的目的。

     

    这种交互会有效地避免系统之间的函数调用,以及系统之间需要相互访问数据库等,为各个系统的独立安全,从接口架构设计的层面,提供了保障。

     

    这种模式,我们可以简单且形象地理解为:小明同学在上课时间给班里的小白同学递纸条。其中,小明和小白分别是不同的业务系统,而纸条就是这里的文件了。

    文件传输接口中,常使用的文件格式有哪些?

    常见接口的系统传输文件,主要有:SAP系统中标准的IDOC文件,XML文件、Json文件、EDI文件,有的企业有时候也会直接使用:Excel文件、TXT文件等等。

    当我们确定了系统间的文件格式,接下来需要确认文件中业务字段的生成和解析规则,同时,定义每一个字段的长度、数据类型等等。

     

    二、文件传输接口的常用系统架构设计

    1.业务系统--业务系统

    如下图所示,系统A将业务数据按照约定规则生成数据文件,存储在自己的服务器上。之后,将文件传输给系统B,系统B在接到系统A的文件后,先将文件存储至自己的服务器上,再针对数据进行解析与使用。

     

    2.业务系统--文件存储服务器--业务系统

    如下图所示,有时候为了保证文件传输接口的统一管理,会专门在业务系统间设置一个专门的服务器,用于文件的存取。

    当然下图只展示了两个系统的文件交互,其实,有些时候,在文件存储系统中,会根据不同的业务情况,以及系统交互情况,对所有文件通过文件夹管理起来,这样就能支持多系统、多业务的文件传输接口。

     

    3.业务系统--文件存储系统----文件存储系统--业务系统

     

    前文中,我们专门提到不同企业间的系统接口方案,是可以基于文件传输接口进行设计的,此种方式能够很好地保证各自企业系统及服务器独立安全。

     

     

    4.文件传输协议:

     

    文件的传输,必然有很多传输规定方式和技术通信规则。不同业务系统间,如果有接口业务,文件传输协议的选择,是接口建立的基础。有了相同的传输协议,才能有共同的接口规则。

    我们简单从应用层列举一下传输协议的使用目的:

     

    文件的加密方式需要被定义:

    比如,为了保证数据安全,所传输的文件需要加密,那么双方业务系统在生成和解析文件时,就得具备相同的加密方式;

     

    文件的交互机制需要被定义:

    比如,需要定义具体的交互方式,保证的数据文件不会丢失或重复等。

    假定,当系统A将文件发送给系统B,为保证系统间的文件交互不会丢失或重复等,

    常见的处理方式:当系统A把文件发出后,系统B接到此文件后,会给系统A一个回执消息,当系统A接受到此消息,就认为系统B已经成功接到文件,将不在发送文件了,否则会持续多次尝试发送文件等。

    当然,还有的接口就设置的比较简单,当系统A文件发出后,系统A就默认系统B已经成功接收到文件,并不在做发送,或者直接理解为系统A只发送一次文件;在这种情况下,一旦系统B发现并未收到A的数据,会给系统A发起重新发送的申请等。

    类似以上这类,文件接口交互中的传输握手协议等方式,都可以所选择的传输协议,进行不同程度上的定义和选择。

     

    除此之外,还有很多通信技术层面的协议规定,都可以根据传输协议的选择而定。

    我们常见的传输协议有:FTP/FTPS/OFTP/OFTP2.0/AS2/SFTP等等

    通信协议的采用与连接方式有关等。

     

    三、EDI技术的应用简述

    EDI(Electronic Data Interchange)数据交互标准的应用,是文件传输接口广泛应用的典型代表。

     

    电子数据交换(EDI) 是结构化的数据通过一定标准的报文格式,从一个应用系统到另一个应用系统的电子化的交换,电子数据交换将人为干预降到最小化。一个EDI系统通过内部系统给贸易伙伴系统发送数据只需几秒钟的时间。

     

    为了保证企业间的数据交互规则统一,所以在欧洲、美国等地区,均有统一的基于EDI技术的商用标准。

     

    目前,EDI解决方案在整车企业以及其供应链企业中,在很多贸易行业、运输行业、银行等行业中已得到广泛使用。

    为支持不同企业的EDI技术应用,市面上已经有很多公司有其自己的产品和解决方案,而且也有很多专业的EDI顾问及相关技术人员,保证EDI技术支持下的文件传输接口方案的广泛应用。

     

    展开全文
  • 导读: ... 大家可以关注我个人公众号,所有分享内容,会在公众号第一时间推送,且阅读...中间件的数据接口模式,也会被称为中间数据库的数据交互模式,或者叫数据平台的数据交互,总的来说,就是在各个业务系统间,建...

    导读:

    原文路径:https://mp.weixin.qq.com/s/uq9DfxE5_cvAsitqlcblBg

    大家可以关注我个人公众号,所有分享内容,会在公众号第一时间推送,且阅读排版更好。

    愿大家的学习,轻松且愉快。

    如果大家觉得有用,希望转发关注,谢谢。

    中间件的数据接口模式,也会被称为中间数据库的数据交互模式,或者叫数据平台的数据交互,总的来说,就是在各个业务系统间,建立一个独立的数据库,保证系统间的数据交互,或者叫数据接口。

     

    为什么要使用中间数据库的接口模式?

     

    对于很多企业来说,经常需要多个业务系统支持。如果采用系统间相互的函数调用模式,会导致接口过多,难以管理。基于此情况,多数企业会选择采用中间数据库,以满足多个系统间的数据流转。

    企业很多时候不愿意大规模采用RFC调用的接口模式,常基于且不限于以下几个原因:

     

    1.很明显,基于上图中只有5个系统,但其接口的复杂性已经较高了对于企业来说类似上图中的接口模式,是不易管理的。而且,实际业务中,少有规模的企业,都存在多个系统,并且各个系统之间接口业务不一样。在类似此种情况下,当企业的接口较多时,如果均采用点对点的相互调用接口,对接口以后的维护成本会很大。随着业务发展,很有可能最后谁也不知道某个接口的是否被使用,或者某个接口到底如何被使用。

     

    2.点对点的RFC调用接口,必须要求接口两端的功能均可用,这就有可能会影响业务的及时性。比如,常见的生产管理系统,一般其业务及时性要求很高,生产上发生一笔业务,通过RFC调用传输给ERP,但是ERP系统可能因为财务账期、其他程序锁表等,导致RFC接口无法立刻被调用成功。但生产管理系统又不可能一直等待ERP系统的执行,这样就会出现难以调和的矛盾。

     

    3.其实,很多时候,基于数据安全、信息安全等多方面的考虑,很多系统并不愿意给其他调用自己系统功能的权限,这样也就限制了RFC接口模式的使用。

     

     

    基于上述弊端,企业为了降低系统接口统一管理的难度,以及接口后期的维护成本,结合从安全及业务及时性等角度的综合考虑,一般会采取建立中间数据库的接口方式。

     

    那么,中间数据库接口模式的工作机制是什么?

    如果两个业务系统,采用建立中间数据库的模式进行数据交互,其工作原理可以简单理解为:

    首先,会部署一个专门的数据库或者数据系统,也有称为数据平台等,实际上,就是个专门用于存储系统间交互数据的数据库。

    业务系统不会直接将要传输的数据,传输给其他业务系统,而是会传输给这个中间的数据库,要使用数据的业务系统,会主动去中间数据库取自己需要的数据。

    如下图所示,A系统会将数据写入至中间数据库,B系统会取中间数据库去取需要的数据,反之亦然。

     

     

    采取中间数据库接口的方式,在实际使用中,一般是存在多个系统之间有数据交互的业务情况,如下图所示。

    基于下图,我们对比之前多系统接口采取RFC方式的图例,我们很容易看出来,采取中间数据库接口的交互方式,其接口更加容易管理,且交互方式更加安全。

    当然,采用中间数据库的接口方式,其弊端也比较明显,可能会导致一些常见问题,比如:

     

    1. 数据接受的系统,不能够及时处理数据,不能够在第一时间验证数据的业务及系统层面的准确性。

    很有可能出现,传输数据的系统将数据写入中间数据库,但是,需要接受数据的系统,在中间数据库读取数据时,发现数据有问题,并无法正常使用。

    此种情况,作为接收数据的系统,很难在第一时间对数据进行管控和校验。

    比如,我曾在项目中遇到过一个情况,某企业针对SAP系统与MES系统的所有接口,采取了中间数据库的接口模式。当发生原材料领用的业务时,首先,MES系统出库过账,进而将数据传输给中间数据库,SAP系统会取中间数据库的数据,完成过账。但是,实际执行中,某物料的库存只有10个,MES系统中的程序计算错误,显示库存有12个,用户执行领用12个,且在MES系统中领用成功。此时,当领用12个的数据传输给SAP,由于SAP中的库存数量只有10个,无法针对领用量12进行过账,最终出现问题。

    基于这一案例,如果我们采取的是RFC的接口模式,一旦领用数量大于库存数量,在SAP端就无法过账,直接就反馈给MES了,但是,采用中间数据的接口方式,其校验就会比较滞后,容易产生问题。

    2.接受数据的系统,什么时候去数据库取数据;

     

    其实,基于列举的第一个问题,我们不难看出,中间数据库的接口模式,对于数据接收方的系统来说,有一个问题:应该在什么时候去取数据?

     

    因为基于上述工作机制,数据发送方的系统在给中间数据库写入数据时,数据接收方的系统并不知道。

     

    所以,我们常见的处理方式就是定义自动的系统后台Job,也有的系统会称为后台timer。

     

    简言之,我们就会在系统中定义一个程序,每个一段时间自动去中间数据库取一次。根据业务的及时性要求不同,我们可以定义不同的时间段,比如每十分钟取一次,或者每小时取一次,或者每天取一次等。

     

    采取自动后台Job的方式,可能带来的问题,也比较明显:数据发出方的系统,在某天只写入了三次数据,如果数据接收方定义每小时取一次,那么,实际取数据的次数是24次,对于系统服务器来说,为了3次数据,却需要执行24次程序,这就有些占用服务器资源了。

     

    对于一些业务较多、系统交互较多的企业,排程系统后台Job就变成了一项非常重要的工作。这要基于业务要求本身,系统程序大小等因素,去决定job的执行频率及执行顺序。

    比如,实际情况中,很多取数程序的本身必须有先后顺序,必须得先取某数据,才能取其他数据;有的程序太大、所取数据太多,就不能排在工作时间去取数,因为其很有可能占用过多服务器资源,导致其他业务难以顺利执行,所以,一般此类Job,会被安排在凌晨执行,等等。

     

    3.鸡蛋被放在了一个篮子里。

     

    基于中间数据库的接口模式,我们很容易就能看出来,如果过于集中地使用中间数据库或者数据平台等,意味着我们把核心数据都放在了一个数据库中。如果这个数据库出现问题,就有可能大面积影响相关系统的正常运转。基于这种情况,如果采取中间数据库的方式,其系统安全策略及相关灾备系统等的措施,就非常重要了。

    4.非企业本身的外部系统,如果需要与企业自己的系统进行数据交互,那么,基于安全层面的考虑,不会建议外部企业的系统直接访问内部数据库。

    那么,如果外部系统与企业内部系统有数据交互需求的话,应该采用哪种方式呢?

     

    这个就要基于我们下一篇要介绍的“文件传输的系统接口模式”。

     
     

    展开全文
  • 导读: ... 大家可以关注我个人公众号,所有分享内容,会在公众号第一时间推送,且阅读排版更好。...所谓系统接口,实际上就是不同系统间的数据交换方式。 对于一个企业来说,肯定不是一个系统就能够支持所有业务...

    导读:

    原文路径:https://mp.weixin.qq.com/s/RA2IdYCxyvygPDif_L1KDg

    大家可以关注我个人公众号,所有分享内容,会在公众号第一时间推送,且阅读排版更好。

    愿大家的学习,轻松且愉快。

    如果大家觉得有用,希望转发关注,谢谢。

     

    所谓系统接口,实际上就是不同系统间的数据交换方式。

     

    对于一个企业来说,肯定不是一个系统就能够支持所有业务的运转,几乎所有企业都会使用多个系统,比如较为常见的ERP/MES等。

     

    当企业有多个系统支持其业务时,不同系统间的数据交互就不可避免了。比如,MES作为生产执行系统,在MES中所执行的原材料投料、产成品入库出库等,必然会将相应的数据传输至ERP系统,保证ERP系统中同时进行原材料、成品的货物移动等。

     

    除了企业的内部系统会发生数据交互外,还可能存在不同企业间的系统数据交互。比如,企业可能会将未来的物料需求预测,传输给其下游供应商,供应商接到预测后,会进行生产备货等等。当然,还有很多企业其需要与银行有很多系统接口,比如自动付款等相关业务。

     

    基于企业中的系统接口,我们将主要分享常见的三类系统接口方式,以帮助大家能够理解其工作原理。

     

    三类常见的接口方式,包括:

     

    1.系统间采用远程函数调用(RFC)的方式进行数据交互;

     

    2.系统间采用中间数据库的方式进行数据交互;

     

    3.系统间采用传输文件的方式进行数据交互;

     

    本篇,我们先介绍“远程函数调用(RFC)”的工作原理。

    正文

     

    远程函数调用(Remote Function Call):实际上就是一个系统提供可供其他系统调用的函数,当其他系统传输正确的参数并调用相应函数,则可以在该系统中执行相应的系统功能。这就是最为常见的,使用远程函数调用的系统接口方式。

     

    系统间数据交互的目的,就是一个系统中的功能执行结果,以数据的形式被被传输到另外一个系统,并在利用此结果数据,在另外这个系统中执行相应的系统功能。

     

    远程函数调用(RFC)这种接口模式,就是数据会直接传输相应系统,并在此系统中直接执行系统功能。

     

    我们可以形象的理解为,被调用的系统A,将其系统的账号和密码交给了外部系统B,外部系统B在必要时,会登陆到A系统中,用系统B中的正确参数,也就是数据,去执行A系统中的系统功能。如下图所示。

     

    看到这里,其实,对于很多初级业务顾问来说,理解上可能还有一定困难。那么,我们就模拟一个最简单的业务场景,用以分析“远程函数调用”的工作原理。

     

    假定,某企业的采购员使用SAP系统做业务,而其部门经理会使用另一个审批系统,比如常见的自动办公OA系统,实现对采购员的业务的审批操作。

     

    那么此模拟场景下,其可能出现的实际业务如下:

     

    1.采购员在SAP系统中,创建一个张采购订单,并成功保存,其采购订单号为“123”;

     

    2.采购员在审批系统(OA)中,使用发起审批功能,填入采购订单号“123”,确认发起审批。此时,OA系统中会显示SAP系统中单号“123”的相关信息,包括物料编号、物料名称、采购数量、价格等;

     

    3.当采购员发起审批后,部门经理就能在OA系统中,看到此审批流程,并看到采购订单号“123”,以及所有此次采购业务的信息;

     

    4. 此时,部门经理会在OA系统中执行审批通过,OA系统在SAP系统对订单号“123”完成审批后,会给部门经理显示“批准通过执行成功”;

     

    请问在以上业务中,系统间的接口工作机制是什么样的?

     

    首先,有采购数据的抽取接口,执行逻辑如下:

    OA系统会给SAP传输“订单号”这一参数,同时调用SAP系统中的采购数据获取函数,SAP系统会将采购订单的相应信息反馈给审批系统;

     

    其次,有采购订单的审批接口,执行逻辑如下:

    当部门经理执行审批通过后,审批系统会将“订单号”和“审批通过”这两个参数,传输给SAP系统,并调用SAP系统中的审批函数批准此单号,并将审批成功的结果反馈给审批系统。

     

    具体逻辑如下图所示:

     

    这里我们可以思考以下,OA系统为什么一定要在接到SAP系统将审批成功的结果后,才给部门经理显示审批成功?

     

    OA系统为什么不直接在部门经理执行审批功能后,就直接显示审批成功?OA系统的审批参数已经发出去了,何必要等SAP的反馈呢?

     

    其实,这里就是我们在设计系统接口时,要注意的关键点。多个系统接口的协作,不同于单个系统的功能执行。

     

    以上述业务为例,在单个系统中,如果审批程序执行不成功,系统会立刻根据程序执行结果,告诉你程序执行不成功。可能的原因是,业务单据被锁定,或者相关后台表被锁定等。

     

    在多个系统的协作时,A系统把参数传输给B系统,并调用B系统中的函数,如果此时A系统,直接给使用者显示执行成功,就有可能造成B系统实际的功能并未执行成功,而A系统却告诉使用者已经成功了。

     

    如上述业务场景,OA系统虽然把审批通过的参数传输给了SAP系统,并调用SAP所提供的函数接口,SAP系统很有可能会因为单据锁定等原因,程序无法执行成功,但OA系统如果此时认为审批成功,就会出现问题了。

     

    基于上述内容,我们已经了解了“远程调用函数(RFC)”接口的基本工作原理。

     

    其实,除了SAP系统,几乎所有系统都对会外提供类似“远程调用函数(RFC)”的接口方式。

     

    当然,基于上述介绍,我们也就理解了为什么这种函数,会被称为“远程调用函数(RFC)”了。

     

    因为这类函数主要用以其他外部系统进行调用,外部系统的调用,也叫远程调用,所以我们常称可以供外部调用的函数为:“远程调用函数(RFC)”。当然,这类函数除了可以被外部系统调用,自己系统也可以调用。

     

    这里我们在介绍以下BAPI的概念。在SAP系统中,有很多已经封装好的,可以直接使用的远程调用函数,SAP称其为“BAPI(business application programming interface)”具体可以参考,其他两篇公众号文章。

     

    对于很多非SAP技术相关的朋友,都很了解API,而BAPI无非就是多了个business,就是SAP为其业务定义的API。

     

    远程函数调用这种接口方式,常用于业务简单,接口系统较少、接口业务点对点的业务类型。

     

    但实际业务中,支持企业业务运转的系统,可能会有数个、数十个,甚至数百个。

     

    如果所有系统接口都用远程调用的方式是肯定行不通的。

     

    展开全文
  • 系统间接口联调测试

    千次阅读 2016-02-03 15:12:08
    例如:两个系统之间的部分数据是相互读取的 1. 在一个甲系统增加,修改A数据后,乙系统也会相应的呈现这个改动的数据;在乙系统增加,修改B数据后,甲系统也会相应的呈现这个改动的数据; 即A部分的数据,是由甲...
  • WebAPI 是一种用来开发系统间接口、设备接口 API 的技术,基于 Http 协议,请求和返回格式结果默认是 json 格式。Web API 是一个轻量级的框架,非常适合构建移动客户端服务。 Vue.js是一套构建用户界面的渐进式框架...
  • 细心的读者会发现,这几篇文章分析的Binder接口都是基于C/C++语言来实现的,但是我们在编写应用程序都是基于Java语言的,那么,我们如何使用Java语言来使用系统的Binder机制来进行进程通信呢?这就是本文要介绍的...
  • 系统间数据交互的方案探讨

    千次阅读 2016-03-27 20:26:23
    系统间数据交互的方案探讨 ===================================== 互联网时代, 1等公民是建立规范和协议的人...信息系统的普及应用导致原有系统间的信息孤岛需要通过系统间接口进行数据交互,信息交互的接口常
  • 系统框架:thinkphp5.0 问题描述:系统B需要向系统A通信(主要是数据的传输),数据以及通信校验都没有问题,但是数据无法通信,主要提示 302 found。 问题原因:nginx域名重定向。比如说,当前API地址为...
  • 1.feign的远程调用(http接口调用) 2.RestTemplate 下面参考别的博客我自己的项目来介绍这两种方式~ 1.feign实现springboot/springcloud的远程HTTP调用 参考博文:springboot feign使用 1.1 pom文件中添加相关...
  • 利用 Qt 进行接口间通信

    万次阅读 多人点赞 2017-09-29 19:56:24
    接口的作用,就是提供一个与其他系统交互的方法。其他系统无需(也无法)了解内部的具体细节,只能通过对外提供的接口来与进行通信。 纯虚函数(槽也不例外)很容易理解,那么信号呢? > 在 Qt 中,定义一个...
  • 系统接口规范以及常见的接口技术概述和比较 一、基本要求: 为了保证系统的完整性和健壮性,系统接口应满足下列基本要求: 1、接口应实现对外部系统的接入提供企业级的支持,在系统的高并发和...
  • linux系统调用接口整理

    千次阅读 2016-03-10 20:58:00
     以下是Linux系统调用的一个列表,包含了大部分常用系统调用和由系统调用派生出的的函数。这可能是你在互联网上所能看到的唯一一篇中文注释的Linux系统调用列表,即使是简单的字母序英文列表,能做到这么完全也是很...
  • 关于LIS系统与HIS系统接口方案

    千次阅读 2008-08-28 08:51:00
    背 景 医院信息系统主要包括HIS(Hospital Information System)系统、LIS(Laboratory Information...HIS系统侧重于管理和收费,同时提供与专业系统数据交互的接口。LIS和PACS作为专业性很强的信息系统,侧重在与医疗
  • 分布式系统接口幂等性设计

    万次阅读 2017-05-02 18:00:22
    概念幂等性, Idempotence, 这个词来源自数学领域, 百科 上一元运算的幂等性解释如下: > 设 f 为一由 {x} 映射至 {x} 的...幂等性衍生到软件工程中, 它的语义是指: 函数/接口可以使用相同的参数重复执行, 不应该影响
  • 在前面一篇文章浅谈Service Manager成为Android进程通信(IPC)机制Binder守护进程之路中,介绍了Service Manager是如何成为Binder机制的守护进程的。既然作为守护进程,Service Manager的职责当然就是为Server和...
  • 接口测试用例设计

    千次阅读 2019-10-19 22:52:00
    接口测试用例设计 1 接口测试 1.1 接口测试 ...接口测试:是指针对模块或系统间接口进行的测试。 1.2 接口测试发现的典型问题 接口测试经常遇到的bug和问题,如下: (1)传入参数处理不...
  • 我们在软件成本估算时,对于系统集成类项目,各系统之间的接口设计怎么计算呢?在这种情况下,系统集成接口开发该怎么算就怎么算,外部接口文件+基本过程等等,计算出来的是集成接口开发总费用,一般不再分解到各个...
  • 文章目录6.1 用户接口6.2 其他特殊操作系统6.2.1 嵌入式操作系统6.2.2 分布式操作系统 6.1 用户接口 一、用户接口的发展 早期操作系统对外提供的接口很简陋,功能也单一,包括脱机的作业控制语言(或命令)和联机的...
  • 使用FeignClient实现微服务间接口调用

    千次阅读 2019-08-20 14:23:19
    首先,根据要调用的服务及接口: import com.sample.pass.distrition.model.ResultBody; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.web.bind.annotation.GetMapping; ...
  • 系统间数据交互

    千次阅读 2018-06-08 09:09:51
    各个信息系统间需要数据交互、同步等,举栗子:企业先上线的A系统,后上线B系统,B系统需要同步A系统的人员组织结构。下面分析几种方式:1、 接口A系统发布几个关于人员组织结构的接口,B系统调用接口获取数据。2、...
  • 常见的接口调用方式有三种(设计接口的时候要考虑选用哪种接口) 1、http接口:http是一种网络传输协议,基于TCP。(等价于:http+json) 现在浏览器客户端与服务器端通信基本都是采用http协议。 SpringCloud框架,...
  • 系统接口需要通过其他系统登录后才能跳到此系统,在接口测试时需要添加对应的鉴权信息: 如:一个系统需要通过权限系统登录后再跳转到对应的系统时,在做接口测试时需要把跳转到对应的token加入到对应接口测试时的...
  • 一起来学习 系统封装接口层- CMSIS-OS 之freeRTOS

    万次阅读 多人点赞 2017-05-18 16:41:52
    前些时间偶然在STM32最新的固件库中就发现了这个系统封装接口,当时就把自己所用的系统进行封装。直到最近KEIL5.0发现其中所到的RTX系统也进行了同相的封装。对比了下感觉很有必要和大家分享一下。  采用这个...
  • Binder进程通信机制的Java接口

    千次阅读 2015-03-16 12:27:18
    概述Java代码可以通过JNI方法来调用C/C++代码,因此,Android系统在应用程序框架层中提供了Binder进程通信机制的Java接口,它们通过JNI方法来调用Binder库的C/C++接口,从而提供了执行Binder进程通信的能力。...
  • 系统间对接 各个方案

    万次阅读 2015-11-26 11:53:22
    系统间对接 各个方案
  • 如果有两个系统一个his系统,一个医保系统。 要实现数据互通,怎么做?最好有代码和实现步骤。 his系统怎么把数据上传到医保系统, 医保系统怎么把计算信息返回到his系统? 想知道其中的具体过程,最好有简单的代码...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 496,973
精华内容 198,789
关键字:

系统间的接口