自我认识——生命周期.doc

生命周期 Zsmart-CCB生命周期 生命周期的概念 【什么是生命周期和为什么要引入生命周期？】 【为什么后付费用户没有生命周期？】 【为什么产品配了生命周期就不允许再修改删除？】 预付费用户开户后，在使用的过程中经历激活、在用、单停、双停、拆机等一系列用户状态转换的过程就叫做生命周期。 【怎么区分用户为预付费用户和后付费用户】 判断主产品服务类型是预付费还是后付费还是融合付费，通过哪张表？主产品服务类型已知道 第一个问题看QryIsPrePaid这个服务 用户主产品属性怎么判断是预付费还是后付费，通过哪张表？预后付费属性已配置 第二个问题 看属性attr_code = EXP_PAID_FLAG 1、 用户是预付费用户还是后付费用户，是根据用户所使用的主产品的服务类型来判断的(QryIsPrePaid)，如果主产品的服务类型是融合付费类型，则根据该类型主产品的预后付费属性来判断。(prod_spec_attr这里会配对应的属性id和属性值) 这里的预付费用户有2种情况： 一是订购服务类型为预付费的主产品的用户， 二是订购了服务类型为融合付费、但产品属性为预付费的主产品的用户 2、生命周期是和产品关联起来的，一个订户针对某种产品开完户后，他的生命周期流程也就决定了。然后主要由（订户的余额变化和生命周期的类型）所决定的一种状态扭转 【引入生命周期模型的原因】 从现在生命周期特点可以解读出来【事件触发、组件调用、状态变化可配置】 以前将用户状态转换固化在业务逻辑中，一旦处理逻辑发生改变，需要修改代码， 生命周期的流程可以在系统配置出来，并不是所有的生命周期都一定要有下面这套完整的流转过程，而是视需求决定。目前针对预付费用户的状态转换通过生命周期配置来进行控制 3、满足不同国家、不同运营商的业务适应和发展的需要。 生命周期状态模型 【五个状态：(全称)】 prod_state表有10种，常规用户只用5种 G（未激活）：预付费用户开户后的状态，预开户（PPS用户，需要激活后使用） A（Active激活、在用）G状态用户在买卡后，在规定时间拨打首个电话且有预充值（如果拨打首个电话但没有预充值呢） D（单停）A状态的用户余额用完或失效后立即进入D (余额用完、欠费和余额失效有什么区别，都是通过定时扫描JOB进入D吗) E（双停）D状态用户滞留N天后通过定时扫描JOB进入E【既不能打也不能接】 如果要让E、D——A可以【通过充值，充值后一旦有有效期就复机】 B（正常拆机）超过第一次拨打时间或E状态用户滞留N天后，通过定时扫描JOB进入B（第一次拨打但没有充值） 如果G状态用户在买卡后，未在限定的时间内拨打电话或者充值，则会进入B（拆机）?； G状态用户超过第一次拨打时间后通过定时扫描JOB进入B（拆机） F（欠费拆机） 【和营业员通过前台的业务受理造成的停机拆机是不一样的】 简单解读和两两转换 注：I激活中）是IDEA项目的一个特有的用户状态，它的作用就是判断用户激活后有没有充值，I（激活中）的用户一旦充值后，就立即转为A状态；如果此时用户没有预充值，则直接进入E（双停） 生命周期数据模型 由prod_spec_nameprod_spec_idlifecycle_typelifecycle_type_name 1、模型说明 一个生命周期类型包括若干个确定且不重复的用户状态转换节点 一个用户状态可能转换一到多个不同的目标状态，如D可能演进到A或E. 用户状态的转换取决于某些特定的客户交互事件，并需要考虑在当前用户状态持续的时间 对有特殊转换判别需求的还可以配置专门的Service来进行判别 模型实现 事件触发、组件调用 当某个特定的订户事件发生时，会触发用户生命周期引擎，根据触发条件（包括触发事件、产品规格、用户状态、状态停留时间、条件判别服务等）匹配到具体的生命周期转换节点，再调用转换节点中配置的业务组件，从而完成用户状态转换。【具体用户状态的转换是在业务组件中实现的。】 简而言之：订户事件发生触发生命周期引擎，根据触发条件匹配转换节点，调用转换节点完成用户状态转换 【下面一些常用sql可以帮助查询订户的主产品信息以及配置的生命周期：】 用户状态：prod_state 用户状态图：prod_event_diagram 用户事件处理：prod_event_process——业务功能组件：om_bc 用户事件通知：prod_event_notif ——通知类型：advice_type 适用生命周期类型：lifecycle_apply 生命周期类型：lifecycle_type 客户交互事件：subs_event SELECT * FROM prod_spec a WHERE a.prod_spec_name=dsl_liuyuj