修改后端教案

后端项目开发/后端项目整体介绍.md

-## 后端项目整体介绍
-## 后端项目整体介绍
+# 后端项目整体介绍
+# 后端项目整体介绍
 
-#### 项目结构介绍
+## 项目结构介绍
 
 gjjs-business模块文件结构
 
 ![backenddev1](../assets/images/backenddev1.png)
 
 
-#### 项目流程介绍
+## 项目流程介绍
 
-##### 1.请求流程
+### 1.请求流程
 
 ![image-20210918165941920](../assets/images/gjjs-common2.png)
 
@@ -17,7 +17,7 @@ gjjs-business模块文件结构
 
 
 
-##### 2.Service与Rule如何调用
+### 2.Service与Rule如何调用
 
 1）AbstractRouteService是service层最上层抽象类，对一些基本公共方法(init、executeRule、executeDefault等，这些方法基本每个交易都会去调用)做了实现，保证执行流程的统一，通过getEmitter这个抽象方法来实现多态（子类通过实现这个方法来处理不同业务逻辑，不用去关心具体的执行流程）
 
@@ -31,7 +31,7 @@ gjjs-business模块文件结构
 
 ![](../assets/images/hdservicerule1.png)
 
-##### 3.Emitter的方法分类
+### 3.Emitter的方法分类
 
 RuleEmitter大概有4类方法，分别是
 
@@ -43,9 +43,9 @@ executeDefault （default rule）
 
 executeCheck (参数、数据校验类rule)
 
-##### 4.消息体格式说明
+### 4.消息体格式说明
 
-###### 	请求消息体
+#### 	请求消息体
 
 请求消息体是一个json格式数据，数据格式形如
 ![](../assets/images/qqxxt2.png)
@@ -63,7 +63,7 @@ executeCheck (参数、数据校验类rule)
 
 ![请求实体类](../assets/images/请求实体类.png)
 
-###### 	响应消息体
+#### 	响应消息体
 
 响应消息体是一个json格式数据
 结果成功响应数据格式形如
@@ -101,7 +101,7 @@ executeCheck (参数、数据校验类rule)
 
 
 
-##### 5.VO的规范
+### 5.VO的规范
 
 VO类是前后端数据请求和响应的实体类，VO有一个共同父类VO（BaseVO），字段说明如下：
 
@@ -110,9 +110,9 @@ VO类是前后端数据请求和响应的实体类，VO有一个共同父类VO
 VO按照交易进行划分，一个交易对应一个VO（比如信用证开证交易对应VO是DitopnVO）,VO类使用了lombok插件，不需要set get方法，字段用RelPath注解区分是请求字段还是响应字段（默认没有注解，代表dir属性值是DirType.BOTH,及请求和响应都需要该字段；如果只是请求字段，dir属性值是DirType.IN；如果是相应字段，dir属性值是DirType.OUT）,如图：
 ![](../assets/images/vogf1.png)
 
-##### 6.前后台事件关联方式
+### 6.前后台事件关联方式
 
-###### 调用普通Module下事件
+#### 调用普通Module下事件
 
 例如：
 
@@ -128,7 +128,7 @@ if (rtnmsg.respCode == SUCCESS) {
 
 (2) 同样的，账务面板中的”细节”按钮,对应（Module）setmod中的det事件。使用··``` await this.executeRule(“setmod.det”)```方式调用。
 
-###### 调用ModuleList选中行事件
+#### 调用ModuleList选中行事件
 
 例如：账务 Own Commission/Charges 列表，对应模型setmod/setfeg/setfel（ModuleList）。每行数据对应ModuleList中的一个setfel实例。
 
@@ -151,7 +151,7 @@ if (rtnmsg.respCode == SUCCESS) {
 }
 ```
 
-###### 事件在普通模型下，但实际处理ModuleList选中行
+#### 事件在普通模型下，但实际处理ModuleList选中行
 
 例如：保证金模块中的保证金列表。对应数据模型为：（ModuleList）liaall/liaccv/liaccvg ；但删除操作按钮的对应事件是在（Module）liaall/liaccv模型下的del
 
@@ -173,7 +173,107 @@ if (rtnmsg.respCode == SUCCESS) {
 }
 ```
 
-###### 事件在普通模型下，但实际处理IStream选中行
+#### 事件在普通模型下，但实际处理IStream选中行
 
 此种情况参考"ModuleList选中行"的处理，只需把selDst的值指向IStream即可。
 
+## 运行机制介绍
+
+### 1、缓存
+
+​		MdaContext作为交易的上下文，在交易初始化时生成，在页面中一个交易的初始化后，后面的请求操作都应使用该MdaContext，故而将MdaContext在生成时放入缓存中，key是UUID生成的随机字符串串pageId。在后续的进入交易时，会先根据pageId取出context，并将context放入ThreadLocal，供后续的方法使用；若取出的context为空，则为执行init初始化交易，生成context并放入ThreadLocal。
+
+### 2、Context
+
+​		MdaContext实现IContext接口，每个交易都有一个MdaContext，在页面初始化时，会执行init操作，生成一个MdaContext，该context存有交易的根模块、交易名、配置信息、快照、错误信息等，通过ThreadLocal来传递。
+
+### 3、sysStream
+
+​		SysStream是一个StreamImpl实例，StreamImpl实现了IStream接口，IStream接口主要是控制字节数组的输入流和输出流。sysStream存放的交易中涉及到的各个模块。
+
+### 4、init
+
+#### （1）初始化规则
+
+​        在系统尝试执行可选全局过程`EnterTransaction`之后和执行可选全局过程`InitTransaction`之前，在事务启动时执行此类规则。
+事务中所有模块实例的 INIT 规则都是递归执行的。每个模块首先执行所有相关模块的 INIT 规则（只有当底层模块中的所有 INIT 都被调用时才会执行），然后是它自己的。因此，事务的 INIT 规则在相关模块的所有其他 INIT 规则之后执行。
+
+#### （2）事务启动期间规则的执行顺序
+
+1.如果存在，则调用全局过程“SUB EnterTransaction”。
+2.执行事务中所有模块实例的 INIT 规则。
+3.如果已定义，则调用全局过程“SUB InitTransaction”
+4.执行事务中所有对象的 DEFAULT 规则。
+即：EnterTransaction -> Module Inits -> InitTransaction -> Defaults
+
+
+
+### 5、executeCheck
+
+#### （1）检查规则
+
+​        executeCheck用于验证字段字和内容的一致性。可以为（列表的）字段或模块定义检查规则。
+
+#### （2）触发时机
+
+​		1.当使用键盘按下"Enter"或者失去焦点时
+​		2.当为（列表）模块或字段调用 CheckAll 函数时
+
+#### （3）其他规则
+
+​		一般情况下，检查规则不能修改任何字段的值。
+
+
+
+### 6、executeRule
+
+#### （1）触发时机
+
+​		前端事件执行executeRule时触发，需要至少提供一个路径，后端根据此路径执行相应的rule后返回。若存在多个路径，则顺序执行
+
+#### （2）执行顺序
+
+​		EVENT --> DEFAULT(s) --> CHECK(s)。当存在多个路径时，每个路径都属于独立的模块，只有一个路径的所有EVENT、DEFAULT、CHECK执行完成后下一路径才会顺序被执行。
+
+
+
+### 7、executeDefault
+
+#### （1）默认规则
+
+​		所有Default规则在事务开始时执行3遍（作为事务启动序列的最后一步）。此外，只要前端任意字段的值发生改变，就会执行默认规则
+
+### 8、set方法触发defaultRule机制
+
+​		执行任意字段的set方法时，若传过来的新值与旧值不同，则在部分情况下需要执行对该字段进行了引用的所有default规则。
+​		1.该机制是否触发由DCR开关控制，详情请见`DCR说明`
+​		2.字段被引用的default规则由`resources/defaultRule`中定义的码表获取
+
+
+
+### 9、队列执行
+
+#### invokeExpress产生的队列
+
+##### （1）产生
+
+​		由invokeExpress方法产生。当invokeExpress方法被调用且delay参数值不小于0时，该方法中需要被执行的rule会被加入到"tdContextPOSTQUEUE"队列中。
+
+##### （2）执行清空
+
+​		1.Init过程产生的队列，会在初始化结束前作为最后一个步骤被执行，且执行完成后清空
+​		2.Vo给模型赋值产生的队列，在赋值完成后被立即执行，且执行完成后清空
+​		3.执行Rule产生的队列，会在执行Rule过程结束前作为最后一个步骤被执行（若存在多个Rule，则在每个Rule的最后均会执行），且执行完成后清空
+
+#### set方法触发的DefaultRule队列
+
+##### （1）产生
+
+​		详情请看`set方法触发defaultRule机制`，该机制产生的方法不会被立即执行
+
+##### （2）执行
+
+​		1.请求为executeCheck，则作为每个executeCheck方法的最后一个步骤被执行
+​		2.请求为executeDefault，则作为每个executeDefault方法的最后一个步骤被执行
+​		3.请求为executeRule，则作为每个executeRule方法中invokeExpress产生的队列被执行前的前一个步骤执行
+