本发明涉及计算机技术领域，更具体地，涉及一种业务流管理方法、引擎和计算机可读存储介质。
背景技术：
随着信息化技术的发展，银行间市场、外汇、债券等金融领域的电子化交易系统得到了飞速的发展，同时也对银行间市场交易领域的软件开发提出了挑战。由于银行间交易市场领域业务种类多、业务流程复杂，而且变化频率高，在对现有的应用程序基础上增加新功能或对已有功能进行扩展时，需要对应用程序的代码逻辑进行调整，以适应新需求，传统的开发模式，程序移植性差，代码复用度底，可扩展性不强。
因此，对银行间交易领域的领域模型进行形式化描述，并根据该领域模型构建交易系统的运行引擎，可以提高交易系统的软件重用层次，并改善软件开发的过程。领域模型是领域知识的形式化描述，是领域知识各组成部分的抽象形式，同时领域模型也表示了领域内各系统的一些共同特征。
目前，领域的模型描述方法有基于面向对象方法的uml(unifiedmodelinglanguage，统一建模语言)的建模。其主要概念包括:对象与类、结构与连接、继承、封装、消息通信，这种领域模型描述方法提供了用例图、状态图、时序图、类图等uml描述工具。它在加强对问题域和系统责任的理解、改进交流、对需求的适应性、支持软件重用等方面表现出比其他方法更好的能力。但是基于面向对象方法的uml的建模，无法确保真实需求和领域模型的统一性，容易造成需求和模型的错位。
技术实现要素：
有鉴于此，本申请公开了一种业务流管理方法、引擎和计算机可读存储介质，以使得业务流中的业务单元在执行过程中相互独立从而降低业务活动之间的耦合度。
第一方面，提供一种业务流管理方法，所述业务流包括多个独立的业务单元，其中，所述方法包括：
响应于触发信号启动执行所述业务流的第一组业务单元；
将所述第一组业务单元的输出存储到所述业务流对应的局部上下文中；
执行所述业务流中的下一组业务单元并将每个业务单元的输出存储到所述局部上下文中，直至所述业务流的业务单元执行完毕；
输出所述业务流的执行结果；
其中，执行所述业务流的下一组业务单元包括：
根据关系配置文件查询与所述下一组业务单元相对应的业务单元的输出；
从所述局部上下文中读取所述相对应的业务单元的输出；
根据所述相对应的业务单元的输出执行所述下一组业务单元。
进一步地，所述方法还包括：
管理所述关系配置文件；
其中，所述关系配置文件用于存储业务单元与其他业务单元的关系；所述业务单元与其他业务单元的关系是指业务单元的输入与其他业务单元的输出之间的关系。
进一步地，管理所述关系配置文件包括：
在所述业务流增加新业务单元时，在所述关系配置文件中增加所述新业务单元与其他业务单元之间的关系；以及
在所述业务流中的业务单元修改时，在所述关系配置文件中同步修改该业务单元与其他业务单元之间的关系。
进一步地，所述业务单元与其他业务单元的关系包括前置关系、后置关系、组合关系和因果关系；
其中，在至少两个业务单元为所述组合关系时，所述至少两个业务单元并行执行，所述至少两个业务单元的输出组合在一起作为其他业务单元的输入。
进一步地，所述一组业务单元在存在所述组合关系时包括至少两个业务单元；在不存在所述组合关系时包括一个业务单元。
进一步地，所述触发信号根据触发规则包括单次信号和定时信号；或者
所述触发信号根据信号的可拆分性包括原子性信号和复合信号。
第二方面，提供一种业务流管理引擎，包括：
业务流执行模块，所述业务流包括多个独立的业务单元，所述业务流执行模块被配置为响应于触发信号顺序执行所述业务流中的每个业务单元并在所述每个业务单元均执行完毕后输出所述业务流的执行结果；
触发信号模块，被配置为存储启动所述业务流执行的信号源；
关系管理模块，被配置为存储业务单元与其他业务单元之间的关系；
局部上下文模块，被配置为存储所述每个业务单元的输出。
进一步地，所述业务流执行模块包括：
业务单元执行子模块，被配置为在所述业务流对应的局部上下文中读取与待执行业务单元相对应的业务单元的输出，并根据所述相对应的业务单元的输出执行所述待执行业务单元；
其中，从关系配置文件中查询所述相对应的业务单元的输出。
进一步地，所述关系管理模块包括：
关系新增子模块，被配置为在所述业务流增加新业务单元时，在所述关系配置文件中增加所述新业务单元与其他业务单元之间的关系；
关系修改子模块，被配置为在所述业务流中的业务单元修改时，在所述关系配置文件中同步修改该业务单元与其他业务单元之间的关系。
第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行以实现上述任一项所述的方法。
本申请实施例通过建立并在关系配置文件中存储业务流中的每个业务单元与其他业务单元的关系，使得所述业务流在接收触发信号时顺序执行所述业务流中的业务单元，并且每个业务单元独立执行，从而降低了业务单元之间的耦合度，增加了程序的复用性。
附图说明
通过以下参照附图对本发明实施例的描述，本发明的上述以及其它目的、特征和优点将更为清楚，在附图中：
图1是本申请实施例的sar领域模型的示意图；
图2是本申请实施例的业务单元之间的关系示意图；
图3是本申请实施例的业务流管理方法的流程图；
图4是本申请实施例的业务单元执行方法的流程图；
图5是本申请实施例的业务单元的生命周期示意图；
图6是本申请实施例的业务流管理引擎的结构图；
图7是基于本申请实施例的业务流管理引擎的系统结构图；
图8是本申请实施例的电子设备的示意图。
具体实施方式
以下基于实施例对本发明进行描述，但是本发明并不仅仅限于这些实施例。在下文对本发明的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本发明。为了避免混淆本发明的实质，公知的方法、过程、流程、元件和电路并没有详细叙述。
此外，本领域普通技术人员应当理解，在此提供的附图都是为了说明的目的，并且附图不一定是按比例绘制的。
除非上下文明确要求，否则整个说明书和权利要求书中的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。
在本发明的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。
图1是本申请实施例的领域模型的示意图。图2是本申请实施例的业务单元之间的关系示意图。如图1所示，sar领域模型包括触发信号(signal)11、业务单元(action)12、业务单元(action)13和关系(relationship)14。
触发信号11是用以触发业务流的信号源。根据信号触发的规则，触发信号11可以划分为单次信号和定时信号。单次信号指每接收到一条业务消息，就触发对应的业务流执行一次。定时信号相对灵活，根据业务的实际需求可以定义为每隔预定的时间触发对应的业务流执行一次，或者定义为在预定的时间段内触发对应的业务流执行一次，还可以定义为在预定的时间段内触发对应的业务流执行多次。定时信号经常应用于需要实时反馈数据信息的场景中。根据信号的可拆分性，触发信号11可以划分为原子性信号和复合信号。触发业务流执行的触发信号是唯一的信号源，这个唯一的信号源为原子性信号。触发业务流执行的触发信号包含多个信号源，这些信号源为复合信号。
业务单元12包括业务原型和业务方法。其中，一个业务原型对应一个已知的业务方法。业务方法指业务单元的行为，其包括输入和输出参数，其中，输出参数包括业务单元的执行结果。业务原型指业务单元数据，即业务方法的输入参数与业务原型中数据字段的映射，业务方法的输出参数与业务原型中数据字段的映射。
关系14指业务单元action之间的关系，即将业务单元之间相互作用、相互影响的状态抽象为关系。关系14包括前置关系、后置关系、组合关系和因果关系。如图2所示，业务单元a和业务单元b是后置关系(业务单元b是业务单元a的后置)，即在业务单元a执行之后，在满足预定的条件下执行业务单元b，其中业务单元a的输出存储到其对应的业务流的局部上下文21中，在满足预定的条件后业务单元b执行时调用局部上下文21中业务单元a的输出。例如，登录系统业务流包括“验签”、“验证密码”、“生成令牌”、“取权限表”和“写审计日志”这五个业务单元。他们依次组成了后置关系，也即“验签”、“验证密码”、“生成令牌”、“取权限表”和“写审计日志”顺序执行。在执行业务单元“验证密码”时，需要从对应的局部上下文中调用业务单元“验签”的输出。
业务单元c和业务单元d是组合关系，即业务单元c和业务单元d并行执行，并且在执行完毕之后，它们的执行结果组合在一起存储于对应的局部上下文21中。也就是说，业务单元c和业务单元d形成一个并行组合22，并行组合22的输出可以对其他业务单元的执行产生影响，也即并行组合22可以和其他业务单元形成前置、后置和因果关系。组合关系在处理大数据运算时非常有用。例如，在图2中，业务单元b与并行组合22是前置关系(并行组合22是业务单元b的前置)，即在满足预定的条件下并行组合22在业务单元b前执行，并行组合在执行完毕之后，将组合输出存储在对应的局部上下文21中，业务单元b执行时调用局部上下文21中存储的并行组合22的组合输出。业务单元e并行组合22是因果关系，即执行并行组合22是成功执行业务单元e的必要条件。在执行业务单元e时调用局部上下文21中存储的并行组合22的组合输出。
局部上下文用于存储所述每个业务单元的输出。一个局部上下文对应一个业务流的生命周期，即在该工作流执行结束后，对应的局部上下文中的数据随之删除。也就是说，局部上下文管理业务流执行过程中数据的生存与消亡，以及数据库链路的分配与释放。
应理解，在系统中还存在全局上下文，全局上下文来源于配置信息，其支持系统中所有的业务流，因此全局上下文支持的数据类型有限，但是可以扩展。
局部上下文和全局上下文均具有一组键值对name/type/value，其中，name表示上下文的唯一名字，type表示上下文存储的数据类型，value表示上下文的存储信息。
在本申请实施例中，根据触发信号(signal)、业务单元(action)以及业务单元之间的关系(relationship)构建sar领域模型，使得业务流中的业务单元经触发信号触发后，调用所需要的配置参数和输入参数独立执行，并且业务流的业务单元通过关系连接以顺序执行。因此，基于sar领域模型来管理业务流降低了业务单元之间的耦合度，增加了程序的复用性。并且，根据项目的真实需求构建业务单元之间的关系，进而构建sar领域模型，使得项目需求与领域模型保持统一性。
图3是本申请实施例的业务流管理方法的流程图。图4是本申请实施例的业务单元执行方法的流程图。如图3所示，在步骤s100，响应于触发信号启动执行业务流的第一组业务单元。例如，在登录系统时，响应于触发信号“登录”执行业务单元“验签”。
应理解，具有组合关系的业务单元并行执行，并将他们的执行结果组合对其他业务单元产生影响。因此，一组业务单元中至少包括一个业务单元，在存在组合关系时，至少包括两个业务单元。
在步骤s200，将第一组业务单元执行后的输出存储到业务流对应的局部上下文中。
在基于sar模型的系统中，每个工作流对应一个局部上下文，当一个工作流执行完毕之后，对应的局部上下文中的数据随之删除。也就是说，局部上下文管理业务流执行过程中数据的生存与消亡，以及数据库链路的分配与释放。
在步骤s300，执行下一组业务单元并将该业务单元执行的输出存储到对应的局部上下文中。
在步骤s400，判断当前执行完毕的业务单元是否为业务流中的最后一个业务单元。若是，执行步骤s500。若不是，执行步骤s300。
在步骤s500，输出该业务流的执行结果。
优选地，业务流管理方法还包括步骤s600。在步骤s600，管理关系配置文件。具体地，在业务流增加新业务单元时，在关系配置文件中增加新业务单元与其他业务单元之间的关系。在业务流中的业务单元修改时，在关系配置文件中同步修改该业务单元与其他业务单元之间的关系。这体现了通过增加或修改业务流中的业务单元之间的关系配置文件，就可以实现在实际需求中业务单元之间逻辑关系的变化，简单方便。
其中，步骤s300还包括步骤s310-s330。如图4所示，在步骤s310，根据关系配置文件查询与待执行的下一组业务单元相对应的业务单元的输出。
关系配置文件用于存储业务单元与其他业务单元之间的关系，业务单元与其他业务单元之间的关系也即描述待执行的业务单元的输入与其他业务单元的输出的影响关系。所述关系包括前置关系、后置关系、组合关系和因果关系。例如，业务单元a和业务单元b是前置关系(业务单元b是业务单元a的前置)，则在满足预定的条件下业务单元b在业务单元之前执行，并且业务单元b执行的输出存储于对应的局部上下文中影响业务单元a的执行(在业务单元a执行时从局部上下文中调用业务单元b的输出)。
在步骤s320，从局部上下文中读取相对应的业务单元的输出。其中，相对应的业务单元的输出是指与待执行的下一组业务单元有关系的业务单元的输出。
在步骤s330，根据相对应的业务单元的输出执行下一组业务单元，将执行的输出存储到局部上下文中。
应理解，待执行的业务单元的输入包括与待执行的业务单元有关系的业务单元的输出，还包括配置文件中的其他输入参数，例如在登录系统业务流中，业务单元“验证密码”执行时，输入参数还包括用户输入的密码和系统中存储的密码。
本申请实施例通过基于sar领域模型的执行引擎执行系统中的业务流，使得业务流中的业务单元经触发信号触发后，调用所需要的配置参数和输入参数独立执行，并且业务流中的业务单元通过关系连接以顺序执行。由此可知，这种管理业务流的方法降低了业务单元之间的耦合度，增加了程序的复用性。
图5是本申请实施例的业务单元的生命周期示意图。如图5所示，业务单元的生命周期包括初始化状态51、就绪状态52、运行状态53、离线状态54、结束状态55和错误状态56。业务单元在初始化状态51下，通过读取配置文件，加载所需的业务逻辑代码，进入就绪状态52。业务单元在就绪状态52下，若接收到运行引擎传递过来输入参数进入运行状态53。若接收由运行引擎发出的离线指令进入离线状态54。若接收运行引擎发出的结束指令结束生命周期进入结束状态55。其中，输入参数包括与该业务单元有关系的业务单元的输出。业务单元在离线状态54下，其业务逻辑代码可以进行修改升级替换。业务单元在执行完毕之后或在离线状态54下接收到启动指令，进入就绪状态52。
应理解，一个运行状态53下的业务单元只有等当前所执行的任务结束并恢复就绪状态52之后，才能响应新的输入参数、运行引擎的离线或结束指令。当业务单元处于初始化状态51、运行状态53或离线状态54时，若出现错误，进入错误状态56，并发出警告消息。
图6是本申请实施例的业务流管理引擎的结构图。业务流管理引擎是基于sar领域模型的运行引擎，是一个在基础和业务层之间引入的业务抽象逻辑层，用于描述业务间的依赖关系、协同执行和数据流转等功能，为复杂业务逻辑开发提供底层透明、动态可控的编程模型与处理框架。如图6所示，业务流管理引擎6包括触发信号模块61、业务流执行模块62、关系管理模块63、局部上下文模块64和全局上下文模块65。
触发信号模块61被配置为存储启动业务流执行的信号源。其中，根据信号触发的规则，触发信号可以划分为单次信号和定时信号。单次信号指每接收到一条业务消息，就触发对应业务流执行一次。定时信号相对灵活，根据业务的实际需求可以定义为每隔预定的时间触发对应的业务流执行一次，或者定义为在预定的时间段内触发对应的业务流执行一次，还可以定义为在预定的时间段内触发对应的业务流执行多次。定时信号经常应用于需要实时反馈数据信息的场景中。根据信号的可拆分性，触发信号可以划分为原子性信号和复合信号。触发业务流执行的触发信号是唯一的信号源，这个唯一的信号源为原子性信号。触发业务流执行的触发信号包含多个信号源，这些信号源为复合信号。
业务流执行模块62被配置为响应于触发信号顺序执行业务流中的每个业务单元并在每个业务单元均执行完毕后输出业务流的执行结果。其中，业务流包括多个独立的业务单元，每个业务单元包括业务原型和业务方法。一个业务原型对应一个已知的业务方法。业务方法指业务单元的行为，其包括输入和输出参数，其中，输出参数包括业务单元的执行结果。业务原型指业务单元数据，即业务方法的输入参数与业务原型中数据字段的映射，业务方法的输出参数与业务原型中数据字段的映射。
业务流执行模块62包括业务单元执行子模块621。业务单元执行子模块621被配置为在业务流对应的局部上下文中读取与待执行业务单元相对应的业务单元的输出，并根据读取的相对应的业务单元的输出执行该待执行业务单元。
关系管理模块63被配置为存储业务单元与其他业务单元之间的关系。所述关系包括前置关系、后置关系、组合关系和因果关系。若业务单元a和业务单元b是后置关系(业务单元b是业务单元a的后置)，即在业务单元a执行之后，在满足预定的条件下执行业务单元b，其中业务单元a的输出存储到其对应的业务流的局部上下文中，在满足预定的条件后业务单元b执行时调用局部上下文中业务单元a的输出。例如，登录系统业务流包括“验签”、“验证密码”、“生成令牌”、“取权限表”和“写审计日志”这五个业务单元。他们依次组成了后置关系，也即“验签”、“验证密码”、“生成令牌”、“取权限表”和“写审计日志”顺序执行。在执行业务单元“验证密码”时，需要从对应的局部上下文中调用业务单元“验签”的输出。
若业务单元c和业务单元d是组合关系，即业务单元c和业务单元d并行执行，并且在执行完毕之后，它们的执行结果组合在一起存储于对应的局部上下文中。也就是说，业务单元c和业务单元d形成一个并行组合p，并行组合p的输出可以对其他业务单元的执行产生影响，也即并行组合p可以和其他业务单元形成前置、后置和因果关系。组合关系在处理大数据运算时非常有用。例如，业务单元b与并行组合p是前置关系(并行组合p是业务单元b的前置)，即在满足预定的条件下并行组合p在业务单元b前执行，并行组合在执行完毕之后，将组合输出存储在对应的局部上下文中，业务单元b执行时调用局部上下文中存储的并行组合p的组合输出。业务单元e并行组合p是因果关系，即执行并行组合p是成功执行业务单元e的必要条件。在执行业务单元e时调用局部上下文中存储的并行组合22的组合输出。
关系管理模块63包括关系新增子模块631和关系修改子模块632。其中，关系新增子模块631被配置为在业务流增加新业务单元时，在关系配置文件中增加新业务单元与其他业务单元之间的关系。关系修改子模块632被配置为在业务流中的业务单元修改时，在关系配置文件中同步修改该业务单元与其他业务单元之间的关系。这体现了通过增加或修改业务流中的业务单元之间的关系配置文件，就可以实现在实际需求中业务单元之间逻辑关系的变化，简单方便。
局部上下文模块64被配置为存储每个业务单元的输出。一个局部上下文对应一个业务流的生命周期，即在该工作流执行结束后，对应的局部上下文中的数据随之删除。也就是说，局部上下文管理业务流执行过程中数据的生存与消亡，以及数据库链路的分配与释放。
全局上下文模块65被配置为存储支持系统中所有业务流的数据。由于全局上下文模块65存储的数据支持系统中所有业务流，所以全局上下文支持的数据类型有限。但是全局上下文模块65可以根据实际需求进行扩展。
局部上下文和全局上下文均具有一组键值对name/type/value，其中，name表示上下文的唯一名字，type表示上下文存储的数据类型，value表示上下文的存储信息。
通过基于sar领域模型的业务流管理引擎，使得业务流中的业务单元经触发信号触发后独立执行，并且业务流的业务单元通过关系连接后顺序执行。这降低了业务单元之间的耦合度，增加了程序的复用性。
图7是基于本申请实施例的业务流管理引擎的系统结构图。如图7所示，在基于业务流管理引擎的用户管理统一认证服务器71中，由触发消息“登录”触发的登录业务流包括验签a、验证密码b、生成令牌c、取权限表d和写审计日志e五个业务单元。这五个业务单元依次组成了后置关系，也即验签a的输出会影响验证密码b的执行，验证密码b的输出会影响生成令牌c的执行等。由于这五个业务单元通过后置关系连接起来，在开发时是独立的，在运行空间是单线程或单进程独立运行的，因此业务单元在系统的生命周期时独立演化，互不影响的。由触发消息“新建”触发的新建业务流包括验证idf、实名验证g、保存信息h、数据同步h和写审计日志e。由触发消息“登出”触发的登出业务流包括验证idf、验证令牌j、更新状态k和写审计日志e。其中，登录业务流、新建业务流和登出业务流中均包括写审计日志e。也就是说，在一个业务单元开发完成后，只需要增加或修改关系配置文件，就可以调用该业务单元，而且不会影响业务流中其他业务单元的正常逻辑。
图8是本申请实施例的电子设备的示意图。图8所示的电子设备为通用数据处理装置，其包括通用的计算机硬件结构，其至少包括处理器81和存储器82。处理器81和存储器82通过总线83连接。存储器82适于存储处理器81可执行的指令或程序。处理器81可以是独立的微处理器，也可以是一个或者多个微处理器集合。由此，处理器81通过执行存储器82所存储的指令，从而执行如上所述的本发明实施例的方法流程实现对于数据的处理和对于其它装置的控制。总线83将上述多个组件连接在一起，同时将上述组件连接到显示控制器84和显示装置以及输入/输出(i/o)装置85。输入/输出(i/o)装置85可以是鼠标、键盘、调制解调器、网络接口、触控输入装置、体感输入装置、打印机以及本领域公知的其他装置。典型地，输入/输出装置85通过输入/输出(i/o)控制器86与系统相连。
本领域的技术人员应明白，本申请的实施例可提供为方法、装置(设备)或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品。
本申请是参照根据本申请实施例的方法、装置(设备)和计算机程序产品的流程图来描述的。应理解可由计算机程序指令实现流程图中的每一流程。
这些计算机程序指令可以存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现流程图一个流程或多个流程中指定的功能。
也可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程中指定的功能的装置。
以上所述仅为本发明的优选实施例，并不用于限制本发明，对于本领域技术人员而言，本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。