Orchestrator連携系アクティビティに使うODataについて Vol.2-①

お久しぶりです！ワッキーです

マラソンは終わってしまいましたが、出来る時にブログは書いていきたいですね…自身の備忘のためにも、ブログ大事にしていきたいと思ってます。

さてさて、Orchestrator連携系アクティビティに使うODataについてVol.2ですが、今回はODataだけではなくJSONというものについても触れていければと思います。

vol.1ではJobの取得に特化したアクティビティの使用方法について、使い方をご説明いたしましたが、今回は「もっといろいろなことをしたい！」「Job系アクティビティだと、定義出来る処理が限定的すぎる！」「Job以外のOCコンポーネントとの連携もロボットにさせたい！」と思った方々に向けた内容になっていると思います。

Job取得アクティビティよりも、少し使い方がトリッキーにはなりますが、今回ご紹介するアクティビティはこちら！

Orchestrator への HTTP 要求アクティビティ

これは、結構便利です！
Jobだけでなく、殆どのOrchestratorコンポーネントへの連携が可能で、Orchestratorに繋がっているStudioやロボットであれば、API連携に必要な認証情報は不要なのです～！

実際に私が受け持った案件でも、汎用IDでログインして稼働するロボットのJobを実行したユーザーのIDを取得したいという要望もあった際、こちらのアクティビティを利用いたしました。（いつもお世話になってますFriends MVPのMasatomixさんからもForumで助言など頂いて、試行錯誤いたしました。その節はありがとうございます）

今回は、Process１がProcess２のJobを実行するといった簡単な実装方法をご紹介したいと思います。(実際の案件ですと、後続処理プロセスを実行させる際に使用できるかと思います）
ちなみに、JSONペイロード（後ほど説明）の内容などはクラシックフォルダーを想定した内容になってます。
【Process1側の実装】

依頼詳細：Process1のロボットがログインする環境のユーザー名（仮名 vvacky)と同名のロボットでProcess2を動かしたい。Process2実行時、Process1はProcess2の引数：strStartDateに実行日を入力させたい

ロボット指定してJobを開始はJob系のアクティビティではできません…。また、クラシックフォルダ（近々廃止されるんですけどね…）を絶賛ご利用中の場合、Queueトリガーでロボット指定して後続プロセスを動かすことはできません（モダンなら出来るんですけどね…😢）。

だからこそ、このアクティビティめっちゃ便利です！（TT)

さて、何からすれば良いか、順を追って説明してみます。
①Jobを実行するためには、どんな情報が必要か？
こちらを先に潰しましょう！
OrchestratorとAPI連携をご紹介するMasatomixさんのQiitaでも同じみのPostmanのReferenceを覗いてみます。
OrchestratorでJobを実行するということは、Jobを開始するということですよね。
なので、下記のオレンジ色にハイライトしたようなStartJobsに対して、コマンドを送るものを見ていきたいと思います

そうすると、Postmanのページで4つくらい上記のコマンドを持つ例が出てくると思います。
今回は実行環境がクラシックフォルダで且つ引数を送信するので、一番最初に出てきたPost Start Processが利用できそうです。
スクロールバーで言うと、半分より少し上の部分ですね…💦

（ちなみに、モダンフォルダの場合は2番目に登場するPost Start Processをご参照されると良いと思います。Strategyの値をModernJobsCountにするなどあります。詳細はこちら）
さて、API連携してJobをスタートさせるのに必要な条件がBODYに記載されています。

これはJSONペイロードというもので、上記はJobStartする際に最低限必要な情報を定義するものです。

ReleaseKey：各プロセス固有の値
Strategy：実行方法
RobotIds：実行ロボとのID（”[]”よりリスト型で渡せるので、複数指定可能）
JobPriority：優先度
InputArguments：入力引数（"{}"より配列で渡せるので、複数指定可能）

上記より、Process1がProcess2を実行させるのに、Job以外の別コンポーネントから取得すべき値はProcess固有のReleaseKeyとRobot、vvackyのIdですね。

②Orchestrator への HTTP 要求アクティビティを使用して、ReleaseKeyを取得してみましょう！

アクティビティを置いただけでは勿論、真っ赤に怒られてしまいます。
プロパティに内容を入れていきましょう！
①Orchestrator上のフォルダを指定してください。プロセスが同じフォルダー内であれば指定は不要です（これは、特にモダンフォルダで指定が必要になります）
②Postメソッドの際に必要ですので、後ほど説明します。ReleaseKey取得（Get）の際は指定は不要
③Job情報取得の際でもおなじみOdataの内容を記入します
④情報を取得する場合はGET, Orchestratorにデータを作る（Jobの開始もある意味、実行命令のデータを作る事になります）際はPOSTを指定します
⑤HTTPリクエストした場合の結果を出力します

エンドポイントの相対パスはJobを取得アクティビティのODataと若干記述がことなります。単純にRelease情報のみの場合は下記のような記述になります。

”/odata/Releases”

取得したい情報のコンポーネントがJobだったらコンポーネント名はJobsとなります。ロボットだったらRobotsになります。
今回はProcess2のRelease Keyが欲しいのでフィルター条件をJob取得アクティビティ同様に付け加えます

”/odata/Releases?$filter= ProcessKey eq'Process2' & $select=Key”

Process名はProcessKeyとなり、Processの表示名はNameになります。ReleaseコンポーネントではKeyがReleaseKeyになります
エンドポイントの総合的な記述方法は下記のようになります

コンポ―ネント名の後ろの「?」以降に取得する条件が続きます。
filter文は取得条件で=以下に条件を記述していきます。全部のデータはいらないので、selectで取得項目を絞ります。Filter文とSelect文は＆で繋ぎます。

上記で記載したエンドポイントの相対パスをプロパティに設定し、strReleaseResponseという文字列型変数で結果を取得します

さて,strReleaseResponseですが、JSONがシリアル化された文字列で帰ってきます。今回はReleaseKey1つのみ保持した文字列が返ってくる想定ですので、文字列のママでも良いのですが、やはり処理しやすいようにJSON Objectに逆シリアル化します（複数データがある場合もありますので…）
なので、Web.APIのアクティビティをインストールしましょう

バージョンは１.7.0（2021年10月時点）が安定してますので、そちらにします。するとこんなアクティビティが見つかるとおもいますので、赤く囲ったアクティビティを使いましょう

入力にstrReleaseResponseを入れます。出力は、JSON Object型名探すの大変かと思いますので、Ctrl+Kで変数を生成しちゃってください（雑ｗ）

変数名はjobjResponseとしましょうか…

JSON Objectは実際にログなどで、jobjResponse("value").ToStringで吐き出してみると、こんな感じになります

{
"Key": "######-####-####-####-######"
}

今回はKeyだけなので、とてもシンプルに見えますが,他にもプロセス名やら、色々な情報が{}内に記載されています。
{}内は辞書みたいですね。1プロセス情報が{}なので、2プロセス取得できたら{}で囲まれてる文字列が2組入ってます。

jobjResponse("value")(0)とすると、配列でいう最初のデータを指します。
今回の場合、jobjResponse("value")(0)(“Key”).ToStringとすれば、ReleaseKeyが取れます！

次はロボットの取得ですね…vol.2-②記事に続く…