「Invoke Workflow Interactive」の利用場合と注意事項

#1

今まで、すべての場合でも「Invoke Workflow File」を利用しています。
最新、FrameWorkのプロセスを開発しようと思いまして、
「New」⇒「Transaction Business Process」で新しいプロセスを作成しました。
その中に、「Invoke Workflow File」ではなく、
「Invoke Workflow Interactive」を利用されています。
「Invoke Workflow File」より「Invoke Workflow Interactive」のほうが
メリットがあるかもしれないと思いまして、
利用してみますと、不具合な状況を発見しました。
「Invoke Workflow Interactive」の引数は
「DataRow」型である場合、引用されたワークフロー中にその内容を型取得できないようです。
エラーメセージは「Object reference not set to an instance of an object.」です。
「Invoke Workflow File」に取替えば、
エラーがなくなって、引数の内容も正常に取得できることになります。

その原因はわかりません。
「Invoke Workflow Interactive」の利用場合と注意事項について、
お教えいただきたい。

#2

Invoke Workflow Fileは現在のWindowsセッションで、～Interactiveは「必要に応じてWindowsの対話型セッションを立ち上げる」動作がつきます。

たとえばStudioでデバッグ動作させている場合、この2つに事実上の差異はないと思います。差異が発生するのは、タスクスケジューラー等でRobotを動かし、対話型セッションに誰もログインしていない状態でWorkflowを動かす場合だと思います。
（対話型セッションが存在しないと、ウィンドウ等は表示できないので、たとえば「ダイアログが出るのを前提にクリックする」ようなWorkflowは動作不全を起こします。そういう場合に、Invoke Workflow Interactiveは有効です）

ただ、メリットばかりではなく、書かれているようにDataRow等の一部の変数は引き渡せません。
これは若干、プログラミングの世界に踏み込んだ話になりますが、「文字列（String）」「数値（Int32）」等は引き渡す際に、「同じ値」をそのままコピーすることができますが、DataRowは「その親になるテーブル」や「テーブルの読み込み元のDB」等との関連性がありきなため、単体で値をコピーするということができないからです。
そのため、UiPath（というか、.NET Frameworkで動くアプリケーション全般）は、DataRowのようなオブジェクトに対しては、他の機能にデータを渡すときに「メモリ内のどこにデータが格納されているか」を示す値を渡します。
Invoke Workflowであれば、呼び出し先も同じユーザーセッションで動作しているので、このメモリが参照できますが、Invoke Workflow Interactiveの場合、ユーザーセッションが異なることを前提に設計されています。
セキュリティ等もあり、他のユーザーセッションの値を直接読むことは通常のOSではできませんから、そういった機構を挟むとエラーになってしまう、という話ではないかと思います。

基本的には呼び出しのオーバーヘッド（余計な処理が付与されること）もあるので、明確に「ユーザーセッションが別れてでも呼び出したい」という理由があるのでなければ、Invoke Workflow Fileを使う方が良いです。
それでもInvoke Workflow Interactiveを使うのであれば、上記のように元セッションの「メモリ内にあるDB接続等に紐付いている可能性のあるデータ」までは読めないので、引数として渡すときに各レコードを文字・数字型に変換して渡す、等の対応が必要になるかと思います。

5 Likes
#3

@Honoka

詳しくご説明いただき、
ありがとうございます。

勉強になりました。
これから、もっと実践してみます。
今後ともよろしくお願い致します。

#4

@Honoka

肝心な個所を説明いただいて、ありがとうございます。

#5