閲覧いただきありがとうございます。
仮想環境を外側から操作するのではなく、仮想環境内にUiPathをインストールし、それを実行させることで、業務を実行させる場合は、CitrixではなくUI要素の操作で問題ないという認識でOKですか?
(画面の操作ではないため)
また、スリープさせないで、セッションを切れば、ずっと業務を実行しているということになりますでしょうか?
(スリープやログオフすると止まってしまいますよね?)
閲覧いただきありがとうございます。
仮想環境を外側から操作するのではなく、仮想環境内にUiPathをインストールし、それを実行させることで、業務を実行させる場合は、CitrixではなくUI要素の操作で問題ないという認識でOKですか?
(画面の操作ではないため)
また、スリープさせないで、セッションを切れば、ずっと業務を実行しているということになりますでしょうか?
(スリープやログオフすると止まってしまいますよね?)
UI要素の操作で問題ありません。
セッションを切ったときに画面がロックされなければ大丈夫だと思います。
こんにちは
環境にもよるかもですが、切断時は一筋縄では動かないのでは?と思います。
画面が描画される・されないとか、別でセッションを用意できるかとか、そのあたりの前提もあるかもです。
また本件をARに適用するなら、厳密に考えるとライセンス規約に抵触するかもですね。
返信ありがとうございます。
リモートの画面終了してしまうと、動作については不確定なようですね。
ライセンスについても気になるし。
かといって、普段ユーザーが使っているPC上で利用するのはROBOTの時間であることを考えると気が引けます。
どうしたものか。
いちいちPC用意するのも問題なので、ロボット用の環境は仮想マシンで一括管理したいと考えていたのですが。
やや一般論というか、「たいていの製品はそうなっています」というお話になりますが、仮想環境だとセッションを切っている場合、ユーザーは「ログインされているけれども、デスクトップセッションがない」状態になります。
(もしかしたらセッションを残してくれるVDI・RDPツールもあるのかもしれませんが)
その場合、一部のアクティビティは動作することもありますが、UI要素をどうこうするアクティビティは基本的に動作しないものと思ったほうが良いです。
あと規約的に色々と引っかかりかねない部分はあるので、そこは販社なり公式サポートなりに問い合わせるべきところかな、と思います。
いつも返信ありがとうございます。
サーバーどーん。
仮想マシンどどどーん。
ロボットずばばばーん。
ってやって、ロボット業務部作って管理・開発者一人置いて、省スペース化できないかなぁと。
作業結果をファイルサーバーにおいて、単純な仕事だけを効率よく管理する部門。
UI要素が使えないんじゃ、ほとんど役に立たなそうですね。
UiPathの仕様なんでしょうけど、セッションの状態を常に意識してるってことなんですね。。。
マクロみたいに勝手に動いてくれてればいいのになぁ。
こんにちは
Orchestrator + Unattended Robotの組み合わせでお考えのことはできると思います。
コストが許容できればになりますが。
Orchestrator+Unattended Robotを使えば、そんな感じになります。
OrchestratorからRDPと同じような方式で繋いで動作するので、ネットワーク障害がない限りセッションも維持されます。
ありがとうございます!
頑張ってOrchestratorの勉強もします!
Ochestratorなんですね。
サーバー一台で、親サーバーPで仮想マシンA、B、C、Dを作成します。
仮想マシンAではオーケストレーター動作、マシンB、C、DではUnatendedなRobotという認識でOKですか?それとも、オーケストレーターは親サーバーPで動かすのが常識でしょうか?
オーケストレーター触ったことないので教えてください。
UI要素、使えるようになったみたい?です。
18.4の新機能で、Citrix環境でも要素で認識できるようになったようです。
18.4から新規に追加された機能「Citrix XenApp native support」
今までのような画像認識でなく、要素で認識するので
・TypeIntoなどのUI要素を操作するアクティビティを使用できるので、仮想環境でないときと同じように、普通にワークフローを作ることができ、セレクタの修正もできる
・なので、従来の方法(画像認識とかOCRとか)より精度が高い
クライアントに実行用のリモートランタイムをインストールする必要があります。
そうすると、クライアントのエクステンションが、サーバサイドのコンポーネント(リモートランタイム)に要素を請求するような仕掛けになっているようです。
(ごめんなさい私もあんまり理解できてなくて上手に説明ができません……)
Robotが18.4で、ランタイムをインストールするサーバの.NETが4.6.1以上であることが必要要件だそうです。
まだ日本のサイトだと18.4の情報がないっぽいので、UiPathの英語のページを頑張って読んでみてください……。
こんにちは
いろいろな話が出ていますので、整理の意味で
@kenji さんのご質問の環境はVDI上のOSの中にUiPathをインストールする環境ですので、基本的にはUiPathでUI要素はつかめます。
@Honoka さんのReplyの中で言及されている「UI要素をどうこうするアクティビティは基本的に動作しない」は、このVDI環境と接続しているたとえばRDPなどのセッションが切れた際に、多くの環境では画面描画がされない状況になる(場合によってはログオフする)ため、「UI要素を扱えない」という意味です。
@sumire さんのReplyの中のCitrix native supportは、従来画像でしか扱えなかったCitrixなどの画面転送されたものを、Nativeサポートすることにより、UI要素をつかめる様にするものです。この場合UiPathはVDIの中ではなく、リモートデスクトップ接続元のPCにある状況です。(ので @Honoka さんの意図とは状況が少し違います。)
ちなみにOrchestratorのインストール場所ですが、RobotからOrchestratorに対してHTTPSのコネクションが張れる場所であればどこでもOKです。
そういう意味ではリソースに余裕があればサーバーPでも動作させることはできますが、高い信頼性を得るには他のサーバーを利用して冗長構成で組む必要があります。 (最小構成でIIS+SQL Server, 冗長構成でIIS + SQL Server + Redis cacheが必要です。)
情報ありがとうございます。
ただ、実現したいのは仮想マシンの「ローカル」にUiPathを入れている状態で、仕事をさせるということです。
なので、Citrixで外側からというのではなく仮想環境内のローカルで完結するような感じを想定してました。
画面を閉じている状態で勝手にやってよ、って状態を作りたくて。
仮想マシンじゃ難しいのかなぁと。
実機用意して、切り替え機でモニターを節約するのもばからしいので。
話を整理していただきありがとうございます。
いろんな実現方法がありますね。
予算や規模に応じて最適なものを選択できるようにしたいと思います!