Automation 360 のアーキテクチャとレジリエンス
- 更新日 2023/03/01
Automation 360 のアーキテクチャとレジリエンス
Automation 360 は、フロント オフィスとバック オフィスのテクノロジーのサイロを超え、SaaS とレガシー アプリケーションの両方を含む、すべてのシステムとアプリケーションのビジネスプロセスを自動化する、単一の統合プラットフォームです。
Automation 360 プラットフォームは、分散アーキテクチャを使用してデプロイされます。
一元的な管理は、Control Room と呼ばれる Web ベースのサーバーを介して実行され、デジタル ワークフォースのすべての開発や実行を管理します。Bot エージェントはオートメーションを実行するデバイスにインストールされたランタイムシステムです。
次の図は、Control Room と Bot エージェントのアーキテクチャと関係を示しています。
- * Control Room は、データベース内のパブリック キーに保持する一意のユーザー名とデバイス ID を作成します。
- ** デバイスのパグリック キーが Control Room によって検証され、新しいトークンが作成されることを示します。
次の表では、Control Room、Bot エージェント、およびバック エンド サービス (前の画像で番号が指定されてる) 間で発生するフローとアクションを説明しています。
アクション | 説明 |
---|---|
1 | ブラウザは、Bot エージェントにデバイストークン送信し、登録します。 |
2 | Bot エージェントは、パブリック キーとトークンを作成するためのデバイス リクエストを登録します。 |
3 | Control Room のバック エンド サービスは、Bot エージェントにデバイスが一意のユーザー名とデバイス ID で登録されたことを示す応答を送信します。 |
4 | Bot エージェントは、ブラウザにデバイスが正常に登録されたことを示すメッセージを送信します。 |
5 | Bot エージェントは、Control Room のバック エンド サービスに、JSON Web トークンの認証が成功したことを示すメッセージを送信します。 |
6 | Control Room のバック エンド サービスは、デバイスのパブリック キーを検証し、Web ソケットと新しいトークンの接続を確立します。 |
Control Room と Bot エージェントの復元性
次の表では、Automation 360 と Enterprise 11 の動作や復元性の違いについて説明しています。
ユーザー アクション | Automation 360 で Bot エージェント | Enterprise 11 の Bot Runner クライアント | 注 |
---|---|---|---|
サービス | インストール サービスは、ローカル デバイスで実行されます。 | インストール サービスは、アクティブなユーザー セッションの内部で実行されます。 | |
登録 | デバイスが Control Room に登録されます。 | Control Room にアクティブなユーザーが登録されていること | Bot エージェント サービスは、ローカル システム上で実行されます。 |
認証 | Control Room はエージェント パブリック キーをデータベースに保存します。 | Control Room は、認証キーをメモリに保存します。 | Automation 360 では、Control Room がパブリック キーをデータベースに保存します。このため、Control Room が再起動したとき、より速く再接続できます。Bot エージェントは Control Room の再起動に対して回復性を備えています。 ただし、Enterprise 11 では、Control Room の再接続は再起動後に実行されません。 |
Bot のデプロイ | Bot の優先度は、デプロイ時に確認されます。 Bot Runner ユーザーに対して Bot がキューに入れられると、優先度の高い Bot が優先度の低い Bot の前にデプロイされます。 ただし、優先度の低い Bot がすでに実行されている場合、優先度の高い Bot は、優先度の低い Bot が終了した後でデプロイされます。 |
優先度の低い Bot が動作しているときに優先度の高い Bot がデプロイされると、システムは優先度の低い Bot を一時停止して、優先度の高い Bot を実行します。 優先度の高い Bot が実行された後で、優先度の低い Bot が再開されます。 |
Automation 360 のメリットには、優先度の低い Bot が一時停止されず、デプロイが完了さしてから、優先順位の高い Bot がデプロイされることがあります。 |
エラー処理 | エラー ハンドラー パッケージには、Bot で発生した例外を簡単に処理できるアクションが含まれており、その Bot 内にある他のアクションに制御を移行します。 | エラー処理 コマンドは タスク Bot と MetaBot ロジックが実行されたときのデバッグに役立ちます。 | |
デバイス | デバイスが Control Room に登録されると接続されます。 デバイスの再起動時に再接続します。 |
Bot Runner クライアントが再起動したり、Control Room との接続を失ったりした場合、クライアントに再ログインして接続し直す必要があります。 | Bot エージェントは、すべてのデバイスに個別にログインせずに再接続することができます。 |
再接続 | Bot エージェントは、中断があった場合に自動的に再接続されます。 | Bot Runner クライアントは手動で再接続する必要があります。 | Automation 360 での Bot 登録は堅牢性が高く、Control Room に自動的に再接続することができます。 |
パブリック キーとプライベート キー | パブリック キーとプライベート キーは、デバイスの登録時に生成されます。 このキーは Control Room を認証するために使用されます。 |
Automation 360 と同じ動作です。 | |
サービス | Bot エージェントは、サービスとして実行されます。デバイスを再起動すると、このサービスは自動的に Control Room に接続されます。 Bot エージェントは、Control Room が停止している場合でも、パブリック キーとプライベート キーを使用して接続を確認し続けます。 |
クライアントがログインしてタスクを実行する必要があります。 | |
リモート接続 | リモート デスクトップ プロトコルは、マルチユーザー デバイスにのみ対応しています。 Control Room では RDP は保持されません。 |
リモート デスクトップ プロトコルは、シングルユーザー デバイスとマルチユーザー デバイスの両方でサポートされます。 Enterprise 11 では、リモート デスクトップ プロトコル接続は Control Room から確立され、Control Room によって保持されます。 |
|
自動更新 | Control Room 管理者は、自動更新機能を使用して、Bot エージェントを新しいバージョンに自動更新することができます。 | 自動更新のオプションは使用できません | 自動更新では、各ユーザーは Control Room にログインしてユーザーのデバイスにインストールされた Bot エージェントを更新する必要がないため、ダウンタイムが短縮されます。 |
構成の更新 | 更新はクラウドを介してプッシュされます。 | スタンドアロン構成の更新はありませんが、構成は手動で変更できます。 構成の機能強化はパッチとしてリリースされます。 |
|
グローバル キャッシュ | ユーザーが Control Room にログインした後、ユーザーの現在のデバイスをデフォルトのデバイスとして自動的に設定するようにデバイス設定を構成します。 | 提供なし | |
Bot エージェントから Control Room への接続が失われました | 更新中に、すでに実行中の Bot は、完了するまで実行されます。 | 通常、更新中にすでに実行中の Bot は、完了するまで実行できます。次の例外があります。
|
スケジュール設定のレジリエンス
デバイス プールは、Unattended ライセンスが自由に使える場合、Bot Runner デバイスのビルトインの高可用性 (HA) を提供します。1 台の Bot Runner デバイスに関連付けられているわけではないので、デバイスが何らかの理由で使用できなくなり、Unattended ライセンスのデプロイが自由になった場合でも、オートメーションに影響は生じません。スケジュールされたオートメーションは、次に利用可能な Bot Runner デバイスで自動的に実行されるため、高可用性が提供されます。
「デバイス プールの概要」を参照してください。