先日久しぶりに開発した、Citrix(仮想環境)モードについてお話します。

1.Citrix(仮想化)モードについて

ざっくりいうと、Selectorが使えない(=Ui要素(Element)が取得できない)環境での開発です。
以下のような特徴があります。
①クリックするのはImage(画像)
②Find Elementや Element Existsの の 代わりに Find Imageや Image Existsを使う
③Image(画像)が掴みにくい(変化する)ときは、その近くの常に変わらない画像をAnchor(アンカー=錨)として指定する。
(アンカーからの位置情報で判断して、例えばクリックする画像を見つける)
④クリックが難しいこともあるので、ファンクションキーやタブキー等のショートカットを使うことが多い。

↓画面のイメージは、こんな感じです。
例えば Clickアクティビティを選んでも UiExploreを選んでも
画面全体がブルーグレーになって、なにも選択できません。

つまり、画像データでしか認識できないため、武器は画像(image)と、ショートカット(sendHotKey等)のみとなります。
画像認識メインの「WinActor」と同じ程度の戦力になるイメージです。

この説明だけでは、Citrixの開発のイメージがわかない方は、まずは、UiPathアカデミーのCitrixの項をざっくり見ることをオススメします。

2.どんな開発をしたか?

Citrix(仮想化画面)上での、予め用意されたリストの処理。
RPAのレベルで考えたら、かなり単純なレベルになると思います。

①業務内容
・予算設定入力大量処理
・SAPのシステムを動かす。ボタン押しと入力の単純作業。
・コード毎に配賦された金額を登録するというのが最終形で、予め入力データをリストに作っておきます。

②承認者と申請者が相互に作業する
・承認者:1.コードや年度を入れて設定解除する。
・申請者:2.1の少し発展系、金額も入れる。
・申請者:3.コードを入れて印刷する
・申請者:4.印刷分は目で再鑑する
・申請者:5.コードを入れて申請ボタンを押す
・承認者:6.以降の承認は手作業(citrixでは数字が読み取れないため、ここが限界)

③開発の制約
とても忙しい期末・期初にしか発生しない。その時でしか開発できない。

3.今回のケースのUiPathの構成(今回の反省を踏まえています)

①メイン(Citrix部分)の作成
コードを入力して、登録する(等)の繰り返しフローの部分を作る
ここが一番キモで、これが上手くいかないときは、手こずる。

②Excelのリストを読み込み、ForEachRowの箱を作る。

③②の箱に、①のメイン自動記録モードを入れ込む。
※今回のように似たような処理(申請者・承認者)がある場合は、Invokeを活用すると、すっきりしてわかりやすい。

④Excelのリスト上に、1件ずつの「成功・失敗」を、書き込むするフローを追加しておく

⑤処理が終わったら「終わり」メッセージをつける

実際は、こんな感じです。
(①以外のフローは  で詳しく書いています。 

【実践編:Ifを使った条件分岐が複雑になるとき_Invoke Workflow Fileで別のxamlに飛ばす/Dictionary変数を使う】

 

4.Citrix(仮想環境)の作り方・コツなど

①繰り返し部分(コードを入力する)画面まで進めておく

例えばSAPの画面等の左側を遷移するのは、「揺れ」が大きいのです。
「権限によって項目表示が異なる」「前回終了した場所によって見え方が違う」等が要因です。
そして、そこをカバーする開発には、かなり時間がかかります。
だったら、どうせ起動するのですから、コードを入力する画面まで進んでから、RPAをスタートしましょう。
どこまで画面を進めるかは、メッセージで誘導します。
(いかにも「THE ユーザ開発」ですが、コストをかけずに安定して動けば良いと割り切りましょう。)
そして、今後メニューが変わっても、RPAを修正しなくて済みます。

②自動記録の際は、以下のいずれかだが、確実性を重視すると「ショートカット」が便利
・クリック・TypeInto(文字を入力)/イメージを自分で選ぶ
・ショートカット作戦(SendHotKey・SetToClipbord等によるファンクションキーやタブ等)

③ショートカット作戦での注意
ショートカット作戦は目をつぶって処理しているのと同じと考える。
なのでCitrixモードで、表データを1件ずつ実行するときは、以下をした方が良い。
・画面遷移後に、Find image や image Exist(画像イメージの存在チェック)で、ちゃんと画面が変わったかチェックする。
(いつもの処理でも、ショートカットを使う時は、暴走しないようにFind Element や ElementExistsを使う事は結構あると思います。)
・Excelの処理リスト(の1行ずつ)に、成功・失敗を書き込む。
※作成時やテストの際は、それなりに動くのですが、コード入力した後「該当なし」等が発生しても、
動き続けるので、「ストッパーの設置」(動いているかチェックする仕組み)を作らないと痛い目を見ます。

④ターゲットのボタンが上手く押せない(安定して押せない)時は、アンカー指定を考える
今回印刷ボタンを押した後の、印刷ウィンドウのOKがどうしても押せなくて苦労しました。
ショートカット作戦(send hot key)もダメ。
ふっと思いついて、OKの隣の「キャンセルボタンをアンカー指定」したら、スムーズにうごくようになりました。
(あ、これ『WinActor』で経験したやつだ。画面遷移時に見た目が変わる、アイコンや文字は選んじゃダメなのよね)

⑤本当にやむを得ない時は「Delay」も使う
画面遷移の待ち時間を指定する「Delay」ですが、大体「使うのをオススメしない」という但し書きがついてますね。(それよりFind Elementを使えとか)
でもUi要素が掴めないので、しょうが無い時もあります。
ただし、RPA自体が多少遅くなっても仕方が無いという気持ちで多めに時間を取る必要があります。

5.反省を踏まえた開発方法にたどりついた理由(失敗談や気づき)

①開発は計画的に

業務が実際に発生する時期(繁忙期)にしか出来ない上、他の業務の合間のRPAの開発のため、手が回らず
本番時に「試しにやってみよう。出来たら本番開発に」という怪しいプラン。
思ったより簡単にCitirx部分(画面遷移等)ができた為(過去に作った元ネタが転用できました)
この「承認解除」が出来るなら「申請金額入力」も「申請ボタン押下」も、といった雑な「開発プロセス」。
これが良くなかった。
似てるけど、ちょっと違う処理は、一度だけなら作りっぱなしにできるけど、
次回も使うためには、差分を洗い出しながら作らないと、最終仕上げに想定以上に時間がかかってしまいました。
(というか、まだ仕上げていません)
※時間が取れないからこそ、予めヒアリングして、上手く作る(=Invokeの仕組みをきちんと使う)方が良かったです。

②手作業とRPAは違う

手作業だと、無意識にエラーを回避します。
たとえば、コードに重複があったら、2回目に入力した際に、既に金額が入っているので気づくので二重入力をしません。
またRPAを動かしてみたらエラーがあり、「どうして?」ときいたら、「あ、そういう時もあって、その時の対応は」みたいに、
使用者は完全な要件定義はできません。
その対応としては、以下をプロセスに組み込むことが大事です。
(1)入力リストの整備をきちんとする(重複を予め排除する)…Excel上でチェックすれば良し。
(2)「成功」「失敗」をリストに書き込む

③Citrixは入力された数字やコードは読めないので、最後は人の目も使う

OCRモードもありますが、まず使えないです。
再鑑には、印字する、データを出力する、最後は人の目で画面を見ながら確認する等のプロセスが必要です。
(②で重複チェックをしても防ぎきれない可能性もあります。)

↓日記の目次を作りました。
RPA体験談【目次(主にUiPathについて書いています)】

 

 

 

 

前へ次へ