API ワークフローを利用する

Orchestrator から API ワークフローを利用する

パブリッシュした API ワークフローを Orchestrator から実行するには、以下の手順を実行します。

1. Automation Cloud の Orchestrator で、API ワークフロー プロセスが存在するフォルダーに移動します。
2. [オートメーション] > [プロセス] に移動します。
3. 対象の API ワークフロー プロセスで、対応する行の最後にある [ ジョブを開始 ] を選択します。
4. 開いたページで、以下の情報を入力します。
   • 実行ターゲットの オプション
   • ランタイム引数の オプション。[入力] セクションは API 要求の入力スキーマを表し、実行の入力として使用するプロパティを指定できます。
5. プロセスを実行するには、[ 開始] を選択します。

ワークフローが正常に実行されると、生成された応答をワークフロー実行の詳細 ( [オートメーション] > [ジョブ]) で確認できます。

エージェントで API ワークフローを呼び出す

API ワークフローをツールとして統合することにより、UiPath Agents の機能を拡張します。エージェントは、これらのワークフローに自動的にクエリを実行して関連するコンテキストを収集し、エージェントと AI モデルが利用可能なデータを正確に制御できるようにします。

次のシナリオでは、API ワークフローで Workday から取得したデータを変換し、エージェントに公開される情報を名前とメール アドレスのみに制限する方法を示します。Workday サンドボックスでは、Betty Liu は直属の部下と同僚が割り当てられているマネージャーとして構成されています。エージェントに対するクエリの例を次に示します。

• 「ベティ・リューの部下は誰だ?」
• 「ベティ・リューのためにすべての仲間を提供してください。」
• 「ベティ・リューの仲間で、報告書を持っている人はいますか?」

大事な： このエージェントは Workday の資格情報を保存せず、Workday に直接クエリを実行することもできず、API ワークフローによって返される応答のみに依存します。

開始する前に、次の前提条件が満たされていることを確認します。

• Workday API ワークフローを Orchestrator にパブリッシュしました。Orchestrator から実行したワークフローが正常に実行されることを確認します。
• プラットフォーム ユニットがテナントに割り当てられます。
• 提供されている Workday との連携の例に従うには、ワークフローに以下が含まれていることを確認してください。
  • 姓と名のフィールドを持つ入力スキーマ。
  • ピアと直属の部下の配列を含む出力スキーマ。

1. エージェントを手動で作成します。または、次のプロンプトで Autopilot ジェネレーターを使用します。

   「Workday でマネージャー、レポート、同僚の詳細を問い合わせてください。」

   Autopilot でエージェントが作成され、エージェントのプロンプトと設定が提案されます。この例では、提案されたプロンプトは最初は受け入れられましたが、後に ユーザー プロンプト は簡略化され、 {{ query }} 変数のみが含まれるようになりました。

2. エージェントの [データ マネージャー] パネルで、String 型の queryという入力プロパティを定義します。これにより、 ユーザー プロンプト に有効な参照が含まれるようになります。
   
3. [ クラウドでデバッグ] を選択します。ユーザー プロンプトのクエリを入力するように求められます。ただし、[ 実行トレース ] パネルには、エージェントが現在 Workday にアクセスできないため、まだ応答を提供できないことが示されています。
4. エージェントの[ツール] セクションから、[ API ワークフロー >ツールを追加] を選択します。
5. 既存の API ワークフロー (Workday をクエリするワークフロー) を選択し、その説明を入力します。ベスト プラクティスとして、エージェントがプロンプトに基づいてワークフローを自動的に設定するのに十分な詳細を指定します。明確な説明には通常、入力パラメーターの詳細が含まれます。例えば：
   「労働者の姓と名を入力として受け取り、回答で直属の部下と同僚を提供します。入力された名前は、Workday で検索するマネージャーです。
6. [クラウドでデバッグ] を選択して、エージェントを再度実行します。「ベティ・リューの直属の部下は誰ですか?」というクエリを入力します。[実行トレース] パネルで、エージェントが以下の API ワークフローを呼び出したことが識別されるようになりました。
   • API ワークフローに送信される要求です
   • API ワークフローから受け取る応答です
   • エージェントが応答を使用してクエリを実行する方法

おめでとうございます。

エージェントのユーザー プロンプトのバリエーションを作成できるようになりました。クエリによっては、エージェントは完全な応答を提供する前に API ワークフローへの複数の呼び出しをトリガーする場合があります。

Maestro で API ワークフローをタスクとして使用する

API ワークフローは、Maestro のタスクとして、詳細な API チェーンとデータ変換をカプセル化します。これにより、Maestro の主要なプロセスが明確、簡潔、かつ簡単に管理されます。API ワークフロー内で特定の API インタラクションを分離することで、複数のプロセス間での可読性を維持し、再利用性を促進します。

次のシナリオは、従業員が解雇されるたびに Maestro が Workday API を呼び出し、Slack チーム通知を送信する方法を示しています。

開始する前に、次の前提条件が満たされていることを確認します。

• Workday API ワークフローを Orchestrator にパブリッシュしました。Orchestrator から実行したワークフローが正常に実行されることを確認します。

  API ワークフローに以下が含まれることを確認します。

  • 姓と名のフィールドを含む入力スキーマ。
  • ピアと直属の部下の配列を含む出力スキーマ。

手順 1: エージェンティック プロセスを作成する

1. エージェンティック プロセスを作成します。
2. 開始イベント要素を追加します。「Employee Hired」という名前を付けます。
   1. 開始イベントの[アクション] プロパティで、[ コネクタのイベントを待機] を選択します。
   2. [コネクタ] プロパティで [Workday REST - Worker Created] を選択します。これは、プロセスをトリガーするイベントです。
3. タスク要素を追加し、開始イベントを接続します。「Find Employee Relationships」という名前を付けます。
4. もう 1 つの タスク 要素を追加して「通知を送信」とし、Find Employee Relationships 要素を接続します。
5. 終了イベントを追加します。「通知の送信時」という名前を付けます。

これがプロセスの設定です。新しい従業員が雇用されるたびに、このプロセスによって API ワークフローがトリガーされ、レポート構造や関連する関係などの従業員情報が取得されます。

手順 2: [従業員関係を検索] タスクを設定する

エージェンティック プロセスに必要な API ワークフローは、Find Employee Relationships タスクにあります。設定方法は次のとおりです。

1. 「 従業員関係の検索 」タスクを選択します。
2. [アクション] プロパティで、[API ワークフローを開始し待機] を選択します。
3. [ API ワークフロー ] プロパティで、パブリッシュ済みの Workday API ワークフローを選択します。プロパティ パネルには、選択したワークフローの入力と出力が表示されます。以下に例を示します。
   • 入力 には 、[姓 ] と [名] が含まれます。
   • 出力には 、 マネージャ、 ピア、および レポートの詳細が含まれます。
4. 入力を以下のように設定します。
   • 開始イベント 応答オブジェクトから変数として 名を呼びます 。式エディターを開き、[変数を挿入] を選択して、[ Employee Hired (従業員雇用の>回答)] > [Worker (労働者の氏名)] > に移動します。次に、式に Split(' ')[0] を追加します。次のようになります。

     vars.response_1.worker.descriptor.Split(' ')[0]

     ここで、 worker は 開始イベントの 応答からの応答オブジェクトです。.Split(' ')[0] は、フル ネームをスペース文字で分割し、フル ネームの最初の部分を取得します。
   • 開始イベント 応答オブジェクトの変数としての 姓 です。式エディターを開き、[変数を挿入] を選択して、[ Employee Hired (従業員雇用の>回答)] > [Worker (労働者の氏名)] > に移動します。次に、式に Split(' ')[1] を追加します。次のようになります。

     vars.response_1.worker.descriptor.Split(' ')[1]

     ここで、 worker は 開始イベントの 応答からの応答オブジェクトです。.Split(' ')[1] はフル ネームをスペース文字で分割し、フル ネームの 2 番目の部分を取得します。

手順 3: 通知の送信タスクをカスタマイズする

この手順では、手順 2 で実行した API ワークフローから返されたデータを使用するように [通知を送信] タスクを設定します。

1. [ 通知を送信 ] タスクを選択します。
2. [アクション] プロパティで [コネクタ イベントを実行] を選択します。
3. [ コネクタ ] プロパティで [ Slack] を選択し、自分の コネクションを使用するように設定します。
4. [アクティビティ] プロパティで、[チャンネルにメッセージを送信] を選択します。
5. [ チャンネル名/ID] に、通知の送信先 Slack チャンネルの ID を入力します。
6. [メッセージ] プロパティで、[手順 2: マネージャー、ピア、レポート] の出力変数を選択します。
7. [送信元] プロパティで [bot] を選択します。

手順 4: エージェンティック プロセスをテストする

このエージェンティック プロセスを正常にテストするには、Workday サンドボックス環境にアクセスできることを確認してください。

[ テスト ] を選択してワークフローを検証します。Maestro では、次の 2 つの重要な接続を指定するように求められます。

• Slack 接続—通知の送信タスクで必要です。
• Workday 接続—開始イベントで必要です。

大事な： Maestro は API ワークフローのコネクションを要求しません。これらのコネクションは API ワークフロー自体の中で個別に管理されるためです。