【RPA】UiPathの開発規約について

初めまして。AI&ロボティクスセンター 江草です。

普段の業務はRPAの技術支援で、お客様先で開発したり、Q&A対応を行っております。RPA歴ちょうど1年になりますが、初めての投稿になります。(決して、サボっていたわけではないですよ。)

今回は、開発規約についてお話ししたいと思います。

技術支援の際に、お客様からよく似たような質問を受けることがあります。
読者の皆さんも、どっちのアクティビティを使用したほうが良いのか、どの単位でワークフローを分割すべきなのか、悩むことありませんか?
私も最初の頃は同じ疑問をもっていました。

クレスコではプロジェクトで培ったノウハウやベストプラクティスを開発規約として集約しています。
本日は開発規約として定義すべき内容を紹介してみようと思います。

1.ワークフローの分割単位について

メインファイルだけで分割せずにロボットを作ることもできてしまいます。
例えば、レコーディングで作成すると、1シーケンスとして出力されてしまうこともあり、
読者の皆さんの中にも、メインのみで構成されたプロジェクトを作ってる方もいらっしゃるのではないでしょうか?

しかし、メインファイルだけで作成してしまうと、一機能をテストしたいのに、そのほかの処理まで待たなければなりません。
また、一つのワークフローに200アクティビティ以上配置してしまうと、Studioの動作が重たくなります。

そのため、適切な単位でワークフローを分割する必要があります。

分割する際のメリットとデメリット

 メリット  デメリット
1.ワークフロー単位で変数を設定するため、変数が多くならず可読性が上がる。 1.Invokeの階層が深くなると引数の設定箇所が増えるため、修正漏れが発生する可能性がある。
2.機能単位や画面単位での単体テストがしやすくなる。 2.開発途中でワークフロー分割する際に、変数から引数への修正が必要になる。
3.分割したワークフローを使い回しできる。 3.汎用性が高いワークフローを設計するため、設計コストがかかる。

分割する際の分割単位の考え方

画面遷移毎に分割

対象の処理画面から次の遷移画面までを一つのワークフローとします。
画面毎に分割することで、機能追加や修正する際に、どこのワークフローを修正すればよいのか特定しやすくなり、単体テストも容易になります。

機能ごとに分割

以下の図では、日当計算機能を一つのワークフローとして分割しています。
機能ごとに分割することで、そのほかの処理でも機能を使いまわしすることができます。

2.設計について

普段、実装する前に設計を書いていますか?
条件が少なそうだからSeqenceワークフローで書いてみたら、終わってみたら、IFのネスト深くなることがあります。最初のころは、自分はよくありました。(笑)
設計なしで実装すると、複雑な条件になるかどうか、分からないのですよね。

設計の段階で、条件が複雑にならないようにワークフローを分割することが大切になります。
そのため、設計を考えてから、開発することを推奨しています。

そうすることで、ワークフローの分割をあらかじめ決めることができます。
また、設計時に積極的に共通部品を使うなど検討ができるため、開発効率を上げることができます。

3.DisplayNameについて

UiPathではエラーが発生した際、エラーが発生したアクティビティのDisplayNameがログや画面に出力されます。ただし、DisplayNameが⼀意でないと、どちらのアクティビティでエラーが発生したのか特定しずらくなります。
自動的にDisplayNameが振られることがありますが、一意になるように処理内容を書くことを推奨しています。


開発規約として定義すべき内容を一部紹介しましたが、いかがでしたか?
少しでも設計や開発規約を作る際に、お役に立てば幸いです。

  • このエントリーをはてなブックマークに追加

クレスコのRPAセミナー

クレスコではAIやRPAをテーマとした技術セミナーを定期的に開催しています。現役エンジニアが実践的なノウハウを提供します。ぜひご活用ください。

◆受講者の声
[無料セミナー]RPA導入ファーストステップ
「UiPathのデモ、各ツールの比較が分かりやすく有益と感じた。」
「RPA導入で種々の問題点があるので、”つまずき”の部分が参考になった。」

[有料セミナー]UiPath開発基礎ハンズオン
「セレクターのチューニング、UiExplorerの使用方法が、明日からすぐにでも実践できそう。」
「RPA導入新任者向け研修として最適。今後、当社のRPA開発者向け研修として活用させていただく事を検討します。」


クレスコのRPAセミナーを詳しく見る