1、概述【本文】
2、添加微信功能
3、输出
4、交互式输入
5、权限控制
6、本地测试
7、附录一：菜单特殊字符
8、附录二：微信机器人的开发过程
概述笔者一直面临着一个难题：越来越强的移动应用需求对jxTMS所强调的低成本快速定制形成了很大的压力。因为如果不能很好的整合移动前端的开发，就需要增加新的技术栈，就会和jxTMS所诉求的低成本开发以及热机刷新等快速定制能力也会丧失掉。
但最近再和一个兄弟讨论其业务需求时，由于是设备运维，其故障排查、巡检等作业都需要现场的业务办理，尤其是其维护人员流动性大，技能较为匮乏，实时的、针对性的维护知识支持就非常有价值了。所以笔者经过反复权衡最终以企业微信的内部应用接口开发了基于动态菜单的交互式对话型移动前端ui【以下简称微信机器人】，即后台根据业务逻辑向用户实时推送业务办理信息和操作菜单，用户现场输入并选择操作代码来实现业务办理。
微信机器人将所有的操作和本机器人辖下的文件组织成一个树状的目录，然后用户从根节点通过一层层的子目录序号选择来沿着这个目录树访问相应的操作功能或下载文件。
如上图中的容器表测试功能：
在菜单选择状态时，用户输入0，机器人会显示主菜单，即图片中的第一个提示输出主菜单中选3，机器人显示测试子菜单，即图片中的第二个提示输出测试子菜单中选1，机器人在后台请求执行【容器表测试】功能，并将执行结果【说明：from wxTestCT】输出，再显示【容器表测试】的菜单：由【接受与拒绝】两个操作组成，供用户选择对应的业务操作为了快速操作，操作功能的定位可以用快速缩写，即在菜单选择状态时，用户输入【031】，机器人会跳过上述的从主菜单出发沿着目录树层层显示定位而是直接在后台请求执行【容器表测试】功能。
从技术角度说，企业微信提供了相关的API，甚至包括源码，所以机器人的实现非常简单，关键的是实现后的机器人能最简单的融入到jxTMS原有的体系中，确保低成本快速定制。
需要解决的问题对于jxTMS来说，开发微信机器人最核心的就是两个问题：
功能组织与用户输入逻辑的协调显示界面的处理其中的功能组织就是上面所说的树状菜单，目前有六种菜单项：
主菜单，这是每个机器人应用的根，是用来锚定其它菜单项、收容本应用机器人所有操作的容器，是每个机器人整颗树状菜单的根菜单容器，就是如上图中的任务管理、测试这样的菜单项，它们唯一的功能就是收容其它菜单项，主要是用来组织整个应用的菜单，是树状菜单中的支干文件，是树状菜单的叶子，具体对应一个特定位置的公开文件，选择后可下载数据表，是树状菜单的叶子，对应一个web界面下的数据列表，用户选择了数据表菜单项，则执行相应的查询输出结果，并动态生成子菜单，供用户选择对应行所对应的详情查看并进一步操作容器表，是树状菜单的叶子，对应一个通常的web操作界面，可参考jxTMS的HelloWorld中【web界面的说明】一节的说明。用户选择了容器表菜单项，则显示相应的业务信息，并生成子菜单【如上图最后所示】，供用户查看或选择进一步操作命令，是树状菜单的叶子，对应一个操作，可参考jxTMS的HelloWorld中【动作按钮的响应函数】一节的说明。用户选择了命令菜单项，则根据用户操作的上下文执行相应的操作通过梳理出的这六个菜单项，可以看出用户的输入有两种：
菜单项选择各功能点执行所需要的输入，如新用户自助注册时需要录入姓名等注：有没有好奇上图主菜单中的子菜单序号是1、3，2去哪了呢？！
因为2就是新用户注册，已经注册过了的用户自然不会再看到了，而没有注册的新用户也只能看到一个新用户注册，其它操作都无法选择
机器人的输出则有三种：
菜单项，其中还应分为静态添加的子菜单【根据业务定义在注册机器人功能时就添加，不随业务执行而变动】；动态生成的子菜单，如查询自己要执行的任务，自然是有几个显示几个容器表与数据表的正常输出，就是正常的业务信息供给，只不过要从web界面的html诸控件显示转换为企业微信中的文本显示，要求尽量重用web中的界面设计以减少开发两套ui的工作量用户输入的提示，即web界面是用户根据业务显示自助填写输入信息，而微信机器人是交互式录入，即机器人先提示当前需要输入什么，然后用户再输入最后，就是所有业务系统都不可或缺的权限管控，要能无缝融合到jxTMS的角色与权限中。
附jxTMS目前已打包为docker容器，可以下拉jxTMS的docker镜像并按jxTMS使用示例尝试使用。
