Skip to content

UiPath REFrameworkについて①

Posted in RPA, and UiPath

こんにちは、エピックです。

UiPathに開発のフレームワークがあるのはご存知でしょうか。

以前、Attended Framework というものを紹介させていただきました。

もちろんそちらもUiPathのフレームワークになるのですが、UiPathのフレームワークといえば Robotic Enterprise Framework 、通称REFrameworkが有名です。

大規模な導入で利用されると謳われるフレームワークですが、初見では結構難解です。

幸いにも、UiPath Academy の上級プログラムにて「REFramework 概論コース」が提供されておりこちらで概論を理解することができます。

今回は、そんなREFrameworkについて説明をしてみたいと思います。

では、いきましょー!


REFrameworkとはそもそも何なのか

繰り返しとなりますが、ReFrameworkとは、Robotic Enterprise Frameworkの略称でありUiPathが提供しているワークフロー開発のためのフレームワークになります。

(フレームワークとは、設計の骨組みのようなものであり、開発者の開発負担を減らすことを目的としています)

このワークフローの特徴として、ワークフローの開発において抑えるべき観点が網羅されていることが挙げられます。

つまり、このフレームワークを使いこなしてワークフローを開発できれば、UiPathの開発者としてこの上ないということであり、大規模開発においても通用するワークフローが開発可能であることを示します。


抑えるべき観点とは

先程、ワークフローを開発する際に抑えるべき観点という言葉を使いましたが、UiPath Academy では下記の4つの観点を開発の際に考慮する必要があると記載されています。

  • 信頼性
  • 効率性
  • 保守性
  • 拡張性

信頼性

「安定して動作する」「安全に動作する」の2つを実装できて初めてワークフローの信頼性が成り立ちます。

前者は、例外やエラーが起こった際にも意図したとおりにロボットが動作し、正常に、安定に動作することをいいます。

後者は、パスワードのハードコーディンによる漏洩の恐れがない・メールの自動送信におけるご送信がないなどのセキュリティ面における安全性についてとなります。

RPAを利用し業務を自動化した方であればわかるかと思いますが、自動化するのは簡単だが正常処理からハズレた場合の処理をどこまで考慮するかは非常に悩ましいです。

また、内容によっては例外処理のほうが工数がかかってしまうということもあるでしょうか。

この点において、基本的なエラーハンドリング標準で組み込まれているREFrameworkは非常に優れているといえるでしょう。


効率性

2つ目の観点は効率性です。

効率性とは、「効率的な開発ができる」「効率的なテストができる」ことがポイントとなります。

効率的な開発について、プロセスを操作単位ごとに分解しそれぞれ別のワークフローにて開発を行う、つまり部品化(パーツ化)を行う手法が推奨されています。

これは主に下記の点からです。

  • 類似業務において再利用が可能となる
  • 動作テストでは特定の操作のみ確認をすることができる
  • ワークフローの階層が浅くなるため、可読性が保持される
  • 修正の際、すべてのワークフローを修正する必要がない

REFrameworkは、直接的な効率性は提供しませんが、上記のような開発手法での開発でも問題が無いように設計されています。


保守性

「他の開発者でも保守できる」「継続した保守を実施しやすい」という点がポイントになります。

保守性を高めるのに一番良い方法は、開発の際の共有ルールを社内でつくってしまうことです。

命名ルールや配置ルールなんかはその一つでしょうか。

注釈を絶対につけるというのもよいと思います。

ただ最も効果的なのは、開発手法を統一してしまうことだと私は考えています。

この点において、REFrameworkの利用は社内の保守性を高めることにつながります。

※ただし大多数の社員が利用しているという前提に限る


拡張性

最後は拡張性です。

拡張性という言葉の解釈が難しいですが、要は小さく初めても大規模な展開が必要になった際、再度ワークフローの設計は必要なく、Robotの台数の調整のみで対応可能であるということをいいます。

REFrameworkは、Orchestratorのキューなど、トランザクションの考え方に基づいているため、たとえ処理の量が増えてもワークフローを作り直す必要はありません。


トランザクションという考え方

REFrameworkを理解する上で欠かせない考え方に、トランザクションがあります。

トランザクションとは、データを処理することをいい、この中で処理されるデータのことをトランザクションアイテムと言います。

REFrameworkを利用しないワークフローの組み立てには、一度だけ処理が行われる直線的な処理や処理の中で複数回反復が行われる反復処理がありますがこれらの処理はトランザクションのためのデータの取得は一度しか行われません。

一方で、REFrameworkでは、トランザクションデータの取得が複数回にわたり繰り返し行われるように設定されています。

これにより、万が一エラーが発生し処理が中断した場合も、発生した箇所を特定し隔離した上で、残りのデータの処理を続けるという処理を容易に実装する事ができます。


特殊なレイアウト「ステートマシン」

UiPathで開発の際に利用する一般的なワークフローレイアウトとして、「シーケンス」と「フローチャート」があることはご存知かと思います。

補足をしてきますと、シーケンスとは、上から下へ向かって処理が行われるワークフロー、フローチャートは視覚的な矢印で処理順序を定義することで処理を行わせるワークフローになります。

実は、これ以外にも「ステートマシン」というワークフローレイアウトがあります。

普通に業務を自動化している上では使わないレイアウトかと思います。

(私もREFrameworkを知るまで、というか今でもそれ以外には使ったことないです...)

このレイアウト少し複雑で、ステート(状態)によって処理の順序を定義します。

ステートの定義はかなり広く、例えば社員名簿の処理業務を例にあげれば、「対象データの社員番号が〇〇桁台である状態」や「社員の役職が〇〇である状態」というのはそれぞれ一つのステートとして定義することが出来ます。

また、ステートマシンはアクティビティ単位に分解をした場合、【ステート(State)】アクティビティ・【最終ステート(Final State)】アクティビティの2つのアクティビティより構成されています。

ステート(State)
最終ステート(Final State)

と、ステートマシンの概要について記載しましたがこれ以上の説明は避けたいと思います。

理由は、REFrameworkはたしかにステートマシンを利用しているのですが、テンプレートとあるようにステートマシンにて実装するべき箇所はすべて組み上がっています。

そのため、実際にREFrameworkを利用するとなった場合ステートマシン自体を改修することはなく、あくまでその中の具体的な処理の記述やパラメータの調整の実装のみとなります。

つまり、詳細的な理解はあったほうがいいが、必須ではありません。

もし、ステートマシンについて詳しく聞きたいというご要望をいただければ別記事にて説明してみたいと思います。

次回は、実際にREFramework見てみたいと思います。


一言

REFrameworkの利用って敷居が高いと思うんですよね。

だから、Advancedに設定されていると思うのですが、理解するのにかなり時間が要されると思います。

また、テンプレートのため社内で共通化することが望ましいと考えますが、そこまで出来ていいる企業様っているのでしょうか?

大変気になります。

というわけで、最後までお読みいただきありがとうございました。

ご質問等はコメントにていただければと思います。

では。


単行本(ソフトカバー): 208ページ 出版社: インプレス (2018/10/15)
単行本(ソフトカバー): 464ページ 出版社: 翔泳社 (2020/5/25)

Be First to Comment

コメントを残す