营销活动业务在配置中会同一时间存在多个营销活动，用户进入某个场景，首先需要给用户展示目前用户能够享受的营销活动，增加用户参与此场景的意向，然后用户参与场景后需要给用户提示对应的营销活动，用户如果没有参与成功需要给用户提示具体没有参与成功的原因。那么在参与前，具体的场景中需要进行用户资格的校验，并且用户参与后需要进行资格记录。
同时，资格校验能够有效防止用户重复参与的问题，通过配置用户的次数资格来进行校验，用户参与成功一次进行记录，后面用户参与前对次数资格进行相关的校验。
资格分类
资格设计先要针对资格进行分类，通过不同的分类进行各自分类领域模块设计。分类的原则是分层漏斗分类：优先过滤大量不满足、消耗服务器资源较少的活动，再过滤需要消耗服务器资源较多的活动，最后是进行风控资格校验。按照这个分类原则后面可能会出现多个营销活动，这个是另外一个话题—营销推荐设计。
以上是目前苏宁金融这边针对资格设计的分类：静态资格、动态资格和风控资格。此处风控资格校验作为独立的一个分类并且放在最后，主要是由两个方面考虑：（1）风控的内容很多，在苏宁金融有专门的风控中心来进行风控规则的制定和执行；（2）风控返回的风控级别也有很多，营销活动的不同、触发风控的级别不同，对应的营销活动处理逻辑也不一样。
下面针对以上的分类的静态资格和动态资格进行相关的领域模块具体设计探讨。
静态资格
静态资格在苏宁金融营销中的定义是：用户进入具体场景、当时用户属性标签的一个静态数据。
静态数据的获取方面主要通过两个部分获取：（1）上游系统的传递，这个数据主要是获取用户所处的场景数据，包括但不限于：用户当前进行的业务及业务数据、用户使用终端、网络环境等等数据。（2）用户属性标签的大数据获取。在苏宁金融大数据中心有一套完整的用户实时标签库，用户请求后通过次标签库实时查询用户目前的标签。
静态数据的过滤在技术方案中适合采用规则引擎进行相关资格校验。目前在苏宁金融的营销系统中使用Drools，主要是考虑以下几个方面：
（1） 业务规则较多，如果使用编码方式新增规则就需要进行相关的编码，增加代码量和维护成本。
（2） Drools的自定义关系操作符：通过自定义关系操作符可以针对不同的业务规则配置需要的操作符还可以针对每个活动不能匹配的原因进行内部埋点记录，方便运营进行客诉查询。
（3） 纯java实现，学习成本低。
业务配置生成drl文件设计
关于生成drl文件的设计，先来看看drools引擎原理：
Drools引擎通过每个条件进行匹配，最终匹配出相关的活动，所以在设计中需要考虑最终返回的数据是活动集合。
writeRuleFile是入口，通过入口进行内部方法组装，此方法需要功能是组装文件内容和写文件；writeDrlHead方法为写文件头部包、引用和全局变量定义；assembleEvaluatorDefinition方法是组装自定义操作符规则；getActRuleWhenCondition此方法为拼接规则字符串；writeActivityRule此方法为活动的规则写入。
以上是一种纯java代码实现Drl文件生成的一个方式，目的是为了让大家能够理解Drl文件的结构。实际操作过程中也可以通过freemarker模版来生成对应的Drl文件。
Drools规则加载
此处规则加载设计可以设计为内置定时器扫描规则生成表是否有新增记录或者采用分布式集群通知的方式进行加载。
目前，苏宁内部的统一配置平台采用的是自研的SCM平台，能够很好地支持实时修改，应用服务器集群每台应用监听具体某个配置文件的内容变更。
应用服务器监听到需要进行Drl文件 加载后，通过拉取Drl文件，并读取其中的内容生成对应的KieBase。
