CN110058853A - 一种基于工作流及权限控制的api流程化方法 - Google Patents

Abstract

本发明涉及计算机数据接口开放，权限控制领域，提供了一种基于工作流及权限控制的API流程化方法。主旨在于解决现有API因都是一次性且无法复用的代码编写存在代码臃肿、节点繁多、维护困难、开发周期长的问题。其主要技术方案包括：1、对不同的业务属性做类型配置，统一相同含义的业务信息在一套系统中的表达；2、对业务做到配置化管理，实现接口统一和定义一致；3、服务流程定义方法，在服务中定义内部业务逻辑，并将服务流程可视化；4、流程节点间传值，将同一流程不同方法间的传值进行封装成具体对象实体，并存放在内存堆栈中；5、将对象实体在流程中传递，下一级通过拆包，然后合并入参类型和具体对象名后，再次封装向下级传递。

Description

一种基于工作流及权限控制的API流程化方法

技术领域

本发明涉及计算机数据接口开放，权限控制领域，提供了一种基于工作流及权限控制的API流程化方法。

背景技术

现有的API技术大多是基于一次性且无法复用的代码编写组成对外提供服务的API。

其二是目前很多API的提供都是一次性且无法复用的代码编写，这种方式存在代码臃肿、节点繁多、维护困难、开发周期长的问题。且这种形式的API方案很难针对单个调用做到细粒度的权限控制，也无法在多个接口中做到任意组合及值传递，当多个API之间有逻辑关系时只能多次调用，且事务处理需要调用方自行控制。

其三是基于工作流及权限控制的API流程化方案，提出了通过工作流原理将API拆分成多个模块，每个模块之间可以任意组合，模块之间没有强耦合并且不互相依赖，解决了代码重复编写且调用方调用困难的问题。模块可单独配置权限，针对API的权限控制做到细粒度且可控化，在调用流程和安全控制方面都做到了优化。在开发层面，基于一套工作流的流程编辑工具，方便开发人员快速自定义流程及方法，在业务场景明确的情况下快速迭代。在对外提供服务方面，因流程化API的简易对接及联调方便，可使外部渠道快速对接，节省时间和成本。

发明内容

本发明的目的在于解决现有API因都是一次性且无法复用的代码编写存在代码臃肿、节点繁多、维护困难、开发周期长的问题。

为解决上述技术问题本发明采用以下技术方案：

一种基于工作流及权限控制的API流程化方法，包括以下步骤：

步骤1：对不同的业务属性做类型配置，得到一套配置服务元配置中心，用于统一相同含义的业务信息在一套系统中的表达；

步骤2：对业务做到配置化管理，实现接口统一和定义一致；

步骤3：服务流程定义方法，在服务中定义内部业务逻辑，并将服务流程可视化；

步骤4：流程节点间传值，将同一流程不同方法间的传值进行封装成具体对象实体，并存放在内存堆栈中；

步骤5：将对象实体在流程中传递，下一级通过拆包，然后合并入参类型和具体对象名后，再次封装向下级传递。

在上述技术方案基础上，还包括数据导入导出步骤：服务接口导入/导出，服务接口可以文档excel形式定义并方便的导入/导出到数据库或者其他系统中。

上述技术方案中，步骤1包括以下步骤：

步骤1.1：新增服务元数据，定义服务元名称、数据类型，数据长度、数据进度和数据描述；

步骤1.2：在程序初始化时读取此服务元数据表中的字段值，并将此表中的值一次性缓存在分布式缓存服务器中；

步骤1.3：在服务元数据做了变更操作时，元数据同步定时器会对数据库中的元数据定义和缓存服务器中的元数据定义做比对并将不同步的数据重新缓存到缓存服务器中；

步骤1.4：在程序重新读取时，对缓存服务器进行读取，得到最新的元数据定义。

上述技术方案中，步骤2包括以下步骤：

步骤2.1：新增服务接口的所属模块、服务接口的具体方法名称、服务接口的报文类型、服务接口的报文代码以及定义服务接口的描述、配置系统报文头、配置应用头、定义本地报文头；

步骤2.2：在具体配置好的某一服务接口定义中，进行服务接口的具体调用配置，需对服务接口的输入输出信息、入参和出参的字段名称、约束条件、取值范围、是否必输项、值的最大长度、最小长度、接口的提供服务截至日期、字段的具体描述及正则表达式做具体配置；

步骤2.3：服务接口的具体信息在定义完成后在程序初始化时缓存在分布式缓存服务器中，每次的调用接口都从缓存服务器中读取，如有接口定义变更，则会同步缓存服务器与数据库中数据，做到接口定义的一致性。

上述技术方案中，步骤3包括以下步骤：

步骤3.1：在步骤1完成之后，可以通过可视化服务流程定义中心来对服务流程做定制化的定义，首先添加一个服务流程，定义流程ID，流程名称，是否开启状态，是否开启全局事务状态，设置流程的整体超时时间；

步骤3.2：流程定义好后，在数据库中的workflow_init和workflow_desc中就有了流程的具体数据，然后设置流程的开始节点，定义其下级分派节点，节点中可包含已有的服务或其他方法；

步骤3.3：在流程中的各方法有了结果后，需在程序和配置中心中将结果合并，并继续向下一级分配，多级合并及分配用到了流程选举机制，将多个分派任务定义权重，每个权重有自己对应的票数，当要分派下一级时，根据方法合并结果判断权重并计算相应票数，然后根据票数来自动化的决定分派到具体任务和输出结果。

上述技术方案中，步骤4包括以下步骤：

步骤4.1：在原子服务属性中，针对具体服务实现类的别名属性进行设置，此时此流程方法中的返回结果会以此别名进行封装成具体对象，并存放在内存堆栈中；

步骤4.2：下级需要用到上级流程方法中返回的对象时，同样需要在服务实现类的原子服务属性中设置，在入参类型中设置上级方法定义的返回别名对象，如果有多个返回对象，用“#”符号来区分，此时程序会从内存堆栈中找到上级流程的返回结果，并引入到下级流程入参中进行调用；

步骤4.3：在下级流程方法代码中，引入Response参数，在使用此参数时，使用拆包方法，将此参数类型强制转换为上级流程方法中定义的别名参数，然后就可使用此类型中的所有内部方法和内部参数。

上述技术方案中，步骤5包括以下步骤：

步骤5.1：在流程定义xml文件中，将具体对象名称、对象完整类名、对象参数和方法名配置在xml中，并与具体流程service_id绑定；

步骤5.2：在流程配置中心的原子服务属性配置中，将入参的参数名称写入在xml中定义好的对象名称中，在入参类型中写入xml定义好的完整对象路径，代码会读取此配置，并在程序运行时基于反射机制找到此配置，在服务中动态注入代码片段，基于aop原理将代码分片执行，从而在内存堆栈中找到此对象并能够引用对象中的其他方法和参数。

上述技术方案中，数据导入导出步骤具体包括以下步骤：

步骤1：由业务人员在excel中完成接口的定义，并按照约定的规则和表格形式编辑接口功能和具体配置；

步骤2：由开发人员将业务人员excel表格通过服务接口配置中心线上导入到服务接口配置库中，代码对表格中的接口定义和配置做解析读取，并将数据做筛选，读取有效的接口数据并提示不符合标准的接口数据定义；

步骤3：业务人员针对配置中心提示的不符合标准的接口定义做线上变更和修改，完成后接口导入流程完成；

步骤4：服务配置中心勾选需要导出的接口定义，可以批量勾选，选择导出路径，程序将接口定义与缓存服务器的接口定义做比对，并保证接口定义的一致性，然后将数据读取并写入按要求定制的excel表格中，其他业务人员或系统管理员可拿到此份完整接口定义文档做开发或业务对接工作。

本发明因为采用上述技术方案因此具备以下有益效果：

该发明公开了基于工作流及权限控制的API流程化方案，该方案提出了通过工作流原理将API拆分成多个模块，每个模块之间可以任意组合，模块之间没有强耦合并且不互相依赖，解决了代码重复编写且调用方调用困难的问题。模块可单独配置权限，针对API的权限控制做到细粒度且可控化，在调用流程和安全控制方面都做到了优化。在开发层面，基于一套工作流的流程编辑工具，方便开发人员快速自定义流程及方法，在业务场景明确的情况下快速迭代。在对外提供服务方面，因流程化API的简易对接及联调方便，可使外部渠道快速对接，节省时间和成本。

附图说明

图1为本发明结构示意图。

具体实施方式

为进一步说明本发明技术构思，现结合实施例对本发明技术方案做进一步说明。

一种基于工作流及权限控制的API流程化方法，包括以下步骤：

步骤1：服务元数据管理方法，通过对不同的业务属性做类型配置，得到一套配置服务元配置中心，统一相同含义的业务信息在一套系统中的表达，避免对相同含义的业务信息在一套系统中有多种表达；

步骤1.1：在服务元数据管理页面中，新增服务元数据，定义服务元名称、数据类型，数据长度、数据进度和数据描述；

步骤1.2：在程序初始化时读取此服务元数据表中的字段值，并将此表中的值一次性缓存在分布式缓存服务器中，在以后每次代码拉取具体服务元数据时，只读取缓存服务器中的数据，不对数据库做具体操作，减轻数据库压力；

步骤1.3：在配置管理界面对服务元数据做了变更操作时，代码中具体元数据同步定时器会对数据库中的元数据定义和缓存服务器中的元数据定义做比对并将不同步的数据重新缓存到缓存服务器中；

步骤1.4：在程序重新读取时，对缓存服务器进行读取，得到最新的元数据定义。

步骤2：服务接口管理，在接口管理界面对业务做到配置化管理，实现接口统一和定义一致；

步骤2.1：在服务接口管理页面中，新增服务接口的所属模块、服务接口的具体方法名称、服务接口的报文类型、服务接口的报文代码以及服务接口的描述是否有系统报文头、是否有应用头、是否对本地报文头做明确定义；

步骤2.2：在具体配置好的某一服务接口定义中，进行服务接口的具体调用配置，需对服务接口的输入输出信息、入参和出参的字段名称、约束条件、取值范围、是否必输项、值的最大长度、最小长度、接口的提供服务截至日期、字段的具体描述及正则表达式做具体配置；

步骤2.3：服务接口的具体信息在定义完成后在程序初始化时缓存在分布式缓存服务器中，每次的调用接口都从缓存服务器中读取，如有接口定义变更，则会同步缓存服务器与数据库中数据，做到接口定义的一致性。

步骤3：服务接口导入/导出，服务接口可以文档excel形式定义并方便的导入/导出到数据库或者其他系统中；

步骤3.1：由业务人员在exceI中完成接口的定义，并按照约定的规则和表格形式编辑接口功能和具体配置；

步骤3.2：由开发人员将业务人员excel表格通过服务接口配置中心线上导入到服务接口配置库中，代码对表格中的接口定义和配置做解析读取，并将数据做筛选，读取有效的接口数据并提示不符合标准的接口数据定义；

步骤3.3：业务人员针对配置中心提示的不符合标准的接口定义做线上变更和修改，完成后接口导入流程完成；

步骤3.4：服务配置中心勾选需要导出的接口定义，可以批量勾选，选择导出路径，程序将接口定义与缓存服务器的接口定义做比对，并保证接口定义的一致性，然后将数据读取并写入按要求定制的excel表格中，其他业务人员或系统管理员可拿到此份完整接口定义文档做开发或业务对接工作。

步骤4：服务流程定义方法，在服务中定义内部业务逻辑，并将服务流程可视化，实现快速开发和配置；

步骤4.1：在步骤3中的服务接口代码生成之后，可以通过可视化服务流程定义中心来对服务流程做定制化的定义，首先添加一个服务流程，定义流程ID，流程名称，是否开启状态，是否开启全局事务状态，设置流程的整体超时时间等；

步骤4.2：流程定义好后，在数据库中的workflow_init和workflow_desc中就有了流程的具体数据，然后在代码及配置中心中设置流程的开始节点，定义其下级分派节点，节点中可包含已有的服务或其他方法，如用户信息检查、节假日检查、生效日期检查，这些方法可以设置并行也可设置串行，在方法间无状态且无因果关系时建议设置并行，可提高流程效率，其他时候设置串行，保证事务一致性；

步骤4.3：在流程中的各方法有了结果后，需在程序和配置中心中将结果合并，并继续向下一级分配，多级合并及分配用到了流程选举机制，将多个分派任务定义权重，每个权重有自己对应的票数，当要分派下一级时，根据方法合并结果判断权重并计算相应票数，然后根据票数来自动化的决定分派到具体任务和输出结果。

步骤5：流程节点间传值，通过同一流程不同方法间的传值将可用数据进行分部传递，其传值内容为API请求参数和返回参数；

步骤5.1：在原子服务属性中，针对具体服务实现类的别名属性进行设置，此时此流程方法中的返回结果会以此别名进行封装成具体对象，并存放在内存堆栈中；

步骤5.2：下级需要用到上级流程方法中返回的对象时，同样需要在服务实现类的原子服务属性中设置，在入参类型中设置上级方法定义的返回别名对象，如果有多个返回对象，可用#”符号来区分，此时程序会从内存堆栈中找到上级流程的返回结果，并引入到下级流程入参中进行调用；

步骤5.3：在下级流程方法代码中，引入Response参数，在使用此参数时，使用拆包方法，二降此参数类型强制转换为上级流程方法中定义的别名参数，然后就可使用此类型中的所有内部方法和内部参数。

步骤6：接口报文封装对象在流程中传递，通过封装入参类型和具体对象名来向下级传递。

步骤6.1：在流程定义xml文件中，将具体对象名称、对象完整类名、对象参数和方法名配置在xml中，并与具体流程service_id绑定；

步骤6.2：在流程配置中心的原子服务属性配置界面中，将入参的参数名称写入在xml中定义好的对象名称中，在入参类型中写入xml定义好的完整对象路径，代码会读取此配置，并在程序运行时基于反射机制找到此配置，在服务中动态注入代码片段，基于aop原理将代码分片执行，从而在内存堆栈中找到此对象并能够引用对象中的其他方法和参数。

Claims (8)

1.一种基于工作流及权限控制的API流程化方法，其特征在于，包括以下步骤：

步骤1：对不同的业务属性做类型配置，得到一套配置服务元配置中心，用于统一相同含义的业务信息在一套系统中的表达；

步骤2：对业务进行配置化管理，实现接口统一和定义一致；

步骤3：服务流程定义方法，在服务中定义内部业务逻辑，并将服务流程可视化；

步骤4：流程节点间传值，将同一流程不同方法间的传值进行封装成具体对象实体，并存放在内存堆栈中；

步骤5：将对象实体在流程中传递，下一级通过拆包，然后合并入参类型和具体对象名后，再次封装向下级传递。

2.根据权利要求1所述的一种基于工作流及权限控制的API流程化方法，其特征在于，还包括数据导入导出步骤：服务接口导入/导出，服务接口以文档excel形式定义并导入/导出到数据库或者其他系统中。

3.根据权利要求1所述的一种基于工作流及权限控制的API流程化方法，其特征在于，步骤1包括以下步骤：

步骤1.1：新增服务元数据，定义服务元名称、数据类型，数据长度、数据进度和数据描述；

步骤1.2：在程序初始化时读取此服务元数据表中的字段值，并将此表中的值一次性缓存在分布式缓存服务器中；

步骤1.3：在服务元数据做了变更操作时，元数据同步定时器会对数据库中的元数据定义和缓存服务器中的元数据定义做比对并将不同步的数据重新缓存到缓存服务器中；

步骤1.4：在程序重新读取时，对缓存服务器进行读取，得到最新的元数据定义。

4.根据权利要求1所述的一种基于工作流及权限控制的API流程化方法，其特征在于，步骤2包括以下步骤：

步骤2.1：新增服务接口的所属模块、服务接口的具体方法名称、服务接口的报文类型、服务接口的报文代码以及定义服务接口的描述、配置系统报文头、配置应用头、定义本地报文头；

步骤2.2：在具体配置好的某一服务接口定义中，进行服务接口的具体调用配置，需对服务接口的输入输出信息、入参和出参的字段名称、约束条件、取值范围、是否必输项、值的最大长度、最小长度、接口的提供服务截至日期、字段的具体描述及正则表达式做具体配置；

步骤2.3：服务接口的具体信息在定义完成后在程序初始化时缓存在分布式缓存服务器中，每次的调用接口都从缓存服务器中读取，如有接口定义变更，则会同步缓存服务器与数据库中数据，做到接口定义的一致性。

5.根据权利要求1所述的一种基于工作流及权限控制的API流程化方法，其特征在于，步骤3包括以下步骤：

步骤3.1：在步骤1完成之后，通过可视化服务流程定义中心来对服务流程做定制化的定义，首先添加一个服务流程，定义流程ID，流程名称，是否开启状态，是否开启全局事务状态，设置流程的整体超时时间；

步骤3.2：流程定义好后，在数据库中的workflow_init和workflow_desc中就有了流程的具体数据，然后设置流程的开始节点，定义其下级分派节点，节点中可包含已有的服务或其他方法；

步骤3.3：在流程中的各方法有了结果后，需在程序和配置中心中将结果合并，并继续向下一级分配，多级合并及分配用到了流程选举机制，将多个分派任务定义权重，每个权重有自己对应的票数，当要分派下一级时，根据方法合并结果判断权重并计算相应票数，然后根据票数来自动化的决定分派到具体任务和输出结果。

6.根据权利要求1所述的一种基于工作流及权限控制的API流程化方法，其特征在于，步骤4包括以下步骤：

步骤4.1：在原子服务属性中，针对具体服务实现类的别名属性进行设置，此时此流程方法中的返回结果会以此别名进行封装成具体对象，并存放在内存堆栈中；

步骤4.2：下级需要用到上级流程方法中返回的对象时，同样需要在服务实现类的原子服务属性中设置，在入参类型中设置上级方法定义的返回别名对象，如果有多个返回对象，用“#”符号来区分，此时程序会从内存堆栈中找到上级流程的返回结果，并引入到下级流程入参中进行调用；

步骤4.3：在下级流程方法代码中，引入Response参数，在使用此参数时，使用拆包方法，将此参数类型强制转换为上级流程方法中定义的别名参数，然后就可使用此类型中的所有内部方法和内部参数。

7.根据权利要求1所述的一种基于工作流及权限控制的API流程化方法，其特征在于，步骤5包括以下步骤：

步骤5.1：在流程定义xml文件中，将具体对象名称、对象完整类名、对象参数和方法名配置在xml中，并与具体流程service_id绑定；

步骤5.2：在流程配置中心的原子服务属性配置中，将入参的参数名称写入在xml中定义好的对象名称中，在入参类型中写入xml定义好的完整对象路径，代码会读取此配置，并在程序运行时基于反射机制找到此配置，在服务中动态注入代码片段，基于aop原理将代码分片执行，从而在内存堆栈中找到此对象并能够引用对象中的其他方法和参数。

8.根据权利要求2所述的一种基于工作流及权限控制的API流程化方法，其特征在于，数据导入导出步骤具体包括以下步骤：

步骤1：在excel中完成接口的定义，并按照约定的规则和表格形式编辑接口功能和具体配置；

步骤2：将excel表格通过服务接口配置中心线上导入到服务接口配置库中，代码对表格中的接口定义和配置做解析读取，并将数据做筛选，读取有效的接口数据并提示不符合标准的接口数据定义；

步骤3：针对配置中心提示的不符合标准的接口定义做线上变更和修改，完成后接口导入流程完成；

步骤4：服务配置中心勾选需要导出的接口定义，可以批量勾选，选择导出路径，程序将接口定义与缓存服务器的接口定义做比对，并保证接口定义的一致性，然后将数据读取并写入按要求定制的excel表格中。