はじめに
この投稿は、RPAツール「UiPath」で 2023年6月にリリースされた「Coded Automation」について「個人的に」まとめたものです。
2023年7月開催の「UiPathブログ 発信チャレンジサマー」の7日目の記事でもあります。
公式リリース
紹介する情報は、以下の「UiPath公式リリース」を元にしています。
※ 2023年7月7日時点では「コミュニティ版のみ」の「プレビューリリース」という扱いです。今後、機能変更・追加がされるはず。
なので、この記事の閲覧タイミングでは、以下で紹介する内容と変わっている可能性があります。
Coded Automation とは？
Studioでシーケンスやフローチャートを作るように「1）コード化されたワークフロー／2）コード化されたテストケース／3）コードのソースファイル」を作成できるようになりました。
・Windowsまたはクロスプラットフォームプロジェクトで使用可（Windowsレガシは対象外）
・StudioVersion「23.6」以降で使用可
・System.Activities/UiAutomationパッケージ等は「23.6」以降で使用可
選択して新規作成すると、以下のような画面（コード）が表示されます。
従来のような「アクティビティを配置する」形ではなく、コードを沢山書いて自動化処理を実現できます。（もう「ローコード・ノーコード」では無い感じ）
「ワークフロー・テストケース」は今までのxamlの代わりに使用できます。
ソースファイルは「ヘルパークラス／ユーティリティクラス／構造体クラス」として使うみたいです。
「コードを沢山書くRPAなんて嫌だ」という声もあると思いますが、どうやらこれは「従来と違うユーザーへのアプローチ」みたいです。リリースノートには、以下のように記載があります。（以下、英語リリースをGoogle翻訳したもの）
ローコードおよびノーコードは、テストとビジネス プロセス (RPA) の両方の自動化を
構築するための主流のアプローチとして浮上しています。
これらの機能により、新世代の開発者の出現が可能になり、技術力の低い専門家による
開発が効果的に民主化されました。
しかし、より技術的なテスターや RPA 開発者は、ローコードの自動化が理解しにくく、
柔軟性が低く、保守が難しいと感じている人もたくさんいます。
・・・
コードを好む開発者のために、UiPath Studioのコード化されたオートメーションを導入します。
コード化されたオートメーションは、コーディングやスクリプトに精通している人なら誰でも、
使い慣れた環境で作業するため学習曲線を短縮しながら、生産性の向上、複雑さの管理の向上、
コラボレーションとレビューの容易性の向上、可読性の向上、パフォーマンスの向上を体験
できるように設計されています。
私たちの調査によると、自動化開発者の約 40% が自分自身にプログラミング スキルがあると
評価しており、残りの約 25% がスクリプト (通常は ExcelVBA？) の経験があります。
現状、コードは「C#」で書く必要があるので、C#の開発経験がない場合は、難しく感じるかもしれませんが、中身を見る限り「基本的なクラス実装」が出来れば実装できます。カスタムアクティビティをC#で実装できるレベルであれば、問題ないでしょう。
「コードをたくさん書く」＝「保守できる人が限られてしまう」という意味では、現場・チームによっては保守性は落ちると思いますが、前述の通りこれは「新しい選択肢」として捉えるべきでしょう。使わくても良い。
ちなみに、公式ドキュメントで書かれている「コード化されたオートメーション」のメリットは以下です。
あと追加するなら
6. 「Coded Automation」で実装できれば、カスタムアクティビティの代わりに使用できそう
7. 生成AIが「Coded Automation」のコードを教えてくれる未来が来れば、コピペで実装可能
とも言えるかもしれません。
なので、用途・シーンによってはメリットがありそうです。
Coded Automation の種類と概要
改めて見てみると、コードで作成できるものは、以下の3種類です。
| No | ファイル種類 | 用途 |
|---|---|---|
| 1 | コード化されたワークフロー | ワークフロー.xamlの代わり |
| 2 | コード化されたテストケース | テストケース.xamlの代わり |
| 3 | コードのソースファイル | ヘルパークラス／ユーティリティクラス／構造体クラス |
「3）コードのソースファイル」は（少し難しいかもですが）、ちょっとした加工処理だったり、構造体として使うイメージかなと思いました。構造体というのは、データ専用の箱です。
例えば、ECサイトから「商品・価格・説明」などの情報をスクレイピングしたい時には、今までだと「DataTable型（商品名・価格などの列定義がある）」に情報を入れて管理する、のがよくある形だと思いますが、この構造体クラスを用意すれば、DataTableの代わりに使用でき、独自の計算式や編集も内部に持たせることで、柔軟に操作・参照することが出来ます。
つまり、この「コード化されたワークフロー（テストケース）」と「コードのソースファイル」を使うことで
・従来のワークフロー.xamlの代わりに「コード化されたワークフロー.cs」で処理を記載が出来る
・カスタムクラスとして、独自の型／構造体／汎用処理させる定義を「コードのソースファイル.cs」に書ける
ということ、みたいです。
試しに「コード化されたワークフロー」を呼び出してみる
この「コード化されたワークフロー」ですが「xamlファイルから呼び出す」ことも「他のxamlファイルを呼び出す」ことも出来ます。
例えば「今までxamlで書いていた」箇所を「CSharp」のコードで置き換えて、シンプルにしたり高速化したり出来ます。また、今までは「カスタムアクティビティ」に頼って処理していた部分も、自分で頑張って実装することも出来そうです。InvokeCodeでは処理的に限界があった事も「コード化されたオートメーション」なら実現できるかも。
以下は、Main.xamlから「コード化されたワークフロー.cs」を呼び出し、その中で他のxamlを呼び出したものです。
実行するとこんな感じになりました。（xamlとcsを引数を渡しながら行き来してます）
見て学ぶ、書いて覚える
まだ色々検証・調査中なので、具体的な記事として書けないのですが、
興味がある方は、以下のサンプルコードを見てみると、イメージが湧いて面白いかもです。
終わりに
以上、簡単な紹介でした。
次回は後編として「Coded Automation」で具体的な自動化操作をしてみたいと思います。
この記事が参考になったら、 いいね をお願いします。閲覧ありがとうございました。