きな粉もち.net

.NET関連仕事に携わっています。OSSのソースを読んで気がついたことを中心に呟いたりブログに投稿したりしています。最近はUiPathを使ったRPAも研究中。気軽にフォローやツッコミよろしくおねがいします! Gitはここを使っています https://github.com/kinakomotitti

Windows Workflow Foundation × UiPath カスタムアクティビティ × 自分的作成時の注意点


この記事の目的

この記事では、
Uipathのカスタムアクティビティを作るときの注意点をまとめる

を目的としています。
※自分なりの注意点なので、これがすべてではないです。
参考資料

  • UiPathのカスタムアクティビティを作成する公式ドキュメント

activities.uipath.com

  • Windows Workflow Foundationについてのドキュメント

https://docs.microsoft.com/ja-jp/dotnet/framework/windows-work

code.msdn.microsoft.com

  • とても参考にしたページ

 記事の中に、WCF、WFのサンプルコードのダウンロードリンクあり。
 このサンプルコードがとても分かりやすかったです。
カスタム アクティビティ デザイナーでの ExpressionTextBox の使用 | Microsoft Docs

本題

★そもそも、カスタムアクティビティを作るために必要なことは?

UiPathは「Windows Workflow Foundation(以下WF)」をベースに作られています。そのためカスタムアクティビティは、WFのアクティビティデザイナーを使って作成します。

ということで、用意するものは、
WFのコンポーネントをインストールしたVisual Studio Community
※その他のエディションも可
です。

なお、WFを利用するためには、Visual Studio をインストールする際、「個別コンポーネント」からWFをチェックし、明示的にインストールする必要があります。
※個別コンポーネントで指定しないとインストールされないので注意が必要です!
参考↓
f:id:kinakomotitti:20180719200653p:plain

★注意点その1:入出力パラメータ名を明確に!

基本的なお話になりますが、複数のパラメータを有するアクティビティを作成した場合、それぞれがアクティビティの入力値なのか、出力値なのかがわからなくなります。

以下のイメージのように、入力なら入力、出力なら出力と、わかりやすい命名規約を定義しておくのが良いと思います。
f:id:kinakomotitti:20180719200700p:plain
※これは極端ですね・・・

★注意点その2:プロパティには、変数を指定可能に!

カスタムアクティビティのコードを以下に示します。
※プロジェクト全体はGitHubに公開しています。


ここで、「Input」パラメータは、以下の図のように、ワークフローで利用している"変数"を指定することができます。以下の例では、”variable1”という名前の変数を指定しています。
f:id:kinakomotitti:20180719200712p:plain

一方、String型のプロパティとして定義した「Parameter」は、
以下のように、”定数”のみ受け付けるようになります。
f:id:kinakomotitti:20180719200717p:plain

このプロパティに、値をInputのようにvariable1を指定した場合・・・
f:id:kinakomotitti:20180719200724p:plain
本当は、”variable1”変数に格納された”Sample”という文字列が入ってくるのを期待するのですが、定数として扱われるため、"variable1"という文字列が渡されてきます。

[Category("Input")] とする場合は、どんな時もInArgumentを利用するのがよさそうです。WFでカスタムアクティビティを作るときには、常識なのかもしれませんが・・・

★注意点その3:仕様を明らかに!

一般的な「クラスライブラリ」の開発では、メソッドにXMLドキュメントとして仕様を記載します。それにより、インテリセンスなどでメソッドを参照したとき、
何の引数を渡したら、
どんな処理をして、
どんな結果が返ってくるか
という情報を得ることができます。

一方、UiPath(WF)では、作成したカスタムアクティビティについて、上記のような仕様を記載するものがないようです(=_=)

この問題を放置すると、
Step1)カスタムアクティビティの使い方がわからない
Step2)カスタムアクティビティの設計書を探す
Step3)設計書があれば読む
Step4)設計書がなければコードを読む 
Step5)コードから設計書を作成する ←だめだめですねw
といったようにどんどん作業が増えていきます。

そういったことにならないように。
また、設計書を探す手間を省くためにも、
アクティビティに仕様(XMLドキュメント相当のもの)
を書いてしまえばよいのではないかと考えた次第です。
イメージは以下の通りです。
f:id:kinakomotitti:20180719200734p:plain

設計書探さなくて済む。
仕様が変わったらコードの修正と一緒に説明書きを修正して配置までできる。
というメリットを受けることができると思います。

まとめ

初めてカスタムアクティビティを作った後に感じた反省点を目止めてみました。
作ってみてわかることもありますよね
今回の反省を次期開発に活かしたい・・・