RPAにおけるインテグレーションのためのライブラリ開発

NuGetパッケージの作成

次に「NuGet Package Explorer」を起動し、「Create a new package」を選択します。

NuGetパッケージの作成

「Package contents」のペインで、右クリックのメニューより、「Add Lib Folder」を選択し、「lib」という名称のフォルダを作成します。

libフォルダ作成

この「lib」のアイコン上にて再び右クリックのメニューより「Add Exisiting File...」で、作成したライブラリを取り込みます。ここではAwsS3Activity.dllとAwsS3Activity.pdbの2つを取り込みます。

取り込むライブラリの指定

次に左側の「Package metadata」のペインを編集していきます。「Edit Metadata」のボタンより、NuGetパッケージの情報を設定します。

パッケージ情報を設定

次にPackage metadataと書かれた部分の下にある「<>」のボタンより、AWSSDK.S3などとの依存関係の定義を行います。「Edit Metadata」の「Edit Dependencies」の機能からも設定できるようですが、筆者の環境では何かしらの問題でこちらが機能しなかったため、XML形式で直接定義を記載します。

依存関係の定義

dependencyタグに参照しているAWSSDK.CoreとAWSSDK.S3の情報を記載します。バージョンについては、Visual Studioで参照しているものと同じとしています。

<dependencies>
  <dependency id="AWSSDK.Core" version="3.3.104.14" />
  <dependency id="AWSSDK.S3" version="3.3.110.10" />
</dependencies>

依存関係（XML形式）

最後に適当な場所に「AwsS3Activities.0.0.5.nupkg」という名称で保存をします。

NuGetパッケージを保存

UiPath Studioでの検証

UiPath Studioにて適当なプロジェクトを作り、パッケージ管理より、作成したNuGetパッケージを追加します。パッケージ管理の「設定」より、パッケージを保存した場所を「ユーザが定義したパッケージソース」として、そのフォルダパスを登録しておきます。登録したパッケージソースを選択し、「AwsS3Activities.0.0.5.nupkg」を選択し、インストールします。

依存関係を登録しておく

プロジェクトの依存関係にAwsS3Activitiesが追加され、AWSSDK.CoreとAWSSDK.S3についても依存関係の欄に登録されています。

依存関係を確認

ファイルを選択して、そのファイルをS3へアップロードするワークフローです。

ワークフローの内容

早速このワークフローを実行して検証してみます。あまり捻りはないですが、作成した「AwsS3Activities.0.0.5.nupkg」を選択してアップロードしてみます。

S3のコンソールへアクセスすると、見事「AwsS3Activities.0.0.5.nupkg」のファイルがアップロードされていることが確認できました。これにより、RPAで処理したファイルやログファイルなどを簡単にS3へ渡すことが、実現可能となりました。

S3へのアップロードが行えた！

冒頭で筆者自身の経験として、あれば良かったライブラリと説明しておりましたが、それはUiPathのロボットとAWSのファンクションであるサーバレスを連携するという業務自動化を行っていた際のものでした。ロボット側では、主に入出力のファイル操作の自動化を担当していました。一方、AWS側のファンクションでは、デスクトップ上ではリソース上、不可能なほどの膨大な集計や計算の処理を実行するものでした。こちらはロボットとファンクションの間をAPI Gatewayを仲介役としてインターフェイスを構築しておりました。しかし、業務自動化の対象がそもそも膨大であったということで、API Gatewayのタイムアウトや受け付けられるデータサイズの制限、ファンクションであるAWS Lambdaの自体の時間制限な、さまざまな問題が発生しました。この時にS3を媒体として、ロボット側の処理とAWS側の処理を行えればという思いに至ったものです。

今後、このライブラリにS3からのダウンロードやファイルリスト取得の機能も追加することで、RPAとクラウド環境の組み合わせにより、さらにさまざまなことが実現可能となります。決してAPI Gatewayがダメというものでもなく、自動化の要件に応じて、複数の選択肢が与えられるものとなります。

おわりに

筆者はRPA業界に身をおいていますが、業務改革という点ではRPAのみならず、「便利なものは大いに利用するべきだ」という考えです。場合によっては、RPAで一時的に業務負荷を軽減し、本格的な業務改革は負荷軽減で得られた余力を基に行うべきだとも考えております。

ユーザとRPAの関わり方

こちらは、筆者が考える人、ロボット、ブラウザ（SPA：シングルページアプリケーション）そしてモバイルアプリとクラウド（AWSを例とした場合）のインテグレーション、融合のイメージです。

人、ロボット、ブラウザ、モバイルアプリをフロントエンドとし、バックエンドをクラウド環境と分けております。バックエンドは、AWSを前提としています。一つ目の例として、今回のS3連携のライブラリにより、ロボットとS3はネイティブに連携します。仮にロボットがダウンした際には、人が代替としてS3へファイルを置くことで、S3以降の業務処理がトリガーされます。

二つ目の例として、ロボットはAPI Gatewayを通してLambdaの関数を呼び出し、バックエンドの業務処理を実行します。RPAで複数の業務をLambda関数と連携しておきます。ロボットとLambda関数の業務自動化がある程度のボリュームで行えたとすると、バックエンドの処理をある程度まとめて一つのアプリケーションとすることが可能となります。その際にフロントエンドは、ロボットに限らず、ブラウザで結果確認したり、はたまたモバイルアプリで結果確認したりすることも可能となるアーキテクチャーです。

このようにクラウド側での業務処理をマイクロサービス化しておくことにより、業務改革のフェーズに合わせたり、利用用途に合わせたり、アーキテクチャーは柔軟に変更が可能となります。

本連載では、RPAのロボットを中心とし、さまざまなロボットの連携方法をご紹介いたしました。

上記のようなケースに限らず、ロボットが裏方として業務処理を行うケース、ロボット内で機械学習を行うケース、既存のAIサービスと連携するケース、サーバ製品をクラウド環境で稼働させるケースなど多岐に渡り、その事例や実践方法をご紹介しました。

最後となりますが、皆様の業務改革に少しでもお役に立てることを願い、終わりと致します。最後までお付き合いいただき、ありがとうございました。

※当記事の執筆中に、UiPath社としてのUiPath.AmazonWebServices.Activitiesパッケージがリリースされました。当該パッケージにてS3のみならず、EC2の操作の自動化もワークフロー内で可能となります。