编号规则功能详细设计(2014版)(1)

编号规则模块功能详细设计

版本记录

1模块说明

1.1模块作用

编号规则属于工具模块，在系统的很多业务模块中都存在编号来标识数据，就需要有一个模块能尽量适用各种存在规律的编号的生成，编号规则负责该部分的工作，所以该模块属于工具模块，被各个地方所引用。

1.2名词解释

●编号：用于标识一个业务实例、数据条目的有一定业务规则的字串，业务称谓上通常由前

缀、主号码、后缀等组成。整个编号字串从技术称谓上可以分为的一个或多个部份，这些部份叫“编号片段”，每个“编号片段”由一个原子级的编号规则构成。

●编号规则：本设计框架支持一套可扩展的编号规则库。目前本设计预制了以下几种规则：固定

字串、自增（减）序号、枚举形序号库、年月日时分秒格式数字、当前账户组织单元属性、当前账户部门属性、当前账户人员属性、自定义参数注入。本系统将按这些规则实现不同的“规则提供器”。

●序号实例：对于自增（减）序号、枚举形序号规则系统建立序号实例库；这两种规则，需要根

据不同的参数形成不同的序号实例。每个序号实例条目记录了：实例区分组合字串、当前序号最大（小）值等。

1.3原理与算法

1.3.1编号引擎

1.3.2规则定义说明

规则定义分为：规则和规则明细定义。规则定义用于定义一个规则类型，用于识别不同的业务类型调用不同的编号规则。外部业务通过“单据类型编号”（TypeId）调用不同的编号规则。

规则明细定义了编号片断的组成规则和需要配置的项目。规则明细以规则定义为表头。按排列顺序形成编号的组成规则。

固定字段规则生成器：配置一个固定字串

自增（减）序号：是按数字递增（简）规则产生编号片断的。可以配置数字格式如：“#####”

（缺位需用0补齐）或“##,###”（戴格式的数字）可以配置数字起步值、最大值、步长（负步长表示递减）。序号实例区分参数：支持的参数包括全部（除当前明细）的规则明细，这些明细可以按顺序配制成一个字串组合。当运行时，系统按当前请求根据这些参数组成一个字串，然后到“序号实例”库表里查找，如果没有找到，则创建数据条目并从本规则明细的数字起步值开始记录当前序号。如果找到，则从此条目当前序号加步长记录当前序号。此规则还可以通过“序号实例”界面查看当前所有序号实例条目数据，并支持单独维护（实例区分组合字串、当前参数值下的序号的实际值）。还可以配置是否强制连续序号：如果需要强制连续序号，则系统不再自主递增（减）序号，需要外部API来提交递增（减）序号。且如果跳号，则会抛错（具体算法见后面说明）。

枚举形序号库：是按预定义好的序号库来输出编号片断的，比如：“A,B,C….”的字母顺序，当前如果是B了，则下次调用则产生C字母。序号库配置定义在规则明细上，采用“，”区分枚举项。还可以配置正序、倒序。仍可以配置“序号实例区分参数”和“配置是否强制连续序号”。（具体实现方案可以参照自增（减）序号规则提供器）

年月日时分秒格式数字：从当前服务器时钟里获得编号片断的规则提供器。可以配置年月日时分秒的格式输出形式。

当前账户组织单元属性、当前账户部门属性、当前账户人员属性：将从当前账户登录系统后形成的session里提取这些信息。系统支持“classname.propertyname”形式配置提取信息。自定义参数注入：根据系统调用API的定义，支持从调用直接带入参数用于编号片断。系统支持前台ajaxAPI调用参数，基于json串识别参数名，参数值。后台map识别参数名，参数值。本规则可以配置一个参数名。还可以配置直接从：session、request、里提取参数。

1.3.3配置是否强制连续序号算法实现说明

配置是否强制连续序号用于实现采用“由于自增（减）序号、枚举形序号库”的规则生成器。下面用是强制、否强制来简化称谓。

否强制：系统将在调用编号请求API时就对序号进行自增（减）并持久化到序号实例库内。好处是使用简单，基本不用考虑序号重复问题。接近于随机数发生器。缺点是序号不连续（当产生时不提交业务或提交失败）。

是强制：系统不会在调用编号请求API时就对序号进行自增（减），而是需要通过与业务提交同事务内的更新API来驱动对序号进行自增（减）并持久化到序号实例库内。举例某纯Integer 数字递增序号提供器具体算法如下：

调用时API分为初始化session缓存和获得编号两个API；假定获得编号时有两个session都要请求序号，而当前序号为4；则两个session内通过初始化API（用“实例区分组合字串”作为属性key）放入4（假定“实例区分组合字串”相同）。调用API时（此API从session 里创建新序号）各装入（session1:567；session2:56789）则当前：session1最大序号值为7；session2为9。（如果界面都没有提交，则下次界面打开时需再次调用初始化API恢复真实序号最大值4）。如果提交业务，则需要调用更新写入序号API（提交编号API只能是后台API），对于session1，如上图：如果满足要持久化更新的编号个数与最大号是连续的，则进行持久化，按最大编号值更新序号实例库相应条目。对于session2假定8的序号由于业务没有使用，则需要更新5679，会因最大号与编号个数不一致抛出异常。由于与业务提交处于相同事务，则保证序号连续的一致性。如果session1和session2都正常提交了，提交API需要先从数据库内读取当前真实序号情况，然后识别当前提交是否是在当前序号基础上连续递增（减）的，如果不是则此事务也抛出异常。

注意，初始化、获得、提交更新API都是以typeid为参数的，所以：session里应以typeid 为key构建一个Map，再以编号明细的key为内部MAP构建值对象；对于序号类的规则，内部MAP的值为当前序号值。这套session内的数据结构用于维护一个事务中连续创建编号的情况（强制要求联号配置下）。