深入使用明道云之后的内心感受：感觉自己进入了一个雷区，不知道下一步会踩到什么雷
有1人点赞 
我处理 2w 以上得数据都是获取多条数据然后嵌入子流程，不过就是要注意到下次数据选中问题，就要加个表示自己已经处理过了，保证下次能执行不重复就行了，套太多循环，反而很乱
多数据的处理方式目前通过多次处理加字段进行筛选控制，增加定时任务频率解决；但运维起来非常痛苦，目前这种流程有 100 多个，时不时出问题；
每一次升级我都是比较担心的，因为总是会出现这样或者那样的怪现象。任何一个软件都会有 bug，但那只影响那一个软件，而明道云作为通用底座平台，一旦有 bug 就会影响所有使用明道云的用户。所以稳定性应该被排在第一位，这种稳定意味着几层意思：
- 性能稳定，不能动不动就变卡变慢，甚至有的组件打不开；
- 功能稳定，升级前能用的功能，经常会出现有的失灵了，导致数据出不来；
- 界面稳定，不能动不动就莫名其妙的丢失了某块内容，比如门户的应用收藏。
虽然明道如“乐高”般让应用开发变得如此有乐趣，但用户（伙伴）绝对不是拿它用来图个新鲜乐趣的，要严谨、严肃。真心希望官方高度重视起来，把它放在第一位解决，哪怕版本升级的节奏变慢一些都可以。
胡总，我月薪 3K，关我鸟事......😄
是的，我之前咨询过，最靠谱的就是获取多条记录（查询工作表）
确实获取多条记录加子流程，传参下去感觉稳点
批量处理 20000 以下数据限制真是坑，改了不知道多少次了，循环嵌套循环嵌套循环再嵌套循环；
我处理 2w 以上得数据都是获取多条数据然后嵌入子流程，不过就是要注意到下次数据选中问题，就要加个表示自己已经处理过了，保证下次能执行不重复就行了，套太多循环，反而很乱
小张(总)，你又不买服务（签合同），不签合同，谁服务你啊？？？？😄
只能靠论坛各位大佬了
是的，我之前咨询过，最靠谱的就是获取多条记录（查询工作表）
小张(总)，你又不买服务（签合同），不签合同，谁服务你啊？？？？😄
在工作流里用查找多条关联记录有时会找不到，但是用获取多条记录然后通过关联字段等于记录 ID 的方式就能找到。。。。花了超多时间去 debug 才最终意识到找多条关联记录这个方式不总是可靠以后，我们就彻底不用这个方式来获取关联记录了，都统一用获取多条记录然后通过关联字段等于记录 ID 的方式。。
另外，每次升级确实都是心惊胆跳的，说不定哪里就突然不 work 了，记得有一次升级是变更了工作流的筛选条件的处理逻辑（具体不记得了，之前好像是条件中的值为空时跳过该条件，升级后改成了节点报错），导致升级后我们有十几个工作流/PBP 各种报错，花了半天的时间才按新的逻辑适配/处理好而且有一堆没办法处理的脏数据。从那以后，我们每次升级都必须是 SaaS 版本用了 3 个月以后才考虑升级。
真心希望明道云可以把优化可靠性（而不是新功能）作为最高优先级。
是的，我之前咨询过，最靠谱的就是获取多条记录（查询工作表）
你要是私有的，得吐血；我现在就是甩手不管了
哪个版本更新没爆问题？
逼不得已才推去官方，代理我都不找了
早就放弃了，工单提了听不懂，社区提了没下文，不提也不喷。下班了下班了下班了
异步还没处理完，结果暂时可能不一致，最终会一致的
在工作流里用查找多条关联记录有时会找不到，但是用获取多条记录然后通过关联字段等于记录 ID 的方式就能找到。。。。花了超多时间去 debug 才最终意识到找多条关联记录这个方式不总是可靠以后，我们就彻底不用这个方式来获取关联记录了，都统一用获取多条记录然后通过关联字段等于记录 ID 的方式。。
另外，每次升级确实都是心惊胆跳的，说不定哪里就突然不 work 了，记得有一次升级是变更了工作流的筛选条件的处理逻辑（具体不记得了，之前好像是条件中的值为空时跳过该条件，升级后改成了节点报错），导致升级后我们有十几个工作流/PBP 各种报错，花了半天的时间才按新的逻辑适配/处理好而且有一堆没办法处理的脏数据。从那以后，我们每次升级都必须是 SaaS 版本用了 3 个月以后才考虑升级。
真心希望明道云可以把优化可靠性（而不是新功能）作为最高优先级。
同感 2. 3 问题遇到的比较多当前也没有根本解决办法。期待官方尽快出解决方案。
每一次升级我都是比较担心的，因为总是会出现这样或者那样的怪现象。任何一个软件都会有 bug，但那只影响那一个软件，而明道云作为通用底座平台，一旦有 bug 就会影响所有使用明道云的用户。所以稳定性应该被排在第一位，这种稳定意味着几层意思：
为啥不厌其烦在社区提工单？因为希望任总看到，有不一样的结果。
我要有些工单在工单系统里面躺着，我懒得到社区提。
3 我也遇到过，私有部署
字段设置了 1 对 N 双向关联，A 关联了 B，但是 B 没有自动关联 A
工作流触发的筛选条件限制偶尔失效
这个我也碰到过，当时都崩溃了，反复查问题。。。。。
不是吧，这么坑，你用的哪个版本，SaaS 还是私有部署
SaaS 版
是的，把稳定性做好 比上线很多“花里胡哨”的功能 重要的多
明道云官方总是把很多问题归结为：队列要排队、异步等等技术上（2-3 年了一直这样 说不过去啊），看下当年支付宝为了解决支付成功率所下的决心和执行力
明道云连班都不加，怎么能和支付宝比，不像软件公司，像国企
不是吧，这么坑，你用的哪个版本，SaaS 还是私有部署
批量处理 20000 以下数据限制真是坑，改了不知道多少次了，循环嵌套循环嵌套循环再嵌套循环；
你要是私有的，得吐血；我现在就是甩手不管了
哪个版本更新没爆问题？
逼不得已才推去官方，代理我都不找了
是的，把稳定性做好 比上线很多“花里胡哨”的功能 重要的多
明道云官方总是把很多问题归结为：队列要排队、异步等等技术上（2-3 年了一直这样 说不过去啊），看下当年支付宝为了解决支付成功率所下的决心和执行力
你要是私有的，得吐血；我现在就是甩手不管了
哪个版本更新没爆问题？
逼不得已才推去官方，代理我都不找了
第 4 点的应该也是排队处理速度问题，流程触发后可能当时需要排队处理，记录的状态等数据还没更改，导致可以再次触发工作流（状态还没变，筛选条件依然符合）。这种情况需要要杜绝，不仅要串行处理，还需要在触发执行后再次判断状态是否要继续了。
是不是可以在数据落地时判断一次状态？
关于第四点 1 年前应该提过需求：问题的本质服务端没有检验 客户端数据的状态，比如同一条数据被不同人操作同一个：自定义按钮
现在明道云处理的方案应该是：明道云会更新有登陆客户的视图数据，但是当某个客户的的网络出问题后还是会出现问题
第 4 点的应该也是排队处理速度问题，流程触发后可能当时需要排队处理，记录的状态等数据还没更改，导致可以再次触发工作流（状态还没变，筛选条件依然符合）。这种情况需要要杜绝，不仅要串行处理，还需要在触发执行后再次判断状态是否要继续了。
https://bbs.mingdao.net/topic/3670 避坑指南，拿走，不谢。
都是“血”的教训
https://bbs.mingdao.net/topic/3670 避坑指南，拿走，不谢。
关于第四点 1 年前应该提过需求：问题的本质服务端没有检验 客户端数据的状态，比如同一条数据被不同人操作同一个：自定义按钮
现在明道云处理的方案应该是：明道云会更新有登陆客户的视图数据，但是当某个客户的的网络出问题后还是会出现问题
关于用工作流处理：有个客户的工作流数量：2000+、工作表 500+，改用工作流处理 工作量巨大
是的，我们了解用户的处境。
有些汇总的超过了 2 个月还没汇总，和排队执行的解释有冲突
这个肯定就不是排队问题。只有更新较慢，但是依然更新了的是排队问题。
您提到的 1-4 个问题可能是共同的原因导致的，它和 HAP 的动态字段（汇总，他表字段等）的排队计算方式有关。我们正在设法从算力资源，架构和代码等多个角度来解决好，目标就是让队列处理足够快。
从另外一个角度，如果某个应用的数据需要保证事务性，我们建议您还是通过工作流的数据处理节点，而不要仅仅依赖便利性更强的汇总字段。这应该能够解决你提出的一部分问题。
关于用工作流处理：有个客户的工作流数量：2000+、工作表 500+，改用工作流处理 工作量巨大
您提到的 1-4 个问题可能是共同的原因导致的，它和 HAP 的动态字段（汇总，他表字段等）的排队计算方式有关。我们正在设法从算力资源，架构和代码等多个角度来解决好，目标就是让队列处理足够快。
从另外一个角度，如果某个应用的数据需要保证事务性，我们建议您还是通过工作流的数据处理节点，而不要仅仅依赖便利性更强的汇总字段。这应该能够解决你提出的一部分问题。
有些汇总的超过了 2 个月还没汇总，和排队执行的解释有冲突
SaaS 版本
您提到的 1-4 个问题可能是共同的原因导致的，它和 HAP 的动态字段（汇总，他表字段等）的排队计算方式有关。我们正在设法从算力资源，架构和代码等多个角度来解决好，目标就是让队列处理足够快。
从另外一个角度，如果某个应用的数据需要保证事务性，我们建议您还是通过工作流的数据处理节点，而不要仅仅依赖便利性更强的汇总字段。这应该能够解决你提出的一部分问题。
我确认下您使用的是我们的 SaaS 还是私有部署？
SaaS 版本
我确认下您使用的是我们的 SaaS 还是私有部署？