完整版)系统对接方案.docxVIP

完整版)系统对接方案

方式

1.1.1对接方式

本系统采用webservice方式与外部系统进行对接。为了实现数据交换和信息共享，我们采用SOA体系架构和服务总线技术，使各业务子系统和外部业务系统之间能够互相访问和集成。因此，我们采用SOA体系标准作为接口核心标准，其中包括服务目录标准、交换标准、Web服务标准和业务流程标准。我们还制定了适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。同时，我们也考虑了数据交换的安全性，通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。

1.1.2接口规范性设计

系统平台中的接口众多，依赖关系复杂，因此我们必须遵循统一的接口模型进行设计。接口模型不仅要遵循工程统一的数据标准和接口规范标准，还需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。我们采用基于HTTP协议的REST风格接口实现客户端与系统平台以及系统平台间的接口消息协议，协议栈如图4-2所示。

系统采用JSON数据格式传输应用数据，具有自解释和自包含特征。编码和解码通过配置数据对象的序列化和反序列化实现组件完成。

接口协议包含版本信息，通过约束服务功能规范，支持服务平台间接口协作的升级和扩展。服务提供者可通过版本区别同时支持多个版本的客户端，从而使得组件服务的提供者和使用者独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。

请求消息URI中的参数采用UTF-8编码并经过URLEncode编码。请求接口URL格式包括协议、host、port、appname、businesscomponentn。应答的消息体采用JSON数据格式编码，字符编码采用UTF-8.

应答消息根节点为“response”，每个响应包含固定的两个属性节点：“status”和“message”。其他同级子节点为业务返回对象属性，根据业务类型的不同，有不同的属性名称。当客户端支持数据压缩传输时，需要在请求的消息头的“Accept-Encoding”字段中指定压缩方式(gzip)，如消息可以被压缩传输则平台将应答的数据报文进行压缩作为应答数据返回，Content-Length为压缩后的数据长度。

响应结果码在响应消息的“status”属性中，相应的解释信息在响应消息的“message”属性中。响应结果码为6位数字串，根据响应类型，包括成功和其他几类响应码。

系统错误

输入参数不合法错误是一种应用级返回码，用于定义应用级的异常返回。正常的应用级返回码应该定义特定场景的应用级返回说明。

业务数据检查

在接口中，应该提供业务数据检查功能，对于接收到的数据进行合法性检查，对于非法数据和错误数据则应该拒绝接收，以防止外来数据非法入侵，减轻应用支撑平台系统主机处理负荷。业务数据检查的主要内容包括数据格式的合法性，数据来源的合法性和业务类型的合法性。对于解析出的非法数据，可以提供事件报警、分析原因和统计分析等处理方式。

数据压缩/解压

接口应该根据具体的需求提供数据压缩/解压功能，以减轻网络传输压力，提高传输效率，从而使整个系统能够快速响应并发请求，高效率运行。在使用数据压缩/解压功能时，应该具体分析每一类业务的传输过程、处理过程、传输的网络介质、处理的主机系统和该类业务的并发量、峰值及对于所有业务的比例关系等，从而确定该类业务是否需要压缩/解压处理。对于传输文件的业务，必须压缩后传输，以减轻网络压力，提高传输速度。在接口中所使用的压缩工具必须基于通用无损压缩技术，压缩算法的模型和编码必须符合标准且高效，压缩算法的工具函数必须是面向流的函数，并且提供校验检查功能。

完整性管理

根据业务处理和接口服务的特点，应用系统的业务主要为实时请求业务和批量传输业务。实时请求业务采用基于事务处理机制实现，业务传输以数据包的方式进行，对传输和处理的实时性要求很高，对数据的一致性和完整性有很高的要求，应保证高效地处理大量并发的请求。批量传输业务的业务传输主要是数据文件的形式，业务接收点可并发处理大量传输，可适应高峰期的传输和处理，要求传输的可靠性高。

完整性管理在实时交易业务中确保交易的完整性，在批量传输业务中确保数据传输的完整性。消息发送方应遵循本接口规范的验证规则，提供相关验证功能，包括数据的完整性和准确性，超时重发机制的配置，接口元数据信息的提供，敏感数据的加密功能，及时解决数据提供过程中的问题。消息响应方应遵循本接口规范的验证规则，对接收的数据进行验证，及时响应和解决接口数据接收过程中的问题。异常处理应包括生成异常记录文件，自动或人工回收处理可以回收处理的异常记录，记录有关异常事件的日志，根据预先配置的规则进行相关异常处理，并进行自动告警。

接口的可扩展性规划与