当项目里的需求条目慢慢增多以后，再去靠手工一条条核对字段、刷新追踪关系、梳理模块内容，效率就会明显跟不上。在DOORS Classic这个环境里，要弄清楚怎么用DXL脚本来帮忙干活，以及万一脚本跑着跑着报了错，又该从哪入手去排查，这些就是咱们要讲的重点。DXL是DOORS平台自己带的一套脚本语言，它能自动计算字段值、响应系统里的事件，还能给菜单添加自定义功能。它的写法跟C语言、C++有点接近，但里面涉及到的对象、模块，还有权限这些东西，都必须遵守DOORS运行环境的那套规矩。

　　一、DOORS怎么使用DXL脚本

　　头一回鼓捣DXL脚本的时候，最好是先把DOORS自带的DXL交互窗口打开，在里面一条命令一条命令地测，等确认整个思路都没毛病了，再琢磨着把它丢进共享目录或者挂到菜单入口里去，可别一上手就直接对着正式库里的模块动刀。

　　1、打开DXL脚本的编辑窗口

　　不管你是停在数据库浏览的界面上，还是已经点进了具体的模块窗口，都能顺着菜单栏找到【Tools】→【Edit DXL】这一项，点击之后会弹出一个分成上下两半的窗口，上半部那块空白区域就是留给咱们敲脚本的地方，而下半部那片输出区呢，就是专门拿来显示执行结果和报错信息的，写完之后跑一把，对错立马就知道。

　　2、把现成的脚本文件给加载进来

　　要是你手头已经有一份别人写好的dxl文件，那就直接点编辑窗口里的【Load】按钮，把文件翻出来导进去就行；如果脚本里面还要用到DOORS官方打包好的那些公共函数库，那就要去点旁边的【Browse】按钮，去安装目录下边的lib/dxl文件夹里翻一翻，按照IBM文档的说法，DOORS自带的DXL库默认就是放在这个位置的，找不着的时候可以先来这里看看。

　　3、先拿测试模块试跑一下

　　脚本被加载进来以后，只要去点那个【Run】按钮，它就会开始一行一行地往下执行。不过有一条必须记在脑子里，凡是那些打算批量去改字段值、删对象，或者更新链接关系的脚本，绝不能在一上来就直接丢给正式模块去跑，正确的做法是先照原样复制出一个测试用的模块，在这个测试模块上把脚本痛痛快快地跑完，然后仔细比对跑之前和跑之后，对象的总数变了没有、关键字段的值改对了没有，等所有结果都跟自己的预期对上了，再慢慢地把操作范围扩大到正式环境里去。

　　二、DOORS DXL脚本报错怎么定位

　　脚本一走就报execution halted，这种时候别光盯着最后那一行红字发呆，而是得赶紧把目光往上挪，找到输出区里最先跳出来的那条错误，看看它标的是哪个文件名、第几行，然后直接跳到对应位置去琢磨，到底是自己的语法写劈了，还是当前操作的那个对象状态压根就够不着，又或者是权限不够、文件路径指错了地方。

　　1、先从输出区里找第一条错误

　　每次点完【Run】，DXL窗口的下半部分就会把执行情况一条条地列出来，要是脚本里问题比较多，它可能一口气吐出一大串错误。这个时候有一个很顺手的按钮叫做【Next error】，你只管去点它，鼠标光标就会自己蹦到输入区里对应出问题的源代码行上，这个定位的法子在IBM的官方手册里写得一清二楚。

　　2、老老实实从第一条错误开始修

　　后面跟着冒出来的那些错误，很多其实都是被第一条给拖下水，变成那第一条错误的连带反应，比如说开头一个变量忘了先声明，那么脚本往后凡是碰着这个变量的地方，全都会提示找不到这个东西；又比如负责打开模块的那条指令一开始就失败了，那紧跟着去循环处理模块里对象的那些代码，肯定也是一条路走到黑的报错。所以先把最头上那条错误给解决掉，然后再重新点一次运行，往往能一下子清掉大半的消息。

　　3、确认模块的打开状态和访问权限

　　如果你的脚本是围绕着当前那个模块来写的，那么去查错的时候，一定得亲眼确认一下这个模块是不是已经在界面上打开了，而且打开的时候用的是啥模式。要是只想从模块里面读一读数据，那么即便在只读的模式下，脚本也照样能跑；可要是打算批量的去改字段的值，或者去删几条对象，那就要确保自己拥有编辑的权限才行。另外，脚本内部用到的那些属性名字、视图名称，还有跨模块跳转时写的链接路径，也得一个一个跟系统里真实的叫法去核对，别指望系统会自动帮你纠正拼写。

　　三、DOORS DXL脚本为什么无法运行

　　有时候脚本本身翻来覆去地看，好像一行也没写错，可偏偏就是跑不起来，这种时候就很可能是代码本身没啥问题，而是DOORS当前的运行环境根本就没打算让你去执行，排查的时候得把权限、备份，还有从最小单元开始测试这几个事情绑在一块儿来搞。

　　1、看看Run按钮是不是灰的

　　要是你打开编辑窗口以后，发现不光【Run】是灰色的，连【Save As】都点不动，那不用瞎猜了，这多半就是数据库那边已经把普通用户编辑和运行DXL脚本的权限给关掉了，IBM的官方支持文档里也是这么建议的，碰到这种情况最直接的法子就是赶紧去找你们DOORS的管理员，问清楚当前的策略到底是怎么设置的，还有能不能帮你临时放开一下。

　　2、把脚本拆成最小的片段来测

　　在怀疑一切之前，最稳妥的排查手段就是把脚本大卸八块，先只留一两行最最简单的输出语句，比如就让它往输出区里打一个“hello”，点一下Run看看窗口到底能不能正常工作，然后每试成功一步，再小心地把打开模块、遍历对象、修改属性、写回数据这些功能一样一样地往回拼接，每次只多还原一小块逻辑模块，这样就能非常清楚地看到，到底是加到哪一步的时候把整个脚本给搞趴下了。

　　3、动手批量修改前一定先做好备份

　　DXL脚本干起活来效率是很吓人的，它能用飞快的速度处理成千上万条需求，但也正因为它跑得这么快，万一中间的逻辑有哪怕一点点小偏差，也可能在几秒钟之内把整批需求给改得面目全非。所以在正式对着生产环境按下Run之前，一定要先给自己铺好退路，要么给当前模块建一条基线，要么把整个模块从头到尾导出一份来做备份，并且等跑完之后，也别忘了随机抽几条记录出来，比对一下对象的数量、关键字段里的值，还有需求之间的链接关系是不是都还是正确的。

　　总结

　　最后总结一下，在DOORS Classic客户端上怎么使用DXL脚本，以及脚本报错之后怎么去定位原因，这一整套的操作顺序其实是可以固定下来的：先进到【Tools】→【Edit DXL】，把交互编辑窗口给调出来，然后把要用的脚本通过【Load】或者【Browse】给加载进去，接着点【Run】让它开始执行；一旦遇上执行报错，就照着输出区里头最靠前的那条错误信息，用【Next error】直接定位到对应的行号上，随后再把模块的打开模式、字段和视图的名字、外部引用文件的路径，还有当前账号的权限，逐一都排查清楚；等到脚本被反复测试，证明它已经稳稳当当了之后，再把它放到正式的模块上面去跑，这样才是最把稳的做法。