活动规则组建方法、装置和计算机系统、介质与流程

本公开涉及互联网技术领域，更具体地，涉及一种活动规则组建方法、装置和计算机系统、介质。

背景技术：

线上营销活动是营销推广方式中最常用的一种推广方式，可以让用户在参与活动的互动同时，完成商家的营销推广，并且可以降低用户对营销推广的抵触情绪。

营销活动从开始到结束，要经历几个阶段：确定营销目标->策划营销方案->制定活动规则->实现活动规则->推广营销活动->营销数据分析；在实现活动规则阶段，不同营销目的的活动，往往需要针对营销目标来定制不同的活动规则，然后研发人员定制化开发系统去实现不同活动规则来支持营销活动。

也就是说，现有技术中营销活动实现的核心是活动规则，研发人员在开发营销活动时，不同活动规则来支持营销活动实现的方法如下：每个营销活动单独定制化开发一套接口服务。

在实现本公开构思的过程中，发明人发现现有技术中至少存在如下问题：由于营销活动规则不一样，为了保证营销活动不相互影响，需要为每个营销活动单独定制化开发一套接口服务，这导致一个营销活动的平均研发周期在2周左右。但是，单个营销活动一般都是短期类促销推广，每个营销活动从投入比来看，投入的研发成本、时间成本和服务器成本比较高。此外，大促销活动阶段，营销活动特别多，且有多个营销活动同一时间推广的案例，这种情况下，定制化开发活动规则，对研发人员的依赖比较高；且在研发人员有限的情况下，无法并行支持多个营销活动同时进行，开发效率明显不足。

技术实现要素：

有鉴于此，本公开提供了一种解决在研发营销活动时的研发人力成本、时间成本过高的问题的活动规则组建方法、装置和计算机系统、介质。

本公开的一个方面提供了一种活动规则组建方法，应用于第一客户端，所述方法包括：首先，根据活动方案确定所需的规则，然后，获取所述所需的规则的规则组件标识，接着，至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树，得到前端规则树和前端规则树标识，所述前端规则树的至少部分节点包括规则组件标识，然后，将所述前端规则树和对应的前端规则树标识发送给服务端进行存储。这样使得开发人员无需为每个营销活动单独定制化开发一套接口服务，只需要在第一客户端如开发端，至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树，得到前端规则树和前端规则树标识，然后将所述前端规则树和对应的前端规则树标识发送给服务端即可完成开发任务，如由服务器将前端规则树转换为可以运行的规则树，大幅度缩减了开发人员的开发用时。

根据本公开的实施例，所述至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树可以包括如下操作：首先，在gojs前端框架的画布功能上添加与所述所需的规则的规则组件标识对应的图标，然后，至少基于所述图标和所述活动方案所需规则的逻辑关系构建可视化前端规则树，所述可视化前端规则树具有唯一可视化前端规则树标识，接着，所述将所述前端规则树和对应的前端规则树标识发送给服务端进行存储包括将所述可视化前端规则树和对应的可视化前端规则树标识以json形式发送给服务端进行存储。这样可以实现可视化的前端开发，有助于进一步提升开发效率，且更加直观。

根据本公开的实施例，所述方法还可以包括如下操作：首先，在将所述前端规则树和对应的前端规则树标识发送给服务端进行存储之后，创建至少一个活动，每个活动具有唯一活动标识，然后，至少将所述前端规则树标识相关联的至少一个活动标识发送给服务端进行绑定，得到前端规则树标识和活动标识的对应关系。这样便于实现一个规则树可以对应多个活动，即当活动中所用到的规则树与其他活动相似时，可以无需进行重复开发，只需要创建一个活动，将该活动的活动标识与对应的规则树标识进行绑定即可。

本公开的另一个方面提供了一种活动规则组建方法，应用于服务端，所述方法包括：首先，接收前端规则树，所述前端规则树的至少部分节点包括规则组件标识，然后，按照有序树的顺序遍历所述前端规则树，得到规则组件标识，接着，利用所述规则组件标识查询规则库，得到规则组件，然后，将规则组件转换为规则节点，接着，依据所述前端规则树的节点间关系将所述规则节点串成规则树，然后，存储所述规则树及对应的前端规则树标识。这样可以由服务端自动根据接收的前端规则树的各节点中的规则组件标识构建可以由服务端运行的规则树，替代开发人员进行了相关部分的工作，大大降低了开发的人力成本和开发用时。

根据本公开的实施例，所述规则库可以通过以下方式获取：首先，获取规则，然后，基于组件标准将所述规则组件化，得到规则组件，接着，将所述规则组件存储在规则库中，每个规则组件具有唯一规则组件标识。这样可以形成如基于历史使用过的规则的规则组件，并构建成库以便于查询或使用。

根据本公开的实施例，所述组件标准可以包括：入参、正确出参、错误出参和异常出参。

根据本公开的实施例，所述方法还可以包括如下操作：在得到所述规则树之后，将所述规则树序列化成json串，相应地，所述存储所述规则树及对应的前端规则树标识可以包括将所述json串及对应的前端规则树标识建立关联并存储，这样便于进行存储。

根据本公开的实施例，当接收到前端规则树标识和活动标识的对应关系时，所述存储所述规则树及对应的前端规则树标识可以包括存储所述规则树及对应的活动标识，这样可以便于使用时根据输入的活动标识确定规则树。

根据本公开的实施例，所述方法还可以包括如下操作：首先，接收请求指令，所述请求指令为第二客户端发送的包括用户标识信息和前端规则树标识信息的指令，然后，响应于接收到所述请求指令，根据所述前端规则树标识信息确定规则树，接着，基于所述用户标识信息以有序树的顺序遍历所述规则树，得到针对所述用户标识信息相应地规则树的输出结果，然后，将所述输出结果发送给所述第二客户端。这样可以通过遍历规则树的方式得到针对所述用户标识信息相应地规则树的输出结果，并反馈给用户。

根据本公开的实施例，所述规则树以序列化的json串形式存储，相应地，所述根据所述前端规则树标识信息确定规则树可以包括如下操作：首先，根据所述前端规则树标识信息确定序列化的json串，然后，对所述序列化的json串进行反序列化处理，得到规则树。

根据本公开的实施例，所述请求指令为第二客户端发送的包括用户标识信息和活动标识信息的指令，相应地，所述根据所述前端规则树标识信息确定规则树包括根据所述活动标识信息确定规则树。这样使得用户可以在活动界面上只需要输入用户标识信息，即可由服务器确定适用的规则树，并基于规则树确定用户对应的输出结果。

根据本公开的实施例，所述基于所述用户标识信息以有序树的顺序遍历所述规则树，得到针对所述用户标识信息相应地规则树的输出结果可以包括如下操作：首先，从规则树中提取根节点，如果所述根节点为规则组件，则由根节点输出与所述用户标识信息对应的结果，提取与所述结果对应的子节点，如果所述子节点为规则组件，则由子节点输出与所述用户标识信息对应的结果，重复上述操作直至规则树深度遍历结束，得到最后一个子节点的输出结果，然后，将所述最后一个子节点的输出结果发送给所述第二客户端。通过上述遍历过程即可得到用户对应的输出结果。

本公开的另一方面提供了一种活动规则组建装置，包括规则获取模块、第一规则组件标识获取模块、构建模块和第一发送模块。其中，所述规则获取模块用于根据活动方案确定所需的规则，所述第一规则组件标识获取模块用于获取所述所需的规则的规则组件标识，所述构建模块用于至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树，得到前端规则树和前端规则树标识，所述前端规则树的至少部分节点包括规则组件标识，所述第一发送模块用于将所述前端规则树和对应的前端规则树标识发送给服务端进行存储。

根据本公开的实施例，所述构建模块可以包括：画图单元和构建单元。其中，所述画图单元用于在gojs前端框架的画布功能上添加与所述所需的规则的规则组件标识对应的图标，所述构建单元用于至少基于所述图标和所述活动方案所需规则的逻辑关系构建可视化前端规则树，所述可视化前端规则树具有唯一可视化前端规则树标识，所述第一发送模块具体用于将所述可视化前端规则树和对应的可视化前端规则树标识以json形式发送给服务端进行存储。

根据本公开的实施例，所述装置还可以包括：创建模块和第二发送模块。其中，所述创建模块用于在将所述前端规则树和对应的前端规则树标识发送给服务端进行存储之后，创建至少一个活动，每个活动具有唯一活动标识，以及所述第二发送模块用于至少将所述前端规则树标识相关联的至少一个活动标识发送给服务端进行绑定，得到前端规则树标识和活动标识的对应关系。

本公开的另一方面提供了一种一种活动规则组建装置，包括第一接收模块、第二规则组件标识获取模块、规则组件获取模块、规则节点转换模块、规则树获取模块和第一存储模块。其中，所述第一接收模块用于接收前端规则树，所述前端规则树的至少部分节点包括规则组件标识，所述第二规则组件标识获取模块用于按照有序树的顺序遍历所述前端规则树，得到规则组件标识，所述规则组件获取模块用于利用所述规则组件标识查询规则库，得到规则组件，所述规则节点转换模块用于将规则组件转换为规则节点，所述规则树获取模块用于依据所述前端规则树的节点间关系将所述规则节点串成规则树，以及，所述第一存储模块用于存储所述规则树及对应的前端规则树标识。

根据本公开的实施例，所述规则库可以通过以下单元获取：规则获取单元、组件化单元和存储单元。其中，所述规则获取单元用于获取规则，所述组件化单元用于基于组件标准将所述规则组件化，得到规则组件，以及，所述存储单元用于将所述规则组件存储在规则库中，每个规则组件具有唯一规则组件标识。

根据本公开的实施例，所述组件标准可以包括：入参、正确出参、错误出参和异常出参。

根据本公开的实施例，所述装置还可以包括：序列化模块。其中，所述序列化模块用于在得到所述规则树之后，将所述规则树序列化成json串，相应地，所述第一存储模块具体用于将所述json串及对应的前端规则树标识建立关联并存储。

根据本公开的实施例，当接收到前端规则树标识和活动标识的对应关系时，所述第一存储模块可以具体用于存储所述规则树及对应的活动标识。

根据本公开的实施例，装置还可以包括：第二接收模块、规则树确定模块、输出模块和第三发送模块。其中，所述第二接收模块用于接收请求指令，所述请求指令为第二客户端发送的包括用户标识信息和前端规则树标识信息的指令，所述规则树确定模块用于响应于接收到所述请求指令，根据所述前端规则树标识信息确定规则树，所述输出模块用于基于所述用户标识信息以有序树的顺序遍历所述规则树，得到针对所述用户标识信息相应地规则树的输出结果，以及，所述第三发送模块用于将所述输出结果发送给所述第二客户端。

根据本公开的实施例，所述规则树以序列化的json串形式存储，相应地，所述规则树确定模块可以包括：反序列化单元和规则树获取单元。其中，所述反序列化单元用于根据所述前端规则树标识信息确定序列化的json串，以及，所述规则树获取单元用于对所述序列化的json串进行反序列化处理，得到规则树。

根据本公开的实施例，所述请求指令为第二客户端发送的包括用户标识信息和活动标识信息的指令，相应地，所述规则树确定模块具体用于根据所述活动标识信息确定规则树。

根据本公开的实施例，所述输出模块可以包括：根节点获取单元、遍历单元和发送单元。其中，所述根节点获取单元用于从规则树中提取根节点，所述遍历单元用于如果所述根节点为规则组件，则由根节点输出与所述用户标识信息对应的结果，提取与所述结果对应的子节点，如果所述子节点为规则组件，则由子节点输出与所述用户标识信息对应的结果，重复上述操作直至规则树深度遍历结束，得到最后一个子节点的输出结果，以及，所述发送单元用于将所述最后一个子节点的输出结果发送给所述第二客户端。

本公开的另一方面提供了一种计算机系统，包括：一个或多个处理器和存储装置，所述存储装置用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，可以至少部分地解决由于营销活动规则不一样，为了保证营销活动不相互响应，需要为每个营销活动单独定制化开发一套接口服务，导致开发的人工成本和时间成本高的问题，并因此可以实现开发人员只需要在开发端基于规则组件标识和活动中各规则之间的逻辑关系构建前端规则树，并将其发送给服务端即完成了开发工作，后续可以由服务端自动将前端规则树解析为可执行的规则树，大大缩短了开发用时且降低了人工成本的技术效果。

根据本公开的实施例，通过可视化开发增加了直观性，且有助于进一步降低开发成本。

根据本公开的实施例，一个规则树可以对应多个活动，当多个活动可以采用相同的规则树时，无需重复开发，只需要创建一个活动，并将活动标识与对应的规则树标识进行绑定即可完成开发。

根据本公开的实施例，对规则树进行序列化后便于进行存储。

附图说明

通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：

图1示意性示出了根据本公开实施例的活动规则组建方法、装置和计算机系统、介质的应用场景；

图2a示意性示出了根据本公开实施例的用于活动规则组建方法的流程图；

图2b示意性示出了根据本公开实施例的前端规则树的结构示意图；

图2c示意性示出了根据本公开另一实施例的前端规则树的结构示意图；

图2d示意性示出了根据本公开实施例的规则组件的结构示意图；

图3a示意性示出了根据本公开另一实施例的活动规则组建方法；

图3b示意性示出了根据本公开实施例的规则树转换过程示意图；

图3c示意性示出了根据本公开另一实施例的活动规则组建方法；

图3d示意性示出了根据本公开实施例的规则树使用方法流程图；

图4a示意性示出了根据本公开实施例的活动规则组建装置的框图；

图4b示意性示出了根据本公开另一实施例的活动规则组建装置的框图；

图5示意性示出了根据本公开实施例的适于实现活动规则组建方法的计算机系统的方框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。

本公开的实施例提供了一种活动规则组建方法、装置和计算机系统、介质。该方法包括活动规则组建过程和活动规则解析过程，在活动规则组建过程，在开发端需要进行如下操作，首先，根据活动方案确定所需的规则，然后，获取所述所需的规则的规则组件标识，接着，至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树，得到前端规则树和前端规则树标识，所述前端规则树的至少部分节点包括规则组件标识，以及，将所述前端规则树和对应的前端规则树标识发送给服务端进行存储。在活动规则解析过程中，首先，接收前端规则树，所述前端规则树的至少部分节点包括规则组件标识，然后，按照有序树的顺序遍历所述前端规则树，得到规则组件标识，接着，利用所述规则组件标识查询规则库，得到规则组件，然后，将规则组件转换为规则节点，接着，依据所述前端规则树的节点间关系将所述规则节点串成规则树，以及存储所述规则树及对应的前端规则树标识，这样就可以实现在服务端自动生成规则树以便于进行使用。

图1示意性示出了根据本公开实施例的活动规则组建方法、装置和计算机系统、介质的应用场景。图1中的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

开发人员和用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种开发应用和网络应用，如gojs等，此外，终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所构建的前端规则树进行解析以生成规则树的后台服务器，还可以是对用户利用终端设备101、102、103所浏览的网站或所请求的服务提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的活动规则组建方法一般可以由服务器105执行或者由终端设备101、102、103执行。相应地，本公开实施例所提供的活动规则组建装置一般可以设置于服务器105中，或者可以设置于终端设备101、102、103中。本公开实施例所提供的活动规则组建方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的活动规则组建装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图2a示意性示出了根据本公开实施例的用于活动规则组建方法的流程图。该流程图适用于开发人员所使用的开发端，具体可以为如上所示的终端设备101、102、103等。

如图2a所示，该方法可以包括操作s201～操作204。

首先，在操作s201中，根据活动方案确定所需的规则。

在本实施例中，本操作用来将营销活动里要使用的规则确定下来，例如，规则a、规则b和规则c等。

在一个具体实施例中，营销活动a中需要用到如下规则：规则a(是否为普通会员)、规则b(是否为铂金会员)和规则c(是否为黑金会员)。

在另一个具体实施例中，营销活动a中需要用到如下规则：规则d(是否为实名用户)和规则e(是否为已实名非金融活跃用户)。这些规则可以用于确定接下来执行什么操作。

然后，在操作s202中，获取所述所需的规则的规则组件标识。

在本实施例中，可以通过与服务器进行交互以获取所述所需的规则的规则组件标识，例如，通过查询服务器中的规则库来确定上述所需的规则对应的规则组件和规则组件标识，其中，所述规则库可以是预先构建的用于存储的各使用过的规则对应的规则组件，所述规则组件可以是按照组件标准将规则抽象后组件化，可供所有的活动使用。每个规则组件具有唯一规则组件标识。例如，规则组件标识1对应规则a(是否为普通会员)抽象得到的规则组件。

接着，在操作s203中，至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树，得到前端规则树和前端规则树标识，所述前端规则树的至少部分节点包括规则组件标识。

在本实施例中，可以将营销活动里要使用的规则组件(如规则组件a、规则组件b、规则组件c)对应的规则组件标识(如规则组件标识a、规则组件标识b、规则组件标识c)，按照策划的营销方案以树结构串起来，组建成一棵前端规则树，树的最末级节点，根据活动要求，可以设置活动奖池或自定义文案等，系统保存后，该营销活动的活动规则定义将以树结构的形式存储起来。

可选地，所述至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树可以包括如下操作：首先，在gojs前端框架的画布功能上添加与所述所需的规则的规则组件标识对应的图标，然后，至少基于所述图标和所述活动方案所需规则的逻辑关系构建可视化前端规则树，所述可视化前端规则树具有唯一可视化前端规则树标识。gojs为一个实现交互类图表(比如流程图，树图，关系图，力导图等等)的js库。

图2b示意性示出了根据本公开实施例的前端规则树的结构示意图。如图2b所示，营销活动a中包括三个规则组件：是否为普通会员的规则组件、是否为铂金会员的规则组件以及是否为黑金会员的规则组件。营销活动a所需规则的逻辑关系为首先判断用户是否为普通会员，如果是，则进入普通会员奖池，如果数据异常则输出提示信息(如未中奖)；如果否，则判断用户是否为铂金会员，如果是，则进入铂金会员奖池，如果数据异常则输出未中奖；如果否，则判断用户是否为黑金会员，如果是，则进入黑金会员奖池，如果数据异常则输出未中奖，如果否，则输出未中奖。其中，当进入普通会员奖池、铂金会员奖池或黑金会员奖池之后，可以调用抽奖相应的接口以获取该用户是否中奖以及奖品等，然后反馈给用户。

图2c示意性示出了根据本公开另一实施例的前端规则树的结构示意图。如图2c所示，营销活动b中包括两个规则组件：是否实名用户的规则组件和是否为已实名非金融活跃用户的规则组件。营销活动b所需规则的逻辑关系如图2c所示，可以参考如图2b的相关说明，在此不再赘述。

图2d示意性示出了根据本公开实施例的规则组件的结构示意图。

如图2d所示，规则组件是按照组件标准将规则抽象后组件化，可供所有的活动使用。组件实现可以采用if-else逻辑，组件标准：入参(如用户信息)、出参(可以包括正确出参true/错误出参false/异常出参error)，组件校验逻辑可以是一个自定义接口服务或者第三方接口服务。

可选地，至少基于所述图标和所述活动方案所需规则的逻辑关系构建可视化前端规则树，所述可视化前端规则树具有唯一可视化前端规则树标识。相应地，所述将所述前端规则树和对应的前端规则树标识发送给服务端进行存储包括将所述可视化前端规则树和对应的可视化前端规则树标识以json形式发送给服务端进行存储。其中，json的全称为javascriptobjectnotation，是一种轻量级的数据交换格式，易于人阅读和编写，同时也易于机器解析和生成。

在一个具体实施例中，首先，在画布上搭建和组织前端规则树，从规则库中获取营销活动所需规则组件的规则组件标识(此处规则组件默认在系统运行阶段已经形成为可用的组件)。例如，利用gojs前端的js框架，将各个规则组件标识对应的图标以有序树结构组织起来，如图2c和图2d所示，此时画布中的前端规则树结构是gojs的前端结构标准，只是给画布展示用，并不能直接给活动解析模块识别，在这里称为前端规则树frontruletree。

然后，在操作s204中，将所述前端规则树和对应的前端规则树标识发送给服务端进行存储。

具体地，将页面搭建好的前端规则树以json形式保存到服务端的数据库中，并获取服务端生成的前端规则树frontruletreeid，将前端规则树和对应的前端规则树frontruletreeid进行绑定并存储。这样就可以实现当输入前端规则树frontruletreeid时，就可以在服务器中找到对应的前端规则树frontruletree以及对应的数据。

在其它实施例中，所述方法还可以包括操作s205。

在操作s205中，在将所述前端规则树和对应的前端规则树标识发送给服务端进行存储之后，创建至少一个活动，每个活动具有唯一活动标识。

相应地，至少将所述前端规则树标识相关联的至少一个活动标识发送给服务端进行绑定，得到前端规则树标识和活动标识的对应关系。

具体地，创建一个活动，生成活动唯一标识actkey，然后将actkey和上述创建好的前端规则树标识frontruletreeid绑定起来，建立关联关系actrulemap。

这样可以使得一个前端规则树对应多个活动。例如，当多个活动所采用的前端规则树相同时，则可以仅分别创建一个活动，并将多个活动的活动标识与对应的前端规则树的前端规则树标识绑定即可完成开发任务，大大降低了开发成本。

图3a示意性示出了根据本公开另一实施例的活动规则组建方法。

如图3a所示，该方法适用于服务端，具体可以为如图1所示的服务器105、服务器集群等。本实施例主要用于将前端规则树frontruletree转成在服务端可解析的规则树ruletree。所述方法可以包括操作s301～操作306。

在操作s301中，接收前端规则树，所述前端规则树的至少部分节点包括规则组件标识。例如，通过网络接收所述第一客户端发送的前端规则树。

在操作s302中，按照有序树的顺序遍历所述前端规则树，得到规则组件标识。

在本实施例中，可以通过前端规则树标识frontruletreeid从数据库中查询到对应的前端规则树frontruletree，按照有序树的顺序遍历frontruletree，将frontruletree里的规则组件标识提取出来。这样使得服务器可以得到当前营销活动所需的规则对应的规则组件id。

在操作s303中，利用所述规则组件标识查询规则库，得到规则组件。

具体地，可以通过规则组件标识查询规则库得到规则组件信息rulecominfo。

其中，所述规则库通过以下方式获取：首先，获取规则，可以是历史上使用过的规则，还可以是开发人员编制的规则等。

然后，基于组件标准将所述规则组件化，得到规则组件。其中，所述组件标准可以包括：入参、正确出参、错误出参和异常出参，具体可以参考如图2d所示。

接着，将所述规则组件存储在规则库中，每个规则组件具有唯一规则组件标识。

在操作s304中，将规则组件转换为规则节点。

具体地，可以将规则组件信息rulecominfo转换成规则树节点rulenode。

在操作s305中，依据所述前端规则树的节点间关系将所述规则节点串成规则树。

具体地，可以在生成规则树节点rulenode的同时，将rulenode按照frontruletree的有序树结构串成结构树ruletree。这样就可以得到服务端可运行的规则树。

活动规则在开发端以树结构存储起来后，只是一堆静态定义，而必须通过解析让树结构里的各个规则按照规则定义的标准执行生效。

图3b示意性示出了根据本公开实施例的规则树转换过程示意图。如图3b所示，通过该转换过程即可实现将服务端不能运行的前端规则树转换为服务端可以运行的前端规则树。

在操作s306中，存储所述规则树及对应的前端规则树标识。

本公开提供的活动规则组建方法可以由服务端自动将第一客户端发送的前端规则树解析成服务端可运行的规则树，大大减小了开发人员在开发过程中的任务量，有助于节省开发成本且可以缩短开发用时。

在另一个实施例中，所述方法还可以包括操作s307。

在操作s307中，在得到所述规则树之后，将所述规则树序列化成json串。

具体地，将转换完的ruletree序列化成json串：ruletreejson，并将ruletreejson保存到关联关系actrulemap里。这样便于存储规则树。

相应地，所述存储所述规则树及对应的前端规则树标识包括将所述json串及对应的前端规则树标识建立关联并存储。

此外，当接收到前端规则树标识和活动标识的对应关系时，所述存储所述规则树及对应的前端规则树标识包括存储所述规则树及对应的活动标识。通过将所述规则树及对应的活动标识建立关联关系，这样可以在使用该规则树时，例如，用户在用户端的某个营销活动的页面中输入用户信息时，服务端即可得到该营销活动的活动标识，通过该活动标识可以获取对应的规则树，以便获取该用户相对于该规则树的输出结果。

图3c示意性示出了根据本公开另一实施例的活动规则组建方法。本实施例主要用于说明如何使用规则树获取用户对应的输出结果。

如图3c所示，所述方法还可以包括操作s308～操作s311。

在操作s308中，接收请求指令，所述请求指令为第二客户端发送的包括用户标识信息和前端规则树标识信息的指令。

在本实施例中，该第二客户端可以为参与营销活动的用户使用的终端，具体可以为如图1中所示的终端设备101、102或103等。例如，当用户点击了打开了某个活动的页面，则服务端会获取到当前用户的用户标识信息和该活动的页面对应的前端规则树标识信息。

可选地，所述请求指令为第二客户端发送的包括用户标识信息和活动标识信息的指令，相应地，所述根据所述前端规则树标识信息确定规则树包括根据所述活动标识信息确定规则树。由于用户或服务端并不容易得知当前活动页面对应的前端规则树标识，但是，在之前的实施例中，可以将活动标识和对应的规则树绑定，而活动标识很容易通过活动页面获取，这样就便于通过活动页面得到活动标识，进而得到对应的规则树。

在操作s309中，响应于接收到所述请求指令，根据所述前端规则树标识信息确定规则树。

具体地，可以通过查询数据库得到所述前端规则树标识信息对应的规则树。

在操作s310中，基于所述用户标识信息以有序树的顺序遍历所述规则树，得到针对所述用户标识信息相应地规则树的输出结果。

具体地，所述基于所述用户标识信息以有序树的顺序遍历所述规则树，得到针对所述用户标识信息相应地规则树的输出结果可以包括如下操作：首先，从规则树中提取根节点，然后，如果所述根节点为规则组件，则由根节点输出与所述用户标识信息对应的结果，提取与所述结果对应的子节点，如果所述子节点为规则组件，则由子节点输出与所述用户标识信息对应的结果，重复上述操作直至规则树深度遍历结束，得到最后一个子节点的输出结果，以及，将所述最后一个子节点的输出结果发送给所述第二客户端。

在操作s311中，将所述输出结果发送给所述第二客户端。

在另一个实施例中，所述规则树以序列化的json串形式存储，相应地，所述根据所述前端规则树标识信息确定规则树可以包括如下操作：首先，根据所述前端规则树标识信息确定序列化的json串，然后，对所述序列化的json串进行反序列化处理，得到规则树。

本公开提供的活动规则组建方法可以利用服务器自动解析的规则树获取当前用户对应的输出结果。

图3d示意性示出了根据本公开实施例的规则树使用方法流程图。

如图3d所示，涉及到第二客户端和服务端之间的数据交互，以下以一个具体实施例进行说明。

操作1，用户以登录状态在活动页面参与活动，以下用大转盘抽奖为例进行示例性说明，系统会获取当前参与用户唯一的用户标识userid和当前活动唯一的活动标识actkey，然后页面会带着userid和actkey这两个参数向服务端发起http抽奖请求。

操作2，当服务端接收到抽奖请求后，先从http抽奖请求里提取参数actkey，通过actkey从数据库actrulemap里查询到该活动对应的规则树json结构(ruletreejson，此操作如果对性能有要求，可以提前将规则树同步到缓存里，用查询缓存替代查询数据库)。

操作3，将ruletreejson通过反序列化方式，反序列为规则树ruletree对象。

操作4，当服务端获取到规则树ruletree后，再从http抽奖请求httprequest参数提取用户唯一的用户标识参数userid，开始判断用户是否满足规则树里的规则，如从ruletree里提取根节点rulenode，将userid和rulenode一起传入下一步遍历流程。

操作5，解析规则树节点rulenode，从规则树节点rulenode对象里取出节点类型nodetype。

操作6，根据nodetype判断当前的rulenode是不是规则组件，如果rulenode的nodetype是规则组件，则进行操作7；如果不是规则组件，则进行操作10。

操作7，如果当前rulenode的nodetype是规则组件，根据rulenode实现方式来执行规则校验，规则校验实现方式可以如下所示：一种是自定义接口或者调用第三方接口(如新用户身份接口)，一种设置阈值类的(比如活动参与次数)，当然，还可以根据需求存在其他规则校验方式，在此不做限定。

操作8，执行完规则校验后，按照组件输出标准，会返回结果：true、false或error三种结果，然后根据这三个结果类型，从规则树里，取出当前规则树节点rolenode对应结果的下一个规则树子节点subrolenode。

操作9，重复操作5至操作8，继续解析subrolenode。

操作10，如果nodetype不是规则组件类型，则继续判断当前rulenode是不是奖池类型，如果是奖池类型，则进行奖池抽奖，终止遍历，返回抽奖结果；如果不是奖池类型，则继续操作11。

操作11，如果rolenode既不是规则组件，又不是奖池，则判断rolenode是否为最后一种类型：自定义文案类型，如果是，此时会终止遍历，返回自定义文案，如果不是，则表明出现异常结果，此时也会终止遍历，返回自定义文案。

操作12，将规则解析和校验的结果封装成标准返回类型，输出给用户浏览的页面，页面根据不同结果做相应的用户交互。

活动推广后，用户参与一次活动，就代表要解析活动对应的规则树。规则解析过程中，采用的是三叉树的深度优先遍历原理，当整个规则树遍历完后，就能得出该给用户发放何种奖励。规则树里的rulenode只有三种类型：规则组件、奖池和自定义文案，遍历解析规则树时，如果rulenode是规则组件类型，将继续遍历其在规则树中的下一级rulenode；如果是rulenode是奖池类型或者自定义文案类型，则终止规则树遍历，返回奖池抽奖结果或者自定义文档。其中，三叉树为一种计算机学科中的数据存储结构，三叉树是分左、中、右子树的一棵有序树。深度优先遍历是沿着树的深度遍历树的节点，尽可能深的遍历树的分支。

图4a示意性示出了根据本公开实施例的活动规则组建装置的框图。

如图4a所示，装置400可以包括规则获取模块410、第一规则组件标识获取模块420、构建模块430以及第一发送模块440。

所述规则获取模块410用于根据活动方案确定所需的规则。

所述第一规则组件标识获取模块420用于获取所述所需的规则的规则组件标识。

所述构建模块430用于至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树，得到前端规则树和前端规则树标识，所述前端规则树的至少部分节点包括规则组件标识。

所述第一发送模块440用于将所述前端规则树和对应的前端规则树标识发送给服务端进行存储。

其中，所述构建模块430包括：画图单元和构建单元。

所述画图单元用于在gojs前端框架的画布功能上添加与所述所需的规则的规则组件标识对应的图标。

所述构建单元用于至少基于所述图标和所述活动方案所需规则的逻辑关系构建可视化前端规则树，所述可视化前端规则树具有唯一可视化前端规则树标识。

相应地，所述第一发送模块440具体用于将所述可视化前端规则树和对应的可视化前端规则树标识以json形式发送给服务端进行存储。

此外，所述装置400还可以包括创建模块450和第二发送模块460。

所述创建模块450用于在将所述前端规则树和对应的前端规则树标识发送给服务端进行存储之后，创建至少一个活动，每个活动具有唯一活动标识。

所述第二发送模块460用于至少将所述前端规则树标识相关联的至少一个活动标识发送给服务端进行绑定，得到前端规则树标识和活动标识的对应关系。

本公开提供的活动规则组建装置可以使得开发人员无需为每个营销活动单独定制化开发一套接口服务，只需要构建模块430至少基于所述规则组件标识和所述活动方案所需规则的逻辑关系构建前端规则树，得到前端规则树和前端规则树标识，然后将所述前端规则树和对应的前端规则树标识发送给服务端即可完成开发任务，如由服务器将前端规则树转换为可以运行的规则树，大幅度缩减了开发人员的开发用时。

图4b示意性示出了根据本公开另一实施例的活动规则组建装置的框图

如图4b所示，装置500可以包括第一接收模块510、第二规则组件标识获取模块520、规则组件获取模块530、规则节点转换模块540、规则树获取模块550和第一存储模块560。

所述第一接收模块510用于接收前端规则树，所述前端规则树的至少部分节点包括规则组件标识。

所述第二规则组件标识获取模块520用于按照有序树的顺序遍历所述前端规则树，得到规则组件标识。

所述规则组件获取模块530用于利用所述规则组件标识查询规则库，得到规则组件。

所述规则节点转换模块540用于将规则组件转换为规则节点。

所述规则树获取模块550用于依据所述前端规则树的节点间关系将所述规则节点串成规则树。

所述第一存储模块560用于存储所述规则树及对应的前端规则树标识。

其中，所述规则库可以通过以下单元获取：规则获取单元、组件化单元和存储单元。

所述规则获取单元用于获取规则。

所述组件化单元用于基于组件标准将所述规则组件化，得到规则组件。所述组件标准包括：入参、正确出参、错误出参和异常出参。

所述存储单元用于将所述规则组件存储在规则库中，每个规则组件具有唯一规则组件标识。

此外，所述装置500还可以包括序列化模块570。

所述序列化模块570用于在得到所述规则树之后，将所述规则树序列化成json串。

相应地，所述第一存储模块560具体用于将所述json串及对应的前端规则树标识建立关联并存储。

当接收到前端规则树标识和活动标识的对应关系时，所述第一存储模块560具体用于存储所述规则树及对应的活动标识。

进一步地，所述装置600还可以包括：第二接收模块580、规则树确定模块590、输出模块610和第三发送模块620。

所述第二接收模块580用于接收请求指令，所述请求指令为第二客户端发送的包括用户标识信息和前端规则树标识信息的指令。

所述规则树确定模块590用于响应于接收到所述请求指令，根据所述前端规则树标识信息确定规则树。

所述输出模块610用于基于所述用户标识信息以有序树的顺序遍历所述规则树，得到针对所述用户标识信息相应地规则树的输出结果。

所述第三发送模块620用于将所述输出结果发送给所述第二客户端。

可选地，所述规则树以序列化的json串形式存储，其中，所述规则树确定模块590包括：反序列化单元和规则树获取单元。

所述反序列化单元用于根据所述前端规则树标识信息确定序列化的json串。

所述规则树获取单元用于对所述序列化的json串进行反序列化处理，得到规则树。

如果所述请求指令为第二客户端发送的包括用户标识信息和活动标识信息的指令，相应地，所述规则树确定模块590具体用于根据所述活动标识信息确定规则树。

在一个实施例中，所述输出模块610包括：根节点获取单元、遍历单元和发送单元。

所述根节点获取单元用于从规则树中提取根节点。

所述遍历单元用于如果所述根节点为规则组件，则由根节点输出与所述用户标识信息对应的结果，提取与所述结果对应的子节点，如果所述子节点为规则组件，则由子节点输出与所述用户标识信息对应的结果，重复上述操作直至规则树深度遍历结束，得到最后一个子节点的输出结果。

所述发送单元用于将所述最后一个子节点的输出结果发送给所述第二客户端。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，规则获取模块410、第一规则组件标识获取模块420、构建模块430、第一发送模块440、创建模块450、第二发送模块460、第一接收模块510、第二规则组件标识获取模块520、规则组件获取模块530、规则节点转换模块540、规则树获取模块550、第一存储模块560、序列化模块570、第二接收模块580、规则树确定模块590、输出模块610和第三发送模块620中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，规则获取模块410、第一规则组件标识获取模块420、构建模块430、第一发送模块440、创建模块450、第二发送模块460、第一接收模块510、第二规则组件标识获取模块520、规则组件获取模块530、规则节点转换模块540、规则树获取模块550、第一存储模块560、序列化模块570、第二接收模块580、规则树确定模块590、输出模块610和第三发送模块620中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，规则获取模块410、第一规则组件标识获取模块420、构建模块430、第一发送模块440、创建模块450、第二发送模块460、第一接收模块510、第二规则组件标识获取模块520、规则组件获取模块530、规则节点转换模块540、规则树获取模块550、第一存储模块560、序列化模块570、第二接收模块580、规则树确定模块590、输出模块610和第三发送模块620中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图5示意性示出了根据本公开实施例的适于实现上文描述的方法的计算机系统的方框图。图5示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图5所示，根据本公开实施例的计算机系统700包括处理器701，其可以根据存储在只读存储器(rom)702中的程序或者从存储部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。处理器701例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器701还可以包括用于缓存用途的板载存储器。处理器701可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在ram703中，存储有系统700操作所需的各种程序和数据。处理器701、rom702以及ram703通过总线704彼此相连。处理器701通过执行rom702和/或ram703中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom702和ram703以外的一个或多个存储器中。处理器701也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统700还可以包括输入/输出(i/o)接口705，输入/输出(i/o)接口705也连接至总线704。系统700还可以包括连接至i/o接口705的以下部件中的一项或多项：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至i/o接口705。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被处理器701执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom702和/或ram703和/或rom702和ram703以外的一个或多个存储器。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。

以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。