用 Power Automate for desktop 实现核心系统转录自动化 ── 将 Excel、纸质单据的手动录入替换为 UI 自动化

· 更新日期: · · Power Automate, RPA, 桌面流程, UI 自动化, Excel, 核心系统, 业务自动化, 技术咨询

「负责人每天都要把 Web 订单表单或邮件收到的订单,手动重新录入到公司内部的销售管理系统里」「月末要把考勤、申请用的 Excel 汇总转录到核心系统,得花整整两天」。我们经常收到这类咨询。这些案例的共同点是:转录的目的地,是一套已经使用了 10 年、20 年的老旧业务系统(WinForms 或 VB6 时代的界面、专用客户端),既没有 API,也没有 CSV 导入功能。

对系统进行改造固然能从根本上解决问题,但由于供应商已经不在了、没有源代码、或改造费用不划算等原因,手动录入持续存在的情况并不少见。填补这一空白的现实工具,就是通过 Power Automate for desktop(PAD)实现的 UI 自动化。它直接重现人所进行的键盘输入和鼠标操作,因此无需对转录目标系统做任何改动即可实现自动化。而且在 Windows 11 上,不用额外安装即可直接尝试,门槛也很低。

不过,UI 自动化也是一种「一开始跑起来很容易,要稳定持续运行却很难」的工具。本文将聚焦于转录业务,从是否应该选择 UI 自动化的判断开始,梳理免费可用范围与许可的边界、稳定运行的设计,直至失败时的恢复。关于 Power Automate 整体的使用场景划分与错误处理的一般性讨论,笔者已经在「用 Power Automate 自动化业务 ── 云端流程与桌面流程的使用场景划分及错误处理设计」中写过,本文则是针对转录业务的专题讨论。

1. 先说结论

  • UI 自动化是最后的手段。 应先确认转录目标是否具备 CSV 导入、数据库直接写入、API、文件对接等接口。只要有一种可用,稳定性都会明显更高。
  • PAD 标准内置于 Windows 11,在 Windows 10 上也可以免费安装。 借助录制器和 400 多种操作,读取 Excel 并输入到界面的转录流程可以零代码搭建。12
  • 只要是自己搭建流程并在本机手动运行(有人执行),就不需要额外付费。 无论使用职场・学校账户还是 Microsoft 账户都是如此。而从云端流程自动启动、按计划执行、共享流程,则需要 Power Automate Premium 许可。34
  • 类似夜间批处理的无人执行(unattended),还需要额外完成计算机注册并购买 Power Automate Process 许可。 技术层面也存在「所有用户必须已注销」等特有前提条件。56
  • 稳定运行的关键在于选择器的构建方式、元素等待、以及按单条记录粒度的异常处理这三点。用一连串固定 Wait 拼起来的流程,迟早一定会出故障。789
  • 为了在失败时能知道「已经录入到哪里」,应从一开始就设计成让输入源 Excel 具备状态列和登记编号列,并按每条记录写回结果。这样即使重新执行,也不会发生重复录入。
  • 由于因界面变化而出故障的宿命无法消除,件数多、不能停摆、目标应用更新频繁的业务,属于数据对接开发或核心系统改造的范畴。 具体的判断界线将在第 8 章整理。

2. 转录工作存在什么问题

从 Excel 或纸质单据向核心系统转录数据,其问题并不仅仅是「简单作业占用时间」这么简单。根据我们收到的咨询,常见的问题共有以下三点。

  • 时间集中在结算日附近。 如果是每天的接单录入,工作量还算分散,但月末结算的账单处理和考勤汇总,往往会在结算日之后的一到两天内高度集中地进行转录。在这段时间里,负责人几乎无法做其他工作,很多公司应该都是靠加班或增援来消化这部分工作量。
  • 录入错误会流向下游。 位数打错、行错位、商品编码搞混——转录错误往往要等到变成账单或库存数量出问题之后才会被发现,因此排查原因和更正所耗费的功夫,往往是录入错误本身的好几倍。加入双重核对可以减少错误,但同时也会增加时间成本。
  • 会变成只有那个人才能做的工作。 「这个界面必须按这个顺序输入,否则会报错」「只有这家客户需要特殊的录入方式」之类的诀窍,会积累在负责人个人的脑子里,一旦他休假,业务就会停摆。

自动化的价值并不只是缩短时间。由于流程只会按照设定好的方式录入,转录错误得以消除;而且操作步骤以流程的形式被固定下来,也能缓解业务对个人的依赖。能够抹平结算日附近的高峰,同样意义重大。

另外,如果转录来源是纸质单据或传真,在此之前还需要一道「读取」工序。关于传真订单的 OCR,笔者已经在同期发布的「用 AI Builder 读取传真订单并交由 Power Automate 处理」中做了说明,本文则以转录来源「已经是 Excel 等数据形式」为前提展开。

3. 自动化方式的选择 ── UI 自动化是最后的手段

首先要强调的一点是:界面操作自动化(UI 自动化)是选择项中的最后一个。 UI 自动化依赖界面布局、分辨率、响应速度等「显示层面的因素」,因此无论做得多么细致,都不可避免地比直接传递数据的方式更容易出故障。应先确认转录目标核心系统是否具备下列接口。

对接方式 需要确认的内容 稳定性 备注
CSV・定长文件导入功能 菜单深处是否有「外部数据导入」「批量登记」之类功能。向供应商的手册、支持部门确认 即便是老旧业务系统,出乎意料地也常常具备这项功能。生成待导入文件的工作,本身可以用 PAD 或 PowerShell 自动化
数据库直接写入 是否清楚数据库类型和连接信息;供应商的维保合同是否允许直接写入 存在绕过业务逻辑(编号生成、一致性检查)的风险,因此读取可以直接进行,写入则需谨慎,须验证
API・对接中间件 较新的版本包是否提供对接选项 需要权衡额外的费用
文件对接(监控文件夹) 是否具备读取放入指定文件夹中的文件的机制 在票据系统或仓储系统中常见
UI 自动化(PAD) 以上皆无时 唯一无需改动界面即可实现的方法,也是本文的主题

另一个选择方向,是「消除」转录本身——也就是对核心系统进行改造或重建。关于是否要给 VB6 应用添加导入功能,或者干脆将其 Web 化、从接单入口重新构建,笔者在「将 VB6 应用迁移到 .NET ── 事前调查、兼容性、分阶段迁移的实践指南」和「判断是否应将 Windows 应用迁移到 Web ── 判断标准与现实的迁移模式」中做了梳理。由于改造需要投入开发费用,先用 PAD 自动化来争取时间,等业务量增加、看到自动化的极限之后再投资改造,这样的顺序也是现实可行的。

4. Power Automate for desktop 的基础

导入门槛低

PAD 标准内置于 Windows 11 中。在开始菜单搜索「Power Automate」即可找到该应用,首次启动时会自动下载并可立即开始使用。2 Windows 10 和 Windows Server 2016 同样拥有使用权限,可以从下载中心免费安装。2 安装方式分为 Microsoft Store 版和 MSI 安装程序版;如果还考虑到后文提到的云端对接(计算机注册),建议选择可以一并安装计算机运行时应用的 MSI 版。10

用录制器搭建骨架

PAD 具备录制器,可以记录操作并转换为一系列操作步骤。它会以与 UI 元素的关系为基础记录鼠标和键盘操作,对于搭建转录流程的骨架来说已经足够实用。对转录业务尤其有帮助的一点是,记录方式可以在 UIA(UI Automation)和 MSAA(Microsoft Active Accessibility)之间选择。 UIA 是面向 WPF、WinForms 等相对较新应用的推荐方式,MSAA 则是面向 VB6 或经典 Win32 等 UIA 无法识别元素的老旧应用的方式。 当老旧核心系统的界面元素无法顺利识别时,把录制器的记录模式切换为 MSAA,有时就能识别成功。11

不过,录制器终究只是用来搭建骨架的。它无法记录条件分支和循环,因此前提是录制之后还要在设计器中编辑完善。11

UI 元素与选择器

PAD 会把界面上的按钮、文本框等记忆为「UI 元素」。其实质是一种选择器,通过窗口层级与属性的组合来定位元素。转录流程的寿命,几乎完全取决于这个选择器的构建方式。如果选择器中包含连续编号的索引或动态变化的 ID,即使界面外观完全相同,也可能在某一天突然无法识别。把会变化的属性从 Equals 改为 Contains 或正则表达式,为重要操作设置备用选择器以实现故障转移,出故障时用 Repair selector 功能生成修复候选——这些基本做法,笔者在整体指南中已经写过。7

有一点是转录业务特有的注意事项:UI 自动化的操作,是以目标窗口位于前台为前提运行的,如果不在前台,会自动将其切换到前台。12 也就是说,运行期间的电脑基本上是「流程独占」的。 应避免负责人在同一台电脑上一边运行流程一边做其他工作,因为这容易导致误点击、误输入。

转录的基本结构:从 Excel 读取,写入界面

转录流程的基本形态是「用 Excel 操作读取 → 在循环中逐条用 UI 操作写入」。用 Launch Excel 打开文件,用 Read from Excel worksheet 读取范围后会得到一个数据表变量。如果勾选「将首行作为列名」选项,后续在循环中就可以用类似 CurrentItem['客户编码'] 的方式按列名引用值,对列顺序调整的抗性也更强。13 写回结果时使用 Write to Excel worksheet。如果想追加到行末尾,可以用 Get first free row on column 查找空行。13

5. 免费可用范围与许可的边界

在决定是否引入 PAD 时,一定会被问到「免费到什么程度、从哪里开始收费」。这条边界,位于「构建流程・手动运行」与「自动运行・以组织为单位进行管理」之间。

可以做的事情 Microsoft 账户 职场・学校账户(无需追加许可) Power Automate Premium
流程构建・录制器・400 多种操作・异常处理
流程的保存位置 OneDrive(个人) 默认环境的 Dataverse 多个环境的 Dataverse
从 PAD 控制台手动执行(有人执行)
从云端流程启动(按计划・事件触发) × ×
流程共享・执行日志集中管理 × ×

无论使用哪种账户,构建流程和手动执行都不需要额外付费。34 使用 Microsoft 账户时,流程会保存到 OneDrive;使用职场・学校账户时,则会保存到默认环境的 Dataverse。如果是在公司里使用,出于后续管理的考虑,通常建议从职场账户开始。4

跨越这条边界的时机,是想要实现「无需人工点击按钮也能运行」的时候。要让桌面流程在固定时刻或事件触发时启动,需要配置成由云端流程调用,为此需要做好以下准备。14

  1. 计算机注册:将运行流程的电脑注册到 Power Automate 云端。用 MSI 版中包含的计算机运行时应用登录即可完成注册。需要注意的是,Windows 10/11 的 Home 版不支持这种直接连接方式。10
  2. 桌面流程连接:创建一个连接(Windows 账户的凭据),供云端流程登录到该计算机。14
  3. 许可:创建连接的用户,必须持有与执行形态相匹配的许可。14 如果是在有人登录的电脑上运行的有人执行(attended),需要 Power Automate Premium(包含有人 RPA 权限的用户许可)。106
  4. 无人执行(unattended)还需要为该计算机分配 Power Automate Process 许可。 Process 许可不是绑定在用户身上,而是绑定在计算机(或流程)上的许可,每台计算机可获得一个无人执行名额(无人机器人)。需要注意的是,分配 Process 许可的计算机,前提是必须已经由持有 Premium 许可的用户注册完成。也就是说,光购买 Process 许可,如果没有 Premium 用户,也无法完成配置。56

总结来说,如果运行模式是「负责人早上按下按钮,在眼前看着转录流程跑完」,那么在免费范围内就能完成。如果是「深夜自动跑完」的运行模式,就需要 Premium + Process(外加已注册的计算机)。如果转录所需时间大约是每天 30 分钟,先从免费的有人执行开始,等件数增多之后再考虑无人化,这样的顺序就已足够。关于许可的整体思路(包括标准/高级连接器的边界),笔者在同期发布的「Power Automate 的许可与标准・高级连接器的边界」中做了详细梳理。

6. 实现稳定运行的设计

用「等待元素」代替固定 Wait

老旧核心系统的搜索、登记响应时间会随负载大幅波动。用「等待 3 秒」这类固定 Wait 调出来的流程,一定会在系统变慢的那天出故障。基本做法是用 Wait for window content 操作,实现「等待特定 UI 元素或文本出现(或消失)」的等待方式。8 获取窗口(Get window)也可以设置超时,可以选择「在指定秒数内找不到就判定失败」还是「持续等到出现为止」。8 在转录流程中,「等待登记完成的提示消息出现之后再进入下一行」这种等待方式尤其重要。如果不等待就开始下一条录入,画面会在上一行尚未登记完成时就切换过去,导致数据混乱。

按「单条记录」组织异常处理

转录流程的异常处理,惯用做法不是包裹整个流程,而是用 On Block Error 包裹循环中单条记录的处理逻辑。 出错时记录该行的失败内容,把界面恢复到初始状态(关闭录入界面、返回菜单等),然后进入下一行。这样一来,即使 100 条记录里只有 1 条商品编码有误,其余 99 条也能完成录入,只留下失败的这一条交给人工处理。对于响应延迟等临时性错误,还可以配合按操作粒度设置的重试机制。9 关于错误处理的细节做法(用 Get last error 获取错误内容、善后设计等),请参阅整体指南以及同期发布的「Power Automate 的错误处理与重试设计」。

即使失败,也要能知道「录入到哪里了」

UI 自动化没有像 Web 系统那样的事务机制。如果流程中途崩溃,而又不知道「已经登记到核心系统的哪一行」,就只剩下两个选择:重新执行导致重复录入,或者对全部记录进行目视核对。有两种设计可以防止这种情况。

  1. 让输入源 Excel 具备状态列。 准备「未处理」「处理中」「完成」「错误」这样的状态列,以及记录核心系统所生成登记编号的列。在开始录入某一条记录之前先标记为「处理中」,在界面上确认登记完成并读取登记编号后,再写回「完成」状态和该登记编号。由于流程始终只以「未处理」的行为对象,无论重新执行多少次,都不会触碰已经录入完成的行(可安全重试)。
  2. 只需人工确认停留在「处理中」状态的行。 流程如果会崩溃,一定是发生在录入过程当中,因此需要怀疑的只有停留在「处理中」的行。重新执行之前,只需针对这一行去核实核心系统的情况即可,核对范围会从 100 条缩小到 1 条。

这个状态列本身也就成了执行记录。「昨天的转录是否全部完成」这样的问题,不需要查看流程的执行历史,只要打开 Excel 就能看到——这种形式也很便于向业务现场解释说明。

无人执行环境的陷阱

「有人执行时运行正常的流程,一旦转为无人化就跑不动了」——这类咨询真的非常多。原因大多在于环境的差异。

  • 会话前提:在无人执行时,Power Automate 会在目标计算机上新建一个远程桌面(RDP)会话,并在执行结束后注销。执行期间,目标计算机的屏幕会保持锁定状态。作为前提条件,该计算机必须所有用户都已注销;在 Windows 10/11 上,只要还残留任何人的会话(哪怕只是锁定状态),执行就会失败。在 Windows Server 上,如果残留着与连接使用的同一用户的锁定会话,也会报错。如果维护作业结束后习惯用「锁定」或「断开连接」的方式离开,而不是注销,夜间流程就会因此停摆。务必注销是这里的关键口诀。5
  • 权限:连接所使用的用户,必须能够在该计算机上创建 RDP 会话(通常需要属于 Remote Desktop Users 组)。此外,无人执行不支持涉及提升到管理员权限的操作。5
  • 屏幕分辨率:RDP 会话的默认分辨率,有时会与搭建流程时所用的屏幕不同。分辨率降低后,搭建流程时能看到的 UI 元素可能被隐藏到屏幕之外,从而导致「找不到元素」的失败;基于坐标的操作也可能因此点到别的地方。5 对策是可以在流程属性中,把「无人执行时的屏幕分辨率」固定为与搭建时相同的数值。15 DPI 缩放的差异也是同类失败的原因之一,因此稳妥的做法是让搭建时与执行时的 DPI 都统一为 100%。16

验证完这些要点之后,再到云端流程一侧设置计划触发(例如工作日每天早上 6 点执行)。包含工作日判断和月末处理在内的计划设计,笔者在同期发布的「Power Automate 的定期执行流程与工作日设计」中做了讨论。

7. 转录流程的实例设计

把前面介绍的各个部件组合起来,设计一个「订单清单 Excel → 核心系统的接单录入界面 → 结果写回 Excel」的典型转录流程,大致如下。

没有某一条发生错误全部处理完毕开始:手动或从云端流程触发Read from Excel worksheet读取订单清单 首行作为列名状态列中是否存在「未处理」的行汇总处理结果并记录日志・通知结束启动核心系统并登录用等待元素确认菜单界面已显示对未处理的行逐条循环循环内用 On Block Error 包裹将状态列更新为「处理中」打开接单录入界面并输入各项目每次界面切换都用 Wait for window content点击登记按钮 → 等待完成消息从界面读取生成的登记编号将状态列设为「完成」并写回登记编号将错误内容记录到该行登记前失败标记为「错误」/登记后失败保持「处理中」将界面返回菜单后处理下一行登出并关闭核心系统

对设计要点做一些补充说明。

  • 输入值的校验要在 UI 操作之前完成。 商品编码的位数、数值项目中是否混入了文字、必填项目是否缺失——读取 Excel 之后应立即在流程一侧进行校验,有问题的行应在接触核心系统之前就标记为「错误」。相比通过 UI 操作去处理核心系统弹出的错误对话框,提前在前面拦截要稳定得多。
  • 只有在点击登记按钮之前发生的失败,才可以标记为「错误」。 如果异常处理一律把状态列改写为「错误」,那么即便登记按钮的操作已经成功(例如在等待完成消息、或写回过程中)之后才失败的行,也会被标记为「错误」,这会导致负责人重新执行该行,从而在核心系统中造成重复登记的事故。登记操作之后发生的失败,应让状态列保持「处理中」;不将「处理中」的行作为重新执行的对象,而是由人工核实核心系统一侧是否已经登记成功,再手动改为「完成」或「未处理」。这种设计的要点,不是消除模糊状态,而是把模糊的情况有意识地交给人工确认。
  • 要预先考虑到界面上的错误对话框。 即便如此,仍然会发生录入时的错误(库存不足、客户授信错误等)。可以预见的对话框,可以用「是否包含某个窗口」的条件分支来捕获,并记录到该行的错误内容中;无法预见的情况则交给 On Block Error 处理。9
  • 要对件数和耗时有大致的预估。 UI 自动化每条记录耗时数十秒并不罕见。如果 100 条记录耗时 1 小时,那么用夜间无人执行完全可以承受;但如果每天有数千条记录,那就是应该重新审视 UI 自动化这一手段本身的信号(详见下一章)。
  • 输入源的规范化要提前处理好。 字符编码和日期格式的不一致、全角半角混杂等来自 CSV、Excel 的常见陷阱,笔者在「CSV 文件处理实践指南 ── 防止乱码、0 丢失、日期错乱」中做了梳理。

8. PAD 自动化应该做到什么程度

UI 自动化只要界面发生变化,迟早会出故障。这并不是靠设计就能解决的问题,而是这种方式本身的宿命。正因如此,才需要对「可以用 PAD 自动化的转录」和「应该转向开发・改造的转录」划出一条清晰的界线。

情况 判断
每天数十到数百条,即使失败,第二个工作日重新执行也来得及 PAD 就足够了,先从有人执行开始
目标应用的界面多年未变(长期不动的遗留应用) 适合用 PAD。颇具讽刺意味的是,「不变的界面」正好与 UI 自动化相性最好
目标应用频繁升级(例如 SaaS 的 Web 界面等) 需要在「选择器要持续维护」的前提下做判断。如果每次更新都会出故障,UI 自动化就不合适
每天数千条以上,运行时间挤压业务时间 UI 自动化的处理速度会遇到瓶颈,属于新增 CSV 导入功能开发或数据对接开发(受托开发)的范畴
停摆会导致当天发货、开票停止的核心业务 如果不允许「出故障就先改回手动录入」,UI 自动化就不适用,应考虑核心系统改造或系统间对接开发
想在转录的同时让流程做复杂的业务判断(库存分配、定价) 把业务逻辑塞进流程里是维护不过来的,业务逻辑应该放在系统一侧

判断的大致标准,是看「即使这个流程坏掉一周不修,改回手动录入,业务是否还能照常运转」。如果能运转,用 PAD 自动化就有足够的价值;如果不能运转,那么这项转录工作就已经不再是「自动化」的需求,而是「系统对接」的需求,需要考虑新增导入功能、数据库对接,或者干脆将接单・发单本身电子化(例如 EDI将传真接单迁移到 Web)。

还有一点,PAD 的流程也容易变成「只有搭建者本人才能碰的资产」。流程内容、连接、执行用计算机由谁来交接,笔者在同期发布的「Power Automate 的个人依赖对策 ── 所有者、连接、交接的设计」中做了梳理。

9. 总结

对于既没有 API 也没有 CSV 导入功能的核心系统,转录工作可以用 PAD 的 UI 自动化实现「无需改动系统」的自动化。在 Windows 11 上可以直接开始使用,只是搭建后在本机运行也不需要额外付费。仅仅是让负责人从每天一小时的转录中解放出来、不再需要排查和更正转录错误,就已经足以收回引入所花费的功夫。

不过,重要的是不要弄错顺序和设计。在使用 UI 自动化之前,先寻找 CSV 导入、数据库、API、文件对接等接口;从免费的有人执行开始,若要无人化,要把握好 Premium + Process 许可以及计算机必须已注销这些前提;用选择器、元素等待、按单条记录的异常处理来实现稳定运行,并通过状态列的写回始终保留「录入到哪里了」的记录;一旦件数、重要程度、界面变更频率超出 UI 自动化的守备范围,就不要勉强让它继续承担,而应切换到核心系统改造或数据对接开发。

我们公司承接从 PAD 转录自动化的设计评审,到后续导入功能新增、系统间对接的受托开发,乃至遗留应用迁移这一整条链路的咨询。即便您还处在「不知道我们的核心系统能不能做到」这个阶段,也欢迎随时垂询。

相关文章

相关咨询领域

合同会社小村软件(合同会社小村ソフト)承接从 Power Automate for desktop 转录自动化的设计与稳定化咨询,到 UI 自动化无法覆盖的核心系统数据对接开发、遗留应用改造等一系列业务。

参考链接

  1. Microsoft Learn, Get started with Power Automate in Windows 11。介绍了 Windows 11 预装的 Power Automate 应用,以及借助 400 多种操作和录制器,即使没有编码经验也能创建流程。 

  2. Microsoft Learn, Power Automate licensing FAQ。介绍了 Windows 11 用户可以在默认环境中免费使用有人 RPA 桌面流程(不支持共享或在其他环境中创建)、在 Windows 搜索栏中搜索 Power Automate 会在首次启动时自动下载、以及 Windows 10、Windows Server 2016 同样拥有使用权并可从下载中心获取。  2 3

  3. Microsoft Learn, Get started with a work or school account。介绍了使用职场・学校账户运行 Power Automate for desktop 无需额外付费、默认环境需要 Dataverse 数据库、以及要解锁自动执行和流程共享等 RPA 功能需升级到高级版。  2

  4. Microsoft Learn, Prerequisites and limitations。按登录账户类型(Microsoft 账户/职场・学校账户/组织高级账户)对功能进行了比较:录制器、操作、异常处理各类账户均可使用;与云端流程的连接(启动・计划)、共享、集中管理与报表仅限高级版;保存位置为 OneDrive 或 Dataverse。  2 3

  5. Microsoft Learn, Run unattended desktop flows。介绍了无人执行需要 Power Automate Process 方案、Power Automate 会创建 RDP 会话并在执行后注销、执行期间屏幕会保持锁定、需要所有用户都已注销(在 Windows 10/11 上,如残留会话包括锁定状态的会话都会导致失败)、连接用户需要具备创建 RDP 会话的权限(Remote Desktop Users 组)、不支持涉及提升管理员权限的执行,以及 RDP 会话的默认分辨率与搭建时不同可能导致找不到元素而失败。  2 3 4 5

  6. Microsoft Learn, Types of Power Automate licenses。介绍了有人 RPA 权限(计算机注册、有人执行的触发等)包含在 Premium 用户许可中,无人 RPA 需要为计算机分配 Process 许可(每台计算机可获得一个无人机器人),以及为计算机分配 Process 许可的前提是该计算机已由 Premium 用户完成注册。  2 3

  7. Microsoft Learn, Build a custom selector。介绍了把会变化的属性从 Equals 改为 Contains 或正则表达式,从而构建动态、不易出故障的选择器;通过多个选择器实现故障转移;以及用 Repair selector 生成修复候选。  2

  8. Microsoft Learn, UI automation actions。介绍了用 Wait for window content 操作等待特定文本或 UI 元素出现/消失,以及 Get window 操作的超时设置(可选择在指定时间内找不到就判定失败,或是持续等待)。  2 3

  9. Microsoft Learn, Handle errors in desktop flows。介绍了用 On Block Error 按代码块粒度进行异常处理,以及按操作粒度设置重试(Retry action if an error occurs)。  2 3

  10. Microsoft Learn, Manage machines。介绍了通过计算机运行时应用(随 MSI 安装程序一同提供)进行计算机注册、Windows 10 Home・Windows 11 Home 无法使用直接连接、从云端流程启动桌面流程需要带有人 RPA 权限的高级用户方案、以及无人执行需要为计算机分配流程容量(无人机器人)。  2 3

  11. Microsoft Learn, Record desktop flows。介绍了录制器会以与 UI 元素的关系为基础,将鼠标和键盘操作记录并转换为操作步骤;记录方式可以在 UIA(推荐用于 WPF、WinForms 等较新框架)与 MSAA(用于 VB6、经典 Win32 等 UIA 不支持的遗留应用)之间选择;条件分支和循环无法记录,前提是录制后要进行编辑。  2

  12. Microsoft Learn, Automate desktop applications。介绍了 UI 自动化操作要求目标窗口位于前台,如果不在前台,会自动将其移动到前台。 

  13. Microsoft Learn, Excel actions。介绍了用 Launch Excel 创建实例、用 Read from Excel worksheet 读取单个单元格或范围(转换为数据表,可选择将首行作为列名)、用 Write to Excel worksheet 写入数据,以及用 Get first free row on column 获取空行。  2

  14. Microsoft Learn, Trigger desktop flows from cloud flows。介绍了从云端流程启动桌面流程的前提条件(已注册的计算机或计算机组、职场・学校账户、桌面流程连接、连接创建者持有与执行形态相匹配的许可),以及通过输入输出变量在云端与桌面之间传递数据。  2 3

  15. Microsoft Learn, Set screen resolution on unattended mode。介绍了当无人执行时的分辨率低于搭建时、导致元素被隐藏而失败的情况下,可以通过流程属性(Display resolution for unattended runs)或注册表来固定分辨率。 

  16. Microsoft Learn, Troubleshoot unattended desktop flow execution failures。介绍了有人会话与无人会话之间的分辨率或 DPI 缩放差异会导致失败,以及将设计时和执行时的 DPI 统一为 100% 等应对措施。 

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

与本文相近的主题页面。以本文为起点,可以进一步了解相关服务和其他文章。

本文与以下服务页面相关联,欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

Power Automate for desktop 可以免费使用吗?
可以。Windows 11 标准内置了 Power Automate 应用,Windows 10 也可以从微软下载中心免费安装。使用职场・学校账户也无需额外付费,即可使用录制器、400 多种操作、异常处理等流程构建与手动执行(有人执行)的全套功能。不过,从云端流程自动启动、共享流程、集中管理执行日志,则需要付费的 Power Automate Premium 许可。
要在夜间或清晨无人值守的情况下运行转录流程,需要哪些条件?
无人执行(unattended)需要配置为由云端流程调用,前提条件包括:注册目标计算机、创建桌面流程连接,以及为该计算机分配 Power Automate Process 许可。计算机的注册本身也必须由持有 Premium 许可的用户来完成。从技术层面看,无人执行会新建一个远程桌面会话来运行,因此目标计算机上必须所有用户都已注销;只要还残留一个锁定中的会话,在 Windows 10/11 上就会执行失败。
听说 UI 自动化容易出故障,它真的能实用吗?
只要目标核心系统的界面保持稳定,它就是实用的。出故障的原因大多在于 UI 元素的识别方式(选择器)和等待不足,因此把会变化的属性改为 Contains 或正则表达式、设置备用选择器、用等待元素出现的操作代替固定等待,这些设计能大幅提升稳定性。不过,因界面布局变化而出故障的宿命本身无法消除,所以如果目标应用更新频繁,或者处理的件数、重要程度使得停摆会影响业务运转,就应该考虑数据对接开发或核心系统本身的改造,而不是 UI 自动化。
如果转录流程中途失败,会不会搞不清楚已经录入到哪里了?
只要设计得当,是可以防止的。关键在于让作为输入源的 Excel 具备状态列(未处理・处理中・完成・错误)和登记编号列,每录入一条记录,就先确认核心系统一侧的登记结果,再把状态写回去。这样一来,一旦失败,Excel 中就会保留已登记到哪一行的记录;即使重新执行,也只会以「未处理」的行为对象,因此不会发生重复录入。如果按每条记录的粒度做异常处理,记录出错的行并继续处理下一行,就能避免一条录入错误导致整个流程停止。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心,擅长难以复现的故障调查,以及既有资产仍在运行的项目。

返回博客列表