销售业务面向SaaS应用的业务逻辑定制框架的研究.docx

销售业务面向SaaS应用的业务逻辑定制框架的研究.docx

《销售业务面向SaaS应用的业务逻辑定制框架的研究.docx》由会员分享，可在线阅读，更多相关《销售业务面向SaaS应用的业务逻辑定制框架的研究.docx（5页珍藏版）》请在冰豆网上搜索。

销售业务面向SaaS应用的业务逻辑定制框架的研究

设计成通用的软件，以便能为尽可能多的租户提供软件服务。

由于存在行业专注、客户行为、供应产品、规章制度、运营策略、文化传统等差异，许多租户仍然有自己独特的业务需求。

由于SaaS支持多个租户运行同一软件实例，应用提供商无法通过为每一个租户开发并维护一个代码版本来满足租户的独特需求。

这就需要SaaS应用允许租户对软件的业务逻辑进行在线定制。

1相关工作

软件的业务逻辑定制技术并不是一个全新的课题，国内外学者在面向传统应用的业务逻辑定制技术方面有不少研究成果，而且有些方法已经被工业界采用了。

参数设置是业界常用的业务逻辑定制方法之一。

所谓参数设置，是指通过表格、XML、Wizard等方式来设置个性化参数，满足用户个性化需求。

这种方法虽然实现起来很方便，但定制能力十分受限，很难达到灵活定义业务逻辑的目的。

流程可视化建模是工作流系统中采用较多的业务逻辑定制解决方案，但是流程在运行时的动态修改比较困难，即如何将运行中的流程实例迁移到新的流程模型中，以及如何在流程定义不完整的情况下进行运行比较困难，而且无法支持非流向型的业务逻辑的定制。

可变性建模是人们从制造业流行的大规模定制中得到启发进而提出的一种业务逻辑定制解决方案。

用户可以按照自己的实际需求对可变点进行建模，然后以一定的方式对可变点进行组合从而达到定制的目的。

该方法由于是确定性建模，模型建好后就很难扩展，对用户之后的一些个性化需求将难以满足。

在人工智能领域中，规则是用来构建基于知识系统的最常用选择。

这就是所谓的业务规则方法。

这种方法提供了一种灵活的业务逻辑定制模式。

Nalepa等人针对业务流程建模中的业务规则设计问题提出了一种基于XTT的方法，XTT采用形式化的语言来描述业务规则，这使得业务规则便于验证。

但是，这种方法对于用户来说操作很困难，因为它们可能缺乏数学基础，难以编写出业务规则。

对于SaaS应用来说，它与传统软件的业务逻辑定制仍存在不少差别，这些差别包括：

a）SaaS应用的业务逻辑定制需要支持多租户。

每个租户有着自己不同的定制，而传统软件在整个软件系统中只需要一份定制。

b）SaaS应用的定制操作不是在系统运行前定制，而是要能够在系统运行过程中动态执行，从而能够根据需求的变化随时作出相应的定制，而且定制时不能把系统暂停下来，以免影响其他租户。

c）在SaaS中，大多数定制操作由租户的管理员来执行，而不是由软件供应商的开发人员来配置，这要求定制操作简单易懂。

Salesforee是采用SaaS模式的先驱者之一。

它提供了两种选择来定制业务逻辑，即点击式配置和基于代码的配置。

前者提供了一些简单的点击式向导以供租户定制自己的业务逻辑，这种方式对于定制内容有很大的局限性；后者提供了一种名为Apex的编程语言来供租户定制复杂的业务逻辑，这种方法很灵活但是复杂性高，需要开发人员来定制，不太适合没有或很少有编程经验的租户。

也有学者提出了定制框架来支持面向SaaS应用的业务逻辑定制。

此框架通过定义服务并且在运行时依据规则动态地修改、替换服务从而达到定制业务逻辑的目的。

它采用了SOA的架构。

比较适合于基于Internet系统之间的松散集成，对于紧密集成的单个系统，因性能问题，并不是很适合。

2业务规则模板

SaaS应用的业务逻辑定制必须由租户在线定制，而租户可能没有或有很少编程能力，所以面向SaaS应用的业务逻辑定制须尽可能简单。

而业务规则模板的方法具有很好的灵活性和易用性，比较适合SaaS应用。

因此，笔者考虑采用此方法来使得租户可以方便地定制符合自己需求的业务逻辑。

在不同的领域中，业务规则的表述形式也不尽相同。

所以，设计一种针对所有领域的通用的业务规则模板几乎是不可能的。

本文采用了领域工程的方法针对一个特定领域来设计业务规则模板。

设计业务规则模板的步骤如下：

a）采用领域工程的方法，识别此领域中与业务逻辑相关的所有的共性和可变性。

并建立领域分析模型。

b）对可变性进行分析，建立领域设计模型，并识别出与业务逻辑相关的核心业务对象及其属性。

C）对可变性中存在的共同形式进行抽象，然后以结构化的自然语言表述出来，形成业务规则模板。

对于业务规则模板的格式，笔者参考了ECA（event-condition-action）规则的表述形式。

ECA采用了“ONsomeeventifsomeconditionthensomeactions”的格式，业务规则由事件、条件和动作三部分组成。

为了便于所提出的业务逻辑定制框架中的规则翻译器将租户定义的业务逻辑转换成规则引擎可以识别的格式，将事件部分也归入到条件部分中，即将事件也看做是一种条件。

本文设计的业务规则模板包含两种类型，即条件模板和动作模板。

条件模板描述了期望或不期望的约束；动作模板则表示当条件满足时会触发什么样的动作。

这些条件模板和动作模板可以分别组合起来以表示复杂的条件与动作。

将条件部分与动作部分组合则可以表示一条业务规则。

3框架的架构

通过采用业务规则模板的方法，本文设计和实现了一个灵活的适合SaaS应用的业务逻辑定制框架。

框架的架构如图1所示。

图1面向SaaS应用的业务逻辑定制框架架构

从图1中可以看出，架构共包括七个构件：

可视化规则定义器、规则翻译器、业务对象表、规则引擎、验证引擎、规则文件库以及数据库。

根据此框架，业务逻辑的定制流程可以分为以下几步：

a）业务规则定义。

通过可视化规则定义器，其提供了一些预先设计的结构化自然语言描述的业务规则模板，租户可以从这些模板中选择他们所需要的，并将模板内容填写完整然后进行自由组合。

与此同时，系统会自动将租户定义的业务逻辑中相关的业务对象加入到租户的业务对象表中。

b）业务规则格式转换。

在业务规则被定义好之后，它将会被送入到规则翻译器中。

规则翻译器会按照预先定义好的转换规则自动将业务规则的条件部分和动作部分转换成规则引擎可以识别的格式。

C）业务规则验证。

系统将规则名称、规则属性以及转换后的规则的条件和动作部分组合起来以形成完整的业务规则并加入到验证引擎中。

验证引擎会对租户定义的所有的业务规则进行冗余性、循环依赖性及不一致性等语义错误进行检测。

d）业务规则存储。

经验证成功的业务规则会加入到规则文件库中租户的规则文件中。

为了便于规则的查询修改，将业务规则的各个部分如规则名称、规则属性、规则条件、规则动作等存储到数据库中。

e）业务规则执行。

当一个租户登录进系统后，系统会将此租户的规则文件装载到规则引擎的规则库中以供规则引擎使用。

当系统运行至规则引擎调用点时，系统将会首先检查租户的业务对象表来决定是否调用规则引擎。

如果与当前调用点相关的业务对象存在于租户的业务对象表中，系统将会调用规则引擎以执行租户定义的业务逻辑，否则将不会调用。

在此框架中，之所以为每个租户配备了一个业务对象表，是因为每个租户都有其特定的需求，这将会导致租户可能需要定义大茸的业务逻辑。

大量的业务逻辑可能会涉及到大量的业务对象。

这就意味着在一个SaaS应用中，会预先设置大量的规则引擎调用点。

对于某些租户来说，很多的调用点不是他们所需要的，这些多余调用点的存在会降低系统的性能，因此为每个租户配备了一个业务对象表。

当租户定义业务逻辑时，与业务逻辑相关的业务对象将会被加入到租户的业务对象表中。

如果系统需要调用规则引擎，它会首先检查租户的业务对象表；如果与当前调用点相关的业务对象存在于租户的业务对象表中，系统将会调用规则引擎，否则将不会调用。

通过此种方法，系统的性能得到了优化。

此框架通过采用基于领域工程的业务规则模板的方法，与现有的业务逻辑定制方法相比，具有如下优点：

a）可定制内容丰富。

采用领域工程的方法，对某一领域内的可变点进行建模，基本覆盖了租户对于可变性的需求。

b）定制操作简单。

提供了大量的自然语言描述的业务规则模板，租户无须自己去编写复杂的业务逻辑，只需要选择符合自己需要的模板，并将模板内容补充完整即完成了一条业务逻辑的定制。

c）错误发生概率低。

由于采用规则模板的方式来定义业务逻辑，很大程度上可以避免业务逻辑语法错误的发生。

4框架的实现

4.1建立领域模型

本文选择了三个绩效考核系统来分析它们的共性和可变性：

两个离岸产品和笔者为中石化东北化工销售公司大庆分公司开发的系统。

一些领域专家也参与了整个领域建模的过程。

遵循基于特征的领域分析方法，建立了绩效考核领域的领域分析模型。

部分的领域分析模型如图2所示。

在图2中，没有圆圈的方框代表绩效考核领域的共性，而含有圆圈的方框代表可变性。

含有圆圈的方框又可以分为两类，即可选的功能和业务逻辑约束。

带有箭头的虚线表示依赖关系。

可选功能是功能定制中所需考虑的问题，本文不作研究，只关注业务逻辑约束和依赖关系。

当领域分析模型建立好之后，会识别其中核心的业务对象并建立领域设计模型。

部分的领域设计模型如图3所示。

如“指标数目约束”中，识别出的相关业务对象是考核模板，相关的属性是指标数目。

这些业务对象及其属性将会被提供给租户以供定制时使用。

图2部分绩效考核领域分析模型

图3部分绩效考核

4.2基于领域的业务规则模板

通过对业务逻辑约束的分析，可以发现这些业务逻辑约束条件部分和动作部分都各自有着相似之处。

对这些相似之处进行抽象然后以结构化的自然语寿表述出来，就形成了业务规则模板。

对于依赖关系，也可以这样做。

例如，模板创建功能中包含这样一条业务逻辑：

如果考核模板中的指标数目少于4，那么系统将会提示模板不可用。

计分管理功能中包含这样一条业务逻辑：

如果考核任务中实际完成任务与预先分配任务的百分比大于120%，那么此项指标得分加10分。

从这两条业务逻辑约束中可以发现，它们的条件部分均符合这样的格式：

一个业务对象的属性满足特定的值。

因此，对这两条业务逻辑约束的条件部分进行抽象，然后以结构化的自然语言表示出来就形成了这样一条业务规则条件模板：

（业务对象）的（属性）满足（操作符）（值）。

同理，动作模板的设计也是如此。

分析所有的业务逻辑可变性后，本文设计的业务规则模板如表1所示。

表1业务规则模板

模板内括号中的内容表示需要租户去选择或者填写。

定义了八种类型的内容，它们分别是业务对象、属性、操作符、值、操作、信息、用户名以及邮件地址。

在这些类型中。

业务对象、属性以及操作的内容预先提供。

租户只需要按照各自的需求选择他们所需要的，而其他内容则需要租户自己填写。

在这些条件模板中，本文设计了一个模板来表示定量的时间信息。

然而这个模板不能转换成规则引擎可以识别的格式，需要由自己来处理这种形式的条件。

为了解决这个问题，在应用中定义了一个时钟调度函数。

为了能够处理规则引擎的工作内存中的业务对象，本文设计了另外三个动作模板：

a）插入（业务对象）；b）撤销（业务对象）；c）更新（业务对象）。

它们均与业务逻辑不相关。

4.3定制业务逻辑

采用可视化的规则定义器，如图4所示，用户可以通过选择和填写业务规则模板方便地定制出其所需要的业务逻辑。

图4可视化规则定义器

用户可以通过填写规则名称和规则描述，设置规则的优先级以及选择合适的模板来定制符合他们需求的业务逻辑。

通过这种方法，用户不需要具有编程知识，只需要了解企业的业务逻辑即可。

这种定制方法使得业务逻辑的定制变得简单方便，而且杜绝了业务逻辑的语法错误。

4.4转换和验证业务逻辑

当一条业务逻辑被定义好之后，它将会被送入到规则翻译器中。

规则翻译器会自动将业务规则的条件部分和动作部分转换成规则引擎可以识别的格式。

例如，租户自定义的一条业务规则的条件部分是“（考核轮次）的（考核状态）满足（=）（已开始）”，由于在实验中采用的规则引擎为JBoss旗下的Drools，转换后的Drools可以识别的格式为“Appraisalround（appraisalState==”已开始“）”。

当业务规则的条件部分和动作部分被转换好之后，将规则名称、属性、优先级以及转换后的条件和动作部分组成完整规则的形式加入到验证引擎中进行验证。

因为采用了业