REST Web サービス パッケージ

REST Web サービス パッケージのアクションをメソッド (DELETE、GET、PATCH、POST、または PUT) として使用し、API へリクエストを送信して API からレスポンスを受信します。

REST Web サービス アクションの操作

REST リクエストを送信してレスポンスを受信するには、次の情報を指定します。すべてのメソッドで必ずしもすべてのパラメーターが必要なわけではありません。
  • URI を入力: API リソースの一意のアドレス。
  • プロキシ構成: プロキシを設定するには、[プロキシ構成] から [システム] または [カスタム] タブを選択します。
    オプション 説明
    システム

    システム プロキシは、Bot が動作している Bot ランナー マシンに設定されているプロキシです。

    このオプションが選択されている場合、Bot エージェントはシステム プロキシを使用します。
    カスタム

    このオプションは、REST Web サービス のアクション内でカスタム プロキシを設定することができます。たとえば、REST API をシステム プロキシ以外の別のプロキシでルーティングする必要がある場合、[カスタム] オプションを選択し、REST アクション内にプロキシの詳細を指定することが可能です。

    次の詳細を指定します。

    • ホスト: プロキシのホスト名または IP アドレス
    • ポート: プロキシのポート番号
    • ユーザー名 (任意): プロキシ認証に使用するユーザー名
    • パスワード (任意): プロキシ認証に使用するパスワード
      注: 設定するプロキシが認証プロキシである場合、[ユーザー名] と [パスワード] のフィールドに資格情報を入力する必要があります。
    [ホスト]、[ポート]、[ユーザー名]、および [パスワード] の各フィールドの場合、[資格情報]、[変数]、または [安全でない文字列] タブから選択します。
    • 資格情報: 資格情報 Vault で利用可能な値を使用します。
    • 変数: ユーザー定義変数に資格情報値を保存する変数を使用します。
    • 安全でない文字列: 使用する値を手動で指定します。
  • 認証モード: 3 つの認証モードがサポートされています。
    • 認証なし: サーバーへのアクセスに認証を必要としないエンドポイントにアクセスするには、このオプションを使用します。
    • Control Room ユーザー トークン: REST Web サービス アクションは、Control Room へのログイン時に生成されたトークンを使用してエンドポイントにアクセスします。
    • 基本: [基本] は、ユーザーを認証する最も簡単な方法です。このオプションを選択した場合は、ユーザー名とパスワードを入力します。この手法では、入力されたユーザー名およびパスワードを base64 でエンコードした「Authorization」というヘッダーを使用します。
    • ログイン済み AD ユーザー: 関連する API にアクセスする権限を与えられた Active Directory (AD) ユーザーは、AD を介して認証されます。リクエストに資格情報は必要ありません。
    • Windows NT LAN Manager (NTLM) 認証 (AD ユーザー): 暗号化された資格情報やプレーン テキストとしてユーザー名とパスワードをクライアントが提供できるチャレンジ/レスポンス認証方法。Automation Anywhere Credential Vault に保存されている資格情報を使用することが推奨されます。
    • OAuth2 - Control Room でマネージ: OAuth と Control Room を統合すると、サードパーティ プロバイダーの認証に使用するトークンを一元管理し、安全に保管できます。Control Room で OAuth 接続を使用するには、Web サービスを構成し、認証の詳細 (クライアント ID、クライアント シークレット、認証 URL など) をメモしておく必要があります。詳細については、「Control Room で OAuth 接続を構成する」をご覧ください。

      次の動画では、REST Web サービスで OAuth 接続を使用する方法を示します。

  • ヘッダー: すべてのメソッドでヘッダーが必要です。ヘッダーは、リクエストに関連付けられたメタデータを表します。
  • コンテンツタイプ: コンテンツ タイプを含むヘッダーは、クライアントとサーバー間のコンテンツ ネゴシエーションを定義します。REST Web サービス アクションは、以下のコンテンツ タイプをサポートしています。
    • application/x-www-form-urlencoded: URL のパラメーターをエンコードします。
    • JSON (application/json): JSON 要求本文を入力します。
    • XML (application/xml): XML 要求本文を入力します。
    • Text (text/plain)
    • XML (text/xml)
    • HTML (text/html)
    • multipart/form-data: ほとんどの場合、ファイルをサーバーにアップロードするためにバイナリ データを送信します。
    • Custom
      Custom: 標準コンテンツ タイプに該当しないカスタム コンテンツを追加します。たとえば、v .11.x から Automation 360 に移行する場合、application/vnd.whispir.message-v1+json は標準コンテンツ タイプのいずれにも該当しません。
  • 置換を追加: REST 要求本文に変数を入力できます。変数はデータのシンボリック表現であり、必要な場合は、手動で入力しなくても値にアクセスできます。たとえば、次の REST 本文の要求について考えてみましょう。
    {
   "name":"{{name}}",
   "email":"{{email}}",
   "status":"Active"
}
    上記の要求本文では、[置換を追加] をクリックして必要な値を追加することで、二重カッコで囲まれた変数を置換できます。
  • 詳細オプション:
    • 失敗応答をキャプチャ: [成功/OK] のレスポンスを除く失敗レスポンスをキャプチャするには、このチェック ボックスをオンにします。失敗レスポンスの詳細は、レスポンスの本文にキャプチャされます。
    • https を使用するときは、安全でない接続を許可します: https を使用するときに安全でない接続を許可する場合は、チェック ボックスをオンにします。
    • Cookie を受け入れる: サーバーのレスポンスからセッション Cookie を自動的にキャプチャするには、このチェック ボックスをオンにします。
      • キャプチャ: この機能を有効にすると、サーバーのレスポンスに含まれるセッション Cookie をキャプチャします。
      • 安全な保管: キャプチャされた Cookie は、プロセス メモリ内で暗号化され、永久に保存されることはなく、オートメーション セッション外ではアクセスできなくなります。
      • 再利用: Cookie は自動的に後続の REST 呼び出しに含まれるため、手作業による Cookie 処理が不要になり、オートメーションの信頼性が向上します。
      • 複数の Cookie の処理: この機能は、サーバーから返される複数の Cookie をシームレスに処理し、必要な認証情報がすべて含まれていることを保証します。
      • 破棄: キャプチャされた Cookie は、オートメーション セッションの終了時または Bot の実行終了時に自動的に破棄され、データのセキュリティとプライバシーが確保されます。
      注: キャプチャされた Cookie は、発行元のドメインに固有のものであり、異なるドメインに対して行われるその後の REST 呼び出しに自動的に使用されることはありません。これは、domainA.com からキャプチャされた Cookie は、domainB.com へのリクエストには利用されないことを意味します。
  • アクションの完了を待機: REST リクエストを送信してレスポンスを受信するまでのタイムアウト値を設定できます。POST、PUT、DELETE、PATCH、GET などの アクション を実行する場合、[アクションの完了を待機] フィールドで待機時間 (ミリ秒単位) を指定できます。デフォルトでは、待機時間は 60,000 ミリ秒です。
  • 出力変数: レスポンスの出力はディクショナリ変数にキャプチャされます。ディクショナリ変数はキーと値のペアです。レスポンス ヘッダー名をキーとして使用するとヘッダー値が返されます。「本文」をキーとして使用すると、レスポンス本文が返されます。
    注: REST API のレスポンス ステータスを表示するために、ディクショナリ変数においてレスポンス キーとその値を使用できます。
    API リソースのヘッダー名のリストを取得するには、次の手順を実行します。
    1. REST Web サービス アクションの後に ループ アクションを挿入します。
    2. [ディクショナリ内の各キー] 反復子を選択します。
    3. [ディクショナリ変数] フィールドで、REST Web サービス アクション出力を保持する変数を選択します。
    4. 各キーの値を $prompt-assignment$ に割り当てます。
    5. [ファイルに記録] アクションを挿入します。
    6. ヘッダー名のリストを保持するテキスト ファイルへのファイル パスを指定します。
    7. [テキストをログへ入力] フィールドに $prompt-assignment$ を挿入します。
    8. [既存のファイルを上書き] オプションを選択します。
    9. [保存] をクリックします。

      Bot を実行すると、API リソースから選択したファイルにヘッダー名が印刷されます。

値の安全な受け渡し

Credential Vault から Web サービスに値を安全に渡すには、サポートされている次のアクション フィールドにロッカー、資格情報、および属性を指定します。
  • URI
  • カスタム ヘッダー
  • 本文: application/x-www-form-urlencoded コンテンツ タイプの場合は、[パラメーターを追加] をクリックして Credential Vault から値を選択します。

    他のすべてのコンテンツ タイプでは、[資格情報をパラメーターとして選択] オプションを選択して [選択] をクリックします。

REST Web サービス パッケージのアクション

アクション 説明
DELETE メソッド URI によって特定されるリソースを削除します。
GET メソッド URI に含まれるパラメーターによって特定された情報を取得します。すべてのパラメーターは URI の一部として渡されるので、GET メソッドの [コンテンツ タイプ] はありません。

GET メソッドの制限と特徴には次が含まれます。

  • URI の長さは 2,048 文字に制限されます。
  • すべてのパラメーターが URI で渡されます。
  • GET メソッドは URI に含まれるデータを公開するので、POST メソッドに比べて安全性が低くなります。
  • GET はデータを変更しないので、承認に関係なく、すべてのユーザーにとって安全に機能します。

「GET メソッドの使用」を参照してください。
PATCH メソッド URI によって特定されるリソースを修正します。
POST メソッド URI に新しいリソースを作成します。
  • パラメーターがリクエスト本文で渡されます。
  • リクエスト本文の長さに制限はありません。

「POST メソッドの使用」を参照してください。
PUT メソッド URI または本文で渡されたパラメーターに基づいてリソースが更新または置き換えられます。「PUT メソッドの使用」を参照してください。

プロキシ サポート

デバイスがプロキシで構成されている場合、この パッケージ からのすべてのアウトバウンド リクエストはプロキシ サーバー経由でルーティングされます。「Bot エージェント とプロキシの設定されているデバイスの接続」を参照してください。