业务规则信息处理方法、装置及系统与流程

本申请涉及业务规则信息处理技术领域，特别是涉及业务规则信息处理方法、装置及系统。

背景技术：

在“新零售”的线上线下相结合的业务模式下，零售商可以通过线上的应用程序(app)提供商品对象的信息，用户可以通过线上的app进行浏览、购买等行为。同时，零售商还可以开设线下的实体店铺，用户也可以通过线下的实体店铺进行商品对象的购买。同时，线上的订单也可以由线下的实体店铺进行发货等一系列的处理，并最终配送到用户指定的收货地址。

其中，在线下的实体店铺中，经常会用到多种终端设备，例如，自助结算终端机，pos销售终端，等等，通过这种终端设备的存在，可以实现很大程度上的自助下单等功能。例如，某用户在某实体店铺内选购了一些商品，之后，可以使用具体的自助结算终端机分别对这些商品进行扫码，生成具体的支付订单，然后再通过手机等移动终端设备对收款码进行扫码等方式完成支付，等等。

这种实体店铺内部的终端中，经常会需要运行一些业务逻辑，在一种实现方式下，可以由服务端实现具体的业务处理逻辑，终端设备一侧只需要接收具体的业务处理结果即可。但是，这种对具体业务逻辑进行中心化执行的方式下，一旦服务端出现故障等问题，则会导致所有的终端设备无法正常工作，系统的容灾性能比较差。为此，在现有技术中，还提供了分布式执行业务逻辑的方案，也即，具体的业务处理逻辑由具体的运营方分别配置到实体店铺的各种终端中，这样，具体的业务处理逻辑可以由具体的终端设备来执行，网络中一台设备出现故障，不会影响到其他设备的正常运行，从而提高系统的容灾性能。但是，在实际应用中，具体实体店铺中的终端中经常会涉及到一些易变业务逻辑，比如运费计算策略，商品条码解码及校验，优惠促销等，这部分业务逻辑会根据活动，业务场景等，执行不同的策略。但是，在上述分布式执行的方案中，由于具体的业务逻辑分散在各类终端的业务代码中，因此，在业务逻辑发生改变时，需要开发人员介入去修改所有终端的系统代码，测试执行回归测试，以保障系统的稳定性，运营/产品确认最终无误，然后更新各类型终端系统。但是，在具体的修改代码以及回归测试等过程中，稍有不慎，即会发生故障，或某一客户端逻辑漏改等。总体来说，这种做法具有代码侵入性，运营策略的每次修改都需要开发介入，增加了研发成本，不利于团队协作。

技术实现要素：

本申请提供了业务规则信息处理方法、装置及系统，能够实现易变的业务规则与业务系统解耦，在业务规则发生变化时，避免分别修改各个第一客户端的业务代码，提升系统稳定性。

本申请提供了如下方案：

一种业务规则信息处理系统，包括：

服务端以及至少一个第一客户端；其中，

所述服务端，用于提供业务规则数据库，并向所述第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息；

所述第一客户端，用于利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则，并从所述服务端获得所述目标业务规则，保存在所述第一客户端所在的终端设备本地，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

一种业务规则信息处理方法，包括：

服务端提供业务规则数据库，所述数据库中保存有至少一条业务规则；

向第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

一种业务规则信息处理方法，包括：

第一客户端利用服务端提供的引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

从服务端获得目标业务规则信息，并将所述目标业务规则信息在终端设备本地进行保存；

在对所述基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，实现对所述基础业务逻辑的处理。

一种业务规则信息处理方法，包括：

第二客户端提供用于创建业务规则信息的第一操作选项；

通过所述第一操作选项接收到业务规则创建指令后，提交到服务端，以便所述服务端将所创建的业务规则信息添加到业务规则数据库，以用于提供给第一客户端，在对关联的基础业务逻辑进行处理的过程中，利用所述服务端提供的引用方式信息对所述目标业务规则进行调用，以实现对所述基础业务逻辑的处理。

一种业务规则信息处理方法，包括：

服务端提供业务规则数据库，所述数据库中保存有第一客户端在进行与结算相关的业务处理过程中，所需用到的业务规则信息；

向所述第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在进行与结算相关的业务处理时，通过对所述目标业务规则进行调用，完成对所述与结算相关的业务的处理。

一种业务规则信息处理装置，包括：

数据库提供单元，用于提供业务规则数据库，所述数据库中保存有至少一条业务规则；

引用方式信息提供单元，用于向第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

业务规则提供单元，用于接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

一种业务规则信息处理装置，包括：

规则引用单元，用于利用服务端提供的引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

业务规则信息保存单元，用于从服务端获得目标业务规则信息，并将所述目标业务规则信息在终端设备本地进行保存；

业务规则信息调用单元，用于在对所述基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，实现对所述基础业务逻辑的处理。

一种业务规则信息处理装置，包括：

第一操作选项提供单元，用于提供用于创建业务规则信息的第一操作选项；

创建请求提交单元，用于通过所述第一操作选项接收到业务规则创建指令后，提交到服务端，以便所述服务端将所创建的业务规则信息添加到业务规则数据库，以用于提供给第一客户端，在对关联的基础业务逻辑进行处理的过程中，利用所述服务端提供的引用方式信息对所述目标业务规则进行调用，以实现对所述基础业务逻辑的处理。

一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供业务规则数据库，所述数据库中保存有至少一条业务规则；

向第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以将具体的业务规则信息(例如，易变的业务规则信息)保存在服务端，并向第一客户端提供用于对业务规则进行引用等处理的引用方式信息，使得第一客户端能够将具体的业务规则保存到终端设备本地，并通过对具体业务规则的调用，完成具体业务逻辑的处理。这样，可以实现易变的业务规则与业务系统中基础业务处理逻辑的解耦，在业务规则发生变化时，只需要在服务端对业务规则进行修改，即可由服务端将修改后的规则推送到具体业务规则的第一客户端，从而提升系统的稳定性，避免分别修改各个第一客户端的业务代码。

再者，业务规则可以在分布式客户端执行，当规则中心的服务端宕机时，也只是影响规则的新增和修改，已有规则不受任何影响，可以正常执行，解决了规则中心化执行(在服务端执行具体的规则，第一客户端只接收执行结果的方案)带来的性能问题及单点故障问题，提升系统容灾能力，一定程度上保障了系统的稳定性。

另外，通过由第一客户端对业务规则进行订阅的方式，使得服务端能够将业务规则推送到具体的订阅方第一客户端，在此过程中，与具体客户端的类型以及客户端所属终端设备的类型都是无关的，因此，可以实现业务规则的跨平台多客户端执行，提升规则执行效率，并保证了多端规则一致性。

最后，在可选的方式下，还可以提供灵活的业务配置界面供业务方自由配置，避免微小业务逻辑变更修改整个业务系统，节省研发成本。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3是本申请实施例提供的第二方法的流程图；

图4是本申请实施例提供的第三方法的流程图；

图5是本申请实施例提供的第四方法的流程图；

图6是本申请实施例提供的第一装置的示意图；

图7是本申请实施例提供的第二装置的示意图；

图8是本申请实施例提供的第三装置的示意图；

图9是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，如图1所示，可以提供一服务端，该服务端可以维护业务规则数据库，针对具有易变性等特点的业务处理逻辑，可以在服务端的业务规则数据库中创建具体的业务规则，同时，服务端还可以提供具体用于对业务规则进行引用的引用方式信息，以使得第一客户端能够在自己的基础业务处理逻辑中对服务端配置的业务规则进行引用。例如，具体可以提供用于对业务规则进行调用、订阅等处理的sdk包(软件开发工具包)，这样，可以通过在第一客户端(具体可以是“新零售”业务模式下实体店铺中的pos、自助结算设备、自助售卖机等终端设备中运行的客户端)加入相关的处理代码，使得第一客户端可以利用这种sdk包从服务端获得具体所需的业务规则，并且可以在所在的终端设备本地进行保存，在接收到对应的业务逻辑处理请求时，还可以利用所述sdk对所述目标业务规则进行调用，以实现对应的业务逻辑处理。

也就是说，具体的容易发生变化的业务规则信息，不再直接配置在第一客户端中，而是首先配置在服务端，由服务端进行统一的保存，因此，服务端也可以称为“规则中心”。第一客户端可以订阅其中的一条或者多条业务规则等方式，服务端则可以将具体客户端订阅的业务规则推送到客户端所在的终端设备本地，实现在终端设备本地对业务规则的调用。

在此基础上，如果某条业务规则需要修改，例如，关于对商品对象的条形码进行扫码的业务规则中，需要增加一种新的条码，则可以直接在该服务端对该业务规则的内容进行修改，修改前后，该业务规则的id等标识并不会发生变化。并且，在完成对某业务规则的修改后，服务端可以根据客户端与具体业务规则之间的订阅关系，确定出哪些客户端订阅了该业务规则，并且可以向这些客户端进行修改后的业务规则的推送。相应的，客户端可以对服务端的消息进行监听，接收到关于某条业务规则的修改消息后，也可以对本地保存的该条业务规则的内容进行修改。这样，在后续的业务处理逻辑中，就可以直接使用修改后的业务规则进行处理。可见，通过这种方式，可以实现在服务端对业务规则的集中配置以及更新，然后由服务端下发给具体订阅了各条业务规则的客户端，从而使得客户端更及时地实现对具体业务规则的更新，而不再需要由开发者分别修改各个客户端的代码，因此，效率以及准确率都会得到提升。

下面对本申请实施例提供的具体技术方案进行详细介绍。

实施例一

首先，该实施例一提供了一种业务规则信息处理系统，如图1所示，该系统具体可以包括：

服务端101以及至少一个第一客户端102；其中，

所述服务端101，用于提供业务规则数据库，并向所述第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息；

所述第一客户端102，用于利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则，并从所述服务端获得所述目标业务规则，保存在所述第一客户端所在的终端设备本地，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

其中，服务端的业务规则数据库中可以保存多条具体的业务规则，具体的业务规则可以是由业务方等创建的。具体实现时，具体的业务规则创建方可能有多个，例如，具体“新零售”系统中具体业务链路上的多个业务方，这些业务方都可能具有配置具体业务规则的需求，具体如商品方、支付方、仓库方，等等。因此，为了便于对具体的业务规则进行创建或者修改等操作，如图1所示，还可以提供第二客户端102，该第二客户端主要面向的是具体的业务方用户，也即业务规则的创建方用户，具体可以以独立的应用程序，或者网页等形式存在。通过该第二客户端，可以提供具体的配置界面，具体的配置界面中可以包括用户添加新的业务规则的操作选项，用于查看已经创建的业务规则的操作选项，用于修改某条业务规则的操作选项，等等。这样，业务方便可以通过配置界面的方式进行可视化的规则创建或者修改等操作，相对于编辑代码的实现方式而言比较方便快捷。

具体实现时，由于是在服务端进行具体业务规则的配置，而具体的第一客户端需要在终端设备本地对业务规则进行调用，因此，为了达到上述目的，服务端还可以为具体的业务规则提供对应的id等标识，并提供具体用于对业务规则进行调用、订阅等处理的sdk包(软件开发工具包)。这样，如果某个具体的终端设备的第一客户端中需要进行某业务处理，并需要使用具体的业务规则，则可以首先引入注册机制，也即，在第一客户端的具体代码中加入对业务规则进行订阅的代码实现。其中，所述服务端提供的sdk包中可以包括用于对业务规则进行订阅的接口等信息，因此，可以在第一客户端中实现对这种订阅接口的调用，并以具体的业务规则的id等标识作为参数即可。或者，在具体实现时，具体的业务规则在服务端进行保存时，可以按照具体的所述的业务域(可以由业务规则的创建者进行业务域的指定)等进行分类，而第一客户端在引用具体的业务规则时，也可能会需要对同一业务域下的多个业务规则分别进行引用，因此，也可以以具体的业务域的标识等作为参数对订阅接口进行调用，等等。这样，服务端便可以将具体的业务规则信息提供给订阅了具体业务规则的第一客户端，相应的，第一客户端则可以在终端设备本地对业务规则进行保存。另外，还可以在第一客户端的业务代码中，通过sdk实现对具体业务规则的调用等逻辑，这样，在具体进行业务逻辑处理的过程中，客户端便可以在终端设备本地对具体的业务规则进行调用，并实现对应的业务逻辑处理。

由于第一客户端可以通过注册的方式对具体的业务规则进行订阅，因此，服务端还可以保存具体的订阅关系信息，也即，记录下哪些第一客户端订阅了哪些业务规则等信息，例如，在一种具体的实现方式下，具体的保存形式可以如表1所示：

表1

其中，关于业务域与具体业务规则之间的对应关系，服务端也可以进行保存，例如，如表2所示：

表2

对于业务方而言，如果在具体的应用过程中，需要对某条业务规则进行修改，则可以直接通过第二客户端等方式，向服务端发起修改请求，由服务端对具体业务规则的内容进行修改，例如，增加某条新的规则内容，或者修改原来的某条规则的内容，等等。具体如，某业务规则是与商品条码扫描相关的解码规则等信息，随着业务的开展，需要修改原来的解码规则，则可以将该修改信息提交到服务端。相应的，由于服务端记录了第一客户端与业务规则之间的对应关系，因此，在发现某条业务规则被修改时，首先就可以查询表1的方式确定出哪些第一客户端订阅了该业务规则，然后，将该修改后的业务规则信息推送到订阅了该业务规则的第一客户端。或者在具体实现时，还可以确定出该业务规则所属的业务域，将该修改后的业务规则信息，推送给订阅了该业务域的第一客户端，等等。相应的，第一客户端可以对服务端的消息进行监听，在监听到具体的消息后，可以对终端设备本地对应保存的业务规则信息进行更新。这样，由于具体业务规则的id等信息并没有发生变化，因此，在以业务规则id为参数对业务规则调用的过程中，可以直接定位到该修改后的业务规则，进而可以利用修改后的业务规则进行具体的业务逻辑处理。

可见，在本申请实施例中，可以实现易变的业务规则与业务系统解耦，这样，在业务规则发生变化时，只需要在服务端对业务规则进行修改，即可由服务端将修改后的规则推送到订阅了具体业务规则的第一客户端，从而提升系统的稳定性，避免分别修改各个第一客户端的业务代码。

再者，业务规则可以在分布式客户端执行，当规则中心的服务端宕机时，也只是影响规则的新增和修改，已有规则不受任何影响，可以正常执行，解决了规则中心化执行(在服务端执行具体的规则，第一客户端只接收执行结果的方案)带来的性能问题及单点故障问题，提升系统容灾能力，一定程度上保障了系统的稳定性。

另外，通过由第一客户端对业务规则进行订阅的方式，使得服务端能够将业务规则推送到具体的订阅方第一客户端，在此过程中，与具体客户端的类型以及客户端所属终端设备的类型都是无关的，因此，可以实现业务规则的跨平台多客户端执行，提升规则执行效率，并保证了多端规则一致性。

最后，在可选的方式下，还可以提供灵活的业务配置界面供业务方自由配置，避免微小业务逻辑变更修改整个业务系统，节省研发成本。

实施例二

该实施例二是与实施例一相对应的，从服务端的角度，提供了一种业务规则信息处理方法，参见图2，该方法具体可以包括：

s201：服务端提供业务规则数据库，所述数据库中保存有至少一条业务规则；

s202：向第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

s202：接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

具体实现时，服务端还可以获得第一客户端与业务规则标识之间的订阅关系并保存；这样，根据接收到的业务规则修改请求对目标业务规则进行修改后，还可以向订阅所述目标业务规则的至少一个第一客户端推送修改后的目标业务规则信息，以便所述第一客户端通过调用所述修改后的目标业务规则进行对应的业务逻辑处理。

其中，所述至少一个第一客户端包括至少一个实体店铺关联的终端设备中运行的客户端；其中，所述实体店铺中包括多种不同类型的终端设备；此时，在多种不同类型的终端设备中的不同第一客户端对同一目标业务规则进行了订阅的情况下，可以将向所述多种不同类型的终端设备中的不同第一客户端推送所述修改后的目标业务规则信息，实现业务规则的跨平台多客户端执行。

另外，具体实现时，服务端还可以为所述业务规则数据库中的业务规则分配标识信息，以便所述第一客户端将所述业务规则标识作为参数对所述业务规则的订阅或者调用操作。

具体实现时，为了便于业务方发起请求，还可以为业务方提供第二客户端，此时，可以通过接收第二客户端的创建业务规则的请求，创建业务规则，并添加到所述业务规则数据库中。

其中，所述业务规则数据库中可以按照所属的业务域的不同，对所述业务规则进行分组保存；此时，所述创建业务规则的请求中还携带有所创建的业务规则所属的业务域标识信息；这样，在所述业务规则数据库中，还可以将所创建的业务规则保存到所述业务域标识对应的分组中。

在这种情况下，第一客户端可以对具体的业务域进行订阅，相应的，服务端可以接收第一客户端提交的对目标业务域的订阅请求信息，并保存该第一客户端与该业务域之间的订阅关系；这样，在所订阅的业务域中的业务规则发生修改时，可以将该修改后的业务规则信息推送给订阅该业务域的第一客户端。

另外，还可以通过接收所述第二客户端的修改指定业务规则的请求，对所述指定业务规则进行修改，以便将该修改后的业务规则信息推送到订阅该业务规则的至少第一客户端。

在一种具体的应用场景中，所述第一客户端包括至少一个实体店铺中与结算相关的终端设备中运行的客户端；此时，所述业务规则包括所述第一客户端在进行结算业务处理过程中所需用到的规则。

具体的，所述在进行结算业务处理过程中所用到的规则，包括：商品对象图形码解码规则，或者优惠方式规则或电子资源计算规则。以上业务规则都具有易变等特点，因此，可以通过本申请实施例中的方式实现与其他非易变业务逻辑的解耦。

实施例三

该实施例三也是与实施例一相对应的，从第一客户端的角度，提供了一种业务规则信息处理方法，参见图3，该方法具体可以包括：

s301：第一客户端利用服务端提供的引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

s302：从服务端获得目标业务规则信息，并将所述目标业务规则信息在终端设备本地进行保存；

s303：在对所述基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，实现对所述基础业务逻辑的处理。

具体实现时，第一客户端还可以向所述服务端订阅目标业务规则信息，以便在所述目标业务规则发生修改时，服务端将修改后的目标业务规则信息推送到所述第一客户端。

另外，还可以向所述服务端订阅目标业务域，以便在所述目标业务域下的业务规则发生修改时，服务端将修改后的目标业务规则信息推送到所述第一客户端。

实施例四

该实施例四也是与实施例一相对应的，从第二客户端的角度，提供了一种业务规则信息处理方法，参见图4，该方法具体可以包括：

s401：第二客户端提供用于创建业务规则信息的第一操作选项；

s402：通过所述第一操作选项接收到业务规则创建指令后，提交到服务端，以便所述服务端将所创建的业务规则信息添加到业务规则数据库，以用于提供给第一客户端，在对关联的基础业务逻辑进行处理的过程中，利用所述服务端提供的引用方式信息对所述目标业务规则进行调用，以实现对所述基础业务逻辑的处理。

具体实现时，第二客户端还可以提供用于对指定业务规则进行修改的第二操作选项；通过所述第二操作选项接收到对指定业务规则的修改信息后提交到服务端，以便所述服务端向订阅所述指定业务规则的至少一个第一客户端推送修改后的业务规则信息，所述第一客户端通过调用所述修改后的目标业务规则进行对应的业务逻辑处理。

实施例四

该实施例四是针对一种具体的应用场景，从服务端的角度，提供了一种业务规则信息处理方法，参见图5，该方法具体可以包括：

s501：服务端提供业务规则数据库，所述数据库中保存有第一客户端在进行与结算相关的业务处理过程中，所需用到的业务规则信息；

s502：向所述第一客户端用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

s503：接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在进行与结算相关的业务处理时，通过对所述目标业务规则进行调用，完成对所述与结算相关的业务的处理。

其中，所述在进行结算业务处理过程中所用到的规则，包括：商品对象图形码解码规则；所述第一客户端的基础业务逻辑用于对用户选择的商品对象进行识别以及结算处理；此时，服务端可以根据接收到针对指定业务规则的修改请求，向该指定业务规则中增加新的图形码解码规则；并向订阅该指定业务规则的至少一个第一客户端推送所述新的图形码解码规则，以便所述第一客户端在对指定商品对象进行扫码结算的过程中，通过引用所述新的图形码解码规则对所述商品对象的图形码进行解码，以获得对应的商品对象标识信息。

或者，所述在进行结算业务处理过程中所用到的规则，包括：商品对象优惠方式规则；所述第一客户端的基础业务逻辑用于对商品对象进行结算处理的过程中计算所需的电子资源信息；此时，可以根据接收到针对指定业务规则的修改请求，对该指定业务规则中的优惠方式规则进行修改；并向订阅该指定业务规则的至少一个第一客户端推送所述修改后的优惠方式规则信息，以便所述第一客户端在对指定商品对象集合进行结算的过程中，通过引用所述优惠方式规则对所述指定商品对象集合的信息进行判断，以确定是否满足优惠条件，并根据判断结果确定所需支付的电子资源信息。

与实施例一相对应，本申请实施例还提供了一种业务规则信息处理装置，参见图6，该装置具体可以包括：

数据库提供单元601，用于提供业务规则数据库，所述数据库中保存有至少一条业务规则；

引用方式信息提供单元602，用于向第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则sdk；

业务规则提供单元603，用于接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

具体实现时，该装置还可以包括：

订阅关系获得单元，用于获得第一客户端与业务规则标识之间的订阅关系并保存；

业务规则修改单元，用于根据接收到的业务规则修改请求对目标业务规则进行修改；

业务规则推送单元，用于向订阅所述目标业务规则的至少一个第一客户端推送修改后的目标业务规则信息，以便所述第一客户端通过调用所述修改后的目标业务规则进行对应的业务逻辑处理。

其中，所述至少一个第一客户端包括至少一个实体店铺关联的终端设备中运行的客户端；其中，所述实体店铺中包括多种不同类型的终端设备；

此时，所述业务规则推送单元具体可以用于：在多种不同类型的终端设备中的不同第一客户端对同一目标业务规则进行了订阅的情况下，可以将向所述多种不同类型的终端设备中的不同第一客户端推送所述修改后的目标业务规则信息，实现业务规则的跨平台多客户端执行。

另外，具体实现时，该装置还可以包括：

标识分配单元，用于为所述业务规则数据库中的业务规则分配标识信息，以便所述第一客户端将所述业务规则标识作为参数对所述业务规则进行订阅或者调用操作。

具体实现时，为了便于业务方发起请求，还可以为业务方提供第二客户端，此时，所述装置还可以包括：

创建请求接收单元，用于可以通过接收第二客户端的创建业务规则的请求，创建业务规则，并添加到所述业务规则数据库中。

其中，所述业务规则数据库中可以按照所属的业务域的不同，对所述业务规则进行分组保存；此时，所述创建业务规则的请求中还携带有所创建的业务规则所属的业务域标识信息；这样，所述创建请求接收单元具体可以用于：在所述业务规则数据库中，还可以将所创建的业务规则保存到所述业务域标识对应的分组中。

在这种情况下，第一客户端可以对具体的业务域进行订阅，相应的，所述装置还可以包括：

业务域订阅请求接收单元，用于接收第一客户端提交的对目标业务域的订阅请求信息，并保存该第一客户端与该业务域之间的订阅关系；这样，在所订阅的业务域中的业务规则发生修改时，可以将该修改后的业务规则信息推送给订阅该业务域的第一客户端。

另外，该装置还可以包括：

修改请求接收单元，用于通过接收所述第二客户端的修改指定业务规则的请求，对所述指定业务规则进行修改，以便将该修改后的业务规则信息推送到订阅该业务规则的至少第一客户端。

在一种具体的应用场景中，所述第一客户端包括至少一个实体店铺中与结算相关的终端设备中运行的客户端；此时，所述业务规则包括所述第一客户端在进行结算业务处理过程中所需用到的规则。

具体的，所述在进行结算业务处理过程中所用到的规则，包括：商品对象图形码解码规则，或者优惠方式规则或电子资源计算规则。以上业务规则都具有易变等特点，因此，可以通过本申请实施例中的方式实现与其他非易变业务逻辑的解耦。

与实施例三相对应，本申请实施例还提供了一种业务规则信息处理装置，参见图7，该装置可以包括：

规则引用单元701，用于利用服务端提供的引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

业务规则信息保存单元702，用于从服务端获得目标业务规则信息，并将所述目标业务规则信息在终端设备本地进行保存；

业务规则信息调用单元703，用于在对所述基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，实现对所述基础业务逻辑的处理。

具体实现时，该装置还可以包括：

第一订阅单元，用于向所述服务端订阅所述目标业务规则，以便在所述目标业务规则发生修改时，服务端将修改后的目标业务规则信息推送到所述第一客户端。

第二订阅单元，用于向所述服务端订阅目标业务域，以便在所述目标业务域下的业务规则发生修改时，服务端将修改后的目标业务规则信息推送到所述第一客户端。

与实施例四相对应，本申请实施例还提供了一种业务规则信息处理装置，参见图8，该装置可以包括：

第一操作选项提供单元801，用于提供用于创建业务规则信息的第一操作选项；

创建请求提交单元802，用于通过所述第一操作选项接收到业务规则创建指令后，提交到服务端，以便所述服务端将所创建的业务规则信息添加到业务规则数据库，以用于提供给第一客户端，在对关联的基础业务逻辑进行处理的过程中，利用所述服务端提供的引用方式信息对所述目标业务规则进行调用，以实现对所述基础业务逻辑的处理。

具体实现时，该装置还可以包括：

第二操作选项提供单元，用于提供用于对指定业务规则进行修改的第二操作选项；

修改信息提交单元，用于通过所述第二操作选项接收到对指定业务规则的修改信息后提交到服务端，以便所述服务端向订阅所述指定业务规则的至少一个第一客户端推送修改后的业务规则信息，所述第一客户端通过调用所述修改后的目标业务规则进行对应的业务逻辑处理。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供业务规则数据库，所述数据库中保存有至少一条业务规则；

向第一客户端提供用于对所述数据库中的业务规则进行引用的引用方式信息，以便所述第一客户端利用所述引用方式信息，在所述第一客户端的基础业务处理逻辑中引用目标业务规则；

接收到所述第一客户端提交的获取目标业务规则的请求时，将所述目标业务规则提供给所述第一客户端，以便所述第一客户端在所在的终端设备本地进行保存，在对基础业务逻辑进行处理的过程中，通过对所述目标业务规则进行调用，完成对所述基础业务逻辑的处理。

其中，图9示例性的展示出了电子设备的架构，具体可以包括处理器910，视频显示适配器911，磁盘驱动器912，输入/输出接口913，网络接口914，以及存储器920。上述处理器910、视频显示适配器911、磁盘驱动器912、输入/输出接口913、网络接口914，与存储器920之间可以通过通信总线930进行通信连接。

其中，处理器910可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器920可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器920可以存储用于控制电子设备900运行的操作系统921，用于控制电子设备900的低级别操作的基本输入输出系统(bios)。另外，还可以存储网页浏览器923，数据存储管理系统924，以及业务规则信息处理系统925等等。上述业务规则信息处理系统925就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器920中，并由处理器910来调用执行。

输入/输出接口913用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口914用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线930包括一通路，在设备的各个组件(例如处理器910、视频显示适配器911、磁盘驱动器912、输入/输出接口913、网络接口914，与存储器920)之间传输信息。

另外，该电子设备900还可以从虚拟资源对象领取条件信息数据库941中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器910、视频显示适配器911、磁盘驱动器912、输入/输出接口913、网络接口914，存储器920，总线930等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的业务规则信息处理方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。