用 Power Automate for desktop 实现核心系统转录自动化 ── 将 Excel、纸质单据的手动录入替换为 UI 自动化
· 更新日期: · Go Komura · 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
- 计算机注册:将运行流程的电脑注册到 Power Automate 云端。用 MSI 版中包含的计算机运行时应用登录即可完成注册。需要注意的是,Windows 10/11 的 Home 版不支持这种直接连接方式。10
- 桌面流程连接:创建一个连接(Windows 账户的凭据),供云端流程登录到该计算机。14
- 许可:创建连接的用户,必须持有与执行形态相匹配的许可。14 如果是在有人登录的电脑上运行的有人执行(attended),需要 Power Automate Premium(包含有人 RPA 权限的用户许可)。106
- 无人执行(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 系统那样的事务机制。如果流程中途崩溃,而又不知道「已经登记到核心系统的哪一行」,就只剩下两个选择:重新执行导致重复录入,或者对全部记录进行目视核对。有两种设计可以防止这种情况。
- 让输入源 Excel 具备状态列。 准备「未处理」「处理中」「完成」「错误」这样的状态列,以及记录核心系统所生成登记编号的列。在开始录入某一条记录之前先标记为「处理中」,在界面上确认登记完成并读取登记编号后,再写回「完成」状态和该登记编号。由于流程始终只以「未处理」的行为对象,无论重新执行多少次,都不会触碰已经录入完成的行(可安全重试)。
- 只需人工确认停留在「处理中」状态的行。 流程如果会崩溃,一定是发生在录入过程当中,因此需要怀疑的只有停留在「处理中」的行。重新执行之前,只需针对这一行去核实核心系统的情况即可,核对范围会从 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」的典型转录流程,大致如下。
flowchart TD
Start([开始:手动或从云端流程触发]) --> ReadX[Read from Excel worksheet<br/>读取订单清单 首行作为列名]
ReadX --> Filter{状态列中是否存在「未处理」的行}
Filter -- 没有 --> Report[汇总处理结果并记录日志・通知] --> End([结束])
Filter -- 有 --> Launch[启动核心系统并登录<br/>用等待元素确认菜单界面已显示]
Launch --> Loop[对未处理的行逐条循环<br/>循环内用 On Block Error 包裹]
Loop --> Mark[将状态列更新为「处理中」]
Mark --> Entry[打开接单录入界面并输入各项目<br/>每次界面切换都用 Wait for window content]
Entry --> Confirm[点击登记按钮 → 等待完成消息<br/>从界面读取生成的登记编号]
Confirm --> WriteBack[将状态列设为「完成」并写回登记编号]
WriteBack --> Loop
Loop -. 某一条发生错误 .-> Handler[将错误内容记录到该行<br/>登记前失败标记为「错误」/登记后失败保持「处理中」<br/>将界面返回菜单后处理下一行]
Handler --> Loop
Loop -- 全部处理完毕 --> Close[登出并关闭核心系统] --> Report
对设计要点做一些补充说明。
- 输入值的校验要在 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 自动化业务 ── 云端流程与桌面流程的使用场景划分及错误处理设计
- 将 VB6 应用迁移到 .NET ── 事前调查、兼容性、分阶段迁移的实践指南
- 判断是否应将 Windows 应用迁移到 Web ── 判断标准与现实的迁移模式
- Power Automate 的错误处理与重试设计
- CSV 文件处理实践指南 ── 防止乱码、0 丢失、日期错乱
相关咨询领域
合同会社小村软件(合同会社小村ソフト)承接从 Power Automate for desktop 转录自动化的设计与稳定化咨询,到 UI 自动化无法覆盖的核心系统数据对接开发、遗留应用改造等一系列业务。
参考链接
-
Microsoft Learn, Get started with Power Automate in Windows 11。介绍了 Windows 11 预装的 Power Automate 应用,以及借助 400 多种操作和录制器,即使没有编码经验也能创建流程。 ↩
-
Microsoft Learn, Power Automate licensing FAQ。介绍了 Windows 11 用户可以在默认环境中免费使用有人 RPA 桌面流程(不支持共享或在其他环境中创建)、在 Windows 搜索栏中搜索 Power Automate 会在首次启动时自动下载、以及 Windows 10、Windows Server 2016 同样拥有使用权并可从下载中心获取。 ↩ ↩2 ↩3
-
Microsoft Learn, Get started with a work or school account。介绍了使用职场・学校账户运行 Power Automate for desktop 无需额外付费、默认环境需要 Dataverse 数据库、以及要解锁自动执行和流程共享等 RPA 功能需升级到高级版。 ↩ ↩2
-
Microsoft Learn, Prerequisites and limitations。按登录账户类型(Microsoft 账户/职场・学校账户/组织高级账户)对功能进行了比较:录制器、操作、异常处理各类账户均可使用;与云端流程的连接(启动・计划)、共享、集中管理与报表仅限高级版;保存位置为 OneDrive 或 Dataverse。 ↩ ↩2 ↩3
-
Microsoft Learn, Run unattended desktop flows。介绍了无人执行需要 Power Automate Process 方案、Power Automate 会创建 RDP 会话并在执行后注销、执行期间屏幕会保持锁定、需要所有用户都已注销(在 Windows 10/11 上,如残留会话包括锁定状态的会话都会导致失败)、连接用户需要具备创建 RDP 会话的权限(Remote Desktop Users 组)、不支持涉及提升管理员权限的执行,以及 RDP 会话的默认分辨率与搭建时不同可能导致找不到元素而失败。 ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, Types of Power Automate licenses。介绍了有人 RPA 权限(计算机注册、有人执行的触发等)包含在 Premium 用户许可中,无人 RPA 需要为计算机分配 Process 许可(每台计算机可获得一个无人机器人),以及为计算机分配 Process 许可的前提是该计算机已由 Premium 用户完成注册。 ↩ ↩2 ↩3
-
Microsoft Learn, Build a custom selector。介绍了把会变化的属性从 Equals 改为 Contains 或正则表达式,从而构建动态、不易出故障的选择器;通过多个选择器实现故障转移;以及用 Repair selector 生成修复候选。 ↩ ↩2
-
Microsoft Learn, UI automation actions。介绍了用 Wait for window content 操作等待特定文本或 UI 元素出现/消失,以及 Get window 操作的超时设置(可选择在指定时间内找不到就判定失败,或是持续等待)。 ↩ ↩2 ↩3
-
Microsoft Learn, Handle errors in desktop flows。介绍了用 On Block Error 按代码块粒度进行异常处理,以及按操作粒度设置重试(Retry action if an error occurs)。 ↩ ↩2 ↩3
-
Microsoft Learn, Manage machines。介绍了通过计算机运行时应用(随 MSI 安装程序一同提供)进行计算机注册、Windows 10 Home・Windows 11 Home 无法使用直接连接、从云端流程启动桌面流程需要带有人 RPA 权限的高级用户方案、以及无人执行需要为计算机分配流程容量(无人机器人)。 ↩ ↩2 ↩3
-
Microsoft Learn, Record desktop flows。介绍了录制器会以与 UI 元素的关系为基础,将鼠标和键盘操作记录并转换为操作步骤;记录方式可以在 UIA(推荐用于 WPF、WinForms 等较新框架)与 MSAA(用于 VB6、经典 Win32 等 UIA 不支持的遗留应用)之间选择;条件分支和循环无法记录,前提是录制后要进行编辑。 ↩ ↩2
-
Microsoft Learn, Automate desktop applications。介绍了 UI 自动化操作要求目标窗口位于前台,如果不在前台,会自动将其移动到前台。 ↩
-
Microsoft Learn, Excel actions。介绍了用 Launch Excel 创建实例、用 Read from Excel worksheet 读取单个单元格或范围(转换为数据表,可选择将首行作为列名)、用 Write to Excel worksheet 写入数据,以及用 Get first free row on column 获取空行。 ↩ ↩2
-
Microsoft Learn, Trigger desktop flows from cloud flows。介绍了从云端流程启动桌面流程的前提条件(已注册的计算机或计算机组、职场・学校账户、桌面流程连接、连接创建者持有与执行形态相匹配的许可),以及通过输入输出变量在云端与桌面之间传递数据。 ↩ ↩2 ↩3
-
Microsoft Learn, Set screen resolution on unattended mode。介绍了当无人执行时的分辨率低于搭建时、导致元素被隐藏而失败的情况下,可以通过流程属性(Display resolution for unattended runs)或注册表来固定分辨率。 ↩
-
Microsoft Learn, Troubleshoot unattended desktop flow execution failures。介绍了有人会话与无人会话之间的分辨率或 DPI 缩放差异会导致失败,以及将设计时和执行时的 DPI 统一为 100% 等应对措施。 ↩
相关文章
共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。
用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工,以及错误处理设计
本文整理 Power Automate 云端流程与桌面流程的区别、与 PowerShell / VBA 的分工、许可证、错误处理、UI 自动化的稳定化,以及凭据信息的安全处理,提供把业务自动化落地到生产环境的实务设计指南。
把 Excel VBA 宏迁移到 Power Automate ── 用 Office Scripts 替换的范围,与继续保留为 VBA 的范围
本文梳理 Excel VBA 宏能否迁移到 Power Automate,涵盖 Office Scripts 可以替换的范围、只有 VBA 才能做到的事情、连接器的限制值、许可证要求,以及从盘点开始的分阶段迁移推进方式。
Power Automate 的错误处理与重试设计 ── 防止「原本正常运行的流程不知不觉停止了」
一套防止 Power Automate 流程「不知不觉就停止了」的设计模式集合。基于 Microsoft Learn 的官方规范,整理重试策略的默认值、通过范围(Scope)实现的 Try-Catch、失败通知、重新提交与幂等性,直至并发控制。
用 Power Automate 设计定期执行流程 ── 月末处理・营业日判定・提醒的实务
本文整理用 Power Automate 的 Recurrence 触发器自动化定期处理的实践指南,涵盖默认时区为 UTC 的陷阱、日期表达式、基于法定节假日主数据表的营业日判定、催办设计,以及 90 天自动关闭等运维注意事项。
用 Power Automate 自动处理邮件收到的订单・发票 PDF ── 保存、分类、通知与读取的设计
本文整理用 Power Automate 自动化处理邮件收到的订单・发票 PDF 的保存、分类与通知设计,从 Outlook 触发器与共享邮箱的前提条件、签名图片误判的应对方法,到用 AI Builder 读取内容及其许可证注意事项,均以实务者视角进行解说。
相关主题
与本文相近的主题页面。以本文为起点,可以进一步了解相关服务和其他文章。
Windows 技术主题
汇整 KomuraSoft LLC 关于 Windows 开发、故障调查与既有资产活用文章的主题中心。
与本主题相关的服务
本文与以下服务页面相关联,欢迎从最接近的入口查看。
技术咨询 & 设计评审
协助梳理设计方向、架构边界、生命周期责任,以及既有 Windows 资产的处理方式。
既有资产活用 & 迁移支持
在持续活用 COM / ActiveX / OCX 资产、原生代码与 32 位依赖的同时,协助规划阶段性的迁移。
常见问题
汇总了咨询这一主题时常见的问题。
- 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 软件开发、技术咨询与故障排查为中心,擅长难以复现的故障调查,以及既有资产仍在运行的项目。