Change Rules

@@ -6,6 +6,8 @@
 
 
 
+---
+
 ### 1. 各应用的定义
 
 为了能够让各应用在一个Topic中发布或订阅消息，就需要对各个应用作一个规范的定义。以下是针对现有的产品作出英文名称的定义:
@@ -31,57 +33,83 @@
 
 #### 2.1  建立Topic
 
-- Topic 命名方法：{客户编号}-{环境编号}，表示不同的客户在不同的环境所使用的Topic；
+- 任何应用如果需要向Topic上发布消息，必须负责建立此Topic的责任（注：多个应用如果需要向一个Topic发布消息，则第一个发布的建立此Topic) 
+
+- 任务应用建立Topic并使用其发布消息时，**必须**编写相关文档并说明消息的业务类型、消息体的结构说明和示例。
+
+- Topic 命名方法：**{企业编号}-{环境编号}**，表示不同的客户在不同的环境所使用的Topic；
 
-- 客户编号：取客户官方英文名并去掉除英文字母外的其他字符，然后转成大写；
+  ​
 
-  例如：星期六的官方英文名是st-sat，因此星期六的客户编号为STSAT；
+- 企业编号：取企业官方英文名并去掉除英文字母外的其他字符，然后转成大写；
 
-  ​	    兴记的官方英文名是stellafashion，因此兴记的官方编号是STELLAFASHION。
+  > 例如：星期六的官方英文名是st-sat，因此星期六的企业编号为
+  >
+  >  兴记的官方英文名是stellafashion，因此兴记的企业编号是STELLAFASHION。
 
-- 环境编号：使用TEST代表测试环境，DEMO代表演示环境，PRODUCTION代表正式环境，DEV代表开发环境。
+- 环境编号：
+
+  >  使用TEST代表测试环境，DEMO代表演示环境，PRODUCTION代表正式环境，DEV代表开发环境。
 
 - 以下为Topic 名称的几个例子：
 
+  ```
   STSAT-TEST：星期六测试用Topic；
-
   STELLAFASHION-PRODUCTION：兴记生产用Topic 
+  ```
 
 #### 2.2 删除Topic
 
-- 遵循谁建立谁删除的原则；
+- 遵循谁发布谁删除的原则.
 
-### 3. 在Topic上发布消息
 
-- 在Topic上发布消息时，除了消息体外，一定要设置一个标签，以便其他应用能够过滤和识别消息类型；
 
-- 标签命名方法：{应用名称}-{业务名称}；
+---
+
+
+
+### 3. 在Topic上发布消息
+
+- 在Topic上发布消息时，消息**必须**标注标签，以便其他应用在收到消息时能够过滤和识别消息类型；
 
-- 应用名称：即 **1** 中所列出的产品英文名称；
+- 标签命名方法：**{应用名称}-{业务名称}**；
 
-- 业务名称：根据各应用自己的业务来定义，使用做多12为的大写英文字母；
+  * 应用名称：即 **1** 中所列出的产品英文名称；
 
-  例如： 雇员相关的消息，业务名称可以定义为EMPLOYEE
+  * 业务名称：根据各应用自己的业务来定义，最多12个字符的大写英文字母；
 
-  ​            账户相关的消息，业务名称可以定义为USER
+    ```
+    示例：
+    雇员相关的消息，业务名称可以定义为EMPLOYEE
+    账户相关的消息，业务名称可以定义为USER
+    ```
 
 - 以下为标签的几个例子：
 
-  POR-EMPLOYEE：门户发布的雇员信息
+  ```
+  POR-EMPLOYEE ：门户发布的雇员信息
+  CRM-POINT    ：CRM发布的积分信息
+  ```
+
+- 发布消息的消息结构体，各个应用自定义，但是结构体必须发布出gitbook形式，以MD文档进行说明。
+
+
+
+---
+
 
-  CRM-POINT：CRM发布的积分信息
 
 ### 4. 在Topic上订阅消息
 
 #### 4.1 订阅名称
 
-- 订阅名称命名方法：{环境编号}-{订阅者应用名称}-{客户编号}-{发布者应用名称}-{业务名称}；
+- 订阅名称**建议**命名方法：**{环境编号}-{订阅者应用名称}-{企业编号}-{发布者应用名称}-{业务名称}**；
 
 - 环境编号：订阅者环境编号，其值与 **2.1** 中的环境编号一致；
 
-- 订阅者应用名称：即 **1** 中所列出的产品英文名称；
+- 订阅者应用或服务名称： **1** 中所列出的产品英文名称，或应用中的各服务模块名称。长度控制在20字符以内。
 
-- 客户编号：与 **2.1** 中的客户编号一致；
+- 企业编号：与 **2.1** 中的客户编号一致；
 
 - 发布者应用名称：即 **1** 中所列出的产品英文名称；
 
@@ -89,27 +117,34 @@
 
 - 以下为订阅名称的几个例子：
 
+  ```
   DEV-YZ-STSAT-POR-EMPLOYEE：云助开发环境订阅了星期六门户发布的雇员消息
-
   PRODUCTION-DZ-STELLAFASHION-CRM-SITE：店助生产环境订阅了兴记CRM发布的网点消息
+  ```
+
+  ​
 
 #### 4.2 接收端地址
 
-- 推送类型为http
+- 推送类型为http或https
 
 
 - 可以理解为收到推送消息的回调地址，需要个应用自己开发API接口；
 
-- 为了让回调地址可以最大程度重用，可以在创建订阅时在url上带上自己需要的参数；
+- 为了让回调地址可以最大程度重用，**建议**在创建订阅时在url上带上自己需要的参数；
+
+  >  http://emp.api.dev.qingger.com/mns/topic/stsat/por/employee  
 
-  例如：http://emp.api.dev.qingger.com/mns/topic/stsat/por/employee  中，
+  以上，http://emp.api.dev.qingger.com 为接口域名，/mns/topic为接口路径，/stsat/por/employee为自定义参数，分别可以帮助各应用确定公司客户，发布者以及业务类型。
 
-  http://emp.api.dev.qingger.com 为接口域名，/mns/topic为接口路径，/stsat/por/employee为自定义参数，分别可以帮助各应用确定公司客户，发布者以及业务类型。
+  ​
 
 #### 4.3 重试策略、消息推送格式
 
-- 重试策略：使用退避重试
-- 消息推送格式：统一使用JSON格式
+- 重试策略：按照需求定义即可
+- 消息推送格式：建议使用JSON格式，但是如果为其它格式，则需要应用文档进行说明。
+
+