CN104239052A - 业务流生成方法及装置 - Google Patents

Abstract

本发明提供一种业务流生成方法及装置，该方法包括：调用预配置的业务流引擎，该业务流引擎包含业务流的结构模型以及用于构成业务流的节点模型；其中，所述节点模型包括事件模型、动作模型和业务逻辑模型；对每个节点模型执行相应的参数设置；根据完成参数设置后的节点模型以及配置的各节点模型之间的逻辑关系，生成自定义业务流。通过本发明的技术方案，可以提升业务流引擎的通用性和可定制性，并且能够方便地适应于各种需求变更下的业务流开发与更新。

Description

业务流生成方法及装置

技术领域

本发明涉及数据处理技术领域，尤其涉及业务流生成方法及装置。

背景技术

在系统开发前，需要了解该系统的应用场景和实际需求，从而实现具有针对性的系统开发工作。当不同应用场景下的实际需求类似时，可以通过对已开发系统的借鉴，避免重复开发，提升后续系统的开发效率；然而，当实际需求差异较大，或已开发系统的实际需求发生变化时，相关技术中往往无法对已开发系统进行借鉴，甚至可能导致系统的重新开发。

以安防系统为例。随着视频监控系统(video surveillance & controlsystem)、出入口控制系统(access control system)、入侵报警系统(intruderalarm system)、防爆与安全检查系统等安防子系统的迅速发展，安全管理系统(security management system)软件对各个子系统的集成化、统一管理的需求越来越高。

然而，不同行业对于安防系统的处理流程需求不同，导致安全管理系统的设计和开发成为难点，而随着使用过程中的需求增加和变化，涉及的子系统越来越复杂且多样，使得每次定制化开发都需要重新设计和部署，存在严重的时间和资源浪费。

发明内容

有鉴于此，本发明提供一种新的技术方案，可以解决相关技术中多样化的需求导致系统重复开发的技术问题。

为实现上述目的，本发明提供技术方案如下：

根据本发明的第一方面，提出了一种业务流生成方法，包括：

调用预配置的业务流引擎，该业务流引擎包含业务流的结构模型以及用于构成业务流的节点模型；其中，所述节点模型包括事件模型、动作模型和业务逻辑模型；

对每个节点模型执行相应的参数设置；

根据完成参数设置后的节点模型以及配置的各节点模型之间的逻辑关系，生成自定义业务流。

根据本发明的第二方面，提出了一种业务流生成装置，包括：

调用单元，用于调用预配置的业务流引擎，该业务流引擎包含业务流的结构模型以及用于构成业务流的节点模型；其中，所述节点模型包括事件模型、动作模型和业务逻辑模型；

设置单元，用于对每个节点模型执行相应的参数设置；

生成单元，用于根据完成参数设置后的节点模型以及配置的各节点模型之间的逻辑关系，生成自定义业务流。

由以上技术方案可见，本发明通过采用基于事件的业务流引擎，使得业务流的开发具有通用性，则实际需求发生变化时，仅需要调整触发事件和业务流节点的数据信息即可，而核心的业务流引擎并未发生变化，从而实现了主体结构的可重复利用，极大地降低了对时间和资源的浪费，有助于提升系统的开发效率。

附图说明

图1示出了根据本发明一示例性实施例的业务流生成方法的流程图；

图2示出了根据本发明一示例性实施例的业务流引擎的结构示意图；

图3示出了根据本发明一示例性实施例的基于业务流引擎的系统结构示意图；

图4示出了根据本发明一示例性实施例的业务流处理方法的流程图；

图5示出了根据本发明另一示例性实施例的业务流处理方法的流程图；

图6示出了根据本发明一示例性实施例的处理业务流的示意图；

图7示出了根据本发明另一示例性实施例的处理业务流的示意图；

图8示出了根据本发明另一示例性实施例的处理业务流的示意图；

图9示出了根据本发明另一示例性实施例的处理业务流的示意图；

图10示出了根据本发明另一示例性实施例的处理业务流的示意图；

图11示出了根据本发明一示例性实施例的电子设备的结构示意图；

图12示出了根据本发明一示例性实施例的业务流生成装置的流程图。

具体实施方式

为对本发明进行进一步说明，提供下列实施例：

请参考图1，图1示出了根据本发明一示例性实施例的业务流生成方法，可以包括下述步骤：

步骤102，调用预配置的业务流引擎，该业务流引擎包含业务流的结构模型以及用于构成业务流的节点模型；其中，所述节点模型包括事件模型、动作模型和业务逻辑模型；

在本实施例中，图2示出了根据本发明一示例性实施例的业务流引擎，其中Process(或Procedure)即业务流的结构模型，其具体可以由多种类型的节点构成：Event(即事件模型)、BLU(Business Logic Unit，业务逻辑单元，即业务流逻辑模型)、Action(即动作模型，也可以由多个Action构成一个Activity)；其中，Process中的节点还可以包括Sub process(子流程，即子业务流)，且Sub process的结构与图2所示的Process的结构相同，也可以由Event、BLU和Action节点构成，并且也可以进一步包含其他Subprocess节点，即Sub process相当于对其他Process的调用。

其中，Event节点用于定义业务流所属系统(如安全管理系统等)内部生成或连接至该系统的各子系统上报的事件，在系统内具有唯一ID和统一格式；Action节点用于定义一个或多个动作，每个动作为一项基础业务，其中“基础业务”应该理解为具体的不可再分的业务；BLU节点用于定义业务流中的相邻节点之间的转移条件，该转移条件可以为数值关系或逻辑关系等，比如：启动、停止、挂起、使能、反向、计数、延迟、比较(比如大小比较、字符串模糊匹配、时间段匹配等)、输入(比如用户交互、添加流程数据、UI显示等)。

步骤104，对每个节点模型执行相应的参数设置；

在本实施例中，基于如图2所示统一的业务流引擎结构，在执行具体的业务流开发时，只需要参照该业务流引擎结构，对业务流所需的节点、每个节点的参数以及各节点之间的逻辑关系等进行设置即可，显著降低了业务流的开发量。其中，每种类型的节点的数据结构，也在相应的节点模型中予以定义，比如：

在Event模型中，详细信息需要由各个子系统的接入模块确定，具体可以包括：唯一ID、类型、事件源、发生时间、事件参数列表信息等。

在Action模型中，具体可以包括：唯一ID、执行模式、参数数据列表信息，其中执行模式是指该Action节点的执行方式，即该Action节点所属的系统与其他各个子系统之间业务调用的方式，该方式可以有多种类型，比如系统内部定义的消息模式、sip/http等指定互通的协议模式、SDK调用模式等。

其中，若为Activity模型，则包括：该Activity节点下的Action数量和Action信息列表，其中包含每个Action的信息，且信息结构同Action模型中的信息。

在BLU模型中，具体可以包括：名称、执行ID、执行状态，以及输入信息、输出信息。其中，输入信息可以包括：实例化模式、输入数量和每个输入的详细信息，该详细信息可以包含：输入槽位使用标识、输入Node类型、输入Node名称、输入BLU执行ID和输入的数据列表信息。输出信息可以包括：输出数量、是否输出Event、Event信息(如果需要输出的话)、具体输出项信息，该具体输出项信息可以包含：转移条件列表信息(由下一个节点的转移条件列表信息定义)、输出的数据列表信息。

其中，在上述各类型的节点中，Action模型中的“参数数据列表信息”、BLU模型中的“输入信息”中的“输入的数据列表信息”和“输出信息”中的“输出的数据列表信息”的数据结构相同，均可以包括：数据数量和具体数据信息，该具体数据信息可以包括：字段名、字段别名、字段值、字段类型、来源类型、来源名称等。

步骤106，根据完成参数设置后的节点模型以及配置的各节点模型之间的逻辑关系，生成自定义业务流。

在本实施例中，基于对上述各节点模型的选取和定义，则生成的“自定义业务流”即由上述Event节点、Action节点、BLU节点和Sub process节点构成的Process。

Process和Sub process的数据结构可以包括：名称、数据列表信息、节点数量、节点信息、当前执行的节点序号和审计信息。其中，“名称”是标识该业务流的唯一ID；“数据列表信息”与Action模型中的“参数数据列表信息”等的数据结构相同；“审计信息”为是否开始审计等；“节点信息”即该Process或Sub process包含的所有节点的信息，比如每个节点对应的“节点信息”可以包括：

当前节点的类型、名称、详细信息和下一个节点的信息。其中，“类型”即：Event节点、BLU节点、Action节点、Activity节点或Sub process节点；“名称”即当前节点在所属Process或Sub process中的唯一标识；“详细信息”即上述各节点模型中包含的信息；“下一个节点的信息”可以包括：节点名称、序号、转移条件列表信息，该转移条件列表信息具体可以包含：转移条件数量、逻辑操作符(与、或、非)、转移条件项列表，该转移条件项信息具体可以包括：转移条件项名称、关系操作符(等于、不等于、大于、等于、大于或等于、小于或等于、在集合中、不在集合中、包含某字符串、不包含字符串等)、左/右字段信息(字段源类型、字段输入序号、字段名、字段值、字段数据类型)等，从而通过在当前节点的“节点信息”中包含“下一个节点的信息”，以确定节点之间的相互逻辑关系。

由上述实施例可知，本发明的业务流基于事件的触发而执行，则基于该业务流引擎进行业务流的开发时，不同业务流之间仅触发事件等节点的参数发生变化，而作为核心结构的业务流引擎无需变化，使得业务需求发生变化时，只需要对业务流引擎中各节点进行重新定义即可，极大地提高了业务流开发过程中的代码重复利用，有助于节省开发资源、提升开发效率。

基于上述业务流引擎，本发明进一步提出了图3所示的系统结构，该系统以如图2所示的业务流引擎为核心，通过各接口连接至多个功能模块，从而实现与中心数据库、子系统以及外部设备等的数据交互。下面基于系统内的各功能模块，对该系统的工作原理进行详细说明：

1)WEB/UI流程定制配置模块

WEB/UI流程定制配置模块通过接口1与业务流引擎相连，则用户可以通过该模块访问业务流引擎，并基于如图1所示的业务流生成方法，对具体的业务流进行自定义，还可以对业务流的配置信息进行保存与查询等操作。

具体地，用户可以通过WEB页面或客户端的UI界面中对业务流进行配置和生成等操作。在WEB页面或UI界面上，用户可以通过拖拽等图形化操作完成业务流的流程图绘制；通过双击每个节点模型调出参数输入框并输入对应的配置参数，比如对于“联动摄像机的实况”这一业务流，可以输入如摄像机ID、预置位、联动时间、立即触发还是延迟触发、反向、使能等配置参数；配置完成后，用户可以通过接口5调用系统数据中心交互模块，从而将生成的业务流的所有信息保存至中心数据库，并且可以随时对该业务流执行调用和查询等操作。

可见，WEB/UI流程定制配置模块实际上是业务流的定制工具，可以采用基于B/S(Browser/Server，浏览器/服务器端)模式的WEB配置界面或C/S(Client/Server，客户端/服务器端)模式的单独客户端配置界面，对于前者可采用VML(The Vector Markup Language，矢量可标记语言)实画图+JavaScript实现拖拽，后者客户端自行实现画图与拖拽，两者都可以使用XML(Extensible Markup Language，扩展性标识语言)实现业务流的信息保存与解析。

2)WEB/UI显示或系统监控模块

WEB/UI显示或系统监控模块通过接口2与业务流引擎相连，用于完成系统对业务流的过程监控与实例运行时状态显示，提供业务流的权限优先级控制模型。比如某个业务流总共有13个节点，则当该业务流执行到第6个节点时，即可通过WEB/UI显示或系统监控模块展示为“当前执行进度：6/13”。

3)用户交互输入/输出模块

用户交互输入/输出模块通过接口3与业务流引擎相连，主要是在业务流的实例化过程中实现WEB网页(基于B/S模式)或客户端(基于C/S模式)与用户的交互；同时，还可以用于对服务器端对应的信息进行解析与保存等。

4)具体业务模块

具体业务模块连接至各子系统模块，通过接口4与业务流引擎相连，用于实现与各子系统之间的业务调用和交互。

5)系统数据中心交互模块

系统数据中心交互模块通过接口5与业务流引擎相连，用于与系统的中心数据库交互，从而获取与解析业务流的信息、记录与查询业务流执行的日志信息等。

基于上述功能模块，则业务流引擎可以完成对自定义业务流的解析，业务流实例化的控制(创建、激活、挂起、终止等)，业务流中业务的次序、内容导航，以及与用户和子系统的交互，并提供管理与审查功能。

同时，图3还示出了系统内的数据类型，包括：控制数据、流程数据、应用业务数据。其中，控制数据为：业务流引擎内部的状态、控制等通用数据，与具体的业务流和应用业务无关；流程数据为：当前业务流的定制信息、实例化运行时上下文传递用于流程控制的数据(这部分数据最终可能来自应用数据，但是在流程定制时就可以确定其名值对中的名，值未知，故归为流程数据)；应用业务数据为：本业务流中具体应用业务的数据，业务流引擎不可访问系统的应用数据，一般需访问系统的中心数据库。

请参考图4，图4示出了根据本发明一示例性实施例的业务流处理方法，该方法可以包括下述步骤：

步骤402，根据检测到的用户触发操作，确定相应的被触发的事件；

步骤404，根据所述被触发的事件的数据信息，以及预配置的事件与业务流之间的数据信息的映射关系，查询与所述被触发的事件相匹配的自定义业务流；

在本实施例中，通过事先在Event(事件)与Process(业务流)之间建立映射关系，则配置的自定义业务流可以在不同场景下被重复使用，有助于降低开发量。其中，仅需要将该自定义业务流与所需的Event之间建立映射关系，即可通过该Event方便地实现对该自定义业务流的调用。

步骤406，在加载所述自定义业务流时，将所述被触发的事件的数据传递至查询到的自定义业务流；

在本实施例中，通过将被触发的事件的数据传递至自定义业务流，使得自定义业务流中可以通过对该事件的解析，触发其包含的其他节点。

步骤408，根据所述被触发的事件的数据，执行所述自定义业务流。

由上述实施例可知，本发明的业务流基于事件的触发而执行，则基于该业务流引擎进行业务流的开发时，不同业务流之间仅触发事件等节点的参数发生变化，而作为核心结构的业务流引擎无需变化，使得业务需求发生变化时，只需要对业务流引擎中各节点进行重新定义即可，极大地提高了业务流开发过程中的代码重复利用，有助于节省开发资源、提升开发效率。

下面结合图5对本发明的业务流处理方法进行详细描述。其中，图5示出了根据本发明另一示例性实施例的业务流处理方法，该方法可以包括下述步骤：

步骤502，系统接收到订阅的Event消息；

在本实施例中，作为一示例性实施方式，用户可以在系统中进行Event消息的订阅，相当于只有接收到订阅的Event消息时，才触发后续步骤。当然，作为另一示例性实施方式，也可以不执行Event消息的订阅，而是针对接收到的每条Event消息，均执行后续步骤。

步骤504，查询相匹配的Process；

在本实施例中，对相匹配的Process进行查询之前，接收到的Event消息应当于某个Process之间存在匹配关系。比如可以通过下述方式，事先建立该匹配关系：

步骤502’，基于用户需求，在Event消息与Process业务流之间建立映射关系，比如针对Event消息Ea和Process业务流Pa，可以在该Ea与Pa之间进行映射关系的配置；

其中，建立映射关系具体是指在Event的数据信息和Process的数据信息之间建立映射关系。

步骤504’，将Ea-Pa映射关系存储至系统的中心数据库，比如通过图3所示的系统数据中心交互模块实现该存储操作；

进一步地，假定步骤502中接收到的Event消息即Ea，则当步骤504中查询到匹配于Ea的Process为Pa时，可以由上述的系统数据中心交互模块返回查询结果。

步骤506，记载Pa，并根据Ea与Pa之间的映射关系，将Ea的数据信息全部传递至Pa，可以对Pa对应的“来源类型”、“来源名称”等进行填充，以标识这些数据来自Ea。

步骤508，依次解析和执行Pa下的每个Node(节点)。

对于Process下的每个节点，会基于节点的具体类型来实现相应的执行方式，包括：

1)Event节点

Event节点为Process业务流的触发节点，比如图5所示的Ea，用于触发Pa中后续节点的执行。

2)Action节点

Action节点主要是执行来自不同子系统的业务，并将Process中的数据传递给对应的子系统；其中，针对不同的子系统时，需要采用对应的通信方式。

3)BLU节点

BLU节点的执行包括两个方面，即输入的判断与执行、输出的判断与执行。

a.输入的判断与执行：

需要根据输入信息中的实例化模式判断，以进入对应BLU实例。实例化模式一般有：

单输入-单实例模式：当BLU实例仅有一个输入时，如果已初始化过一个Node名称一样的BLU实例，那么将该BLU实例的输入使用现在的输入覆盖，然后对该BLU实例的输出进行判断；

单输入-多实例模式：当BLU实例仅有一个输入时，如果已初始化过一个Node名称一样的BLU实例，那么就再初始化一个BLU实例，直接对输出进行判断；

多输入-顺序输入-单实例模式：对于已初始化的BLU实例，如果输入没有满，则该输入占用该BLU实例的空余槽位，并判断是否有效输入已满(可能有些输入因为定时器的限制，导致已无效)，如满则进行输出判断；如果输入已满，则替换掉第一个槽位；

多输入-顺序满-多实例模式：多输入-顺序满-多实例模式与多输入-顺序输入-单实例模式的区别在于，如果输入已满，则再初始化一个BLU实例。

多输入-不同-单实例模式：如果已有BLU实例的输入被占用，则直接替换该输入，如果输入满，则进行输出的判断执行；

多输入-不同-多实例模式：如果已有BLU实例的输入被占用，则新初始化一个BLU实例，若该BLU实例输入满，则进行输出的判断执行。

b.输出的判断与执行：

对于每一个输出，将输入信息或Process数据信息填充至输出字段，然后判断是否满足输出条件，如果满足则输出，并将BLU实例的状态置位为Enable，否则不输出。对于需要输出Event的，按照用户配置的输出Event的内容，将对应Process数据一一填充至Event信息。对于输出字段是定时器的，启动对应定时器，超时后将BLU实例的状态置位为Disable。

此外，当步骤508中的最后一个节点执行完成后，若存在与预配置的审计信息相匹配的信息，则生成审计报告，否则不生成；其中，审计信息是用户在定制Process时配置的。

基于图5所示的业务流处理方法，下面结合一典型应用场景进行详细描述。请参考图6，图6示出了一示例性实施例的请求开启银行金库大门的业务流：

图6所示的业务流包括5个节点，分别为Event节点1：刷卡事件1；Event节点2：刷卡事件2；BLU节点1：BLU-1，且BLU节点1的输入端连接至Event节点1和Event节点2、输出端连接至BLU节点2；BLU节点2：BLU-2。

其中，BLU节点1为单输入-多实例模式，因而为刷卡事件1和刷卡事件2分别建立一个BLU-1实例；其中，BLU节点1的输出转移条件中有10秒定时器，即刷卡事件的触发时间不超过十秒时输出卡ID，否则输出无效。

BLU节点2为多输入-顺序满-多实例模式，输入是两个BLU-1的输出，输出是请求开门事件，输出的条件为：①两个输入取“并”逻辑且均有效；②两个输入的卡的ID不同。因此，如果任何一个输入超过10秒后状态被置为无效或者两次刷卡时同一ID，则输出判断失败，即不会认为是请求开门事件，从而对两次刷卡事件进行了关联和汇聚。

在图6所示的业务流基础上，如果对应用需求提出了修改，比如要求刷卡时的卡ID在{A，B，C}范围内，才允许开门。相应地，图7示出了满足上述条件的业务流，该业务流只需要在图6实施例的基础上，对BLU节点1的业务逻辑进行修改即可，即为BLU节点1的输出转移条件添加“卡ID在指定范围内”，则使得刷卡事件1或刷卡事件2输入的卡ID不满足该条件时，不会触发请求开门事件，从而不仅对两次刷卡事件进行了关联和汇聚，还对Event的内容进行了过滤。

同时，基于图6所示的已开发的业务流，仅需要对BLU节点1进行配置调整，而可以重复利用其他节点及处理逻辑，即可得到图7所示的业务流，从而有效提升了业务流的开发效率。

在图7所示的业务流基础上，如果对应用需求提出了修改，比如要求在指定时间段(比如8:00-11:30和13:00-17：00，即上班时间)才能够正常触发请求开门事件，否则需要经理值班室打开一个预设开关。相应地，图8示出了满足上述条件的业务流，该业务流在图7所示实施例的基础上添加了下述节点：

BLU节点3，在BLU节点2对应的BLU-2实例有效时，对时间条件进行判断；当处于指定时间段内时，则BLU节点3对应的BLU-3实例的输出将作为BLU节点6(对应于BLU-6实例)的输入；当处于其他时间时，则BLU-3实例的输出将作为BLU节点5(对应于BLU-5实例)的输入。

其中，BLU-5的输入还包括BLU节点4对应的BLU-4实例，该BLU-4实例由Event节点3“经理值班室的开关按下”触发，并当判断该事件的触发时间点处于“其他时间”时，向BLU-5实例进行输出；而BLU-5实例将来自BLU-3实例和BLU-4实例的输入取“并”逻辑作为输出转移条件，BLU-6实例在满足“经理值班室的开关按下”触发事件时，也可以触发“请求开门事件”。

可见，上述实施例通过BLU节点对子系统的刷卡事件进行了过滤、关联与汇聚，最终形成对用户来说合规且有效的事件信息，提高了信息度，节省了人工查看多个事件后再由操作员用户做出判断的工作量，实现了事件定制化与处理自动化。

下面结合另一典型实施例进行说明。请参考图9，图9示出了另一示例性实施例的请求开启银行金库大门的业务流，该业务流在系统接收到请求开门事件时触发，包括：

步骤902，在Activity业务活动中，对刷卡信息与持卡人信息进行对比；

在本实施例中，上述对比操作具体如图10所示：

步骤902A，获取刷卡信息；

步骤902B，展示联动实时窗格；

步骤902C，执行用户交互，提示抓拍操作；

步骤902D，用户手动执行抓拍操作；

步骤902E，执行用户交互，确认抓拍操作；

步骤902F，值班操作员初步对比。

步骤904，在Action活动1中，由领导进行核实与授权；

步骤906，在Action活动2中，值班员执行开门操作，然后结束业务流。

图11示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图11，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成业务流生成装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图12，在软件实施方式中，该业务流生成装置可以包括调用单元、设置单元和生成单元。其中：

调用单元，用于调用预配置的业务流引擎，该业务流引擎包含业务流的结构模型以及用于构成业务流的节点模型；其中，所述节点模型包括事件模型、动作模型和业务逻辑模型；

设置单元，用于对每个节点模型执行相应的参数设置；

生成单元，用于根据完成参数设置后的节点模型以及配置的各节点模型之间的逻辑关系，生成自定义业务流。

可选的，所述事件模型用于定义业务流所属系统内部生成或连接至该系统的各子系统上报的事件；

所述动作模型用于定义一个或多个动作，每个动作为一项基础业务；

所述业务逻辑模型用于定义业务流中的相邻节点之间的转移条件。

可选的，所述节点模型还包括：

子业务流模型，所述子业务流模型用于对已生成的业务流进行调用。

可选的，还包括：

选取单元，用于选取事件；

映射单元，用于将被选取的事件的数据信息与所述自定义业务流的数据信息进行映射配置操作；

存储单元，用于存储配置的映射关系，以使得当所述被选取的事件被触发时，根据所述映射关系调用所述自定义业务流。

因此，本发明通过采用基于事件的业务流引擎，使得业务流的开发具有通用性，则实际需求发生变化时，仅需要调整触发事件和业务流节点的数据信息即可，而核心的业务流引擎并未发生变化，从而实现了主体结构的可重复利用，极大地降低了对时间和资源的浪费，有助于提升系统的开发效率。

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

Claims (8)

1.一种业务流生成方法，其特征在于，包括：

调用预配置的业务流引擎，该业务流引擎包含业务流的结构模型以及用于构成业务流的节点模型；其中，所述节点模型包括事件模型、动作模型和业务逻辑模型；

对每个节点模型执行相应的参数设置；

根据完成参数设置后的节点模型以及配置的各节点模型之间的逻辑关系，生成自定义业务流。

2.根据权利要求1所述的方法，其特征在于，

所述事件模型用于定义业务流所属系统内部生成或连接至该系统的各子系统上报的事件；

所述动作模型用于定义一个或多个动作，每个动作为一项基础业务；

所述业务逻辑模型用于定义业务流中的相邻节点之间的转移条件。

3.根据权利要求1所述的方法，其特征在于，所述节点模型还包括：

子业务流模型，所述子业务流模型用于对已生成的业务流进行调用。

4.根据权利要求1所述的方法，其特征在于，还包括：

选取事件；

将被选取的事件的数据信息与所述自定义业务流的数据信息进行映射配置操作；

存储配置的映射关系，以使得当所述被选取的事件被触发时，根据所述映射关系调用所述自定义业务流。

5.一种业务流生成装置，其特征在于，包括：

调用单元，用于调用预配置的业务流引擎，该业务流引擎包含业务流的结构模型以及用于构成业务流的节点模型；其中，所述节点模型包括事件模型、动作模型和业务逻辑模型；

设置单元，用于对每个节点模型执行相应的参数设置；

生成单元，用于根据完成参数设置后的节点模型以及配置的各节点模型之间的逻辑关系，生成自定义业务流。

6.根据权利要求5所述的装置，其特征在于，

所述事件模型用于定义业务流所属系统内部生成或连接至该系统的各子系统上报的事件；

所述动作模型用于定义一个或多个动作，每个动作为一项基础业务；

所述业务逻辑模型用于定义业务流中的相邻节点之间的转移条件。

7.根据权利要求5所述的装置，其特征在于，所述节点模型还包括：

子业务流模型，所述子业务流模型用于对已生成的业务流进行调用。

8.根据权利要求5所述的装置，其特征在于，还包括：

选取单元，用于选取事件；

映射单元，用于将被选取的事件的数据信息与所述自定义业务流的数据信息进行映射配置操作；

存储单元，用于存储配置的映射关系，以使得当所述被选取的事件被触发时，根据所述映射关系调用所述自定义业务流。