二开异构系统薪资数据对接

——基于系统云星空集成功能样例参考

1、s-HR 薪酬数据能不能推送到云星空再做业务计算呢？

2、s-HR 薪酬代发单能不能只推送汇总后的数据到云星空呢？

3、s-HR 薪酬计算能不能拉取第三步系统(比如OA)的某业务数据过来参与计算呢？

在日常的s-HR系统使用过程中，标品这边多少能听得到现场的这些声音，针对这样的一些类似的个性化的需求或者说是业务特性反馈咨询到我们这里。对于我们薪酬领域，咨询较多的就是这类薪资数据的对接推送或同步。然而从标品角度上来讲，目前系统针对性的拓展对接不是很理想，而且涉及到薪资的数据安全，标品并没有额外提供类似功能的基础支持。本文将以这些需求背景下，对于这些场景如果二开，提供一些概况性方面的指导，旨在对现场项目二开这种功能时，有一定的参考帮助。

以下从特定的标品业务，对接云星空的凭证集成功能参考为切入口，讲解下针对特性功能的异构系统数据对接的处理思路。

前备条件：

    推送方：s-HR

    接收方：金蝶云星空

    推送数据来源：核算分摊数据

    接收数据承载：云星空薪资单

以下从五个方面解释下标品实现的参考：

数据对应、数据转换、数据接口、数据一致性、数据安全

数据对应

    数据对应需要考虑双方系统对应传输的核心数据上，关联数据和基础业务数据的映射匹配设计。

    如标品该功能传输的核算分摊数据，关联推送的基础数据有人员、组织、职位，薪酬项目是关联的业务数据，都需要考虑按照什么样的规则做数据映射。首先了解到云星空那边也有对应的人员、组织、职位等基础数据，所以针对这些基础数据，需要考虑如何把两边的数据联系起来，薪酬项目数据星空那边建立了薪资项列表承载，单独作为薪酬项目和薪资项对应的关系维护。

    具体s-HR功能落地实现上，s-HR系统维护了一张映射表，记录同步后的基础数据和项目及规则的id对应关系，即s-HR的人员、组织、职位、薪酬项目、计算规则（对应薪资单据）等数据在系统维护了这样的一张映射表，数据在接收方新加就会在映射表中维护一条新加的映射数据，更新数据的话依赖这张映射表找到对应的对方数据处理。

    Tips：老版本的集成设计上这种数据对应是依据异构系统基础数据的编码对应的。

数据转换

    数据转换即是将推送方按数据接收方的数据格式要求，调整合适的数据到对应接受方的数据接口中，接收方将有特点的业务数据承载。一般推送会按接收方业务数据格式，存在标准的接收api接口的话，需要按照api字段文档，跟进数据对应的关系组装合适的数据结构再推送。

    接收方标品的api无法完全满足的情况下，需要考量专项的接收接口二开调整，因为不能保证推送方一定能提供得了接收方需要的接口所有业务字段的信息（例如薪酬单据到财务单据），二开时需要考虑有效数据的接收解析和额外必填业务字段的默认值处理。

    标品功能上，针对云星空薪资数据的推送，星空那边单独有薪资列表承载接收的数据，s-HR组装计算规则的信息推送解析对应云星空薪资单据头信息，组装核算分摊明细数据至薪资单据分录信息。

    如现场需要推送汇总的数据，需考虑确保接收接口功能能满足解析汇总数据，推送方需要对明细的数据进一步处理，当然，如果推送方已有业务记录汇总的数据，则直接查对应的数据拼装合适对应结构即可再调用推送。

    从这个方向来说，接口功能也是一个很关键的参考因素。

数据接口

    数据接口即是推送方调用接收方的接口作为数据处理，转化到异构系统数据的功能。要求对外、安全、可靠等。从功能产品上面来讲，一般会有对应的接口规范，比如s-HR这边的osf接口，云星空那边的统一webapi平台，都有接口的规范化定义。

    再考虑异构数据集成业务，需要首先考虑系统是否已有提供类似的业务功能接口做相应的数据推送或数据接收，当然不能保证系统一定就能有很合适的接口功能提供，如果功能上有差异且无法变通处理的情况下，则需要二开拓展接口做数据处理。

    标品功能上，推送薪资数据对应的云星空接口，是针对s-HR这边特殊提供的数据解析功能接口，而校验云星空那边的薪资数据是否生成凭证的判断，调用的则是通用的webapi处理。

    若现场确定特性的推送的功能没有已有接口对应，确实需要二开话，可参考对应系统的接口开发规范拓展，当然也可另外找能联系两边系统数据对接的一套方案也可以，只要保证数据能推送接收，数据传输过程的对外安全可靠即可（比如有客户有考虑直接数据库的数据转换，这种就是绕过接口推送解析的方案，不过不是很建议，这种方案很难校验数据的合法性和一些业务特征，除非确实有合适的场景可以这么用）。

数据一致性

    数据一致性区别于接口数据的一次推送，倾向于解释数据业务流转过程中，下游数据的依赖和上游数据的更新冲突的考虑，是一个更长的时间单位内会反映出的问题。

    接口的数据处理一致性本节姑且不谈，这个应该是接口定义是就需要考虑的。如果是推送完成业务数据的流转导致的一致性问题，也是需要考虑设计的。

    标品功能上，薪资数据推送云星空若已生成了财务凭证后，s-HR这边将无法对对应的期次核算数据反审核重新计算调整薪资分摊数据的。

    所以设计层面上，二开可根据实际情况做必要条件的控制。比如异构系统两边对接的都是单据，在下游单据到达业务流转的某个状态后，可反向同步此状态至上游，或者上游在操作对应的单据修改撤销都需要再额外判断下游数据的状态，其都是控制上游对数据的撤销或修改，都应当受到下游的数据状态控制，当然实际情况可能不一定会是单据状态，可能是更后的一个业务操作标识，具体情况需要具体调整。

数据安全

    安全问题可能现场考虑并不多，但是也是极其重要的一个环节。关于安全的考虑应该在各个阶段都有。

    在接口开发阶段，系统接口平台可能会规范一些必要的安全设计，比如数据加密、单点登录等。

    在开发逻辑代码阶段，开发人员也需要考虑已有接口实现（不一定是系统标准提供的）是否已充分考虑到安全的一些相关影响，如果没有满足或者存在某方面的安全隐患，也需要及时规避调整。比如接口如果没有实现数据的加密传输，则需要双方业务代码考虑是否需要按加密的形式处理业务数据。再一个接口数据处理，也需要考虑是否有敏感信息的打印或者sql注入的风险等。

    在数据入库时，是否会有脏数据产生，数据完整性的考虑，必要的数据校验必不可少。

当然这些只是安全考虑的一部分，具体的还需要跟据实际情况分析。

标品功能上，s-HR这边会依赖云星空的对应环境密钥文件建立安全连接再传输数据，云星空也是调用s-HR的osf服务，满足单点登录的安全规范。

至此，再回到开头的三个问题，也能发现这些拓展功能的一些共性。

针对这些数据要求处理，首先要去考虑系统标准上的支持，有无对应功能已能满足，如果不满足，是否有变通处理途径，还不行的话，就考虑定制化的拓展。

定制化的拓展，还是根据上面讲解的五个方面考虑，应该大致有一个思路处理。要考虑异构系统两边的数据对应，数据的转换组装，接口的拓展，后续数据维护的控制流程，及安全方面的考虑。

就拿第一个问题来说，s-HR标品目前是没有这种组装核算数据的接口提供，需要拓展取数逻辑，两边的数据按什么规则对应，同时确定云星空那边按什么数据结构承载数据，是否有标准的接口可用，可用的话可以到什么程度，会不会有什么特殊的逻辑需要处理，还是说有必要再二开一个对应的接收接口或接收承载的业务数据表。业务流转过程中如何控制，是否有特殊场景需要考虑。再一个安全，安全需求安全开发安全编码等是否都考虑到位，假如是内部网络服务环境，从开发周期快速上线的角度来说是不是可以考虑降低安全要求等。而第三个问题也就只是在数据完成推送后，增加一个s-HR的函数拓展取数即可。这些问题梳理了一遍之后，整体的实现逻辑整体上就有一个大致的框架或思路，能规避一些可能会出现的问题。

当然，本文的这种讲解只能作为一个参考，现场的业务需求和场景可能存在更复杂的情况，这里旨在提供一个全方面的参考思路以协助拓展方案的设计落地，可能还是没有解决现场的一些实际问题，但是还是希望能给现场设计的拓展方案给一些有用的指导，如果针对具体的细节功能需要了解，可在论坛或外网找些相关对应的资料深入研究（比如二开环境搭建，osf的拓展，云星空webapi拓展等）。