CN112101889A - 一种基于元数据的业务流控制方法及装置 - Google Patents

Abstract

本申请公开了一种基于元数据的业务流控制方法及装置，用以解决现有的业务流控制方法缺乏个性化逻辑、灵活性差、适用性差的问题。该方法根据来源实体元数据，调用业务流流程维度配置，确定对应的维度；根据所述来源实体元数据以及所述维度，确定对应的业务流程；根据所述业务流程对应的业务规则，对所述来源实体进行业务处理。本方法在业务流统一控制的基础上，增强了控制的灵活性，使得该统一控制方法能够应用在各种场景中，丰富了流程的适用场景，实现了个性化的业务逻辑控制。

Description

一种基于元数据的业务流控制方法及装置

技术领域

本申请涉及企业资源计划技术领域，尤其涉及一种基于元数据的业务流控制方法及装置。

背景技术

在企业资源计划系统中，业务流控制方法主要包括生单、回写等操作。

目前，对业务流进行控制时，通常采用两种方法：第一，针对每个业务流的生单、回写操作，分别手动进行程序编写，以严格控制程序逻辑；第二，建立业务来源实体与目的实体之间的映射关系，以简化和统一业务实体的生单、回写等处理过程。

但是，上述方法均存在一定的问题。手写编写程序容易出现漏填、错填、属性未赋值、重复赋值等问题，重复劳动过多，工作量太大，耗费过多人工成本。此外，在实体逻辑较为复杂的情况下，建立映射关系的方法并不适用，还是需要进行手动编写，这就丧失了业务流统一控制管理的优点。

发明内容

本申请实施例提供一种基于元数据的业务流控制方法及装置，用以解决现有的业务流控制方法缺乏个性化逻辑、灵活性差、适用性差的问题。

本申请实施例提供的一种基于元数据的业务流控制方法，包括：

根据来源实体元数据，调用业务流流程维度配置，确定对应的维度；

根据所述来源实体元数据以及所述维度，确定对应的业务流程；

根据所述业务流程对应的业务规则，对所述来源实体进行业务处理。

在一个示例中，根据所述业务流程对应的业务规则，对所述来源实体进行业务处理之前，所述方法还包括：确定所述业务流程对应的业务事件；根据所述业务事件对应的路由构件，确定是否对所述来源实体进行业务处理；若否，则终止所述业务流程。

在一个示例中，根据所述业务事件对应的路由构件，确定是否对所述来源实体进行业务处理，包括：根据所述业务事件对应的路由构件标识，获取业务处理类配置，加载业务事件路由接口；调用所述业务事件路由接口，确定是否对所述来源实体进行业务处理。

在一个示例中，所述业务规则为映射规则；根据所述业务流程对应的业务规则，对所述来源实体进行业务处理，包括：根据所述映射规则，确定来源实体与目的实体之间的属性映射关系；根据所述属性映射关系，采用映射程序对所述来源实体进行业务处理，以得到目的实体。

在一个示例中，所述业务规则为业务构件；根据所述业务流程对应的业务规则，对所述来源实体进行业务处理，包括：调用所述业务构件，加载业务动作接口，根据相应的业务动作，对所述来源实体进行业务处理。

在一个示例中，根据所述业务事件对应的路由构件标识，获取业务处理类配置，包括：根据所述业务事件对应的路由构件标识，获取所述来源实体对应的业务处理接口类与业务处理实现类。

在一个示例中，所述业务流程为生单流程；所述方法还包括：根据生单处理的成功或失败结果，进行相应的生单回调处理。

在一个示例中，所述业务规则为生单规则；调用所述业务构件之前，所述方法还包括：调用生单前处理构件，对所述来源实体进行预处理；调用所述业务构件之后，所述方法还包括：调用生单后处理构件，进行生单后的处理。

在一个示例中，根据所述来源实体元数据以及所述维度，确定对应的业务流程，包括：根据所述来源实体元数据以及所述维度，确定来源实体对应的多个业务流程；根据所述所述业务流程对应的业务规则，对所述来源实体进行业务处理，包括：针对每个业务流程，根据该业务流程对应的业务规则，对所述来源实体进行业务处理。

本申请实施例提供的一种基于元数据的业务流控制装置，包括：

第一确定模块，根据来源实体元数据，调用业务流流程维度配置，确定对应的维度；

第二确定模块，根据所述来源实体元数据以及所述维度，确定对应的业务流程；

处理模块，根据所述业务流程对应的业务规则，对所述来源实体进行业务处理。

本申请实施例提供一种基于元数据的业务流控制方法及装置，至少包括以下有益效果：

通过建立业务事件路由接口、生单动作接口、回写动作接口等接口标准，通过生单流程元数据、回写流程元数据将业务事件、生单规则、回写规则、业务动作联系起来，建立了统一的基于元数据的控制业务流的生单和回写的方法。通过这种方法，能够对业务流进行统一控制与操作，有利于大量减少重复劳动，提高工作效率，还有利于提高业务流控制的准确性。

此外，本申请通过增加流程维度配置，针对不同的应用场景，可设置不同的控制维度，以在业务流统一控制的基础上，增强了控制的灵活性，使得该统一控制方法能够应用在各种场景中，丰富了流程的适用场景，实现了个性化的业务逻辑控制。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的基于元数据的业务流控制方法流程图；

图2为本申请实施例提供的基于元数据的业务流控制装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请实施例提供的基于元数据的业务流控制方法流程图，具体包括以下步骤：

S101：根据来源实体元数据，调用业务流流程维度配置，确定对应的维度。

在本申请实施例中，服务器可根据来源实体元数据的标识，调用业务实体对应的业务流流程维度配置，以获得该维度配置中对应的维度。其中，业务实体元数据是对业务实体的属性进行描述的信息，业务流流程维度配置表示根据业务实体的不同业务流程预设的不同维度配置。

业务流流程维度配置可针对每类实体，配置相应的维度，以供相应的业务流程使用。业务流流程维度配置主要包括标识、实体元数据标识、维度1、维度2等属性。其中，“标识”用于唯一标识一个业务流流程维度配置，“实体元数据标识”用于表示该业务流流程维度配置对应的实体元数据标识，服务器可根据该属性来确定本业务流流程维度配置；“维度1”用于表示该业务流流程维度配置中所选用的其中一个维度，为实体中的一个属性；“维度2”与“维度1”具有相同意义，表示该业务流流程维度配置中所选用的另一个维度。在实际应用中，类似“维度1”与“维度2”的属性的数量可根据需要增加或减少，本申请对此不做限定。

在一个实施例中，服务器可通过业务流流程维度配置中的“获取维度配置”操作，根据实体元数据标识，确定对应的业务流流程维度配置，以及对应的维度1、维度2的值。“获取维度配置”操作的输入参数为实体元数据标识，返回值为对应的维度列表。

S102：根据来源实体元数据以及维度，确定对应的业务流程。

在本申请实施例中，服务器在确定业务流对应的维度后，可根据来源实体元数据标识以及获得的维度值，确定相匹配的业务流程元数据，以获得来源实体对应的接下来要进行的业务流程。其中，业务流程元数据用于表示业务流中相关业务流程的控制描述信息。

业务流程主要包括生单流程与回写流程。

在一个实施例中，来源实体在进行生单操作时，可根据来源实体元数据标识与维度值，确定对应的生单流程元数据。

具体的，生单流程元数据主要包括标识、生单流程名称、来源实体元数据标识、来源维度1、来源维度2、目的实体元数据标识、目的维度1、目的维度2、生单业务事件标识、生单规则标识等属性。

其中，“标识”用于唯一标识一个生单流程；“生单流程名称”用于描述生单流程的名称；“来源实体元数据标识”用于表示来源实体；“来源维度1”用于描述生单流程中来源实体的一个控制维度，与S101中业务流流程维度配置中的“维度1”属性相对应，且属性值相同；“来源维度2”用于描述生单流程中来源实体的另一个控制维度，与S101中业务流流程维度配置中的“维度2”属性相对应，且属性值相同；“目的实体元数据标识”用于标识目的实体，在生单流程中，目的实体表示进行生单操作后生成的业务实体；“目的维度1”用于表示目的实体的一个控制维度，与“来源维度1”相对应且属性值相同；“目的维度2”用于表示目的实体的另一个控制维度，与“来源维度2”相对应且属性值相同；“生单业务事件标识”用于唯一表示一个生单业务事件，生单业务事件用于触发生单流程，具体描述见下文；“生单规则标识”用于唯一标识一个生单规则，表示生单流程所采用的规则，具体描述见下文。

在生单过程中，服务器可通过生单流程元数据中的“获取生单流程”操作，根据输入参数——来源实体元数据标识与两个维度值，确定相匹配的来源实体标识与来源维度对应的生单流程元数据，即可获得在这两个维度值下来源实体对应的生单流程。

可知，根据业务流流程维度配置中维度的不同，对应生单流程元数据中来源维度、目的维度的不同，可确定来源实体所对应的不同生单流程。也就是说，即使来源实体与目的实体相同，也可能存在多种不同的生单流程，这样能够适用于多种不同的业务场景。

在一个实施例中，在生单完成后，进行回写操作时，可根据来源实体元数据标识与维度值，确定对应的回写流程元数据。

具体的，回写流程元数据主要包括标识、回写流程名称、来源实体元数据标识、来源维度1、来源维度2、目的实体元数据标识、目的维度1、目的维度2、回写业务事件标识、回写规则标识等属性。

其中，“标识”用于唯一标识一个回写流程；“回写流程名称”用于描述回写流程的名称；“来源实体元数据标识”用于表示来源实体；“来源维度1”用于描述回写流程中来源实体的一个控制维度，与S101中业务流流程维度配置中的“维度1”属性相对应，且属性值相同；“来源维度2”用于描述回写流程中来源实体的另一个控制维度，与S101中业务流流程维度配置中的“维度2”属性相对应，且属性值相同；“目的实体元数据标识”用于标识目的实体，在回写流程中，目的实体表示回写操作对应的输出业务实体；“目的维度1”用于表示目的实体的一个控制维度，与“来源维度1”相对应且属性值相同；“目的维度2”用于表示目的实体的另一个控制维度，与“来源维度2”相对应且属性值相同；“回写业务事件标识”用于唯一表示一个回写业务事件，回写业务事件用于触发回写流程，具体描述见下文；“回写规则标识”用于唯一标识一个回写规则，表示回写流程所采用的规则，具体描述见下文。

在回写过程中，服务器可通过回写流程元数据中的“获取回写流程”操作，根据输入参数——来源实体元数据标识与两个维度值，确定相匹配的来源实体标识与来源维度对应的回写流程元数据，即可获得在这两个维度值下来源实体对应的回写流程。

同样的，根据业务流流程维度配置中维度的不同，对应回写流程元数据中来源维度、目的维度的不同，可确定来源实体所对应的不同回写流程。

可知，在生单流程与回写流程中，来源实体、目的实体是相反的。

例如，在生单过程中，来源实体为A，得到目的实体为B，而在回写流程中，来源实体为B，得到目的实体为A。

在一个实施例中，服务器根据来源实体元数据标识与维度值，可确定与之对应的多个业务流程元数据，获得多个业务流程。在这种情况下，服务器可通过获取业务流程操作，得到返回的业务流程列表。于是，服务器可按照顺序，依次对各业务流程进行操作执行。

S103：根据业务流程对应的业务规则，对来源实体进行业务处理。

在本申请实施例中，服务器可根据确定出的业务流程中包括的业务规则标识，确定对应的业务规则，并采用该业务规则对来源实体进行相应的业务处理。

业务规则的种类包括两种：映射规则与业务构件。其中，映射规则用来描述来源实体的属性与目的实体的属性之间的映射关系，为预设的较为固定的通用规则，可用于较为常规的业务流操作。业务构件表示开发人员编写的特定构件，具有较为独特的业务逻辑，灵活性较高。

在一个实施例中，服务器确定出的业务规则为映射规则时，可根据映射规则，确定来源实体与目的实体之间的属性映射关系。于是，服务器可根据确定出的属性映射关系，采用相应的映射程序对来源实体进行业务处理，以得到输出业务实体。

在一个实施例中，服务器确定出的业务规则为业务构件时，可调用该业务构件，加载相应的业务动作接口，以根据对应的业务动作，对来源实体进行业务处理。其中，不同的业务流程对应不同的业务构件，以及不同的业务动作。

在一个实施例中，服务器在对来源实体进行生单操作时，可根据生单流程中的生单规则标识，通过获取生单规则操作，输入生单规则标识的参数，以得到生单规则元数据的返回值。

生单规则元数据用于定义业务流中来源实体生单成目的实体的规则，主要包括标识、生单规则名称、来源实体元数据标识、目的实体元数据标识、映射规则标识、生单构件标识、生单前处理构件标识、生单后处理构件标识、备注等。

其中，“标识”用于唯一标识一个生单规则；“生单规则名称”用于描述生单规则的名称；“来源实体元数据标识”用于表示来源实体；“目的实体元数据标识”用于表示目的实体；“映射规则标识”用于唯一标识一个映射规则，映射规则用于描述来源实体属性与目的实体属性之间的映射关系；在生单过程中，业务构件包括生单构件、生单前处理构件与生单后处理构件，“生单构件标识”用于唯一标识一个生单构件；“生单前处理构件标识”用于唯一标识一个生单前处理构件，用于进行生单前的业务处理；“生单后处理构件标识”用于唯一标识一个生单后处理构件，用于进行生单后的业务处理；“备注”用于描述生单规则的用途。

需要说明的是，在一个生单规则元数据中，“映射规则标识”与“生单构件标识”只能有一个属性有值。若“映射规则标识”有值，则表示生单规则采用映射规则；若“生单构件标识”有值，则表示生单规则采用生单构件。

在一个实施例中，在生单过程中，服务器在调用生单构件之前，还可首先调用生单前处理构件，对来源实体进行预处理。服务器在调用生单构件之后，还可调用生单后处理构件，进行生单后的处理。其中，生单前处理构件与生单后处理构件的业务逻辑可根据具体的业务实体的需要设置，本申请对此不做限定。

在一个实施例中，服务器在对来源实体进行回写操作时，可根据回写流程中的回写规则标识，通过获取回写规则操作，输入回写规则标识的参数，以得到回写规则元数据的返回值。

回写规则元数据用于定义业务流中目的实体回写来源实体的规则，主要包括标识、回写规则名称、来源实体元数据标识、目的实体元数据标识、映射规则标识、回写构件标识、备注等。

其中，“标识”用于唯一标识一个回写规则；“回写规则名称”用于描述回写规则的名称；“来源实体元数据标识”用于表示来源实体；“目的实体元数据标识”用于表示目的实体；“映射规则标识”用于唯一标识一个映射规则，映射规则用于描述来源实体属性与目的实体属性之间的映射关系；“回写构件标识”用于唯一标识一个回写构件，即业务构件；“备注”用于描述回写规则的用途。

其中，回写规则元数据的“映射规则标识”与“回写构件标识”中只能有一个属性有值。若“映射规则标识”有值，则表示回写规则采用映射规则；若“回写构件标识”有值，则表示回写规则采用回写构件。

在一个实施例中，业务构件元数据用于描述业务构件，主要包括标识、业务构件名称、业务构件类型、业务处理接口类、业务处理实现类、描述等属性。其中，“标识”用于唯一标识一个业务构件；“业务构件名称”用于描述业务构件的名称；“业务构件类型”用于根据用途对业务构件进行分类，业务构件主要包括三种类型：用于路由的构件、用于生单的构件、用于回写的构件，不同构件应用在不同场景；“业务处理接口类”用于表示该业务构件对应的业务处理接口类，不同类型的业务构件对应不同的业务处理接口类；“业务处理实现类”用于表示该业务构件对应的业务处理实现类，用于实现上述业务处理接口类，在不同的业务事件中，同一接口可能对应不同的实现类；“描述”用于表示业务构件的用途。

在一个实施例中，服务器在根据来源实体元数据与维度，获得业务流程后，可通过“获取业务事件”操作，根据业务流程元数据中的业务事件标识属性，确定对应的业务事件元数据的返回值。

之后，服务器可再根据业务事件元数据对应的路由构件，通过路由构件判断是否继续对来源实体进行业务处理。若是，则服务器可继续进行后续操作，获取相应的业务规则。若否，则服务器可终止当前业务流程，执行下一个业务流程。

具体的，业务事件元数据用于记录业务流中的业务事件信息，主要包括标识、业务事件名称、实体元数据标识、业务事件类型、路由构件标识等属性。其中，“标识”用于唯一标识一个业务事件；“业务事件名称”用于描述业务事件的名称；“实体元数据标识”用于表示当前业务事件相关的业务实体；“业务事件类型”用于对业务事件的用途、类型进行分类，可分为生单业务事件与回写业务事件；“路由构件标识”用于唯一标识一个路由构件，路由构件是业务构件的一种，用于进行后续是否继续进行生单或回写的业务判断。

在一个实施例中，服务器在根据路由构件判断是否能够继续时，可根据业务事件元数据对应的路由构件标识，确定该路由构件对应的业务构件元数据。于是，服务器可通过业务构件元数据中的“获取业务处理类配置”操作，获得该路由构件对应的业务处理类的配置，并加载对应的业务事件路由接口。

服务器可通过调用该业务事件路由接口，根据返回值，确定是否对来源实体继续进行业务处理。其中，业务事件路由接口的返回值为布尔类型，返回“是”则表示来源实体符合业务处理条件，可继续进行业务处理，返回“否”则表示来源实体不符合业务处理条件，终止业务处理流程。

在一个实施例中，服务器获取的业务处理类的配置，包括业务事件对应的业务构件中的业务处理接口类与业务处理实现类，服务器可通过该业务处理类的配置，加载相应的程序，以实现对业务动作接口的调用。

在一个实施例中，在生单过程中，生单动作接口用于定义业务流生单时业务处理的接口标准。在进行生单时，服务器可通过生单动作接口中的“生单处理”操作，进行生单处理，以来源实体数据为输入，获得生单接口成功或失败的布尔类型的返回值。

若返回值为“是”，生单成功，则服务器可通过“生单成功回调处理”操作，调用回调进行后续处理。若返回值为“否”，生单失败，则服务器可通过“生单失败回调处理”操作，调用回调进行失败处理。其中，回调对应的业务逻辑具体可根据需要设置，本申请对此不做限定。

在一个实施例中，在回写过程中，回写动作接口用于定义业务流回写时业务处理的接口标准。在进行回写时，服务器可通过回写动作接口中的“回写处理”操作，对业务实体进行回写处理。

在本申请实施例中，通过建立业务事件路由接口、生单动作接口、回写动作接口等接口标准，通过生单流程元数据、回写流程元数据将业务事件、生单规则、回写规则、业务动作联系起来，建立了统一的基于元数据的控制业务流的生单和回写的方法。通过这种方法，能够对业务流进行统一控制与操作，有利于大量减少重复劳动，提高工作效率，还有利于提高业务流控制的准确性。

此外，本申请通过增加流程维度配置，针对不同的应用场景，可设置不同的控制维度，以在业务流统一控制的基础上，增强了控制的灵活性，使得该统一控制方法能够应用在各种场景中，丰富了流程的适用场景，实现了个性化的业务逻辑控制。

为方便说明，本申请以采购订单生成采购到货单的生单业务流为例，对业务流控制方法进行说明。其中，采购订单为来源实体，采购到货单为目的实体。

主要步骤如下：

第一，服务器可根据来源实体元数据标识，调用“业务流流程维度配置”的“获取维度配置”操作，获取当前实体关于生单流程的维度列表。如表1所示，左列表示业务流流程维度配置的属性，右列表示对应的属性值。

表1

属性名称	属性值
		标识	DimensionConfiguration
实体元数据标识	PurchaseOrder
		维度1	单据类型
维度2

在本例中，来源实体元数据标识为PurchaseOrder，预设的维度1为单据类型，维度2为空。则服务器可得到来源实体在生单流程中仅有的一个控制维度为单据类型。

第二，服务器可将实体元数据标识PurchaseOrder与获得的维度单据类型的维度值General，传递给生单流程元数据的“获取生单流程”操作，以获取来源实体对应的生单流程。如表2所示，左列为生单流程元数据的属性，右列为对应的属性值。

表2

在本例中，根据实体元数据标识与维度值，服务器仅可得到表2所示的一个生单流程。

第三，服务器可根据生单流程中的生单业务事件标识，调用业务事件元数据的“获取业务事件”操作，获取当前生单流程对应的生单事件。

如表3所示，左列表示业务事件元数据的属性，右列表示对应的属性值。

表3

属性名称	属性值
		标识	PurchaseOrderAuditedEvent
业务事件名称	采购订单审核业务事件
		实体元数据标识	PurchaseOrder
业务事件类型	生单
		路由构件标识	PurchaseOrder2PurchaseArriveRouting

第四，服务器可根据业务事件元数据中的路由构件标识，调用路由构件元数据的“获取业务处理类配置”操作，获得该业务事件对应的业务处理接口类以及业务处理实现类。

如表4所示，左列为路由构件元数据的属性，右列为对应的属性值。

表4

服务器可通过该业务处理类配置，加载对应的程序，以调用业务事件路由接口。

第五，服务器可在业务事件路由接口中，调用其“是否路由”操作，以判断是否继续进行生单操作。

若该操作返回“否”，则针对当前生单流程的业务处理结束。若该操作返回“是”，则根据表2中当前生单流程元数据中的生单规则标识，调用生单规则元数据的“获取生单规则”操作，获取生单规则元数据。

第六，根据生单规则元数据中的“映射规则标识”属性以及“生单构件标识”属性，判断具体采用的生单规则。

首先判断“映射规则标识”属性是否有值，若有值，表示采用映射规则，则根据映射处理程序进行生单操作；若无值，表示不采用映射规则。之后，再判断“生单构件标识”属性是否有值，若有值，表示采用生单构件进行生单。

如表5所示，左列为生单规则元数据的属性，右列表示对应的属性值。

表5

属性名称	属性值
		标识	PurchaseOrder2PurchaseArrive
生单规则名称	采购订单到采购到货单生单规则
		来源实体元数据标识	PurchaseOrder
目的实体元数据标识	PurchaseArrive
		映射规则标识
生单构件标识	PurchaseOrder2PurchaseArriveCreate
		生单前处理构件标识
生单后处理构件标识
		备注

可见，在本例中，来源实体采用生单构件进行生单操作。

第七，服务器可根据生单构件标识对应的属性值，调用生单构件元数据的“获取业务处理类配置”操作，加载对应的程序，实现生单动作接口的调用。

如表6所示，左列表示生单构件元数据的属性，右列表示对应的属性值。

表6

属性名称	属性值
		标识	PurchaseOrder2PurchaseArriveCreate
业务构件名称	采购订单生成采购到货单生单构件
		业务构件类型	生单
业务处理接口类	com.demo.erp.ICreate
		业务处理实现类	com.demo.erp.Po2PaCreateImpl
描述

第八，服务器可在生单动作接口中，调用“生单处理”操作，对来源实体进行生单处理。

若该操作返回“是”，则代表生单处理成功，服务器可调用生单动作接口的“生单成功回调处理”操作进行后续处理。若生单处理操作返回“否”，则表明生单处理失败，则服务器可调用生单动作接口的“生单失败回调处理”，进行失败后处理。

以上操作完成后，则代表当前生单流程处理完毕，可进入下一生单流程的迭代处理。

需要说明的是，在本例中，为简化描述，对部分元数据中相关属性的属性值置空，若无特别说明，则置空不对本生单流程的说明产生影响。并且，业务流中的回写流程与上述生单流程原理相同，流程相似，具体可参考上述生单流程的相关描述。

以上为本申请实施例提供的基于元数据的业务流控制方法，基于同样的发明思路，本申请实施例还提供了相应的基于元数据的业务流控制装置，如图2所示。

图2为本申请实施例提供的基于元数据的业务流控制装置结构示意图，具体包括：

第一确定模块201，根据来源实体元数据，调用业务流流程维度配置，确定对应的维度；

第二确定模块202，根据所述来源实体元数据以及所述维度，确定对应的业务流程；

处理模块203，根据所述业务流程对应的业务规则，对所述来源实体进行业务处理。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

1.一种基于元数据的业务流控制方法，其特征在于，包括：

根据来源实体元数据，调用业务流流程维度配置，确定对应的维度；

根据所述来源实体元数据以及所述维度，确定对应的业务流程；

根据所述业务流程对应的业务规则，对所述来源实体进行业务处理。

2.根据权利要求1所述的方法，其特征在于，根据所述业务流程对应的业务规则，对所述来源实体进行业务处理之前，所述方法还包括：

确定所述业务流程对应的业务事件；

根据所述业务事件对应的路由构件，确定是否对所述来源实体进行业务处理；

若否，则终止所述业务流程。

3.根据权利要求2所述的方法，其特征在于，根据所述业务事件对应的路由构件，确定是否对所述来源实体进行业务处理，包括：

根据所述业务事件对应的路由构件标识，获取业务处理类配置，加载业务事件路由接口；

调用所述业务事件路由接口，确定是否对所述来源实体进行业务处理。

4.根据权利要求1所述的方法，其特征在于，所述业务规则为映射规则；

根据所述业务流程对应的业务规则，对所述来源实体进行业务处理，包括：

根据所述映射规则，确定来源实体与目的实体之间的属性映射关系；

根据所述属性映射关系，采用映射程序对所述来源实体进行业务处理，以得到目的实体。

5.根据权利要求1所述的方法，其特征在于，所述业务规则为业务构件；

根据所述业务流程对应的业务规则，对所述来源实体进行业务处理，包括：

调用所述业务构件，加载业务动作接口，根据相应的业务动作，对所述来源实体进行业务处理。

6.根据权利要求3所述的方法，其特征在于，根据所述业务事件对应的路由构件标识，获取业务处理类配置，包括：

根据所述业务事件对应的路由构件标识，获取所述来源实体对应的业务处理接口类与业务处理实现类。

7.根据权利要求5所述的方法，其特征在于，所述业务流程为生单流程；

所述方法还包括：

根据生单处理的成功或失败结果，进行相应的生单回调处理。

8.根据权利要求5所述的方法，其特征在于，所述业务规则为生单规则；

调用所述业务构件之前，所述方法还包括：

调用生单前处理构件，对所述来源实体进行预处理；

调用所述业务构件之后，所述方法还包括：

调用生单后处理构件，进行生单后的处理。

9.根据权利要求1所述的方法，其特征在于，根据所述来源实体元数据以及所述维度，确定对应的业务流程，包括：

根据所述来源实体元数据以及所述维度，确定来源实体对应的多个业务流程；

根据所述所述业务流程对应的业务规则，对所述来源实体进行业务处理，包括：

针对每个业务流程，根据该业务流程对应的业务规则，对所述来源实体进行业务处理。

10.一种基于元数据的业务流控制装置，其特征在于，包括：

第一确定模块，根据来源实体元数据，调用业务流流程维度配置，确定对应的维度；

第二确定模块，根据所述来源实体元数据以及所述维度，确定对应的业务流程；

处理模块，根据所述业务流程对应的业务规则，对所述来源实体进行业务处理。

Images