VRS专家手册.docx

VRS专家手册 VRS专家手册目录1产品介绍41.1背景说明41.1.1适应需求变化是程序员最大的挑战41.1.2如何适应需求变化41.1.3为面向配置编程提供可视化设计工具51.1.4业务规则管理系统61.1.5 VisualRulesSolution的功能71.1.6 VisualRulesSolution的应用101.1.7 VisualRulesSolution核心技术121.1.8 VisualRulesSolution的特点151.1.9 VisualRulesSolution与web开发平台161.2 VisualRulesSolution组成171.2.1规则引擎171.2.2规则服务181.2.3数据库配置器191.2.4页面模板编辑器191.2.5页面配置器191.2.6规则配置器201.2.7规则库管理系统211.3规则包执行原理221.4 VisualRulesSolution安装232 VisualRulesSolution体验开发242.1关键知识点242.2 Hello World案例开发252.2.1案例描述252.2.2规则包开发252.2.3 Java类调用规则包452.2.4 C#类调用规则包573 VisualRulesSolution深入了解663.1规则配置器663.1.1工作空间、工程、规则组、规则包区别663.1.2对象库能传入的参数663.1.3规则的处理机制673.1.4内存表格的处理机制683.1.5规则的内置循环操作713.1.6 Null对象的处理713.1.7数据库单表操作的功能723.1.8自定义查询的设置733.1.9数据库表本地内存缓存743.1.10数据库表结构更新743.1.11规则执行轨迹的原理741产品介绍1.1背景说明1.1.1适应需求变化是程序员最大的挑战程序员在设计并开发软件系统时，碰到的最大的问题是软件需求不清或者需求的频繁变动。这些变动主要来自于几个方面：（1）前期项目调研时，需求不明确由于需求必须由真正的客户进行确认，并且要变革现有的管理流程和操作方式。程序员在项目前期调研需求时，客户又往往不能前瞻性的说明最终想要的系统是怎样的，因此前期调研的需求也往往是不明确、不完整的。这样导致的后果是，程序员需要加上自己的理解和设计，来补足和确定需求的不完整部分以及不明确部分。当程序员的理解和用户最终的需求不一致时，就会导致返工甚至项目的不能使用。（2）用户需求出现反复，不确定即使前期已经经过确认的用户需求，在真正最后交付使用的时候，仍有可能发生变化。变化的原因可能是用户的要求提高了，或者是程序员没有真正的理解用户需求。这些需求变化，总是发生在即将系统上线的时候，程序员会疲于修改这些需求而造成新的问题。（3）用户需求增加或者变更一般性的项目，系统上线之后，会有较长时间的稳定期。但随着信息化对企业业务管理的深入，某些需求的变更却会发生的非常频繁。比如企业管理流程的变化，产品定价策略的变化，分销返点政策的变化，促销方案的变化等等。这些变化有些是会定期发生变化的，而有些则是不时的在发生。需求的变更造成程序员大量的重复劳动，同时也让程序员为了满足新的需求，改动大量的原先的代码，造成了程序的不稳定等问题。总之，如何适应需求变化，是程序员在系统设计时最主要考虑的问题。1.1.2如何适应需求变化为了能够使开发的系统能够适应需求的变化，程序员做了大量的尝试，也将此作为评价自己系统的一个重要指标。目前程序员为了适应需求变化的尝试主要包括以下几个方面：（1）设计模式的应用设计模式是目前高级程序员，特别是系统分析员必备的技能之一。设计模式最根本的目的，就是为了适应变化，控制变化点。每个模式，都是为了将来系统扩展的考虑，而设计的系统架构。设计模式有几个根本的原则：设计模式主张面向接口编程，而不是面向实现编程。就是希望将来具体的实现发生变化时，不会影响到其他调用该功能的部分。设计模式主张优先使用对象组合，而不是使用类继承。就是因为使用类继承，会是将来需求增加时，使得类的数量会急剧增加。而使用组合，则会大大减少类的数量。设计模式主张发现并封装变化点，就是希望能够事先考虑到将来可能变化的地方，而将其封装起来。设计模式主张类对扩展开放，对修改关闭。就是希望将来需求变化时，不要通过修改现有的类来实现，而是通过扩展新的类来进行实现（2）配置化编程的应用由于采用编码方式，使得程序很难清晰的定位出程序间的接口等关系。为了能够使得程序尽可能的松耦合，现在推出的一些框架，就是希望将程序间的相互调用，通过配置的方式实现。比如Spring，通过XML配置文件，来实现接口的具体实现的调用。另外想Struts等，也是通过XML配置文件，来定义具体的页面跳转等。Hibernate等也是通过XML结构，来定义数据库的表结构等信息。这些工作都是希望能够将变化通过修改XML文件来实现，而不是通过修改程序代码的方式来实现。（3）面向配置开发平台的应用为了能够快速适应将来的这些变化。也可以通过构建开发平台。通过尽可能的复用组件的方式，来实现快速的开发新的应用，同时也加快了需求变化时相应的修改的工作。以上这些都是现在程序员为了满足需求变化而做的努力。都希望能够设计一个好的系统架构，以便将来需求变化时，能够尽可能少的去修改程序，尽可能快的适应变化。1.1.3为面向配置编程提供可视化设计工具面向配置编程使得程序员将工作从原来的完全的编码，转到要书写大量的XML文件上来。如何管理这些XML文件，以及如何简便的开发和维护这些XML文件，是目前碰到的一个新问题。很多时候，发现当不用程序语言，而采用XML语言来进行一些实现，好像也只是转换了一种语言而已，而不是根本性的减少了工作量，而且有时候书写XML文件反而不能像程序一样，有编辑器来自动做严格的语法校验，因此开发的时候也容易出问题。因此需要为这些XML文件，提供一个简便的可视化的设计工作。让程序员通过可视化工具，可以比较方便的进行配置，并且这些XML文件也是自动生成并管理的。比如struts等，就提供了可视化的图形设计器，通过拖拉等方式，实现了对XML文件的管理。程序员根本不用管生成的XML究竟是怎样的，直接使用图形化设计器即可。比如Hibernate等，也是提供了自动生成工具，可以来生成这些XML文件，程序员也不用再去关心怎么去编写这些文件。这些工具的提供，都大大节约了程序员的工作时间。但是虽然有这些工具的提供以及充分借鉴了设计模式等思想的好的系统架构的实现，程序员在面对真正客户需求变化时，还是显得力不从心，感觉客户永远都在挑战程序员的极限。当程序员可以满足用户的需求变更时，会发现用户需求变更的频率也相应的提高了，用户也总是会不断的提出新的要求等。因此，我们需要更加简单和直接的工具，可以直接管理客户需求，可以最快的适应需求的变化。1.1.4业务规则管理系统将用户的业务规则分门别类进行管理，同时提供可视化的配置工具，让最终用户可以直接配置和实现规则。使得用户可以了解业务规则的实现，并且可以直接的对业务规则进行修改。这种方式可以最快的满足用户需求。要采用业务规则管理系统来全面的管理用户的业务规则，就需要很清晰的区分程序中的逻辑以及业务相关逻辑。要采用业务语言来描述业务逻辑，并且可以和程序逻辑无缝的加以衔接。从技术结构上分析，要实现一个系统，特别是基于数据库的B/S方式的应用系统，最主要是实现好表现层、业务逻辑层和数据库层。这几个层面的实现都有所侧重。表现层，主要专注于如何显示数据给用户，以及如何接收用户的输入。在表现层中，更多是控制页面的样式和布局等，以及进行页面组件的控制。至于如何从服务器端取得数据，以及如何将录入的数据存储到服务器上。这些是后台业务逻辑层和数据库层考虑的问题。特别是目前Ajax技术的应用，更加区分了表现层和业务逻辑层的界限。界面层通过DHTML和JavaScript等来控制界面的显示，数据的存取等全部通过Ajax传递到服务器上。界面通过JavaScript来对接收到的数据进行处理。由于目前Ajax以及其他RIA技术的普及，在界面层更多的关注于基于某个框架的应用，比如现在流行的JQuery，ExtJS，Dojo，Flex等，这些框架简化了很多界面层的开发工作，也使得程序员可以更加方便的实现各种易用性强的操作界面。为了让界面层能够制作界面效果和易用性强的功能，对于数据的处理等，需要尽量放到业务逻辑层来实现。界面只管显示效果、格式以及一些基本的校验等。业务逻辑层的侧重和界面层的侧重完全不同，界面层需要提供给程序员尽可能强大的功能等，让其设计出非常好的效果。而业务逻辑层，不用再管数据的格式等。数据的类型和格式都可以是确定的，其侧重就是如何灵活的设置数据处理逻辑。这些逻辑有些是和业务相关的，有些是和具体的技术实现相关的。通过规则引擎和规则配置器是比较好的实现方案。其可以采用业务语言来展现业务逻辑的实现，并且可以实现业务逻辑变更的实时应用。因此业务逻辑层的重点就是如何采用业务语言来描述业务逻辑，并且实现业务逻辑的实时可变。数据库层实现就是要采用对象化的方式来操作数据库层。存储数据库的代码，最好是自动生成的，业务逻辑等，只需要通过接口以及参数，就可以实现对数据库的操作。目前的Hibernate、iBatis等都是通过采用对象化的类来实现对数据库的操作，方便了业务逻辑层的调用。从传统意义上来说，业务规则管理系统需要能够管理业务逻辑层中的和业务相关的商业规则，能够将这些规则从业务逻辑层中提取出来，专门有规则配置器来进行定义和管理。但是在实际的应用中，经常会发现商业规则和程序规则在很多时候不能很好的进行区分，另外有很多逻辑即可以通过数据库表来加以实现，有可以通过决策表等来加以实现。因此商业逻辑和数据库层有些时候，也很难区分开来。为了更方便的来实现和管理商业规则，VisualRulesSolution扩展了规则引擎和规则配置器能够实现的业务逻辑的范围。除了能够定义一般意义上的商业规则，还能定义更加复杂的和数据库层相关的处理规则等。1.1.5 VisualRulesSolution的功能为了能够更全面和简便的管理业务规则，VisualRulesSolution的规则引擎能支持更广泛的业务逻辑实现范围。就目前的规则引擎，缺省情况下，规则引擎提供了以下的实现：（1）常规值对象常用的数值型、字符串、列表、Map、日期等都作为常规类型支持，规则可以直接按照这些类型进行处理。（2）数据库对象包括数据库表对象、视图对象、查询对象、SQL语句对象、存储过程对象、码表常量对象等。这些数据库对象，都可以直接根据数据库中的结构自动生成该对象的结构，以及对该对象的处理方法等。（3）内存表格对象为了能够更方便的对批量数据进行处理，支持了内存中的数据表格，以便对批量数据进行更加方便的处理。内存表格支持表格的列操作，汇总，匹配，追加等操作。（4）XML对象规则引擎支持了XML对象的实现。目前的实现基于JDom 1.0，在实现XML对象时，可以对XML节点的创建、赋值、属性等有更加简便的操作。（5）SOAP对象规则引擎可以直接操作SOAP对象，自动处理SOAP的交互等。规则可以直接和SOAP对象，传递参数和调用等。（6）Excel对象规则引擎基于POI实现了对Excel的操作。包括Excel工作簿，Excel的表格等。其中为了更加方便的操作Excel表格中的数据，特别提供了表格状的数据，以及纵横表格的数据处理。更加方便的实现对Excel的存取等操作。在规则配置器中，为了更多更方便的操作这些规则引擎支持的对象，规则配置器也特别的增加了相应的功能：（1）对象库定义对象库中可以定义常规对象、外部调用以及常量调用等。对其中常规对象的操作，可以定义各种公式，比如取日期的年份、月份等方法。另外对于string、list、date等对象的操作，还可以直接取得对应java的类实现下所有的方法。对于外部调用，如果某些功能，采用规则配置不方便实现。就可以通过程序书写对应的代码，然后通过外部调用。常量调用可以为一些常量，比如0、1等定义特殊的含义。（2）数据库对象定义可以通过数据库的信息，直接取得数据库连接对象。根据这个数据库连接对象，可以直接执行SQL语句等。在数据库连接对象下面，可以添加数据库表对象、视图对象、查询对象、存储过程对象等。其中数据库表对象、视图对象、存储过程对象，都可以直接从数据库中取得所有的表信息，然后选择添加即可。选择了数据库表对象之后，表的字段名称、类型、描述等都可以直接从数据库中取得，并且会自动添加增加、删除、修改、查找的方法，以及对结果集的下一条、上一条、根据字段取值等方法。同时还可以看到表的数据等。操作非常简便。对于数据库查询对象，直接根据select语句可以直接取得select查询返回的结果集的字段信息，以及操作结果集的各种方法。对这些数据库对象的操作，都可以自动从数据库中读取，也会根据数据库变更情况进行调整。（3）内存表格对象定义对于内存表格对象，分为列信息以及数据信息。列信息在对象库中定义，数据信息在规则执行时控制，同时在对象库中，也可以看到规则执行后的内存中表格数据。由于用户一般会将一些表格数据，采用Excel来进行存储。因此规则配置器提供了导入导出功能，实现从Excel中直接读取信息，以及数据，实现数据的初始化操作。在和Excel进行交互时，要求Excel中第一个Sheet保存表格信息。并且第一行保存了列信息，第二行开始，才存储数据信息。在读取列信息时，还会根据第二行存储的数据，自动设置列的类型。（4）XML对象定义可以直接根据XML结构的描述，直接生成XML对象，包括根节点和子节点等信息。并且自动生成了操作XML节点的属性，文本等方法。（5）SOAP对象定义SOAP对象可以通过直接访问SOAP的地址，得到SAOP服务对外提供的接口以及参数等信息。自动生成对SOAP对象的参数操作以及执行调用等方法。（6）Excel对象定义在对象库下面可以直接定义一个Excel工作簿对象，在工作簿对象下面，可以定义Sheet对象，Sheet对象分为三种，一种是常规对象，这可以直接根据行号、列号操作单元格。一种是表格状Sheet，这种可以通过下一条等操作，取得某行数据，并且根据列号操作单元格。另一种是纵横表格状Sheet，这种可以直接通过下一条等操作，直接取得下一个单元格。规则配置器除了支持更多的处理对象之外，还对业务逻辑的定义，扩展了功能。目前的规则定制，具有以下一些功能：（1）规则集实现在实际的规则处理中，需要分类管理规则，同时需要对规则的流转进行控制。规则集的应用，可以实现规则的分类，实现子规则，实现规则循环。规则集可以将所有的规则，以树状的形式进行管理。（2）多种决策表决策表包括几种样式，一种是表格状决策表，这种决策表纵向和横向的上面都是条件，中间部分才是赋值处理。还有一种是多维决策表，每个维度都是条件，并且需要设置满足每个维度条件之后的赋值操作等。另一种是关联决策表，关联决策表可以对前一维度，设置单独的第二个条件，并且设置满足条件之后的赋值操作。（3）规则的多种方式操作规则除了常规的条件和动作之外。还增加了初始化操作、否则操作、否则如果操作、异常操作等。另外规则还支持根据表格数据内置循环等属性。同时还支持互斥规则、失效规则；支持规则有效期；支持规则轨迹记录等。（4）规则流程可以采用流程图方式来定义规则的执行顺序等。可以在流程中设置条件等等操作。目前，VisualRulesSolution的规则配置器已经可以支持定义绝大多数业务逻辑层和数据库层所需要定义的业务逻辑和操作。同时为了方便前端界面等方便的调用规则中定义的逻辑。还自动生成了可供Ajax方式调用的jsp文件，甚至前端的操作界面的代码。1.1.6 VisualRulesSolution的应用VisualRulesSolution提供的这些功能，可以快速的实现用户所需要的系统，可以随时的修改用户的业务规则，以便快速的变更系统以适应新的业务需求。但在目前的项目开发中，采用了众多的组件，众多的系统架构的情况下，究竟在哪些地方使用VisualRulesSolution产品，完成那些方面的工作。这是程序员必须要考虑的问题。就VisualRulesSolution完整的产品功能来说，可以采用此工具完成整个项目的制作，包括实现页面层的代码。但是实际的应用中，根据程序员自身的技术特点，以及公司本身积累的一些组件和经验，并不会全面的采用VisualRulesSolution来实现整个项目。因此以下是可以考虑的VisualRulesSolution的应用场景：（1）经常变更的商业规则一般性的类型校验、格式校验、范围判断等逻辑，都可以通过配置方式自动实现，对于表的操作，其编写的代码也不是太复杂，而且变动也不会太频繁。但是某些也业务相关的商业规则，却可能会定期的发生变更，比如一个季度或者一个月变化一下。像一些奖惩机制、促销策略、计费规则、新产品等。对于这部分商业规则，不适合采用程序代码或者XML配置文件等方式来实现。因为这些方式实现，最终用户必须依赖程序员才能对规则进行修改，而且响应速度也非常的慢。要实现这种应用，就需要在程序中编写调用规则引擎的代码。调用规则引擎有多种方式，一种是通过java类库调用，一种是通过Socket通讯，还有一种是通过SOAP服务调用。（2）后台逻辑的配置实现软件系统在设计时，必须考虑将来用户可能会有的变化，或者允许其发生变更。这些变化点，必须加以封装，并且使其影响最小。但是，在系统设计的过程中，并不能将所有的变化点，都能采用好的设计来加以封装。因为最终系统都是围绕数据库存储来进行，有些结构设计必须依赖数据库表结构的设计。当设计的表结构并不能满足将来业务需求的变更时，就必须去修改数据库表结构。或者修改某些码表形式的数据。采用VisualRulesSolution可以让数据库结构的变化，像业务逻辑的变化一样简单。使得数据库结构发生变化时，影响也是最小的。采用这种方式实现时，可以考虑直接通过Ajax来调用后台逻辑，并且返回需要取得的数据等。（3）B/S方式的完整功能的实现VisualRulesSolution提供了多种web页面的模板，根据这些模板，可以生成用户操作的web页面源代码，无需做程序改动，就能实现用户界面层。缺省模板中，已经可以实现录入、查询、列表等多种功能界面。用户也可以通过增加web页面模板，来支持生成更多的操作界面。采用VisualRulesSolution来实现系统可以加快程序员实现整个系统，可以实现对业务规则的管理，简化业务逻辑变更的工作，减轻系统维护的工作。使得系统可以适应将来需求的变化。1.1.7 VisualRulesSolution核心技术VisualRulesSolution产品最关键的就是实现一个业务语言和程序语言的对应，并且自动编译对应的程序代码，以及实现代码的动态加载。业务逻辑举例：举个最简单的例子：我们计算电信资费逻辑为：如果消费时间在晚上10点之后，并且在早上7点之前那么费用等于通话时间0.3元。如果消费时间在早上7点之后并且在晚上10点之前那么费用等于通话时间0.6元。Java实现：采用java语言实现，一般的实现如下：定义变量：Date xiaofei ;/消费时间double tonghua ; /通话时间double feiyong ; /费用实现逻辑：if ( xiaofei. getHours() =22 ) feiyong = tonghua*0.3 ;if ( xiaofei. getHours() 7)& xiaofei. getHours() 22) feiyong = tonghua*0.6 ;Visual Rules实现：在VisualRulesSolution中，对java语言的实现进行本地化对应：在对象库中，定义三个传入传出变量：变量1：变量名xiaofei ，类型为date ，中文名称为消费时间，java中对应为 xiaofei。添加一个xiaofei变量的子函数 getHours()。定义如下：变量名为getHours()，类型为int，中文名称为消费时间段，java中对应为xiaofei.getHours().变量2：变量名tonghua，类型为double ，中文名称为消费时间，java中对应为 tonghua。变量3：变量名feiyong，类型为double ，中文名称为消费时间，java中对应为 feiyong。在规则包定制中，新建两个规则：规则1：新建两个条件和一个动作。选择对象库中变量名为getHours()的对象，作为条件1的被判断值，选择判断符为小于等于，输入常量7作为判断值。选择对象库中变量名为getHours()的对象，作为条件2的被判断值，选择判断符为大于等于，输入常量22作为判断值。设置两个条件之间的关系为或者关系。选择动作为赋值类型，选择对象库中变量名为feiyong的对象作为赋值动作的被赋值对象，选择变量名为tonghua的对象并且常量0.3作为所赋的值。规则2：新建两个条件和一个动作。选择对象库中变量名为getHours()的对象，作为条件1的被判断值，选择判断符为大于，输入常量7作为判断值。选择对象库中变量名为getHours()的对象，作为条件2的被判断值，选择判断符为小于，输入常量22作为判断值。设置两个条件之间的关系为并且关系。选择动作为赋值类型，选择对象库中变量名为feiyong的对象作为赋值动作的被赋值对象，选择变量名为tonghua的对象并且常量0.6作为所赋的值。Visual Rules逻辑这样，VisualRulesSolution中显示的规则包逻辑为：如果消费时间段小于等于 7 或者消费时间段大于等于 22 那么费用等于通话时间0.3元。如果消费时间段大于 7 并且消费时间段小于 22 那么费用等于通话时间0.6元。此逻辑显示界面其实和java语言完全一一对应，最终生成的代码也一致。生成代码为：/* * 规则 * 如果: * 消费时间段小于等于7 * 或者消费时间段大于等于22 * 那么: * 费用 = 通话时间0.3 */private int excuteRule0() throws Exception try if ( xiaofei.getHours() = 22 ) feiyong = (double)tonghua * 0.3; catch (Exceptione) throw e ; return M_RETURN_DEFAULT; /* * 规则1 * 如果: * 消费时间段大于7 * 并且消费时间段小于22 * 那么: * 费用 = 通话时间0.6 */private int excuteRule1() throws Exception try if ( xiaofei.getHours() 7 & xiaofei.getHours() 程序-旗正商业规则定制平台规则配置器”启动规则配置器。启动后，关闭欢迎首页，进入到缺省的开发工作空间。通过规则配置器的测试步骤包括创建工程、创建规则包、定义对象库、定义规则、发布规则包、测试规则包、创建web页面、web方式测试规则包。以下分别讲述这些步骤具体的操作方法：2.2.2.1创建工程（1）点击菜单栏“文件”下的子菜单“新建规则工程”，或者点击工具栏上的按钮，弹出如下图2-2-2-1-1所示窗口：图2-2-2-1-1新建工程（2）输入“体验开发”作为工程名并选择规则工程的存储路径，如果不需要改变工程存储路径，则直接点击“确定”按钮即可，是对同名工程的处理，如果需要覆盖则勾选上，如下图2-2-2-1-2所示：图2-2-2-1-2录入工程信息（3）点击“确定”后，规则编辑器中就会出现“体验开发”的规则工程，如下图2-2-2-1-3所示：图2-2-2-1-3新建完成的工程通过windows的资源浏览器，也可以看到已经新建的规则工程的存储位置，如下图2-2-2-1-4所示：图2-2-2-1-4工程目录结构如上图2-2-2-1-4所示，可以看到在VisualRulesSolution安装目录下的Samples目录里面，新建了一个“体验开发”的目录，在此目录下面有一个default.prj文件，以及三个目录分别为bak、data和test。其中bak目录将存放此工作下所有自动保存的规则包以及每次备份产生的规则包备份文件，data目录将存放在此工程下新建的规则包，而test目录则用来存放规则工程测试数据。其中，以.auto结尾的文件，都是定时自动保存的规则包，当编辑器异常退出后，会提示是否恢复自动保存的规则包。以.rpk1这种类型结尾的规则包，都是每次备份产生的规则包备份文件。当选择了恢复规则包历史时，会读取这些规则包备份文件，并且根据所选进行恢复。如果通过编辑器恢复失败，可以手工做恢复操作。只需根据文件的修改日期，找到需要恢复的文件，将其后缀改成.rpk之后，然后覆盖data下面对应的文件即可完成恢复工作。2.2.2.2创建规则包（1）右键点击“体验开发”规则工程，在弹出的菜单中选择“新建规则包”，如下图2-2-2-2-1所示：图2-2-2-2-1新建规则包（2）点击“新建规则包”后，在“体验开发”工程下面就会新建一个缺省名为“规则包”的规则包，可以将其直接改名为“hello”，如下图2-2-2-2-2所示：图2-2-2-2-2重命名规则包2.2.2.3定义对象库（1）然后展开“hello”规则包，点击规则包下面的“对象库”，在中间的编辑窗口中，点击添加按钮，并且在弹出窗口中输入需要添加的变量名、类型和显示名称，如下图2-2-2-3-1所示：图2-2-2-3-1添加变量（2）同理添加另一个变量，名称为“welcome”，类型为“string”，显示名称为“欢迎辞”，变量添加完成后的窗口如下图2-2-2-3-2所示，在该窗口中可以通过双击相应项来修改变量的名称、类型、显示名称、分组、传递方向。图2-2-2-3-2变量添加完成2.2.2.4定义规则（1）右键点击“hello”规则包，然后在弹出的菜单中，选择“添加规则”，如下图2-2-2-4-1所示：图2-2-2-4-1添加规则（2）点击“添加规则”后，会在“hello”规则包下面新建一个缺省名为“规则”的规则，将其名称修改为“返回欢迎辞”。点击“返回欢迎辞”规则后，在中间的规则编辑窗体，设置条件和动作。首先添加“添加条件”按钮，如下图2-2-2-4-2所示：图2-2-2-4-2