CN101631093A - 实时数据交换接口的实现方法和系统 - Google Patents

Abstract

本发明公开了一种实时数据交换接口的实现方法和系统，包括：在需要数据交互的各系统间设置枢纽系统，系统中的终端进行数据发送时，按照预定的统一格式生成消息，至少填写业务功能编码、业务对象协议编码、业务处理信息及相关功能；枢纽系统通过协议中会话控制部分中的业务功能编码识别请求的业务，根据业务对象编码及版本号识别业务对象，并根据源和目的点等信息判断路由，做内部处理后转发给落地方；落地方接收到所述消息后，也相应根据控制部分辨别业务场景，根据业务对象实例进行相应的业务处理。本发明使得多个系统之间的交互通过统一协议完成实时接口功能，而不需要系统之间重新制定接口，大大地简化了接口的实现。

Description

实时数据交换接口的实现方法和系统

技术领域

本发明涉及电信数据交换技术，特别是指一种通过实现实时数据交换接口的方法和系统。

背景技术

传统的CRM枢纽与相关系统之间的同步数据交换的系统结构，参见图1所示。为实现客户端对业务的调用，在CRM枢纽和业务平台中都需要针对每种业务设置不同的接口。

运用上述传统的系统接口的方式，当增加或者变更业务时，会涉及多个系统和接口，需要制定或者更改接口，耗费较大的人力物力。特别是对于枢纽这种用来支撑网状互联的系统，涉及的系统多，接口数量巨大，如果用传统的接口来，每当要支撑新的业务时，都需要制定新的接口。

发明内容

有鉴于此，本发明的目的在于提出一种实现实时数据交换接口的方法和系统，使得多个系统之间通过统一的接口实现实时数据交换功能，当增加或者变更业务时，不需要系统之间两个两个的去重新制定接口。

基于上述目的本发明提供的一种实时数据交换接口的实现方法，其特征在于，在需要数据交互的各系统间设置枢纽系统，包括：

发起方进行数据发送时，根据数据传输协议确定实时数据交换接口的入口，根据实际的实时数据交换接口要求完成协议的会话控制部分，填写业务功能编码、业务对象编码，根据实际的业务要求细化业务对象场景，填写业务处理信息及相关功能，从而按照预定的统一格式生成消息，将生成的消息发送到枢纽系统；

枢纽系统通过会话控制部分中的业务功能编码识别请求的业务，根据业务对象编码识别业务对象，并根据源和目的点信息判断路由，转发给落地方；

落地方接收到所述消息后，也相应根据控制部分辨别业务场景，根据业务对象实例进行相应的业务处理。

可选的，该方法所述枢纽CRM收到所述消息后，在转发之前进一步按照预定的统一格式解析所述消息，进行内部处理。

可选的，该方法所述消息中还包括有版本号，所述枢纽系统根据业务对象协议编码和版本号识别业务对象。

可选的，该方法所述生成消息过程中进一步填写协议当前使用的版本号、服务等级；

所述枢纽进一步根据服务等级确定处理的优先级；

目的终端在对接收的消息解析后，进一步根据协议当前使用的版本号确定协议版本。

可选的，该方法所述消息中还包括请求标识，所述业务处理信息位置填写的是业务请求信息；

在落地方返回应答消息中包含有应答标识。

可选的，该方法在落地方进行业务处理后进一步包括：生成应答消息，按照预定的统一格式，在应答消息中填写交易流水号、在业务处理信息位置填写业务处理结果，通过枢纽发送给发起方。

可选的，该方法所述生成消息的过程中，用XML语言编写协议，完成实时数据交换接口。

可选的，该方法所述根据数据传输协议制定接口的入口进一步包括：对于HTTP方式的，制定统一的url入口；Webservice实现接口技术，定义单个接口入口。

可选的，该方法所述根据实际接口要求完成协议的会话控制部分还包括：引用业务对象编码；协议版本号码；填写请求标识；产生交易流水号；定义服务等级；处理的优先级；根据实际发起方机构代码；根据实际填写发起方编码、发起时间。

可选的，该方法所述根据实际要求细化业务对象场景包括：细化对象场景中哪些属性是否必须填写，细化属性的取值。

可选的，该方法所述完成实时交换接口后，还包括：将为该业务制定的业务功能编码、业务对象编码在系统内发布。

可选的，该方法所述预定的统一格式为客户关系管理CRM枢纽数据交换协议规定的格式。

在另一方方面，本发明提出了一种基于上述方法的实时数据交换接口的实现系统，在系统中包括发起方系统、枢纽系统和落地方系统；

在枢纽系统和落地方系统中设置有统一的接口；

枢纽系统通过所述统一的接口接收所有业务相关数据并进行转发；

发起方系统发送的数据按照预定的统一格式生成，并至少包含业务功能编码、业务对象协议编码、业务处理信息及相关功能；

落地方系统通过统一的接口接收所述数据，并进行解析，根据业务功能编码识别出请求的业务，根据业务对象协议编码识别出业务对象接口协议，并根据业务处理信息及相关功能进行相应的业务处理。

从上面所述可以看出，本发明提供的实现实时数据交换接口的方法和系统，通过制定统一接口、按照如CRM枢纽数据交换(CEP)协议等统一格式实现实时数据交换接口，接口的内容通过预定协议完成。使用协议后实现系统接口，增加或者变更业务只需要定义业务功能，及将业务对象实例化。

本发明优选实施例中提供的CEP协议分为会话控制和业务对象两个部分，会话控制部分用于控制协议数据交换会话所需要的系统级的信息，是接口中系统级信息的汇总，在制定的新的接口时，直接按格式填写即可；业务对象是CEP协议中表示业务处理信息及相关功能的部分，是对某一类业务的梳理，当有同类型的业务时，可重用业务对象。因此在定义了业务基类和业务对象之后，当进行业务增加或者进行业务变更时，只需要定义业务功能编码及细化业务对象场景。

另外，枢纽还提供数据交换服务等级的支撑，包括优先级和服务调用超时约定和控制等。

当多个系统进行接口时，采用同样的协议，避免重复的接口制定，接口可重用，只需改变部分取值。

本发明优选实施例中使用XML格式描述CEP协议，实现技术无关性；对于Webservice实现接口技术，单个接口方法入口；对于HTTP协议实现接口技术，单个URL入口。

附图说明

图1为现有技术系统结构示意图；

图2为本发明实施例实时数据交换接口的实现系统结构示意图；

图3为本发明实施例数据交互流程示意图；

图4为本发明实施例业务对象格式示意图；

图5为本发明实施例生成统一格式的消息的流程示意图；

图6为本发明以全国电信系统作为实施例的系统结构示意图；

图7为本发明实施例VIP积分消费服务业务的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

参见图2所示，在本发明的系统结构中，在客户端和业务平台之间设置统一枢纽，在枢纽和作为落地方的业务平台侧分别只设置一个统一接口，该接口能够满足所有业务调用的需求。交互的各方按照统一的格式传输数据。

其数据交互流程参见图3所示，包括以下步骤：

步骤301，发起方向枢纽发起请求。

按照预先约定的格式在请求中会话控制部分填写业务功能编码、业务对象编码等，在业务对象部分填写业务请求信息及相关功能。

步骤302，枢纽通过所述接口收到请求后，会做一些内部处理，例如：按照预先约定的格式解析请求，判断请求是否合法，是否能够找到合适的落地方等。

步骤303，枢纽向落地方转发请求。

步骤304，落地方通过所述接口收到请求后，按照预先约定的格式对请求中的内容进行解析，进行该请求所希望的业务处理，并向枢纽回复应答。

该应答中同样按照预先约定的格式，在会话控制部分填写交易流水号等，在业务对象部分填写业务处理结果及相关功能。

步骤305，枢纽通过所述接口收到应答后，还会做一些内部处理，例如：按照预先约定的格式解析应答，确定应答对应的发起方等。

步骤306，枢纽向发起方回复应答。

发起方收到应答后，按照预先约定的格式对进行解析，获取所需业务数据。

作为本发明优选实施例，为了方便数据交互，定义了CRM枢纽数据交换(CEP)协议来实现统一格式下的实时数据交换。

本发明实施例中，实时数据交换所采用的CEP协议主要包括：会话控制及业务对象两个部分；在技术上基于标准的HTTP(S)或WebServices调用实现协议数据交换。其层次结构参见表1所示，从下往上依次为TCP/IP层、HTTP(S)或WebServices和FTP层、XML层、会话控制和存储目录管理层、业务对象层。

表1

本发明实施例CEP协议的数据表示方式都采用标准的XML格式；即HTTP(s)、WebServices或FTP方式所传递的参数或文件都使用XML文档表示。XML文档的Schema统一管理。

其中，CEP协议当前版本所采用的标准HTTP(S)协议版本为1.1；CEP协议当前版本所采用的标准SOAP(WebServices)版本为1.1/1.2；CEP协议当前版本所采用的标准XML版本为1.0。

本发明实施例CEP协议的数据结构都采用XML方式表示，包括XML Schema文档和XML数据的描述文档，其中XML数据的描述文档用于协议的理解和使用。对于每个XML元素的描述包括：序号；父元素名称；元素名称；约束：是否必填，出现次数；类型：描述元素的数据对象类型；长度：数据的长度，用于物理存储的表示；描述。具体XML结构格式如表2所示：

序号	父元素名称	元素名称	约束	类型	长度	描述	取值说明
								1		ContractRoot	1	String
1.1	ContractRoot	TcpCont	1	String		会话控制	用于存储服务请求以及应答的公共部分和消息的控制数据
								1.2	ContractRoot	SvcCont	？	业务对象		业务对象	服务请求和应答的业务数据，即请求/应答内容。

表2

如上所述实时数据交换CEP协议包含会话控制及业务对象两部分，其中会话控制信息是用于控制协议数据交换会话所需要的系统级的信息。会话控制格式如表3所示：

表3

从表3可以看出，会话控制包括请求类型、交易流水号、源和目的地信息、安全签名信息、服务等级、应答信息等。

其中，请求类型包括业务功能编码、业务对象协议编码、协议当前使用的版本号、请求标识。

交易流水号是用于标识一次完整协议交互。

源和目的地信息包括发起方机构代码、发起方(系统/平台)编码、落地方机构编码、落地方(系统/平台)编码。

安全签名信息是用于标识不同系统/平台身份的不可抵赖的依据，由枢纽统一管理并下发到各机构。

服务等级包括处理的优先级、请求时间和应答时间。

应答信息包括应答内容、应答类型、应答代码、应答描述等。

基于表2所示的实时数据交换协议格式，会话控制请求内容说明如表4所示：

序号	父元素名称	元素名称	约束	类型	长度	描述
							1	ContractRoot	TcpCont	1	String		会话控制协议
1.1	TcpCont	BusCode	1	String	F8	业务功能编码
							1.2	TcpCont	ServiceCode	1	String	F8	接口协议编码
1.3	TcpCont	ServiceContractVer	1	String	F16	协议当前使用的版本号。
							1.4	TcpCont	ActionCode	1	String	F1	请求标识
1.5	TcpCont	TransactionID	1	String	F28	交易流水号
							1.6	TcpCont	ServiceLevel	1	String	F1	服务等级，处理的优先级
1.7	TcpCont	SrcOrgID	1	String	F6	发起方机构代码
							1.8	TcpCont	SrcSysID	1	String	F10	发起方(系统/平台)编码
1.9	TcpCont	SrcSysSign	1	String	V128	发起方(系统/平台)签名
							1.10	TcpCont	DstOrgID	1	String	F6	落地方机构编码
1.11	TcpCont	DstSysID	1	String	F10	落地方(系统/平台)编码
							1.12	TcpCont	ReqTime	1	String	F14	请求时间，时间格式字符串：YYYYMMDDHHMMSS
1.13	TcpCont	Request	＊	-	-	请求/扩展信息
							1.13.1	Request	ReqType	1	String	F1	请求/扩展类型
1.13.2	Request	ReqCode	1	String	F4	请求/扩展代码
							1.13.3	Request	ReqDesc	？	String	V128	请求/扩展描述

表4

对应的会话控制应答内容，如表5所示：

序号	父元素名称	元素名称	约束	类型	长度	描述
							1	ContractRoot	TcpCont	1	String		传输控制协议
1.1	TcpCont	ActionCode	1	String	F1	应答标识
							1.2	TcpCont	TransactionID	1	String	F28	交易流水号
1.3	TcpCont	RspTime	1	String	F14	应答时间，时间格式字符串：YYYYMMDDHHMMSS
							1.4	TcpCont	Response	1	-	-	应答/错误信息
1.4.1	Response	RspType	1	String	F1	会话应答类型
							1.4.2	Response	RspCode	1	String	V10	会话应答代码
1.4.3	Response	RspDesc	？	String	V512	会话应答描述

表5

业务对象是CEP协议中表示业务处理信息及相关功能的部分，本实施例中业务对象的格式如图4所示。业务对象划分为业务基类和八个业务对象类：客户及合作伙伴管理、订单管理、客户服务、客户维系挽留、认证与鉴权、产品管理、营销及销售管理、运营管理。其中，业务基类对应数据结构，业务对象类的取值编码对应主数据。

业务基类是根据业务及企业数据模型规范抽象出来的公用对象，在具体的协议业务对象中被引用为数据类型。

业务对象在格式上包括两部分内容：数据结构及主数据，其中所述主数据是指业务对象类的取值编码。

所述CEP协议中业务对象划分为业务基类和八个业务对象类。具体参见表6所示：

表6

所述业务基类包括客户及SP资料管理、订单管理、产品管理、客户服务等业务对象中抽象出来的公用数据类型信息，具体参见表7所示：

表7

本发明实施例中，实时数据交换CEP协议提供协议级的优先级调度，优先级为1-9，最低优先级为1，最高优先级为9。

对于CEP协议，其消息包的最大数据长度为2M字节。如果超过2M字节需由发起方按照协议的格式拆分成不同的协议请求；或使用批量交换协议。

参见图5所示，利用上述CEP协议，生成统一格式的消息过程主要包括如下步骤：

步骤501，梳理业务需求。

当当前业务为新业务或者或者需要业务变更时，需要对该新的业务进行疏理；当业务为已有业务时，则本步骤只需根据需求确定业务。

步骤502，根据数据传输协议确定实时数据交换接口的入口，对于HTTP方式的，使用统一的url入口；对于Webservice方式的，使用单个接口方法入口。

步骤503，根据实际的实时数据交换接口要求完成协议的会话控制部分；主要是对业务功能进行编码，为接口协议进行编码等。

步骤504，根据实际的业务要求细化业务对象场景；即哪些属性是否必须填写，细化属性的取值。

步骤505，用XML语言编写协议，完成接口。用XML语言能够保证技术无关性。

为更详细的说明本发明的技术方案，在下面的实施例中以全国的电信系统为例，对本发明进行进一步具体说明。

参见图6所示，在各省A-Z的CRM之间、业务平台1-N之间，以及各省A-Z与业务平台1-N之间都统一通过CRM枢纽进行数据交换。

参见图7所示，下面以VIP积分消费服务为例，对本发明方法的交互流程进行具体说明。发起方集团CRM/漫游省通过CRM枢纽向落地方归属省发送积分消费记帐(SVC17001)同步归属地信息。

假设该VIP积分消费服务为新的业务，则首先定义业务功能编码及细化业务对象场景，包括以下步骤701～705

步骤701，梳理业务需求。

要增加VIP积分消费服务；要引用积分兑换这个业务对象。具体疏理结果如表8所示。

表8

步骤702，这个接口基于Webservice，定义接口方法：EXCHANGE。

步骤703，根据实际的实时数据交换接口要求完成协议的会话控制部分。

对业务功能进行编码：BUS17001；

引用的积分兑换业务对象编码：SVC17001；

协议版本号码SVC0000120080808；

填写请求标识：0；

系统产生交易流水号；

定义服务等级：1；

处理的优先级：1；

根据实际发起方机构代码；

根据实际填写发起方(系统/平台)编码、发起时间。

步骤704，根据实际要求细化业务对象场景；即哪些属性是否必须填写，细化属性的取值说明。

参见表9所示：

序号	父元素名称	元素名称	约束	类型	宽度	描述
							2	ContractRoot	SvcCont	1	String	-	请求内容
2.1	SvcCont	PointSvc	1	-	-	积分消费服务
							2.2	PointSvc	PartyCodeInfo	1	-	-	客户标识信息(引PartyCodeInfo)
	PointSvc	SvcLevel	？	String	F1	服务级别
								PointSvc	SvcPlace	？	String	F10	服务场地
	PointSvc	StoreID		String	20	商家编号
								PointSvc	POSID		String20		终端编号
	PointSvc	StoreName		String	100	商家名称
								PointSvc	SvcRecords	＊	-	-	服务消费项目
	SvcRecords	ServiceNo	1	String	20	序列号
								SvcRecords	SvcCode	1	String	20	服务消费项目编码
	SvcRecords	SvcDisc	？	String	V256	服务项目内容
								SvcRecords	SvcValue	？	String	V256	服务项目值
	SvcRecords	Price	1	String	V9	金额
							2.5.7	SvcRecords	Amount	1	String	V6	数量？
2.5.9	SvcRecords	Score	1	String	V12	折合应扣积分
							2.5.11		ScoreType		String	F2	积分类型
2.6	PointSvc	Amount	1	String	V9	总金额
							2.7	PointSvc	TotalScore	1	String	V12	折合应扣总积分
2.7	PointSvc	StaffName	？	String	V100	受理人员名字
							2.7	PointSvc	DealTime	？	String	F14	受理时间
2.7	PointSvc	CreateDt	1	String	F14	发起时间
							序号	父元素名称	元素名称	约束	类型	宽度	描述
2	ContractRoot	SvcCont	1	String	-	应答内容
							2.1	SvcCont	PointSvcRsp	1	-	-	积分兑换返回结果
2.1.1	PointSvcRsp					兑换结果
							2.1.2	PointSvcRsp	PointExchangeID				积分兑换流水号
	PointSvcRsp	CurrPoint				兑换后积分余额

表9

步骤705，用XML语言描述协议；将上述表格所列属性的具体取值通过XML文档描述。

通过XML描述后的结果具体如下：

  <？xml version＝″1.0″encoding＝″UTF-8″？>

<ContractRoot>

<TcpCont>

<BusCode>BUS17001</BusCode>

<ServiceCode>SVC17001</ServiceCode>

<ServiceContractVer>SVC1300120080808</ServiceContractVer>

<ActionCode>0</ActionCode>

<TransactionID>6001030001200809130000000123</TransactionID>

<ServiceLevel>1</ServiceLevel>

<SrcOrgID>600103</SrcOrgID>

<SrcSysID>6001030001</SrcSysID>

<SrcSysSign>123</SrcSysSign>

<DstOrgID>100000</DstOrgID>

<DstSysID>1000000005</DstSysID>

<ReqTime>20080913151515</ReqTime>

  </TcpCont>

<SvcCont>

<PointSvc>

……

……

    </PointService>

  </SvcCont>

</ContractRoot>

如此完成接口。

完成接口后，会把为该业务制定的业务功能编码、业务对象编码在系统内发布，使枢纽以及其他的交互各方都能够按照预定的方式完成该业务。

图7所示系统对VIP积分消费服务业务的执行过程包括以下步骤711～716：

步骤711，集团CRM/漫游省按照CEP协议规定的格式生成请求消息，向CRM枢纽发送。

按照CEP协议规定的格式，根据上述定义的业务功能编码及细化业务对象场景，在生成请求消息的过程中，在业务功能编码BusCode的位置填写BUS17001；在业务对象协议编码，即接口协议编码ServiceCode的位置填写SVC17001；并填写业务处理信息(此处业务处理信息位置填写的是业务请求信息)及相关功能；另外还在请求标识ActionCode位置填写0，代表该消息为请求消息。

除此之外还可以填写协议当前使用的版本号ServiceContractVer；服务等级，即处理的优先级ServiceLevel等项目。

步骤712，CRM枢纽通过所述接口收到请求消息后，会做一些内部处理，例如：按照CEP规定的格式解析请求，根据业务功能编码判断请求的业务是否合法，根据业务对象协议编码判断该业务对象协议是否合法，根据请求消息的目的地址是否能够找到合适的落地方；根据服务等级确定优先级和转发时机等等。

步骤713，CRM枢纽向归属省转发请求消息。

步骤714，归属省通过接口收到请求后，按照CEP规定的格式对请求消息中的内容进行解析，进行该请求所希望的业务处理，并向CRM枢纽回复包含有业务处理结果的应答消息。

在解析后，归属省会根据业务功能编码识别出请求的业务，根据业务对象协议编码识别出业务对象接口协议。另外，还可以进一步根据请求消息中协议当前使用的版本号ServiceContractVer确定协议版本等。最后根据业务请求信息及相关功能进行相应的业务处理。

在生成应答消息的过程中，按照CEP协议规定的格式，填写交易流水号TransactionID、在业务处理信息位置填写业务处理结果等；另外还在应答标识ActionCode位置填写1，代表该消息为应答消息。

步骤715，CRM枢纽通过所述接口收到应答后，还会做一些内部处理，例如：按照CEP规定的格式解析应答消息，确定应答消息对应的发起方(即集团CRM/漫游省)等。

步骤716，CRM枢纽向集团CRM/漫游省回复应答消息。

集团CRM/漫游省通过设置在本地的接口收到应答后，按照CEP规定的格式对进行解析，获取所需业务数据，即积分兑换结果。

以上所述的具体实施例仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种实时数据交换接口的实现方法，其特征在于，在需要数据交互的各系统间设置枢纽系统，包括：

发起方进行数据发送时，根据数据传输协议确定实时数据交换接口的入口，根据实际的实时数据交换接口要求完成协议的会话控制部分，填写业务功能编码、业务对象编码，根据实际的业务要求细化业务对象场景，填写业务处理信息及相关功能，从而按照预定的统一格式生成消息，将生成的消息发送到枢纽系统；

枢纽系统通过会话控制部分中的业务功能编码识别请求的业务，根据业务对象编码识别业务对象，并根据源和目的点信息判断路由，转发给落地方；

落地方接收到所述消息后，也相应根据控制部分辨别业务场景，根据业务对象实例进行相应的业务处理。

2.根据权利要求1所述的方法，其特征在于，所述枢纽CRM收到所述消息后，在转发之前进一步按照预定的统一格式解析所述消息，进行内部处理。

3.根据权利要求2所述的方法，其特征在于，所述消息中还包括有版本号，所述枢纽系统根据业务对象协议编码和版本号识别业务对象。

4.根据权利要求2所述的方法，其特征在于，所述生成消息过程中进一步填写协议当前使用的版本号、服务等级；

所述枢纽进一步根据服务等级确定处理的优先级；

目的终端在对接收的消息解析后，进一步根据协议当前使用的版本号确定协议版本。

5.根据权利要求1所述的方法，其特征在于，所述消息中还包括请求标识，所述业务处理信息位置填写的是业务请求信息；

在落地方返回应答消息中包含有应答标识。

6.根据权利要求1所述的方法，其特征在于，落地方进行业务处理后进一步包括：生成应答消息，按照预定的统一格式，在应答消息中填写交易流水号、在业务处理信息位置填写业务处理结果，通过枢纽发送给发起方。

7.根据权利要求1所述的方法，其特征在于，该方法所述生成消息的过程中，用XML语言编写协议，完成实时数据交换接口。

8.根据权利要求1所述的方法，其特征在于，所述根据数据传输协议制定接口的入口进一步包括：对于HTTP方式的，制定统一的url入口；Webservice实现接口技术，定义单个接口入口。

9.根据权利要求1所述的方法，其特征在于，所述根据实际接口要求完成协议的会话控制部分还包括：引用业务对象编码；协议版本号码；填写请求标识；产生交易流水号；定义服务等级；处理的优先级；根据实际发起方机构代码；根据实际填写发起方编码、发起时间。

10.根据权利要求1所述的方法，其特征在于，所述根据实际要求细化业务对象场景包括：细化对象场景中哪些属性是否必须填写，细化属性的取值。

11.根据权利要求1所述的方法，其特征在于，所述完成实时交换接口后，还包括：将为该业务制定的业务功能编码、业务对象编码在系统内发布。

12.根据权利要求1所述的方法，其特征在于，所述预定的统一格式为客户关系管理CRM枢纽数据交换协议规定的格式。

13.一种基于权利要求1-12任意一项所述方法的实时数据交换接口的实现系统，其特征在于，在系统中包括发起方系统、枢纽系统和落地方系统；

在枢纽系统和落地方系统中设置有统一的接口；

枢纽系统通过所述统一的接口接收所有业务相关数据并进行转发；

发起方系统发送的数据按照预定的统一格式生成，并至少包含业务功能编码、业务对象协议编码、业务处理信息及相关功能；

落地方系统通过统一的接口接收所述数据，并进行解析，根据业务功能编码识别出请求的业务，根据业务对象协议编码识别出业务对象接口协议，并根据业务处理信息及相关功能进行相应的业务处理。

Images