2020 年 9 月

Automation Cloud の Orchestrator の 2020 年 9 月のリリース ノート

2020 年 9 月 22 日

モダン フォルダー

新しい Orchestrator では、新規に作成するテナントに対してクラシック フォルダーを使用できなくなり、新規ユーザーと新規デプロイには既定でモダン フォルダーが設定されるようになりました。

既にモダン フォルダーを使い慣れているユーザーにとって、この変更にはさまざまな利点があります。階層内や階層間でのフォルダーの移動や、フォルダーおよび関連エンティティの削除、そして既定のフォルダー ロールに関連付けられた権限の変更を簡単に行うことができます。

自動化の準備をもっと簡単に行えるよう、新規テナントでは個人用ワークスペースが既定で有効化され、すぐに使える 5 つのロールが自動で作成されます。モダン フォルダーのみのアプローチへの切り替えに伴い、既定のモダン フォルダーのロールに関連する権限を更新しました。以下のリンクからご確認ください。

ロール
Tenant Administrator	✅
Allow to be Folder Administrator (以前の Enable Folder Administration)	✅
Folder Administrator	✅
Allow to be Automation User (以前の Enable Running Automation)	✅
Automation User	✅

管理者ユーザーにはテナント レベルで Tenant Administrator、Allow to be Folder Administrator、Allow to be Automation User、Administrator のロールが付与されます。

フォルダー管理者の属性とテナント管理者の属性を明確に区別するために、フォルダーを対象とするロール (Allow to be Folder Administrator と Allow to be Automation User) からロボットの管理権限を削除しました。ベスト プラクティスとしては、ロボットに係る権限で構成される別のロールを作成し、そのロールを必要なユーザーに対して制御された方法で割り当てることをお勧めします。

権限モデル

アクセス制御をさらにシンプルにするために、「テナントから継承」の割り当てモデルを非推奨としました。これまで「テナントから継承」モデルを使用していた既存のモダン フォルダーは変換され、各ユーザーに対してテナント ロールがフォルダー レベルでも付与されます。

ロールの変換について例を挙げて説明します。たとえばペトリーナさんが Finance と HR のフォルダーで作業をしており、これらのフォルダーはこれまで「テナントから継承」の権限モデルを使用していたとします。この場合、テナントから継承されたロールはフォルダー レベルでフォルダーごとにユーザーに割り当てられます。その結果、ペトリーナさんは Finance と HR の両方のフォルダーでロールを割り当てられ、テナント レベルでもこのロールが保持されます。

クラシック フォルダー

まだクラシック フォルダーを使用している方もご心配無用です。既存のデプロイをアップグレードしても、クラシック フォルダーのサポートは失われません。また、移行 ツール を追加し、素早く簡単にモダン フォルダーに移行できるようにしました。

ロボットを有効化/無効化する

クラシック フォルダーからモダン フォルダーへのロボットの移行を効率化するために、クラシック フォルダー内に存在するロボットを有効化/無効化できるようにしました。このため、移行中の手順でエラーが発生した場合はロールバックを行うことができます。次の接続ステートでのみロボットを無効化できます: 有効、切断、応答なし。

クラシック フォルダーでロボットを有効化/無効化する方法については、こちらをご覧ください。

フォルダー パッケージ

パッケージを個別に保持しながら社内で責任を委任できるよう、第 1 レベルのフォルダーを作成する際に専用のパッケージ フィードを作成できるようになりました。方法についてはこちらをご覧ください。

フィードへのアクセス権は、フォルダー用の新しい権限セット「フォルダー パッケージ」で制御できます。すべてのサブフォルダーは、ルートの親からパッケージ フィードの設定を継承します。

個人用ワークスペースのユーザー エクスペリエンス

フォルダー パッケージ

個人用ワークスペースには、既定で専用のパッケージ フィードが作成されます。パッケージのデプロイは非常に簡単で、ワークスペースにパッケージを追加すると、それがワークスペース内で自動的にプロセスとしてデプロイされます。

マシン テンプレート

今回のリリースからは、マシン テンプレートをユーザーが管理する必要がなくなりました。このため、不要な手間が省け、開発者はワークスペース内ですぐに作業を開始し、オートメーション プロジェクトをパブリッシュしたり、Orchestrator からデバッグ目的でジョブを開始したりできます。

個人用ワークスペース以外に別のフォルダーでも作業をしているユーザーは、マシン テンプレートの Orchestrator デバッグ機能を利用できます。この機能を利用するには、作業対象のフォルダー (そのユーザーが割り当てられているフォルダー) にマシン テンプレートを割り当てます。

簡易版の UI プロファイル

自動化を始めたばかりのユーザー向けに、個人用ワークスペース用の簡易版の Orchestrator UI プロファイルを追加しました。この UI には、ワークスペースで利用できる機能のみが表示されます。UI プロファイルについて詳しくはこちらをご覧ください。

個人用ワークスペースの管理

今回のリリースでは、個人用ワークスペースの管理者および業務担当者のためのさまざまな改良を行い、ワークスペースの管理における主要な機能を提供します。

すべてのワークスペースを一元化された場所から確認できるようになりました。また、開発者のワークスペースのコンテンツを探索して日々の業務を手助けできるようになりました。

使用されていないデータを簡単に整理できるようになりました。ほとんどアクティブでないワークスペースや、従業員が組織を離れたために孤立しているワークスペースを素早く識別し、専用のページ [個人用ワークスペース] で簡単に削除したりフォルダーに変換したりできます。このクリーンアップ作業は管理者の裁量で行うことができ、余計な手間もかかりません。

複数のユーザーに対して個人用ワークスペースを一括でシームレスに有効化できる機能を追加しました。この操作は [設定] ページの [個人用ワークスペース] セクションから行います。管理者がワークスペースを一括で有効化できる対象ユーザーは、テナント内で特定の Attended ライセンス プロファイルを使用しており、まだワークスペースのないユーザー全員です。

個人用ワークスペースについて詳しくは、こちらをご覧ください。

無人オートメーション

特定のマシンでジョブを開始

今回のリリースでは特定のジョブを開始するホスト マシンを選択できるようにしました。これにより、デバッグ機能がさらに向上しました。ジョブについて詳しくはこちらをご確認ください。

ローカル ユーザー向けの Unattended ロボット

Unattended ロボットをローカル アカウントとして機能させる場合に必要な情報を、そのアカウントの Windows ユーザー名およびパスワードのみとし、必須の識別子からホスト マシンを除外しました。このため、ローカルの Windows ユーザーが複数のホスト マシンに配置されていても、無人オートメーションをより簡単に行えるようになりました。

たとえば、LocalUser1 が 5 台のホスト マシンで使用されているとします。これまではそれぞれの組み合わせに対応するように Orchestrator でユーザー エンティティを 5 つ設定する必要がありましたが、今回のリリースからは Unattended ロボットを定義するユーザー エンティティは 1 つだけです。このとき、[Domainame] フィールドには構文 .\LocalUser1 を使用します。この方法を使用すれば、Orchestrator のユーザー エンティティ 1 つで、各ホスト マシン上に存在する特定の Windows アカウントを使用できます。

ドメイン参加済みのアカウントに関する変更はありません。ロボットに必要な構文は domain\username のままです。

ユーザーごとのアセット

業務のニーズにより的確に応えるため、アセットをロボットごとではなく、ユーザーごとに設定できるようにしました。これにより、実行時に使用する資格情報とユーザーとの正確なマッピングを作成でき、モダン フォルダーでのアセットのロジックが向上します。

同時接続実行の制限

ユーザーが 1 度に複数回ログインできないシナリオに対応するため、同時接続の Unattended 実行を制限できるようにしました。ユーザーが同時に複数のジョブを実行できないように制限できるため、ジョブの割り当てのアルゴリズムを調整できます。

HSM プロバイダーの管理

Unattended ロボットの資格情報を取得するために使用するハードウェア セキュリティ モデルを、Orchestrator のテナントから便利に選択できるようになりました。このため、HSM プロバイダーに関する管理性が向上しました。

また、ロボット レベルで HSM を設定する必要がなくなり、無人の自動化のシナリオにおける認証操作が効率化されました。

[キュー アイテムを待機] アクティビティ

v2020.10 より古い [キュー アイテムを待機 ] アクティビティを使用すると、最大 30 秒の遅延が発生する場合があります。このような問題を避けるには、最新のバージョンのアクティビティにアップグレードしてください。

Swagger ライブラリ

Orchestrator API を記述する swagger.json ファイルの生成方法を大幅に変更しました。Swagger ファイル内の API 記述を使用するクライアント ライブラリ ジェネレーター (AutoRest、Swagger Codegen など) に依存している場合、生成されるコードが以前と大幅に異なります。

フォーム POST パラメーターを持つ API

フォームデータ オブジェクトのパラメーターを持つ POST 要求は機能しなくなりました。Orchestrator に POST 要求を行う際は、要求本文の JSON に要求パラメーターを含める方法のみがサポートされます。

常時実行プロセス

プロセス制御機能を向上させるため、[常時実行プロセス] オプションを [プロセスの設定] ページに追加しました。このオプションを使用すると UiPath Assistant からプロセスを終了できなくなります。プロセスの管理方法について詳しくはこちらをご覧ください。

分類ステーション

分類ステーション を追加し、ドキュメントの分類や分割の結果を人間がレビューしたり修正したりできるようにしました。このため、人間とロボットがもっと協力して作業できるようになりました。このアクティビティは、[ 分類ステーションを提示] アクティビティを使用すればユーザーの操作によって提示できます。また、長期実行のワークフロー機能を活用し、分類アクションを Orchestrator の Action Center に統合することもできます。この場合は [ ドキュメント分類アクションを作成 ] アクティビティと [ ドキュメント分類アクション完了まで待機し再開] アクティビティを使用します。

トリガーの自動無効化

今回からは、過去 1 日間で一度も正常に起動できていないトリガーが起動に 10 回失敗すると、そのトリガーは自動的に無効化されます。

テスト データの管理

テスト データのキューや合成テスト データを作成して、テスト データの管理にかかる時間を短縮できるようになりました。テスト データのキューは、テスト データを準備・保存・消費できる一元的な保存場所です。テスト データのキューに含まれるキュー アイテムを FIFO (先入れ先出し) で保存したり消費したりできるテスト ケースの機能を使用すれば、テスト作業の範囲を拡大できます。

改良点

Action Center

今回のリリースでは Action Center がモダン フォルダーもサポートするようになりました。これまで Action Center の使用はクラシック フォルダーのみに制限されていましたが、今後はフォルダーの種類に関わらず Action Center のすべての機能を使用できます。

また、社内のアクション管理者専用に新しくページを追加しました。このためアクションを一元管理し、ユーザーに対する割り当てが簡単に行えるようになりました。

プロセス

使用性に関する改良点の中で今回のリリースで特に重要なのは、プロセスに関するものです。パッケージ レベルでのプロセスの更新について詳しくはこちらをご覧ください。

プロセス同士の識別や区別を行いやすくするため、関連パッケージを Studio でデザインした際に設定した説明がプロセスに継承されるようになりました。これは手動でデプロイした場合でも、自動で個人用ワークスペースにデプロイした場合でも同様です。

また、無制限で自由にプロセスの説明を追加したり、既存の説明を変更したりできます。Orchestrator へのプロセスの追加方法については、こちらをご覧ください。

一括更新機能を追加し、パッケージに関連付けられたプロセスをすべてアップグレードできるようにしました。このため、複数のフォルダーで使用されているプロセスを利用可能な最新バージョンのパッケージに簡単に更新できるようになりました。対象のパッケージを選択すると、関連付けられたプロセスのうちで最新バージョンのパッケージが使用されていないものを Orchestrator が検索し、表示します。

最新バージョンのパッケージに更新するプロセスを選択すれば、操作は完了です。

使用性

前述した新機能や改良点の他にも、使用性や製品全体の一貫性を向上させるためにさまざまな変更を行いました。このセクションでは、ユーザー エクスペリエンスに関わる更新情報について説明します。

Orchestrator ウィンドウのヘッダーの色とロゴを変更する前に設定をプレビューできるようにしました。このため変更を保存する前に設定を適宜調整できます。

ユーザー、ユーザー グループ、マシン テンプレートをフォルダー レベルで直接割り当てられるようになりました。この操作は、フォルダー コンテキストの [設定] ページから行えます。

マシン キーのコピーやランタイムの編集が、[マシン] ページからだけでなく [フォルダー] ページからも直接行えるようになりました。このため、マシン テンプレートのフォルダーへの割り当て作業が簡単になりました。ただし、マシン テンプレートの実行にはランタイムが必要であるため、マシンをフォルダーに割り当てる際はランタイムを割り当てるようにしてください。

Orchestrator の統計情報の概要をもっと使いやすくするために、ホーム ページのジョブのカウンターから対応する [ジョブ] ページに移動でき、移動先のページが適切にフィルター処理されるようにしました。たとえば「実行中のジョブ」に対応するセクションをクリックすると、表示されるページには「実行中」ステートのフィルターが適用されます。

[プロセス] ページに、各プロセスに関連するパッケージ名が表示されるようになりました。

既定のロールに必要な権限を簡単に追加できるようになりました。

テスト オートメーション

テスト ケースを含むテスト オートメーションをパブリッシュすると、プロセスがまだ存在しない場合はプロセスが自動で作成されるようになりました。

テスト スケジュールが、前回の実行が完了した場合にのみ新しいテスト実行を作成するようになりました。

実行メディアがテスト実行でサポートされ、実行に失敗した際に作成されるスクリーンショットを表示できるようになりました。

[テスト ケース] ページで直接テスト セットを作成できるようになりました。

外部ツールで作成したテスト セットが API 経由でのみ表示できるようになり、[テスト セット] ページには表示されなくなりました。

テスト オートメーション パッケージをアップロードする際の検証を 2 件追加しました。このようなパッケージやパッケージのバージョンを正常にアップロードするには、以下の条件を満たす必要があります。

• パッケージには少なくとも 1 つのエントリ ポイントが含まれている
• 同一パッケージの異なるバージョン間では、プロジェクトの種類が同じである

リリース バージョンのフィルター処理およびテスト セットの作成のパフォーマンスを向上させました。

テスト セットを作成する際、パッケージをすべての利用可能なバージョンから選択できるようにしました。

その他

「終了中」ステートのジョブが溜まらないようにする機能を数点追加しました。まず、強制終了のコマンドでジョブを「終了中」ステートに移行できるようにしました。さらに、3 時間に 1 度実行されるクリーンアップのバックグラウンド ジョブはを追加しました。少なくとも 1 日間「終了中」ステートに留まっていたジョブは「失敗」ステートに移行されます。

アクションの保存に対する Webhook (task.saved) を追加し、アクションが完了前に保存された場合に通知が送信されるようにしました。

ログの生成元のホスト マシンの名前でログをフィルター処理できるようになりました。この操作は [ログ] ページの [マシン] フィルターで行うことができます。新しいフィルターは Elasticsearch に格納されているログに対しては機能しますが、データベースに格納されているログについては新規のログ エントリに対してのみ機能します。

Orchestrator で起きているすべてのイベントについて通知を受け取れるよう、フォルダーおよび個人用ワークスペースのアラートを追加しました。アラートについてはこちらをご確認ください。

重大な変更

OData.BackwardsCompatible.Enabled パラメーターが既定で true に設定されるようになりました。つまり、入力データを OData モデルの動的プロパティ (例: QueueItem.SpecificContent) 用に変換する際、Orchestrator は既定で特殊文字を解析・保持するようになり、エンコードやエスケープのメカニズムを使用しなくなりました。

以前は OData.BackwardsCompatible.Enabled は既定で false に設定されており、API 要求を実行する際に構文 "[e-mail]": "#String" を用いてデータ型を指定しない限り、特殊文字はエンコード/エスケープされていました。

お使いのオートメーション プロジェクトが文字のエンコード/エスケープに対処するようにデザインされており、上記以外のメソッド (正規表現のエスケープ解除の式など) を使用している場合は、今後は機能しない可能性があるため、適宜調整してください。または、OData.BackwardsCompatible.Enabled を false に設定して以前の挙動を保持してください。

既知の問題

• + 記号を含むパッケージ バージョンはプロセスの作成に使用できないため、Orchestrator 内では使用できません。
• Studio 内の Orchestrator フィードの言語設定が Robot の言語設定を無視し、Robot の言語に関係なくフィードが英語で表示されます。

バグ修正

• 資格情報ストアの作成または更新が不適切である場合に発生するエラー メッセージが [アラート] ページに表示されず、設定ミスの詳細を確認できませんでした。
• テスト実行のジョブを強制終了すると、Orchestrator のジョブのステートが不適切なものになっていました。
• Folder Administrator ロールを持つユーザーが前提条件を満たしていても、手動で権限を付与されない限りはテスト機能にアクセスできませんでした。
• Test Automation を無効化しても、実行中のテスト スケジュールが無効化されませんでした。
• 以前は 32 文字を超える名前のユーザー グループは編集できませんでした。今回、グループ名 ([グループまたはユーザー名] フィールド) の文字数制限を 256 文字に増やしました。

2020 年 9 月 9 日

新着情報

スタンドアロン ライセンスの削除

Automation Cloud の Orchestrator サービスを使用している場合に、Studio のライセンスをローカルで付与できなくなりました。この変更に関連して、Orchestrator からスタンドアロン ライセンスのチェックボックスを削除しました。この変更に先立って Studio/StudioX/Studio Pro のライセンスをローカルで付与していたユーザーには影響がありませんが、追加で使用する Studio に対してはこの機能は使用できません。

この機能はオンデマンドで有効化できます。お 問い合わせ。

クラシック フォルダー内のロボットを有効化/無効化する

クラシック フォルダーからモダン フォルダーへのロボットの移行を効率化するために、クラシック フォルダー内に存在するロボットを簡単に有効化/無効化できるようにしました。このため、移行中の手順でエラーが発生した場合はロールバックを行うことができます。次の接続ステートでのみロボットを無効化できます: 有効、切断、応答なし。

ロボットを無効化すると、関連する以下のエンティティが影響を受けます。

トリガー

• トリガーは、無効化されたロボットを使用するようには設定できません。
• 無効化されたロボットは、その特定のロボットを使用する既存のトリガーから削除されます。他に特定のロボットが定義されていない場合、そのトリガーはジョブを作成できないため例外をスローします。

ロボットごとのアセット

• 無効化されたロボットは、ロボットごとの値を持つアセットから削除されます。
• アセットに含まれるロボットの値が 1 つのみの場合にそのロボットを無効化すると、アセットは不整合のステートになり、変更できません。

ロボットを再度有効化すると、影響を受けていたすべてのエンティティが使用できるようになります。

改良点

[プロセス] ページに、各プロセスに関連するパッケージ名が表示されるようになりました。

バグ修正

• Test Automation を無効化しても、実行中のテスト スケジュールが無効化されませんでした。