CN108984567A - 一种业务数据管理系统及方法 - Google Patents

Abstract

本申请公开了一种业务数据管理系统及方法，用以降低各类业务数据的获取在编码实现上的复杂度。该系统包括：业务因子库和业务因子引擎；业务因子库用于提供至少一个业务因子的配置信息，一个业务因子的配置信息中包括至少一个属性的定义，一个属性的定义中包括该属性的取值逻辑；业务因子引擎，用于在被需要获取业务数据的客户端调用时，执行以下过程：确定客户端所需获取的业务数据对应的目标业务因子和目标属性，根据客户端的执行上下文，构建目标业务因子的执行上下文，从业务因子库中读取目标业务因子的配置信息，根据目标业务因子的执行上下文，按照所述目标属性的取值逻辑，得到目标属性的取值后，将该目标属性的取值返回给客户端。

Description

一种业务数据管理系统及方法

技术领域

本申请涉及通信技术领域，尤其涉及一种业务数据管理系统及方法。

背景技术

随着互联网的发展，业务处理场景愈加多样化和复杂化，以应用于电信领域的客户关系管理(Customer Relationship Management，CRM)中的订单管理系统为例，该订单管理系统用于解决如何处理客户通过前端页面所提交的订单请求的问题，类似于电信领域内客户订购这样的业务处理场景由于涉及到不同局点的客户，客户需求差异大，变化大，需要获取的业务数据类型多，数据来源也并不完全一致，因而导致订单管理系统中需要定制大量的用于处理订单请求的复杂逻辑，开发维护的门槛高，难度大，响应客户需求速度慢。

由于业务处理过程需要使用到多种类型的业务数据，而业务数据的获取方式并不完全一致，比如有的可能需要从缓存中获取，有的可能需要从外部接口获取，有的可能需要从数据库表里面获取，因而为了获取到业务处理所需要的业务数据往往需要按照所需业务数据的类型以及业务处理场景等定制相应的硬编码逻辑来获取所需要的业务数据。比如，如果所需的业务数据需要从外部接口获取，那么在编码时需要考虑接口的输入参数是否得到满足，例如必填的字段是否为空，获取到的数据需不需要缓存等诸多因素，复杂度较高。

因而，如何降低各类业务数据的获取在编码实现上的复杂度，是业界亟待解决的问题。

发明内容

本申请提供一种业务数据管理系统及方法，用以降低各类业务数据的获取在编码实现上的复杂度。

第一方面，本申请提供了一种业务数据管理系统，所述系统包括：业务因子库以及业务因子引擎；其中：

所述业务因子库，用于提供至少一个业务因子的配置信息，一个业务因子的配置信息中包括至少一个属性的定义，一个属性的定义中包括该属性的取值逻辑，一个业务因子的一个属性用于提供一类业务数据；

所述业务因子引擎，用于在被需要获取业务数据的客户端调用时，执行以下过程：

根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性；

根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文；

从所述业务因子库中读取所述目标业务因子的配置信息，其中读取到的所述目标业务因子的配置信息中包括所述目标属性的定义；

根据所述目标业务因子的执行上下文，按照所述目标业务因子的配置信息中定义的所述目标属性的取值逻辑，得到所述目标属性的取值；

将所得到的所述目标属性的取值返回给所述客户端。

可以看到，本申请上述实施例所提供的业务数据管理系统，通过配置业务因子的多个属性来提供多种类型的业务数据，从而不同业务处理场景中用于实现各种类型业务数据的获取的各种编码逻辑，将可以统一转化为通过调用本申请上述实施例所提供的业务数据管理系统后基于业务因子库中业务因子的属性取值得到，对于需要获取各种类型的业务数据的客户端而言，将不再需要为了获取所需业务数据而定制相应的业务数据获取逻辑，因而，能够降低各类业务数据的获取在编码实现上的复杂度。

在一种可能的实现中，所述业务因子引擎在确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还用于：

查询所述业务因子库中是否存在所述目标业务因子的配置信息，若查询不到，则中止运行并报错；若查询到所述目标业务因子的配置信息，则从所述目标业务因子的配置信息中查询是否存在所述目标属性的定义，若查询不到，则中止运行并报错；

若查询到所述业务因子库中存在所述目标业务因子的配置信息、且查询到所述目标业务因子的配置信息中存在所述目标属性的定义，则从所述业务因子库中读取所述目标业务因子的配置信息。

通过上述过程，将能够先对业务因子库中是否存在目标业务因子和目标属性进行验证，避免由于目标业务因子或目标属性不存在而导致无法实现业务数据获取的情况。

在一种可能的实现中，所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据作为该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并对获取到的所述原始数据进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性获取所述业务因子的其它任一个或多个属性的取值，并对获取到的所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并获取所述业务因子的其它任一个或多个属性的取值，对获取到的所述原始数据以及所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式。

可以看到，属性的定义中包括取值逻辑的定义，在业务因子各个属性的不同的取值逻辑下，各个属性的取值可以是直接获取的数据源中的原始数据，也可以是基于数据源中的原始数据计算得到的，还可以是基于该属性所属业务因子的其它属性计算得到的，因而，通过业务因子，不仅可以向客户端提供原始的业务数据，还可以向客户端提供按照取值逻辑处理得到的业务数据。

在一种可能的实现中，所述业务因子引擎，在根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还用于：

确定是否已存在所述目标业务因子的上下文；

若确定已存在所述目标业务因子的上下文，则从已存在的所述目标业务因子的上下文中确定是否已存在所述目标属性的取值，若已存在所述目标属性的取值，则获取所述目标属性的取值返回给所述客户端，若不存在所述目标属性的取值，则根据已存在的所述目标业务因子的上下文，按照所述目标属性的取值逻辑，得到所述目标属性的取值后返回给所述管理客户端；

若确定不存在所述目标业务因子的上下文，则根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文。

通过上述过程，可以在已存在目标业务因子的上下文以及目标属性的取值的情况下，直接获取目标属性的取值返回给客户端，提高响应速度。

第二方面，本申请提供了一种业务数据管理方法，所述方法包括：

业务数据管理系统在被需要获取业务数据的客户端调用时，根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性；

其中，所述业务数据管理系统中包括业务因子库，所述业务因子库用于提供至少一个业务因子的配置信息，一个业务因子的配置信息中包括至少一个属性的定义，一个属性的定义中包括该属性的取值逻辑，一个业务因子的一个属性用于提供一类业务数据；

所述业务数据管理系统根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文；

所述业务数据管理系统从所述业务因子库中读取所述目标业务因子的配置信息，其中读取到的所述目标业务因子的配置信息中包括所述目标属性的定义；

所述业务数据管理系统根据所述目标业务因子的执行上下文，按照所述目标业务因子的配置信息中定义的所述目标属性的取值逻辑，得到所述目标属性的取值；

所述业务数据管理系统将所得到的所述目标属性的取值返回给所述客户端。

在一种可能的实现中，所述业务数据管理系统确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还包括：

所述业务数据管理系统查询所述业务因子库中是否存在所述目标业务因子的配置信息，若查询不到，则所述业务数据管理系统中止运行并报错；若所述业务数据管理系统查询到所述目标业务因子的配置信息，则所述业务数据管理系统从所述目标业务因子的配置信息中查询是否存在所述目标属性的定义，若查询不到，则所述业务数据管理系统中止运行并报错；

若所述业务数据管理系统查询到所述业务因子库中存在所述目标业务因子的配置信息、且查询到所述目标业务因子的配置信息中存在所述目标属性的定义，则所述业务数据管理系统从所述业务因子库中读取所述目标业务因子的配置信息。

在一种可能的实现中，所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据作为该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并对获取到的所述原始数据进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性获取所述业务因子的其它任一个或多个属性的取值，并对获取到的所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并获取所述业务因子的其它任一个或多个属性的取值，对获取到的所述原始数据以及所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式。

在一种可能的实现中，所述业务数据管理系统根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还包括：

所述业务数据管理系统确定是否已存在所述目标业务因子的上下文；

若所述业务数据管理系统确定已存在所述目标业务因子的上下文，则所述业务数据管理系统从已存在的所述目标业务因子的上下文中确定是否已存在所述目标属性的取值，若已存在所述目标属性的取值，则所述业务数据管理系统获取所述目标属性的取值返回给所述客户端，若不存在所述目标属性的取值，则所述业务数据管理系统根据已存在的所述目标业务因子的上下文，按照所述目标属性的取值逻辑，得到所述目标属性的取值后返回给所述管理客户端；

若所述业务数据管理系统确定不存在所述目标业务因子的上下文，则所述业务数据管理系统根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文。

本发明上述第二方面或第二方面的任一种实现所述方法的实施以及有益效果可与本发明上述第一方面或第一方面的任一种实现所述系统的实施以及有益效果可以相互参见，重复之处不再赘述。

第三方面，本申请实施例还提供了一种装置，该装置具有实现上述第一方面或上述第一方面的任意一种实现所提供的业务数据管理系统的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或所述软件包括一个或多个与上述功能相对应的功能单元。

在一个可能的实现中，所述装置的结构中包括处理单元、存储单元和通信单元，所述存储单元用于存储上述业务数据管理系统中的业务因子库，所述处理单元用于在通过所述通信单元接收到需要获取业务数据的客户端的调用时，执行上述业务数据管理系统中业务因子引擎所执行的流程，通过所述通信单元向客户端返回其所需的业务数据，具体参见上述第一方面或上述第一方面的任意一种实现所提供的业务数据管理系统的详细描述，此处不做赘述。

第六方面，本申请实施例还提供了一种装置，该装置具有实现上述第一方面或上述第一方面的任意一种实现所提供的业务数据管理系统的功能。所述功能可以通过硬件实现。所述装置的结构中包括处理器、存储器和通信接口，所述处理器、所述存储器和所述通信接口通过总线连接；所述通信接口可用于与客户端设备通信；所述存储器可用于存储上述业务数据管理系统中的业务因子库；所述处理器可用于在通过所述通信接口接收到需要获取业务数据的客户端设备的调用时，调用存储在所述存储器中的指令，执行上述业务数据管理系统中业务因子引擎所执行的流程，通过所述通信接口向所述客户端设备返回其所需的业务数据，具体参见上述第一方面或上述第一方面的任意一种实现所提供的业务数据管理系统的详细描述，此处不做赘述。

第七方面，本申请还提供了一种计算机可读存储介质，该存储介质中存储软件程序，该软件程序在被一个或多个处理器读取并执行时，可实现上述第一方面或上述第一方面的任意一种实现所提供的业务数据管理系统的功能。

附图说明

图1为本申请一些实施例所提供的业务数据管理系统的逻辑框图；

图2为本申请一些实施例中业务因子库中业务因子的配置示意图；

图3为本申请一些实施例所提供的业务数据管理方法的流程示意图；

图4为本申请一些实施例所提供的业务数据管理系统应用于实际场景中的结构示意图；

图5为本申请一些实施例所提供的业务数据管理系统应用于实际场景中的流程示意图；

图6为本申请一些实施例所提供的业务数据管理系统在实际场景中应用后业务的流程示意图；

图7为本申请一些实施例提供的一种装置的结构示意图。

具体实施方式

下面结合附图，对本申请的实施例进行描述。

本申请实施例提供了一种业务数据管理系统及方法，用以降低各类业务数据的获取在编码实现上的复杂度，避免目前大部分业务管理软件系统存在大量的复杂定制逻辑，开发维护的门槛高，难度大，响应客户需求速度慢的缺陷。

应当指出的是，本申请实施例所提供的业务数据管理系统和业务数据管理方法基于同一发明构思，由于解决问题的原理相似，因此本申请实施例所提供的业务数据管理系统和业务数据管理方法的实施可以相互参见，重复之处不再赘述。

具体地，本申请实施例所提供的业务数据管理系统，通过配置业务因子的多个属性来提供多种类型的业务数据，从而对于不同业务处理场景中用于实现各种类型业务数据的获取的各种编码逻辑，将可以统一转化为对本申请实施例所提供的业务数据管理系统进行调用并基于业务因子的属性取值得到，对于需要获取业务数据的客户端而言，将不再需要为了获取所需业务数据而定制相应的业务数据获取逻辑，因而，能够降低各类业务数据的获取在编码实现上的复杂度。

图1示出了本申请一些实施例所提供的业务数据管理系统的逻辑框图。

如图1所示，本申请一些实施例所提供的业务数据管理系统100包括有：业务因子库101以及业务因子引擎102。

其中，业务因子库101，用于提供至少一个业务因子的配置信息；一个业务因子的配置信息中包括至少一个属性的定义，一个属性的定义中包括该属性的取值逻辑，一个业务因子的一个属性用于提供一类业务数据。

具体地，在一些可能的实现中，业务因子的上述配置信息可通过元数据(Metadata)来描述，元数据是用于描述数据的结构化数据，能够描述数据本身的特征和属性。

比如，图2示出了本申请一些实施例中业务因子库中一个业务因子的配置示意图。

如图2所示，该配置示例中使用因子(Factor)表示业务因子库中一个业务因子，使用因子元数据(Factor Metadata)表示该业务因子的配置信息；

因子元数据包括有结构元数据201和属性元数据202：结构元数据201可用于描述因子所具有的各个属性，比如图2所示的属性1、属性2、属性3或更多；属性元数据202可分别对应与各个属性，用于对各个属性进行描述，比如图2中所示出的，属性元数据202中可包括有属性名称、属性类型、属性取值脚本、缓存等等，其中，属性取值脚本可用于描述该属性的取值逻辑。

具体地，一个业务因子的一个属性的取值逻辑可以用于描述该属性从数据源获取原始数据作为该属性的取值的方式；或者，一个属性的取值逻辑也可以用于描述该属性从数据源获取原始数据，并对获取到的原始数据进行计算得到该属性的取值的方式；或者，一个属性的取值逻辑还可以用于描述该属性获取该业务因子的其它任一个或多个属性的取值，并对获取到的其它任一个或多个属性的取值进行计算得到该属性的取值的方式；或者，一个属性的取值逻辑还可以用于描述该属性从数据源获取原始数据，并获取该业务因子的其它任一个或多个属性的取值，对获取到的原始数据以及其它任一个或多个属性的取值进行计算得到该属性的取值的方式。

其中，上述计算具体可以是由算数运算符、关系运算符、逻辑运算符以及位运算符中的任一种或多种形成的计算；其中，算数运算符比如有+、-、*、/、％、++、--；关系运算符比如有＝＝、！＝、>、>＝、<、<＝；逻辑运算符比如有&&、||、！、^、&、|；位运算符比如有～、>>、<<、>>>；等等。

比如，基于图2所示的因子配置示例，假设如图2所示的因子为用于提供用户相关的各类业务数据的用户业务因子，该因子的配置信息中存在一个用以提供用户号码的属性1，和一个用以提供用户全名(按照姓+名方式组成的用户名)的属性2，并假设用户号码存储在数据库中，用户的姓以及用户的名均存储在缓存中，那么：

属性1的取值脚本具体可以是描述如何从数据库中获取到用户号码来作为属性1的取值的方式；属性2的取值脚本具体可以是描述如何从缓存中获取用户的姓以及用户的名，并将获取到的用户的姓和用户的名按照姓+名的方式进行拼接(通过逻辑运算符&来计算)得到属性2的取值的方式。

可以看到，由于业务因子各个属性的取值可以是直接获取的数据源中的原始数据，也可以是基于数据源中的原始数据计算得到的，还可以是基于该属性所属业务因子的其它属性计算得到的，因而，通过业务因子，不仅可以向客户端提供原始的业务数据，还可以向客户端提供按照取值逻辑处理得到的业务数据。

基于上文所描述的业务因子库101以及业务因子，可以看到，通过本申请上述实施例，可以根据业务处理的需要在业务因子库101中配置相应的业务因子，比如包括不限于：用户业务因子(subscriber)、用户列表因子(subscribers)、订单项因子(orderItem)、订单项列表因子(orderItems)、商品规格信息因子(offeringInfo)、产品规则信息因子(productInfo)、操作员因子(staff)、群用户因子(groupSubscriber)、群用户列表因子(groupSubscribers)、群成员因子(groupMember)、群成员列表因子(groupMembers)、订单因子(order)、账户因子(account)、账户列表因子(accounts)、客户因子(customer)等等。

在一些实际场景中，业务因子库101中各个业务因子的配置信息可以采用多种存储方式。比如，可存储在可扩展标记语言(Extensible Markup Language，XML)文件中，存储在数据库中或者以上两者相结合的方式等等。

通过本申请上述实施例中的业务因子库101，不同业务处理场景中各种类型业务数据的获取逻辑能够统一转化为业务因子库101中各个业务因子各个属性的取值逻辑，客户端需要获取业务数据时，可直接通过调用业务数据管理系统100，由业务数据管理系统100基于业务因子库101中相应的业务因子的配置信息，向客户端提供其所需的业务数据，从而降低各类业务数据的获取在编码实现上的复杂度。

如图1所示，业务数据管理系统100中还包括有业务因子引擎102，由业务因子引擎102执行业务数据管理系统100在客户端的调用下，向客户端提供业务数据的逻辑。

具体地，业务因子引擎102可实现为一系列可执行的软件代码，这一系列软件代码所实现的逻辑结构中包括向客户端提供的调用接口(Application ProgrammingInterface，API)，以及读取业务因子库101中配置信息的内部API，以及在通过调用接口被客户端调用后，通过内部API访问业务因子库101，得到客户端所需业务数据返回给客户端的逻辑。

图3示出了本申请一些实施例中业务数据管理系统100在被需要获取业务数据的客户端调用时所执行的方法流程示意图。如图3所示的流程具体可由业务数据管理系统100中的业务因子引擎102执行，该流程可如下描述。

在步骤301部分，业务数据管理系统100中的业务因子引擎102根据客户端的调用，确定客户端所需获取的业务数据对应的目标业务因子和目标属性；在步骤302部分，业务因子引擎102根据客户端的执行上下文，构建目标业务因子的执行上下文。

在一些可能的实现中，业务因子引擎102向客户端提供的调用接口可以实现为预设的语法结构；比如，业务数据管理系统100可对外开放一种专用的领域专用语言(DomainSpecific Language，DSL)语法，语法的结构样例可以如$Factor_+{目标业务因子名称.目标属性名称}，由目标业务因子的名称和目标业务因子中目标属性的名称来指示需要获取的业务数据。该语法可用于对业务因子引擎102进行调用，从而触发业务因子引擎102执行步骤301部分，对该语法进行解释执行，确定出目标业务因子的名称以及目标属性的名称。

举例来说，在电信领域业务订单的校验场景中，假设用户提交了用于订购流量包的订单请求后，订单管理系统在处理订单请求过程中将需要对用户状态进行校验，比如仅在用户状态为活跃(active)状态时才继续为该用户订购流量包，如果用户状态为非活跃(inactive)状态是终止该用户的订购请求，基于上述业务数据管理系统100对外开放的语法结构样例，并假设业务因子库101中配置有用于提供用户相关的各类型业务数据的业务因子，使用“subscriber”表示，并假设该业务因子中定义了用于提供用户状态数据的属性，使用“status”表示，上述对用户状态的校验逻辑将可以直接通过“$Factor_subscriber.status＝’active’”来实现，订单管理系统需要校验用户状态时，由“$Factor”调用业务因子引擎102，或者也可以理解为业务因子引擎102对“$Factor”进行拦截，触发对该语法的解析，确定该语法的意图是需要获取“subscriber”这个业务因子下的“status”这个属性的取值，即确定出订单管理系统所需获取的业务数据对应的目标业务因子为“subscriber”和目标属性为“status”。

执行上下文(execution context)，或者也被称为执行上下文环境，是用来描述代码执行的抽象概念，代码通常可认为是在某个执行上下文中运行的。在本申请一些实施例中，当客户端在客户端当前的执行上下文中调用业务因子引擎102时，业务因子引擎102将可以通过步骤302部分，根据客户端的执行上下文，构建出目标业务因子的执行上下文，从而在目标业务因子的执行上下文中运行业务因子引擎102内部的逻辑结构，调用结束后返回客户端原来的执行上下文中。

可选地，由于执行上下文在构建后会具有一个设定的生命周期，因而在图3所示流程的一种可能的实现中，业务因子引擎102根据客户端的调用，确定客户端所需获取的业务数据对应的目标业务因子和目标属性之后，可以先确定是否已存在目标业务因子的上下文：

如果确定已存在目标业务因子的上下文，则业务因子引擎102可以直接从已存在的目标业务因子的上下文中确定是否已存在目标属性的取值，若已存在目标属性的取值，那么业务因子引擎102将可以直接获取目标属性的取值返回给客户端，若不存在目标属性的取值，则业务因子引擎102可以根据已存在的所述目标业务因子的上下文，再按照目标属性的取值逻辑，得到目标属性的取值后返回给管理客户端；

如果确定不存在目标业务因子的上下文，则业务因子引擎102可以执行步骤302部分，根据客户端的执行上下文，构建目标业务因子的执行上下文。

具体地，业务因子引擎102在构建出目标业务因子的执行上下文的过程中，除了根据调用时传递的参数，即目标业务因子和目标属性，还可根据客户端上下文，获取与该客户端所需获取的业务数据相关的参数放入目标业务因子的执行上下文中。比如，业务因子引擎102可在其内部逻辑结构中定义出需要从客户端执行上下文中获取的参数。

仍然以上述电信领域中业务订单的校验为例，用户提交了用于订购流量包的订单请求后，订单管理系统在处理该订单的执行上下文中将会存储有该订单请求所对应的用户标识(Identity，ID)，即提交该订单请求的用户的标识，进而，业务因子引擎10在解析语句“$Factor_subscriber.status”后，可按照其内部的逻辑结构，获取订单管理系统的执行上下文中的用户标识，来构建业务因子“subscriber”的执行上下文。

进而，在步骤303部分，业务因子引擎102可从业务因子库101中读取目标业务因子的配置信息，其中读取到的目标业务因子的配置信息中包括目标属性的定义。

在一些可能的实现中，业务因子库101各个业务因子的配置信息具体可以存储为XML文件，因而，业务因子引擎102在步骤303部分具体可以是读取目标业务因子所对应的XML文件中存储的配置信息。

可选地，业务因子引擎102在确定客户端所需获取的业务数据对应的目标业务因子和目标属性之后，通过步骤303从业务因子库101中读取目标业务因子的配置信息之前，可以先对业务因子库101中是否存在该目标业务因子的配置信息以及该目标业务因子的配置信息中是否存在该目标属性的定义进行验证，从而避免由于目标业务因子或目标属性不存在而导致无法实现业务数据获取的情况。

在一种可能的实现中，业务因子引擎102确定客户端所需获取的业务数据对应的目标业务因子和目标属性之后，可以先查询业务因子库101中是否存在目标业务因子的配置信息，若查询不到，则中止运行并报错；

若业务因子引擎102查询到目标业务因子的配置信息，则可进一步从目标业务因子的配置信息中查询是否存在目标属性的定义，若查询不到，则中止运行并报错；

若业务因子引擎102查询到业务因子库中存在目标业务因子的配置信息、且查询到目标业务因子的配置信息中存在目标属性的定义，则业务因子引擎102将可以执行如图3所示流程的后续步骤。

比如，仍以上述电信领域业务订单的校验为例，客户端通过“$Factor_subscriber.status”对业务数据管理系统100中的业务因子引擎102进行调用后，业务因子引擎102解析“$Factor_subscriber.status”得到的“subscriber”(即上述目标业务因子)以及“status”(即上述目标属性)，进而，业务因子引擎102将可以以“subscriber”为业务因子的名称，查询业务因子库101中是否存在“subscriber”的配置信息，并在查询到存在“subscriber”的配置信息时，以“status”为属性名称，查询“subscriber”中是否存在“status”的定义，在查询到“subscriber”中存在“status”的定义后，再执行如图3所示流程的后续步骤，否则，可以中止运行，并可以向客户端报错。

进一步地，业务因子引擎102通过上述步骤构建出目标业务因子的执行上下文，并读取到目标业务因子的配置信息之后，在步骤304部分，业务因子引擎102便可以根据目标业务因子的执行上下文，按照目标业务因子的配置信息中定义的目标属性的取值逻辑，得到目标属性的取值；从而在步骤305部分，业务因子引擎102可将所得到的目标属性的取值返回给客户端。

具体比如，仍然基于上述电信领域业务订单的校验场景，假设目标业务因子“subscriber”的配置信息中定义“subscriber”具有的属性包括有用户标识(subscriber.ID)、用户状态(subscriber.status)、名(subscriber.First Name)、中间名(subscriber.Middle Name)、姓(subscriber.Last Name)以及全名(subscriber.fullname)等；并假设“subscriber.ID”的取值逻辑为从“subscriber”的执行上下文中获取用户标识作为取值，“subscriber.status”、“subscriber.First Name”、“subscriber.MiddleName”、“subscriber.Last Name”的取值逻辑均分别为从数据源(比如存储介质或者外部服务器等)直接获取相应的用户数据作为取值，“subscriber.full name”的取值逻辑为由“subscriber.First Name”+“subscriber.Middle Name”+“subscriber.Last Name”拼接得到：

基于上述假设，客户端在需要获取用户状态时，将可由语句“$Factor_subscriber.status”调用业务因子引擎102，业务因子引擎102在创建“subscriber”的执行上下文，并读取“subscriber”的配置信息之后，将可按照“subscriber”的配置信息中“subscriber.ID”的取值逻辑，从“subscriber”执行上下文中获取来自客户端执行上下文的用户标识作为“subscriber.ID”的取值，再按照“subscriber”的配置信息中“subscriber.status”的取值逻辑在由该用户标识所确定执行上下文中从数据源获取该用户的status的取值，然后将所获取到的该用户的status的取值返回给客户端；上述属性“subscriber.ID”也可以称为是业务因子“subscriber”的主键属性；

又比如，在客户端在需要获取用户全名时，相应地，可由语句“$Factor_subscriber.full name”调用业务因子引擎102，业务因子引擎102在创建“subscriber”的执行上下文，并读取“subscriber”的配置信息之后，将可按照“subscriber”的配置信息中“subscriber.ID”的取值逻辑，从“subscriber”执行上下文中获取来自客户端执行上下文的用户标识作为“subscriber.ID”的取值，再按照“subscriber”的配置信息中“subscriber.full name”的取值逻辑先在由该用户标识所确定执行上下文中执行“subscriber.First Name”、“subscriber.Middle Name”、“subscriber.Last Name”的取值逻辑，得到这些属性的取值，再按照“subscriber.First Name”+“subscriber.MiddleName”+“subscriber.Last Name”的方式进行拼接，得到该用户的full name的取值，然后将所获取到的该用户的full name的取值返回给客户端

通过本申请上述实施例可以看到，在本申请上述实施例所提供的业务数据管理系统中，通过配置业务因子的多个属性来提供多种类型的业务数据，从而不同业务处理场景中用于实现各种类型业务数据的获取的各种编码逻辑，将可以统一转化为通过调用本申请上述实施例所提供的业务数据管理系统后基于业务因子库中业务因子的属性取值得到，对于需要获取各种类型的业务数据的客户端而言，将不再需要为了获取所需业务数据而定制相应的业务数据获取逻辑，因而，能够降低各类业务数据的获取在编码实现上的复杂度。

此外，可以看到，本申请上述实施例所提供的业务数据管理系统提供了将业务数据的获取需求语义化表达的实现方式，通过业务因子的配置满足各类业务数据的获取需求，有序可控，并更贴近于自然语言语义化描述，能够简化业务需求的实现，可将客户端的业务数据需求“配置”出来。比如对于客户端而言，通过本申请上述实施例所提供的业务数据管理系统，将可以直接使用业务因子和属性的名称进行调用来获取所需的业务数据，从而避免大量相似的逻辑硬编码重复建设，增加系统的可扩展性。以用户状态校验为例，客户端侧将只需要配置校验逻辑即可，而不用再关注如何获取用户的状态的逻辑。又比如，假设客户端侧实现使用的是硬编码方式，在客户希望增加一个用户等级的校验需求的场景下，目前往往是通过重新编码的方式实现出“怎么校验用户等级”的过程，无法通过语义化表达的实现方式来简化实现。

为了更清楚地说明本申请上述实施例所提供的业务数据管理方案，图4示出了本申请一些实施例所提供的业务数据管理方案应用于实际场景中的示意图。

如图4所示，该示例场景中包括有用户401、前端系统(Frontend System)402、订单管理系统(Order Management)403以及本申请前述实施例所描述的业务数据管理系统100。

具体地，前端系统402可以是诸如浏览器页面、手机应用(application，APP)等可直接与用户进行交互的系统；订单管理系统可以是用于对前端系统402所提交的请求进行后台处理的系统。

在如图4所示的场景中，用户401通常可通过前端系统402提交用于购买商品的相关信息，比如包括有用户401的用户标识信息，用户所需购买商品的标识信息，用户地址信息等等；前端系统402接收用户401提交的信息后，将基于用户401提交的信息，向订单管理系统403提交创建订单请求(Create Order Request)；

订单管理系统403接收到前端系统402提交的创建订单请求后，将需要对该订单进行校验，而校验涉及到业务数据的获取，如图4所示，在应用有本申请一些实施例所提供的业务数据管理系统的情况下，订单管理系统403在需要获取业务数据时，将可以调用业务数据管理系统100，由业务数据管理系统100获取相应的业务数据返回给订单管理系统403。

基于如图4所示的应用场景示例，以及如图2所示的业务因子的配置示例，图5示出了本申请一些实施例所提供的业务数据管理系统应用于实际场景中的流程示意图。

如图5所示，订单管理系统403调用业务数据管理系统100，获取对前端系统402提交的Create Order Request进行校验的业务数据，具体过程如下：

步骤500：订单管理系统接收到创建订单请求后，确定需要校验创建该订单请求的用户的用户状态(Validata Order)。

基于上文中的语法示例，用户状态的校验逻辑具体可配置为”$Factor_subscriber.status＝＝active”，该逻辑等式成立，即用户状态是active，则表示用户状态校验成功，进而可继续为该用户处理该订单请求，否则，即用户状态非active(比如用户状态为inactive)，则表示用户状态校验失败，那么将可不再为该用户处理该订单请求；

“$Factor_subscriber.status”用于调用业务因子引擎102获取当前用户的用户状态，在该校验逻辑中也可称之为校验的DSL语法，该语法可作为业务数据管理系统100中业务因子引擎102的输入。

步骤501：业务因子引擎102在运行态对该语法“$Factor_subscriber.status”进行解释执行，从中解析出目标业务因子和目标属性。

具体地，业务因子引擎102在执行态会对DSL语法“$Factor_subscriber.status”中的$Factor_进行拦截，进而解析出语法的意图是需要访问“subscriber”这个业务因子以及该业务因子的“status”这个属性。

步骤502：业务因子引擎102验证目标业务因子以及目标属性的合法性，即识别业务因子库101中是否存在目标业务因子的配置信息，并识别目标业务因子的配置信息中是否存在目标属性的定义。

具体地，业务因子引擎102在解析得到目标业务因子为“subscriber”以及目标属性为“status”后，可以将“subscriber”作为业务因子名称，并将“status”作为属性名称，从业务因子库101中各个业务因子的配置信息中查询“subscriber”以及“status”。

如图5所示，基于图2所示的业务因子的配置示例，业务因子的配置包括结构元数据和属性元数据，进而业务因子引擎102在解析得到目标业务因子为“subscriber”以及目标属性为“status”后，可以先查询业务因子库101中是否存在“subscriber”的配置信息，在查询到存在“subscriber”的配置信息后，从“subscriber”的结构元数据中查找是否存在属性“status”的定义。

步骤503：业务因子引擎102验证目标业务因子以及目标属性合法后，根据订单管理系统的上下文，构建目标业务因子的执行上下文。

如图5所示，订单管理系统403的执行上下文中将存在有订单中的用户标识(如图中的SubId：12345******)，因而，业务因子引擎102在构建目标业务因子上下文过程中，可以将订单管理系统403的执行上下文中的用户标识放入目标业务因子的执行上下文中。

步骤504～步骤508：业务因子引擎102构建目标业务因子的执行上下文后，调用业务因子引擎102内部的API(步骤504)，读取目标业务因子的配置信息(步骤505)，进而计算生成目标业务因子的对象(步骤506)，运行目标业务因子的配置信息中的目标属性的取值逻辑(步骤507)，得到目标业务因子的对象中目标属性的取值，从而将该业务数据返回给订单管理系统403(步骤508)，以使得订单管理系统403完成订单校验。

具体地，业务因子引擎102可首先从执行上下文中获取“subscriber”的主键属性(即SubId)，进而可先从存储介质或者外部服务中根据SubId查询是否已存在有“subscriber”对象，如果业务因子引擎102确定已有“subscriber”的对象，那么业务因子引擎102可直接获取“subscriber”的对象，从存储介质上获取到的“subscriber”对象中比如可包括有用户状态，用户号码，First Name，Middle Name，Last Name这些属性信息；如果业务因子引擎102确定没有“subscriber”的对象，那么业务因子引擎102可根据“subscriber”的结构元数据生成“subscriber”的对象。

如图5所示，业务因子引擎102可先通过读取“subscriber”的结构元数据，生成“subscriber”的对象(包括有各个属性)，进而按照“status”的属性元数据中定义的取值逻辑，得到“subscriber.status”的取值。

业务因子引擎102得到业务因子中目标属性的取值后，便可以将目标属性的取值返回给订单管理系统用于业务校验逻辑，即可以将subscriber因子的status属性的取值返回给订单管理系统中的校验逻辑“$Factor_subscriber.status＝＝active”来实现业务校验。

可以看到，通过本申请上述实施例所提供的业务数据管理系统，订单管理系统可通过配置的方式直接获取到所需的业务数据，而不需要定制用于获取业务数据的编码逻辑，因而能够简化业务需求的实现，降低业务数据获取的复杂度。

本申请上述实施例所提供的业务数据管理系统在配置完成后，可作为获取业务数据的手段，直接提供给业务开发人员在脚本中使用。比如，以电信领域中布置促销活动的场景为例，假设该促销活动要求非欠费用户才能订购该促销活动的商品(offer)，因而在该促销活动业务的编码实现中需要具有对希望订购促销活动的商品的用户是否符合该促销活动的条件进行校验的逻辑，即校验该用户是否欠费，基于本申请上述实施例所提供的业务数据管理系统，在该校验的逻辑代码中，可以直接使用业务因子来获取用户是否欠费的信息。

图6示出了本申请一些实施例所提供的业务数据管理系统在上述场景中应用后业务的流程示意图。如图6所示，该流程具体包括如下步骤：

步骤601～步骤602：用户通过营业厅的前端系统办理促销活动的商品订购，营业厅的前端系统向订单管理系统发送该用户请求订购促销活动产品的订单请求。

步骤603：订单管理系统接收到上述订单请求之后，确定需要对该订单请求进行校验。

比如，订单管理系统确认需要对该用户的余额进行校验，如果该用户当前已欠费则不允许该用户订购该促销活动的产品。

具体地，在订单管理系统的校验过程中提供了业务校验逻辑的配置能力，比如可基于业务因子配置DSL脚本“$Factor_subscriber.balance>＝0”，来实现用户余额的校验。

步骤604：订单管理系统通过上述DSL脚本调用业务数据管理系统100中的业务因子引擎102，请求获取用户余额完成校验逻辑。

步骤605：业务因子引擎102被调用，解析上述DSL语法得到目标业务因子“subscriber”和目标属性“balance”后，判断目标业务因子以及目标属性是否合法。

如图6所示，业务因子引擎102确定目标业务因子为用户业务因子，目标属性为用户余额，并在业务因子库101中查询到了用户业务因子“subscriber”的配置信息，在用户业务因子的配置信息中查询到了用户余额“subscriber.balance”的属性定义，因而判断目标业务因子以及目标属性合法，进而转入执行步骤606。

步骤606：业务因子引擎102从订单管理系统的执行上下文中获取订单数据的用户ID，初始化用户业务因子的执行上下文。

步骤607：业务因子引擎102读取业务因子库101中的用户业务因子的配置信息。比如可读取包括用户业务因子的配置信息的xml文件。

步骤608：基于“subscriber”的执行上下文，业务因子引擎102按照“subscriber”的配置信息中的结构元数据配置，生成用户业务因子的对象。

步骤609：基于“subscriber”的执行上下文，业务因子引擎102根据“subscriber.balance”的属性元数据配置中定义的取值逻辑，获取“subscriber.balance”的取值。

具体地，“subscriber.balance”是“subscriber”的属性，“subscriber.balance”的取值逻辑为“subscriber”中的“balance”属性里配置的脚本，脚本的逻辑具体可以是从当前用户(基于“subscriber”的执行上下文确定)的实例数据上找到“balance”这个属性，进而可获取到属性值，该属性值即为当前用户的用户余额。

步骤610：业务因子引擎102将所得到的用户余额返回给订单管理系统。

步骤611：订单管理系统使用业务因子引擎102返回的用户余额执行上述DSL语法“$Factor_subscriber.balance>＝0”的校验逻辑，完成用户余额的校验，如果校验成功，则为该用户创建和办理其所请求的促销活动的商品，如果校验失败，则反馈无法办理的通知。

步骤612：订单管理系统向营业厅的前端系统反馈订单请求的结果。

步骤613：营业厅的前端系统向用户反馈促销活动的商品的订购结果。

应当理解的是，上述仅以用户业务因子(subscriber)为例，介绍了本申请实施例所提供的业务数据管理系统在实际场景中的应用，在电信领域的订单管理系统中，基于业务上的需要类似的可以配置出很多业务因子，比如包括不限于：用户业务因子(subscriber)、用户列表因子(subscribers)、license因子、订单项因子(orderItem)、订单项列表因子(orderItems)、商品规格信息因子(offeringInfo)、产品规则信息因子(productInfo)、操作员因子(staff)、群用户因子(groupSubscriber)、群用户列表因子(groupSubscribers)、群成员因子(groupMember)、群成员列表因子(groupMembers)、订单因子(order)、账户因子(account)、账户列表因子(accounts)、客户因子(customer)，基于上述各种业务因子实现业务逻辑的过程均可参见本申请前述各实施例的实施，本申请在此将不做详述。

综上所述，通过本申请上述实施例所提供的业务数据管理系统，各类业务处理场景中获取各类型业务数据的复杂执行逻辑将可被统一抽象为对业务因子的操作，多种类型的业务数据可以业务因子为载体进行聚合，从而对于不同业务处理场景中用于实现各种类型业务数据的获取的各种编码逻辑，将可以统一转化为对本申请实施例所提供的业务数据管理系统进行调用并基于业务因子的属性取值得到，对于需要获取业务数据的客户端而言，将不再需要为了获取所需业务数据而定制相应的业务数据获取逻辑，因而，能够降低各类业务数据的获取在编码实现上的复杂度，避免大量相似的逻辑硬编码重复建设，增加系统的可扩展性。

基于同样的发明构思，本申请还提供了一种装置，所述装置上可部署有上述如图1所示的业务数据管理系统，可以实现如图3所示的业务数据管理方法流程。

图7示出了本申请一些实施例提供的一种装置的结构示意图。如图7所示，该装置700可以包括：处理器701、存储器702和通信接口703；处理器701、存储器702和通信接口703之间可以通过总线704连接。

总线704可以分为地址总线、数据总线、控制总线等等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。本申请实施例中并不限定处理器701、存储器702和通信接口703之间的具体连接介质。

通信接口703可以包括有用于与其他网络设备相连的接口，用于与其他网络设备进行通信。例如，通信接口703可包括与客户端设备相连的接口，用于与客户端设备进行通信。接口可以是有线接口，无线接口或其组合。有线接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线接口例如可以为无线局域网(英文：wirelesslocal area network，WLAN)接口，蜂窝网络接口或其组合。

存储器702可以是非易失性存储器，比如硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)等，还可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)。存储器702是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

具体地，存储器702中可存储有如图1所示业务数据管理系统100中的业务因子库101，用于提供至少一个业务因子的配置信息，一个业务因子的配置信息中包括至少一个属性的定义，一个属性的定义中包括该属性的取值逻辑，一个业务因子的一个属性用于提供一类业务数据；存储器702中还可以存储有处理器701执行的程序指令，该程序指令在设计时用于实现如图1所示业务数据管理系统100中的业务引擎102的相应功能。

处理器701可以包括中央处理器(central processing unit，CPU)，或者也可包括数字处理器等。具体地，处理器701，可用于在通过通信接口703接收到需要获取业务数据的客户端设备的调用后，调用存储在存储器702中的程序指令，执行图3所示的方法流程，包括：

根据所述客户端设备的调用，确定所述客户端设备所需获取的业务数据对应的目标业务因子和目标属性；根据所述客户端设备的执行上下文，构建所述目标业务因子的执行上下文；从所述业务因子库中读取所述目标业务因子的配置信息，其中读取到的所述目标业务因子的配置信息中包括所述目标属性的定义；根据所述目标业务因子的执行上下文，按照所述目标业务因子的配置信息中定义的所述目标属性的取值逻辑，得到所述目标属性的取值；将所得到的所述目标属性的取值通过所述通信接口703返回给所述客户端设备。

应当指出的是，处理器701、存储器702和通信接口703可具体用于实现本申请前述实施例所提供的业务数据管理系统各可能实施例的功能。本申请在此不再赘述。

本申请一些实施例还提供了一种计算机可读存储介质，用于存储为执行本申请上述实施例所描述的业务数据管理系统的功能所用的计算机软件指令，其包含用于执行本申请上述实施例所描述的业务数据管理系统的功能所设计的程序。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (9)

1.一种业务数据管理系统，其特征在于，所述系统包括：

业务因子库以及业务因子引擎；其中：

所述业务因子库，用于提供至少一个业务因子的配置信息，一个业务因子的配置信息中包括至少一个属性的定义，一个属性的定义中包括该属性的取值逻辑，一个业务因子的一个属性用于提供一类业务数据；

所述业务因子引擎，用于在被需要获取业务数据的客户端调用时，执行以下过程：

根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性；

根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文；

从所述业务因子库中读取所述目标业务因子的配置信息，其中读取到的所述目标业务因子的配置信息中包括所述目标属性的定义；

根据所述目标业务因子的执行上下文，按照所述目标业务因子的配置信息中定义的所述目标属性的取值逻辑，得到所述目标属性的取值；

将所得到的所述目标属性的取值返回给所述客户端。

2.如权利要求1所述的系统，其特征在于，所述业务因子引擎在确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还用于：

查询所述业务因子库中是否存在所述目标业务因子的配置信息，若查询不到，则中止运行并报错；若查询到所述目标业务因子的配置信息，则从所述目标业务因子的配置信息中查询是否存在所述目标属性的定义，若查询不到，则中止运行并报错；

若查询到所述业务因子库中存在所述目标业务因子的配置信息、且查询到所述目标业务因子的配置信息中存在所述目标属性的定义，则从所述业务因子库中读取所述目标业务因子的配置信息。

3.如权利要求1或2所述的系统，其特征在于，所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据作为该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并对获取到的所述原始数据进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性获取所述业务因子的其它任一个或多个属性的取值，并对获取到的所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并获取所述业务因子的其它任一个或多个属性的取值，对获取到的所述原始数据以及所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式。

4.如权利要求1-3中任一项所述的系统，其特征在于，所述业务因子引擎，在根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还用于：

确定是否已存在所述目标业务因子的上下文；

若确定已存在所述目标业务因子的上下文，则从已存在的所述目标业务因子的上下文中确定是否已存在所述目标属性的取值，若已存在所述目标属性的取值，则获取所述目标属性的取值返回给所述客户端，若不存在所述目标属性的取值，则根据已存在的所述目标业务因子的上下文，按照所述目标属性的取值逻辑，得到所述目标属性的取值后返回给所述管理客户端；

若确定不存在所述目标业务因子的上下文，则根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文。

5.一种业务数据管理方法，其特征在于，所述方法包括：

业务数据管理系统在被需要获取业务数据的客户端调用时，根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性；

其中，所述业务数据管理系统中包括业务因子库，所述业务因子库用于提供至少一个业务因子的配置信息，一个业务因子的配置信息中包括至少一个属性的定义，一个属性的定义中包括该属性的取值逻辑，一个业务因子的一个属性用于提供一类业务数据；

所述业务数据管理系统根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文；

所述业务数据管理系统从所述业务因子库中读取所述目标业务因子的配置信息，其中读取到的所述目标业务因子的配置信息中包括所述目标属性的定义；

所述业务数据管理系统根据所述目标业务因子的执行上下文，按照所述目标业务因子的配置信息中定义的所述目标属性的取值逻辑，得到所述目标属性的取值；

所述业务数据管理系统将所得到的所述目标属性的取值返回给所述客户端。

6.如权利要求5所述的方法，其特征在于，所述业务数据管理系统确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还包括：

所述业务数据管理系统查询所述业务因子库中是否存在所述目标业务因子的配置信息，若查询不到，则所述业务数据管理系统中止运行并报错；若所述业务数据管理系统查询到所述目标业务因子的配置信息，则所述业务数据管理系统从所述目标业务因子的配置信息中查询是否存在所述目标属性的定义，若查询不到，则所述业务数据管理系统中止运行并报错；

若所述业务数据管理系统查询到所述业务因子库中存在所述目标业务因子的配置信息、且查询到所述目标业务因子的配置信息中存在所述目标属性的定义，则所述业务数据管理系统从所述业务因子库中读取所述目标业务因子的配置信息。

7.如权利要求5或6所述的方法，其特征在于，所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据作为该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并对获取到的所述原始数据进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性获取所述业务因子的其它任一个或多个属性的取值，并对获取到的所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式；或者，

所述一个业务因子的一个属性的取值逻辑用于描述该属性从数据源获取原始数据，并获取所述业务因子的其它任一个或多个属性的取值，对获取到的所述原始数据以及所述其它任一个或多个属性的取值进行计算得到该属性的取值的方式。

8.如权利要求5-7中任一项所述的方法，其特征在于，所述业务数据管理系统根据所述客户端的调用，确定所述客户端所需获取的业务数据对应的目标业务因子和目标属性之后，还包括：

所述业务数据管理系统确定是否已存在所述目标业务因子的上下文；

若所述业务数据管理系统确定已存在所述目标业务因子的上下文，则所述业务数据管理系统从已存在的所述目标业务因子的上下文中确定是否已存在所述目标属性的取值，若已存在所述目标属性的取值，则所述业务数据管理系统获取所述目标属性的取值返回给所述客户端，若不存在所述目标属性的取值，则所述业务数据管理系统根据已存在的所述目标业务因子的上下文，按照所述目标属性的取值逻辑，得到所述目标属性的取值后返回给所述管理客户端；

若所述业务数据管理系统确定不存在所述目标业务因子的上下文，则所述业务数据管理系统根据所述客户端的执行上下文，构建所述目标业务因子的执行上下文。

9.一种计算机存储介质，其特征在于，所述计算机可读存储介质中存储软件程序，所述软件程序在被一个或多个处理器读取并执行时可实现权利要求5-8任一项所述的方法。