更新时间: 试题数量: 购买人数: 提供作者:

有效期: 个月

章节介绍: 共有个章节

收藏
搜索
题库预览
为什么要拆子流? 复用、易维护、单点修复;也便于异常隔离(子流失败不拖垮主流)。 参数传递两端 输入变量:主流→子流,传入上下文(如待处理文件列表、登录凭据指针)。 输出变量:子流→主流,回传执行结果(计数、错误明细、关键 I 命名规范与类型约束(布尔/数值/文本/列表/字典)能显著减少“错绑”。 和云端流的数据回传 云端流调用 PA 7) “云端流 + PAD” 的协同编排(常见企业级闭环) 常见链路 云端流触发事件(如“审批通过”)→ 调用桌面流 完成在旧系统的录入/导出 → 桌面流输出结果(编号/状态/截图路径)→ 云端流继续收口(通知、归档、异常派单)。 协同设计要点 云端流负责编排:触发/路由/重试/补偿; PA 失败即回传明确错误码/截图,便于云端分支处理(自动重试/转人工)。 8) 无人值守运行(Unattende 前置条件 禁止屏保/自动锁屏,确保会话可见;对 VM 建议专用镜像与开机脚本自检。把“屏保与会话锁定设置”列为关键注意项。 一台机器人一次只能执行一个桌面流(并行需排队/多机扩容),参考全局开发/许可指引的说明。 调度与队列 多任务集中发起时,用队列/调度“削峰填谷”,避免资源争用与登录互踢。 环境隔离 生产机上尽量最小化软件组合,避免系统弹窗/自动更新打断机器人。 外设/打印/多屏等差异会改变控件坐标与层级,尽量统一模板。 9) 异常处理:截图 + 继续/终止策略 + 审计(把失败变成“可管理的失败”) 全局异常处理块 在主流与关键子流外层放置全局异常处理,捕捉未预期错误,自动截图、记录上下文(输入参数、当前页面标题、已处理数量),再决定“终止或继续”。明确推荐“全局异常处理 + 截图”。 可恢复设计 关键步骤设计幂等(例如根据唯一键判断是否已处理),配合断点续跑(从上次成功点继续),避免“半程失败就全推倒重来”。 3 审计与回溯 输出“运行日志 + 证据(截图/导出文件路径)”到固定盘/SharePoint 库;云端流可基于该明细做周报/异常汇总。 10) 上线与运维清单(落地即可用) 元素选择器体检:唯一、稳定、避免易变属性,必要时用父子锚点。 3 等待机制替代固定延时:所有关键点击前都要“等可点击/可见”。 Excel 起手式:启动实例→打开→批量读写→保存关闭→释放。 异常铁三角:全局捕获 + 截图 + 日志(含输入参数/页面标题/错误文本)。 无人值守前置:关屏保/锁屏、统一分辨率/缩放、单机单流、用队列控并发。 , 与云端协同:云端编排重试与补偿;PA 小结 PA 和云端流配合,才能把“脚本”升级为“可运营的自动化服务”。 真正的稳定来自工程化:参数化、子流化、证据化、队列化。 ⭐第三部分:Power BI(数据模型 + DAX + 发布共享) 1) 总体框架:Power Query(整形)→ 语义模型(建模)→ 报表(表达) 三层分工要记牢:Power Query 负责获取与清洗数据;语义模型承载表、关系、度量等逻辑;报表负责可视化与交互。 “语义模型”明确为表/关系/度量的载体,不是主题或布局。 标准工作流(常见于内部培训材料):Desktop 中完成获取/整形/建模/报表 → 发布到 Power BI Servic 牢记:仪表板只能在 Servic 2) Power Query(数据清洗)——“好模型的一半来自这里” 职责与定位 PQ 是 ETL(抽取、转换、加载)工具:合并/追加、去重、透视/逆透视、类型修正、缺失值处理、列拆分、格式标准化等。 两个高频操作:合并 vs 追加 合并(Join):横向拼接字段,用键把两个表“对齐”后补充列(比如将“客户主数据”合到交易明细)。 追加(Appen 最佳实践 在 PQ 阶段就修正数据类型(日期/文本/数值),避免进模型后难以定位问题。 尽量在 PQ 做“脏活”,让模型更“干净轻盈”,报表计算才稳。 3) 数据建模:星型模型优先,关系尽量单向