③私たちはOCとどう向き合うか（みやぎさん）

MVP SESSION 18:30～19:30 私たちは「OC」と どう向き合うか ～ UiPath Orchestrator の 運用のあれこれ ～ UiPath Japan MVP 2023 @miya_gis

■ ブレイク：最近 @miya_gis リモート x 4年 運動不足 11/29 放送終了 11/21 連載終了 2025 アニメ再開 モニター購入 スタンディングで 運動不足解消へ 行けなかった、昨日も 昨日でドラマ最終回 12/18発売の単行本で 追加ストーリー 次期「黄金郷」編

■ 今日の話 OC 運用の「困った」を 解決する 話 @miya_gis ・利用規模で事情は違うけれど… ・オンプレ or クラウド関係なく ・いくつかの現場での話 OCとは？OC運用で詰まること・困ること 例えばこんな感じで解決？ OCの webhook とは？使い方ポイント OCの API とは？使い方ポイント 実践 余談（時間があれば） Next) OCとは

■ Orchestrator（OC）とは？ @miya_gis 有人ロボットおよび無人ロボットの作業の準備、展開、 トリガー、監視、測定、追跡に必要な機能を提供 ⇒ ロボット の 管理機能（中規模以上で必須） ！運用実例・ナレッジが出にくい Next) OC運用 で 詰まる（困る）こと

■ OC運用 で 詰まる（困る）こと ※個人的ランキング 通知 (mail/popup) が使えない フォルダを跨いでジョブ結果が見れない 開始順でトリガーが見れない タイムトリガーのメンテが面倒 ログ検索で、日本語検索が使えない @miya_gis

■ OC運用 で 詰まる（困る）こと 通知 (mail/popup) が使えない @miya_gis 通知をカスタマイズする （次ページへ） フォルダを跨いでジョブ結果が見れない 見れる仕組みを作る （次ページへ） 開始順でトリガーが見れない 見れる仕組みを作る （次ページへ） タイムトリガーのメンテが面倒 ログ検索で、日本語検索が使えない RPAで自動更新する 検索見出しで英語を使う Next) 例えばこんな感じで（解決）

■ 例えばこんな感じで… @miya_gis OC の イベント を検出して、通知 （webhook） ジョブのエラーを送信 エラーの原因を調査 タスクの更新を送信 承認フロー進捗を確認 プロセスの変更を送信 証跡・不正の抑止 OC の 今の状態 を取得して、確認 （API） マシンのダウンを抽出 マシンを再起動 長時間実行中のジョブを抽出 ジョブを停止 無効になったトリガーを抽出 トリガー更新／削除 今日のジョブ＆トリガを取得 今日の実行予定＆実績を確認 Next) OCのwebhookとは

■ 事前知識 > OC の webhook とは？ @miya_gis

■ OCの webhook とは @miya_gis 特定イベントが発生したら、指定URLに情報送信 イベント一覧 アクション □ task.assignmentChanged □ task.completed □ task.created □ task.updated □ task.deleted □ task.forwarded □ task.saved □ task.sla.evaluate □ task.sla.update トリガー □ schedule.failed キュー アイテム □ queueItem.added □ queueItem.transactionCompleted □ queueItem.transactionFailed □ queueItem.transactionAbandoned □ queueItem.transactionStarted ジョブ □ job.completed □ job.faulted □ job.created □ job.stopped □ job.started □ job.suspended ロボット □ robot.created □ robot.deleted □ robot.updated □ robot.status キュー □ queue.created □ queue.deleted □ queue.updated プロセス □ process.created □ process.deleted □ process.updated Next) webhook の使い方ポイント①

■ OCの webhook の 使い方ポイント① @miya_gis 通知を受ける「パブリックなAPI」が必要 ⇒ 自分にとって「使いやすい or 覚えたい」ものを選ぶと良いかも （後で色々と「いじくる」ので） クラウドが好き：AWS-lambda / AzureFunctions / GoogleCloudFunction… 外部ツール好き：PowerAutomate/ GoogleAppsScript / IFTTT… UiPathにも Integration Service に「webhook(preview）」があるけれど… Next) webhook の使い方ポイント②

■ OCの webhook の 使い方ポイント②

@miya_gis

通知はテナント単位 ＝フォルダ全てのイベントが対象
⇒ フォルダID で 取捨選択 をする
ジョブエラー時のwebhook（例えば）
{
"Type": "job.faulted",
"Job": {
"StartTime": "2024-11-26T14:14:25.637Z",
"EndTime": "2024-11-26T14:14:26.2529616Z",
"Info": "RPA001 在庫集計処理が異常終了しま…",
"Release": {
"ProcessKey": "RPA001_在庫集計処理"
}
},
"TenantId": 2005,
"OrganizationUnitId": 49824

OCのフォルダ設定
テナント
├ EC事業部
（ID：49821）
├ ・・・
└ EC事業部_開発用 （ID：49824）

開発用なので把握不要

}

Next) OCのAPIとは

■ 事前知識 > OC の API とは？ @miya_gis

■ OCの API とは @miya_gis OCが提供するAPI（データの取得・作成・更新） □ AppTasks □ DirectoryService □ Folders □ FoldersNavigation □ JobTriggers □ Licensing □ Logs □ Maintenance □ PackageFeeds □ Releases □ Stats □ Status □ TestAutomation □ TestDataQueueActions □ Translations □ TaskForms □ Alerts □ Assets □ AuditLogs □ Buckets □ BusinessRules □ Calendars □ CredentialStores □ Environments □ ExecutionMedia □ Exports □ GenericTasks □ Jobs □ Libraries □ LicensesNamedUser □ LicensesRuntime □ Machines □ OrganizationUnits □ Permissions □ PersonalWorkspaces □ Processes □ ProcessSchedules □ QueueDefinitions □ QueueItemComments □ QueueItemEvents □ QueueItems □ QueueProcessingRecords □ QueueRetention □ Queues □ ReleaseRetention □ RobotLogs □ Robots □ Roles □ Webhooks □ Sessions □ Settings □ TaskActivities □ TaskCatalogs □ TaskDefinitions □ TaskNotes □ TaskRetention □ Tasks □ Tenants □ TestCaseDefinitions □ TestCaseExecutions □ TestDataQueueItems □ TestDataQueues □ TestSetExecutions □ TestSets □ TestSetSchedules □ Users Next) API の使い方ポイント①

■ OCの API の使い方ポイント① @miya_gis PrivateAccessToken を使うと認証が簡単 ⇒ その人に変わって実行してくれるイメージ Swagger を使うとテストが簡単 ⇒ 必要なパラメータ定義も書いてある テスト実行もできる Next) API の使い方ポイント②

■ OCの API の使い方ポイント② @miya_gis 制限がある（アクセス元IP・呼出回数） ⇒ IPを許可する／短時間に呼び出しすぎない エラーメッセージが分かりにくい ⇒ OC画面をデベロッパツールで見て参考にする Next) 実践①

■ 実践① > ジョブ 異常終了 をリアルタイム通知（webhook） @miya_gis

① ジョブ 異常終了 をリアルタイム通知（webhook） ほぼ、これ ＜違う点＞ ・Teams ⇒ Slack ・担当メンションあり @miya_gis

① ジョブ 異常終了 をリアルタイム通知（webhook）
Orchestrator

job.faulted

"Type": "job.faulted",
"Job": {
"Info": "処理が異常終了…",
"Release": {
"ProcessKey": "R01_在庫集計"
}
},
"TenantId": 2005,
"OrganizationUnitId": 49821
}

HTTP要求の受信時
unitIdが「本番」か
typeが「faulted」か

※ PowerAutomate なら
Teams通知に変更も簡単

post message

DataService

insert

{

Slack

API（PowerAutomate）

webhook

Process

Owner

R01_在庫集計

@miyagi

R02_・・・

@...

no

担当者を特定
slackに投稿

@miya_gis

・実行状況の確認用
（For Apps）

＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿New
Orchestrator-webhook（job.faulted） アプリ 09:14
エラーが発生しました。
[フォルダ] EC事業部（49821） [マシン] VM008
[プロセス] R01_在庫集計
[担当] @miyagi
2024-11-30 13:24 処理が異常終了しました。login.xaml : クリッ
ク '実行’ このUI要素は有効ではありません。…

dataserviceにinsert
終了

※ PowerAutomate は有料版（¥2228/月～）を使用

「メンション通知」が来たら対応（監視不要）
異常終了以外にも「Stopped」等も要チェック

■ 実践② > 本日の ジョブ実行状況 を通知（API） @miya_gis

② 本日の ジョブ実行状況 を通知（API） ほぼ、これ (2回目) ＜違う点＞ ・予定も取得 ・マシン名も取得 ・実行元も取得 @miya_gis

② 本日の ジョブ実行状況 を通知（API） Orchestrator Process（TimeTrigger） @miya_gis Slack post message API）Jobs（実績） ProcessSchedules（予定） 本番フォルダループ ジョブ取得 プロセススケジュール取得 ジョブとプロセススケジュールを合体 マシン別・開始順に並び替え ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿New Orchestrator-ジョブ実行状況（14:55現在） アプリ 14:56 VirtualMachine008 09:00-09:03 (0:03:18) 13:20-13:24 (0:04:51) 13:40-13:58 (0:18:23) 成功 ❍ Q01_サンクスメール送信 失敗 R01_在庫集計 成功 ❍ R01_在庫集計 ※OC手動実行 VirtualMachine009 14:00-14:53 (0:53:06) 15:00- 成功 ❍ T08_予約データ連携 ※Assistant実行 T03_外部連携データ作成 指定なし 15:30- 月次集計 Slackにメッセージ投稿 マシンごとに「実績」と「予定」が見れる 「どこから」の実行で「何分」掛かったか？が分かる

■ 余談 > その他、あれこれ（OC編） @miya_gis

■ 余談① @miya_gis Q）「フォルダ」をどう割れば良い？ ⇒ なるべく「割らない」（同じフォルダのほうが把握しやすい） 同フォルダ内のマシンで「分担」できる（処理枠の活用） 「開発/本番」や「権限」で割るのはあり（仕方ない？） Next) 実行枠が足りないとき

■ 余談② @miya_gis Q）「実行枠」が足りない！ どうする？ ⇒ 「占有」ジョブを減らす（処理時間を短く） 「処理に制限」を入れる（件数制限・時間制限） 「タイムトリガー」で開始を被らせる（詰め込む） 「空いている時間」を使う（早朝・業後・夜間など） 「複数マシン」で実行分散（フォルダ内マシン） Next) 別プロセスにするメリット

■ 余談③ @miya_gis Q）「別プロセス 」にするメリットは？ ※プロセス作成の流れ）パブリッシュ > パッケージ追加 > プロセス作成 > トリガ作成 ⇒ 「同プロセス制約」回避（実行待キューに重複プロセスNG） 「見た目」で区別できる（選びやすい・ジョブ一覧で分かる） ！この辺の「プロセスをどう作るか？」「トリガーとの違い」の公開ナレッジ少ない… Next) OCがダウンしたら

■ 余談④ @miya_gis Q）OC が「サービスダウン」したらどうする？ ⇒ 基本は「その時」に頑張る（手動実行祭？） ダウンを「検知」する仕組みは必要（手順でも可） そんなに無いはず（年数回？数時間？） Next) クラウドOCは大変？

■ 余談⑤ @miya_gis Q）クラウド OC は「更新」に付いて行くの大変？ ⇒ 慣れ れば大した事ない（すぐ慣れる） リリースノート を定期的に見る（月に数回リリースあり） 機能追加 のメリットのほうが大きい（破壊的変更は少ない） OCの VersionUP の計画が不要に（ハードウェアメンテも不要） 新機能を利用するために Studio/Robot の更新 も必須 Next) クラウドOCの凄い機能

■ 余談⑥ @miya_gis Q）クラウド OC の「これは凄い」という機能は？ ⇒ 実行中画面の自動録画（リモート制御はVNCへの抵抗が） API の実装 が 楽（PAT認証） ElasticRobotOrchestration（マシンのオートスケール） サーバーレス ロボット（実行マシン不要） AutomationCloudDedicated（プライベートクラウドOC）

■ 余談 > その他、あれこれ（その他） @miya_gis

■ 余談① Q）「開発」する人 と「運用」する人を分ける？ ⇒ 有識者（≒作った人）が保守するのが一番良い 分離せず、エラーを振り分け、確実に届けること @miya_gis

■ 余談② Q）欲しい機能が「公式提供」されるまで待つ？ ⇒ 提供される保証は無い（提供されない事も多い） 要望は出しつつ、自分たちで作ることも考える @miya_gis

■ 余談③ @miya_gis Q）開発の「速さ」と「品質」はどっちが大事？ ⇒ 「両方」とも大事 早くて品質の高い「ギリギリ」を攻める（これに尽きる） 品質の「高低・ムラ」があって良い（全部100点はムリ） 「作る人のレベル」はどんどん上げる（より早く品質高く）

■ 余談④ @miya_gis Q）RPAは どうすれば「安定稼働」する？ ⇒ 「止まる／直す」前提で作る（早くシンプルに） 「局所的／包括的」なリトライ（リトライしてOKなら） （ヒーリングエージェントにも期待） 「運用と開発」を近くする（実行状況を見える化）

@miya_gis 終わり Thank you UiPath Friends Festival 2024 MVP Session ～ 私たちはOCとどう向き合うか？～ 34