【UiPath】Coded Automationとは？（前編）

# はじめに

この投稿は、RPAツール「UiPath」で 2023年6月にリリースされた「Coded Automation」について「個人的に」まとめたものです。


2023年7月開催の「UiPathブログ 発信チャレンジサマー」の7日目の記事でもあります。

https://note.com/shumpei_w/n/nd082bdf28853


# 公式リリース

紹介する情報は、以下の「UiPath公式リリース」を元にしています。

https://docs.uipath.com/ja/studio/standalone/2023.10/user-guide/coded-automations-introduction

※ 2023年7月7日時点では「コミュニティ版のみ」の「プレビューリリース」という扱いです。今後、機能変更・追加がされるはず。

なので、この記事の閲覧タイミングでは、以下で紹介する内容と変わっている可能性があります。


# Coded Automation とは？

Studioでシーケンスやフローチャートを作るように「`1）コード化されたワークフロー／2）コード化されたテストケース／3）コードのソースファイル`」を作成できるようになりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/cdbee44f-ec55-85c1-df8d-db45e8d2a593.png)

:::note warn
・Windowsまたはクロスプラットフォームプロジェクトで使用可（Windowsレガシは対象外）
・StudioVersion「23.6」以降で使用可
・System.Activities/UiAutomationパッケージ等は「23.6」以降で使用可
:::

選択して新規作成すると、以下のような画面（コード）が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/75edf3c1-9ec2-bfa2-9d54-072e7446962c.png)
従来のような「アクティビティを配置する」形ではなく、コードを沢山書いて自動化処理を実現できます。（もう「ローコード・ノーコード」では無い感じ）

:::note info
「ワークフロー・テストケース」は今までのxamlの代わりに使用できます。
ソースファイルは「ヘルパークラス／ユーティリティクラス／構造体クラス」として使うみたいです。
:::

「コードを沢山書くRPAなんて嫌だ」という声もあると思いますが、どうやらこれは「`従来と違うユーザーへのアプローチ`」みたいです。リリースノートには、以下のように記載があります。（以下、英語リリースをGoogle翻訳したもの）

```
ローコードおよびノー​​コードは、テストとビジネス プロセス (RPA) の両方の自動化を
構築するための主流のアプローチとして浮上しています。
これらの機能により、新世代の開発者の出現が可能になり、技術力の低い専門家による
開発が効果的に民主化されました。
しかし、より技術的なテスターや RPA 開発者は、ローコードの自動化が理解しにくく、
柔軟性が低く、保守が難しいと感じている人もたくさんいます。
・・・
コードを好む開発者のために、UiPath Studioのコード化されたオートメーションを導入します。

コード化されたオートメーションは、コーディングやスクリプトに精通している人なら誰でも、
使い慣れた環境で作業するため学習曲線を短縮しながら、生産性の向上、複雑さの管理の向上、
コラボレーションとレビューの容易性の向上、可読性の向上、パフォーマンスの向上を体験
できるように設計されています。

私たちの調査によると、自動化開発者の約 40% が自分自身にプログラミング スキルがあると
評価しており、残りの約 25% がスクリプト (通常は ExcelVBA？) の経験があります。
```

現状、コードは「C#」で書く必要があるので、C#の開発経験がない場合は、難しく感じるかもしれませんが、中身を見る限り「基本的なクラス実装」が出来れば実装できます。カスタムアクティビティをC#で実装できるレベルであれば、問題ないでしょう。

`「コードをたくさん書く」＝「保守できる人が限られてしまう」`という意味では、現場・チームによっては保守性は落ちると思いますが、前述の通りこれは「`新しい選択肢`」として捉えるべきでしょう。使わくても良い。

ちなみに、公式ドキュメントで書かれている「コード化されたオートメーション」のメリットは以下です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/d4c2ccca-9701-64e9-58b9-fcee237d927d.png)
あと追加するなら

```
6. 「Coded Automation」で実装できれば、カスタムアクティビティの代わりに使用できそう
7. 生成AIが「Coded Automation」のコードを教えてくれる未来が来れば、コピペで実装可能
```

とも言えるかもしれません。
なので、`用途・シーンによってはメリットがありそう`です。


# Coded Automation の種類と概要

改めて見てみると、コードで作成できるものは、以下の3種類です。

| No | ファイル種類 | 用途 |
|:-|:-|:-|
|1 |コード化されたワークフロー|ワークフロー.xamlの代わり|
|2 |コード化されたテストケース|テストケース.xamlの代わり|
|3 |コードのソースファイル|ヘルパークラス／ユーティリティクラス／構造体クラス|

「3）コードのソースファイル」は（少し難しいかもですが）、ちょっとした加工処理だったり、構造体として使うイメージかなと思いました。構造体というのは、データ専用の箱です。

https://learn.microsoft.com/ja-jp/dotnet/csharp/language-reference/builtin-types/struct

例えば、ECサイトから「商品・価格・説明」などの情報をスクレイピングしたい時には、今までだと「DataTable型（商品名・価格などの列定義がある）」に情報を入れて管理する、のがよくある形だと思いますが、この構造体クラスを用意すれば、DataTableの代わりに使用でき、独自の計算式や編集も内部に持たせることで、柔軟に操作・参照することが出来ます。

つまり、この「コード化されたワークフロー（テストケース）」と「コードのソースファイル」を使うことで

```
・従来のワークフロー.xamlの代わりに「コード化されたワークフロー.cs」で処理を記載が出来る
・カスタムクラスとして、独自の型／構造体／汎用処理させる定義を「コードのソースファイル.cs」に書ける
```

ということ、みたいです。


# 試しに「コード化されたワークフロー」を呼び出してみる

この「コード化されたワークフロー」ですが「`xamlファイルから呼び出す`」ことも「`他のxamlファイルを呼び出す`」ことも出来ます。

例えば「今までxamlで書いていた」箇所を「CSharp」のコードで置き換えて、`シンプルにしたり高速化したり`出来ます。また、今までは「カスタムアクティビティ」に頼って処理していた部分も、自分で頑張って実装することも出来そうです。InvokeCodeでは処理的に限界があった事も「コード化されたオートメーション」なら実現できるかも。

以下は、Main.xamlから「コード化されたワークフロー.cs」を呼び出し、その中で他のxamlを呼び出したものです。

![image (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/af04f7c1-5257-9cfd-c391-73251d997bd8.png)

実行するとこんな感じになりました。（xamlとcsを引数を渡しながら行き来してます）
![image (9).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/2f6a14b2-55b8-5cbe-25bd-8bd590aa3980.png)

# 見て学ぶ、書いて覚える

まだ色々検証・調査中なので、具体的な記事として書けないのですが、
興味がある方は、以下のサンプルコードを見てみると、イメージが湧いて面白いかもです。

https://github.com/UiPath/codedautomations-samples


# 終わりに

以上、簡単な紹介でした。
次回は後編として「Coded Automation」で具体的な自動化操作をしてみたいと思います。

この記事が参考になったら、 いいね をお願いします。閲覧ありがとうございました。