你看到的空似乎有所不同-国产化OA问题排查过程

在国产化OA系统的建设中，我们发现了一个异常情况，即使下一节点的操作者为空，流程却仍然能够提交，这与我们预期的提交失败情况不符。

节点操作者就是流程中的参与人，在系统中会根据实际业务需要，规定流程每个环节由谁处理，这个处理人就是节点操作者。

分析前我们先对节点操作者进行了简单逻辑梳理，方便了解系统是如何确定操作者。如图1所示，这一逻辑主要涵盖四个核心过程：业务配置、有序配置、会签关系和条件的判断以及确定操作者。

业务配置：根据具体的业务需求来设定不同的对象类型。这些对象类型丰富多样，包括部门、角色、矩阵以及字段等。

有序配置：将多个对象类型按照批次进行正序排序，通过这种有序的配置方式，我们确保了系统能够按照预设的顺序对对象类型进行管理和处理。

会签属性和条件的判断：设置该对象的会签属性，再通过“与”和“或”的级联条件关系，建立操作者的选择性关系。

确定操作者：将筛选出的操作者策略对象放到一个集合中，并确定最终操作者。

图1

了解操作者实现逻辑后，问题可能的原因无外乎以下几种：

1. 业务配置出现错误；

2. 有序配置逻辑有问题；

3. 条件和会签属性判断逻辑异常；

4. 确定操作者逻辑有误。

思路一

考虑到国产化OA系统已上线运行一段时间，流程流转表现相对稳定，基于以往经验怀疑会不会是配置错误导致？

——对线上环境节点操作者的配置进行检查，发现配置的对象确实为空，如图2，因此可以基本排除因业务配置错误导致流程提交的情况。

图2

思路二

有序配置逻辑异常导致？

——经过刚刚对配置的检查，发现该节点的操作者策略仅配置了一个，因此，可以排除由于有序配置逻辑错误而导致的问题。

思路三

鉴于本次投产是对条件和会签属性判断逻辑进行了优化升级（优化功能如图1的“条件核会签关系判断”），我们不禁怀疑，是否是新增的逻辑改动导致了当前问题的出现？

——在包含优化逻辑的线下环境中尝试复现这一问题，发现问题无法复现。那么新的疑惑随之浮现，在相同的代码和配置（创建人上级字段为空），线上和测试环境的表现却截然不同：测试环境运行正常，而线上环境却出现异常，这背后的原因究竟是什么呢？我们还需要进一步调查和分析，以找出这一差异的根源。

与此同时查看日志，日志显示出现异常的流程节点操作者的确为空（如图3），并结合代码查看，发现在“确定操作者”环节生成的List仅对null做了判断。

图3

问题终于定位了！在确定操作者环节，程序会将筛选出的操作者策略数据转换成一个List。如果数据为null，则不会被添加到该列表中。然而，若数据为空字符串，它会被视为一个有效的元素并添加到列表中。在后续的处理过程中，程序会通过判断List是否包含元素来确定是否存在操作者。因此，即使列表中存在空字符串元素，也被视为有操作者存在，从而流程能够提交。

同时也揭示了线上环境与线下环境表现不一致的根本原因：数据库中存储的值存在差异。具体来说，线下环境中对应的字段值为null，表示该字段没有设置任何值；而在线上环境中，该字段值却是一个空字符串（""），意味着字段被赋予了一个空值，但并非真正的null。如图4。

然而，从业务系统的用户界面和接口返回的数据来看，这两者都显示为“空”，使得我们难以直接区分它们之间的细微差别。这种表现上的相似性增加了问题的复杂性，需要我们采取额外的措施来精确识别和解决问题。

图4

1、技术方案

对生成的操作者List应用StringUtils::isNotBlank判断，我们可以确保List中的字符串不仅不为null，而且也不包含仅由空字符构成的无效字符串。

3、线下测试：

对可能为空的字段进行边界测试，包括空字符串、null值以及有效值的测试，确保系统能够正确处理各种情况。

1、用户反馈问题往往都是一句话，例如流程提交不成功，无法打开页面等，需要在了解国产化OA框架的基础上，用恰当的方法逐一排查，能够得到有效的信息帮助问题缩小范围从而尽快定位。

2、全⾯深⼊了解产品策略和代码逻辑，是快速定位问题的基础，⽇常测试和测试之余都需要不断积累。