action-center
2023.10
false
- インストールとアップグレード
- はじめる前に
- 基本情報
- Activities (アクティビティ)
- 長期実行ワークフローを設計する
- ジョブを開始し参照を取得 (Start Job And Get Reference)
- ジョブ完了まで待機し再開
- キュー アイテムを追加し参照を取得 (Add Queue Item And Get Reference)
- キュー アイテム完了まで待機し再開
- フォーム タスクを作成
- フォーム タスク完了まで待機し再開
- 時間差で再開 (Resume After Delay)
- タスクを割り当て
- 外部タスクを作成
- 外部タスクの完了を待機して再開
- タスクを完了する
- タスクを転送 (Forward Task)
- フォーム タスクを取得 (Get Form Tasks)
- タスク データを取得 (Get Task Data)
- タスクのコメントを追加
- タスクのラベルを更新
- アクション
- プロセス
- 監査
重要 :
このコンテンツの一部は機械翻訳によって処理されており、完全な翻訳を保証するものではありません。
新しいコンテンツの翻訳は、およそ 1 ~ 2 週間で公開されます。

Action Center ユーザー ガイド
最終更新日時 2026年4月29日
ハードウェア要件
Action Center は、マルチ ノード デプロイを使用してインストールできます。使用しているノード デプロイの種類に応じて、異なるハードウェア要件を確認する必要があります。
- シングル ノード デプロイ - シングル ノードの Orchestrator インスタンスに接続されたシングル ノードの Action Center です。
- マルチ ノード デプロイ - 次のマルチノード デプロイをお勧めします。
- マルチノード デプロイのシナリオでは、Orchestrator はロード バランサーの背後に設定される一方で、Action Center の単一インスタンスが別のサーバーにインストールされます。Action Center は、Orchestrator のロード バランサーの URL を指すように構成されます。
- もう 1 つの種類のマルチノード デプロイでは、複数のノードを持つロード バランサーの背後に Orchestrator を設定します。この構成では、Action Center は各 Orchestrator ノードにインストールされ、Action Center の各インスタンスが Orchestrator のロード バランサー URL を指します。
接続された Orchestrator が、こちらに記載されている要件に従って負荷を処理できる場合、Action Center は多数の同時接続ユーザーが使用できるようスケールを拡大できます。
単一ノード展開
シングルノードのハードウェア要件
サンドボックス化された環境内で実行される社内のロード テストに基づき、以下のハードウェア要件を推奨事項として提示します。これらの推奨事項は、以下のセクションに記載されるサンプル データに基づいています。
注:
ユーザーは、業務要件 (平均ペイロード サイズ、想定される負荷、同時接続ユーザーなど) に基づいてハードウェアのサイズを導き出す必要があります。
| 最大同時接続ユーザー | CPU コア数 (2GHz 以上) | RAM (GB) |
|---|---|---|
| 4,000 | 2 | 4 |
| 12,000 | 4 | 4 |
テストの設定とサンプル データ
シングル ノードの Orchestrator インスタンスに接続したシングル ノードの Action Center のパフォーマンスをテストするために、以下の設定とサンプル データを使用しています。
- テスト時間は 3 時間
- フォーム データのペイロードのサイズは 5,000 バイト
- 28,000 個のアクションを作成
- さまざまな 17 の API エンドポイントを実行
- 同時接続ユーザーをシミュレート
マルチ ノード展開
マルチノードのハードウェア要件
パフォーマンス テストに基づいて推奨される各種の最大値は以下のとおりです。
- Orchestrator に接続してジョブを実行する 150,000 台の Attended ロボット
- アクションを処理する 10,000 人の Action Center ユーザー
- ジョブを実行する 3,000 台の Unattended ロボット (アクションを作成し、そのアクションが完了するとジョブを再開)
環境の構成
上記のシナリオでシームレスなパフォーマンスを実現するには、以下の環境構成をお勧めします。
| インスタンス | デプロイ ノードの数 | Azure VM | vCPU コア数 | 周波数 (GHz) | RAM (GB) |
|---|---|---|---|---|---|
| Action Center | 3 | B2s | 2 | 2.0 | 4 |
| Orchestrator | 10 | F16 | 16 | 2.0 | 32 |
| SQL Server | 1 | F32 | 32 | 2.0 | 64 |
ドライブ ストレージ
次の各コンテンツに 1 台のドライブを割り当てます。
| 格納するコンテンツ | ドライブ容量 |
|---|---|
| データベース | 1 TB |
| 一時データベース | 1 TB |
| トランザクション ログ | 1 TB |
データベースのセットアップ
| 製品 | 構成 |
|---|---|
| Redis Enterprise HA | CentOS 8 コアの CPU 2.0 GHz 以上のクロック周波数 16 GB の RAM |
| バケット ストレージ VM | 標準の L32s_v2 Ultra ディスク 4 TB、900 MB/s のスループット |
テストの設定とサンプル データ
Action Center と Orchestrator に対して高負荷をシミュレートするパフォーマンス テストを実行することで、ハードウェア要件ならびに追加の設定と構成を作成しました。テストは、次のサンプル データを使用して実行しました。
- 10,000 人の同時接続 Action Center ユーザー
- 240,000 のアクション
- 60% のドキュメント検証アクション
- 40% のフォーム アクション
- 1 つのフォーム アクションあたりのペイロード:
- フォーム レイアウト—5 KB
- フォーム データ—5 KB
- 100 KB のストレージ ファイル 10 個
- 1 つのドキュメント検証アクションあたりのペイロード:
- 150 KB の PDF ファイル 1 つ