API実施結果とPigeon連絡履歴について

回答済み

コメント

32件のコメント

  • Kompiraサポートチーム

    ご質問ありがとうございます。
    回答させていただきます。

    事象に対する見解について

    まず、得られた結果から推察いたしますに、

    ①items.のparameters.であるscopeId →API採取では c69564eb-c90e-4b80-9f31-412026b27939

    ②items.のparameters.であるscopedisplayName  →API採取ではWebHook_change_s
    ③items.のparameters.であるtime(受信メール本文にあったデータです)→11:01:19
    ④items.のstatus →API採取ではfailed

    上記において「API採取」の結果として記載されている内容は、 2021/10/01 に行われた実行とは異なる実行結果に含まれる内容を参照しているものと考えられます。

    また、こちらでも念のため御社スペースでの過去の総連絡件数を確認させていただきましたが、結果は 739 件(ご質問後に連絡が追加で1件発生したものと思います)であり、画面に表示されている件数は正しいと考えられます。

    画面に出力している情報は、内部的には API を経由して取得したデータを用いており、 API を直接利用したことでこの件数が異なる、特に実際のレコード数よりも多くが取得されるというのは考えにくいことでございます。

    考えられる原因について

    これらについて見かけ上のずれが発生した原因として可能性が高いものとして「ツールによるデータ解析のミス」が考えられます。

    3枚目の画像を拝見するに、おそらく API からの出力をなんらかのツールを通してして確認しているものと思いますが、例えばデータの区切りが誤って判断されてしまうことで、件数が実際と異なってしまったり、データの行がずれてしまい、連絡履歴が持つIDと履歴内容の対応関係が崩れる、ということは十分に考えられます。

    いただいた情報だけではこれ以上踏み込んだことを申し上げるのは難しいところですが、API からの出力を確認しているツールや、API を呼び出す際に実際に発行したコマンドなど、より具体的な情報をいただければより細かなことがわかる可能性はございます。
    もし追加でご提示可能な情報があれば、いただいてもよろしいでしょうか。

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    早々のご対応ありがとうございます。

    ご指摘の通り、このAPI採取用に作成したツールを使っております。
    最新データのほうでは異常が見られなかったので、ご指摘の要因も考えられましたが、
    とりあえずQAを出させていただきました。

    ツールを介さずにAPIを採取してみるなど、切り分けをしてみますので、
    またご協力をお願いいたします。

    Kompira で運用が開始されて半年となり、そろそろ連絡履歴が削除され始めるので
    対処しているところです。

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    以前の質問から間があいてしまいましたが、追加質問をお願いいたします。

    上記事象において、件数の不一致の原因は、データの区切りが誤って判断されるイレギュラーデータが原因と思われます。
    したがいまして、そのデータについてご教示をお願いいたします。
    〔質問〕
    WEBHOOKにて架電したデータの一部に、通常は見られないパラメータ出力がありました。
    これはWEBHOOK での指定によるものでしょうか?自動的に出力されるなどあるでしょうか?

    以下、データ情報

    *****************************************************************************************************

    〔API〕
    /api/apps/pigeon/results?limit=1000

    〔通常と異なる箇所〕

    ・"parameters": { 指定の中に、"event": { 情報が出力

    ・"parameters": { 指定の中に、"message": {情報が出力

    ・"parameters": { 指定の中に、"scope":  {情報が出力

    ・"parameters": { 指定の中に、"space": {情報が出力

    ・"parameters": { 指定の中に、"trigger": {情報が出力

     

    以下、データ抜粋

        {
          "resultId": "e27188cc-0ade-4d21-9c22-de396709db5e",
          "taskId": "fca89e5e-4e69-45d6-9274-d80699956bd2",
          "parameters": {
            "callflow": "callpocPJ_test",
            "date": "2021/12/21",
            "error": "種別 これはテストです。アラートではありません。テストです",
            "event": {
              "createdAt": "2021-12-21T05:42:07.265228Z",
              "createdBy": "876edf0e-593e-0f26-a669-184b265afa8b",
              "eventId": "10661376-cdba-460a-af4d-140feef66afb",
              "messageId": "YWxlcnRodWIvMjAyMS8xMi8yMS8wNS80Mi8wNi80OTI3NDAwODMvMzI4NzdjZTAtN2EzZC00ZDc5LThjMWMtNjE3Y2ZlZGU1MGNiLzRkYzQwMmZiLWU0Y2YtNGYyYS04N2QwLTcxNjA1OWM2NTI5OC5qc29u",
              "method": "set",
              "previousSeverity": 0,
              "scopeId": "1a174c13-2fbb-460a-9a8d-18af36cbf75c",
              "severity": 0,
              "severityName": "severity",
              "value": 0
            },
            "hostname": "test",
            "message": {
              "content": {
                "html": "\u003chtml xmlns:v=\"urn:schemas-microsoft-com:vml\" xmlns:o=\"urn:schemas-microsoft-com:office:office\"
    以降、html情報 continue
     
            "scope": {
              "createdAt": "2021-08-12T01:01:39.520159Z",
              "createdBy": "7b08c764-0bcd-42e6-a48f-3b1d5baaaca9",
              "displayName": "callpocPJ_s",
              "muted": false,
              "remarks": "",
              "scopeId": "1a174c13-2fbb-460a-9a8d-18af36cbf75c",
              "severity": 0,
              "status": "normal",
              "thresholds": {
                "incident": 5,
                "warning": 3
              },
              "updatedAt": "2021-08-12T11:41:46.011875Z",
              "updatedBy": "7b08c764-0bcd-42e6-a48f-3b1d5baaaca9"
            },
            "scopeSeverities": {
              "severity": 0
            },
            "space": {
              "createdAt": "2021-07-12T01:58:30Z",
              "createdBy": "7b08c764-0bcd-42e6-a48f-3b1d5baaaca9",
    以降、space 情報 continue
     
            "trigger": {
              "triggerId": "88058c0a-c4ca-4413-8408-d7753c3cef8c"
            }
          },
     
    "keyInput": "", 以降は通常と同じ
     
    以上です。ご回答のほど、よろしくお願いします。
    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    WEBHOOKにて架電したデータの一部に、通常は見られないパラメータ出力がありました。
    これはWEBHOOK での指定によるものでしょうか?自動的に出力されるなどあるでしょうか?

    parameters には連絡実行時に渡されたパラメータが出力されますが、 AlertHub のアクションを用いて Pigeon を呼び出す場合、 AlertHub からは下記の情報が標準で渡されます。

    • 受信メッセージ
    • 発生イベント
    • イベントの対象スコープ
    • アクション発火に関わったトリガー
    • ご利用のスペース

    なお AlertHub ではトリガーの「パラメーター加工フロー」にて上記以外の情報を追加することができ、また AlertHub 以外から Pigeon を呼び出す場合、 parameters の指定内容は完全に自由となりますので、 parameters にどういったフィールドが含まれるかについては、固定される保証はございません。
    データ展開時にはこの点にご注意ください。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    質問の仕方が悪かったようで、再度質問をさせていただきます。

    5日前の書き込みの中に、以下の情報を記載してあります。

    ********************************************************************

    〔API〕
    /api/apps/pigeon/results?limit=1000

    〔通常と異なる箇所〕

    ・"parameters": { 指定の中に、"event": { 情報が出力

    ・"parameters": { 指定の中に、"message": {情報が出力

    ・"parameters": { 指定の中に、"scope":  {情報が出力

    ・"parameters": { 指定の中に、"space": {情報が出力

    ・"parameters": { 指定の中に、"trigger": {情報が出力

    *******************************************************************

    これらの 通常は表示されない情報が、
    架電結果として表示されるということは、
    WEBHOOK api/apps/pigeon/chain/invoke 処理の際に
    parameters の中で明示的に指定した場合に表示されますか?

    (例えば)

    0
    コメントアクション Permalink
  • 原井麻有

    api/apps/pigeon/chain/invoke 実行時に、parameters の中に
      "parameters":{
         "event": "{{event}}"
       }

    などのように指定した場合に、架電結果レコードとして発生、登録されますか?
    それとも別の要因で自動的に発生、登録されますか?

    WEBHOOKを使った架電に関しては、基本的に同し定義体で架電をかけているので、
    /api/apps/pigeon/results の結果も同じものとなる予測です。

    ですが今回はイレギュラーデータ(前述 ********* 内の〔通常と異なる箇所〕のこと)が数件発生
    してしまったので、その発生要因が人為的なミスなのか、なんらかの事象で無作為に発生しうるものなのかをご教示いただきたいと考えております。

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Takahiro Honda (Fixpoint Inc.)

    まず前提として、 Pigeon では parameters に指定された内容が架電結果の同名フィールドに出力されます。この点はご理解いただけている通りかと存じます。

    現在御社では AlertHub の Webhook アクションを用いて Pigeon に対するリクエスト内容を直接構築し、リクエストを行なっているかと思います。この際、提示いただいたように event のみを parameters に含めたのであれば、 Pigeon 側にも event のみが記録される挙動で間違いございません。

    一方で、元々は上記の形ではなく Pigeon アクションを用いた連携を行なわれたとも思い、そちらを利用した場合は先に提示いただいた

    • event
    • message
    • scope
    • space
    • trigger

    の 5 フィールドが自動的に parameters へ指定されます。該当する履歴はおそらくこの Pigeon アクションにより Pigeon の連絡実行を行った際の履歴と考えられます。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になります。
    今までのご回答に対する質問①と、

    試しに行ってきた再現テスト②についてお応えください。

    • 5 フィールドが自動的に parameters へ指定されます
      とのことですが、それでしたら、
    • ​/api​/apps​/pigeon​/results
      連絡処理結果の一覧取得 を行った際、5フィールドの情報が追加されるデータ(イレギュラー:数件)と5フィールドの情報が表示されないデータ(レギュラー)が混在するのはなぜでしょうか?

      試しに "event" を WEBHOOK のパラメータに指定し、api/apps/pigeon/chain/invoke を実行したところ、 
    • 400 Bad Request
    • "title": "Invalid request parameter(s)",
    • "detail": "Invalid request payload",
    • "instance": "/api/apps/pigeon/chain/invoke"
      ということで、ボディ文に上記の要因が表示されていました。
    • ②以下のWEBHOOK 定義の エラーはどうすれば解除されますか?

     

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    失礼しました。
    ②のエラーはこちらの指定ミスでした。質問を取り消します。

    0
    コメントアクション Permalink
  • Takahiro Honda (Fixpoint Inc.)

    連絡処理結果の一覧取得 を行った際、5フィールドの情報が追加されるデータ(イレギュラー:数件)と5フィールドの情報が表示されないデータ(レギュラー)が混在するのはなぜでしょうか?

    連絡処理結果の一覧取得においては、 Pigeon がどの様な道具で呼ばれたかは関係なく、全ての履歴が返却されます。

    先に書いた通り、御社では現在は Webhook アクションによるリクエストに統一しているものとは思いますが、過去には Pigeon アクションによるリクエストを送ったこともあるかと存じます。履歴は 180 日間の間保持されますので、 Pigeon アクションによる最後のリクエストから 180 日が経過するまではこの履歴は残り、また連絡処理結果を一覧取得した場合の結果にも混在いたします。

    以下のWEBHOOK 定義の エラーはどうすれば解除されますか?

    画像を拝見した限り下記の行の末尾のカンマが抜けておりますので、挿入すれば動くものと考えられます。

    "callflowId":"{{CFid}}"

     

    0
    コメントアクション Permalink
  • Takahiro Honda (Fixpoint Inc.)

    ②のエラーはこちらの指定ミスでした

    回答が前後してしまい申し訳ございません。承知いたしました。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    ご回答ありがとうございました。

    JSON形式で1情報であるものが、こちらのツールで複数レコードに成型されてしまっている原因となっているJSONの階層がわかりましたので、いただいた情報を整理した上で、再度質問いたします。

    (当方のツールの仕様に問題があるかもしれないことは、申し訳ありませんがすこし横に置かせていただきます。)

    ① item>parameters>message>metadata>headers>Received に表示される
    3種もしくは4種のデータによって、別レコードとして成型しています。
    (以下は収集情報例)

    "by mx0085p1iad2.sendgrid.net with SMTP id 6UyEVeFMVe Thu, 07 Oct 2021 06:13:48 +0000 (UTC)",
    "from JPN01-OS2-obe.outbound.protection.outlook.com (unknown [40.107.141.97]) by mx0085p1iad2.sendgrid.net (Postfix) with ESMTPS id 47032A00E0B for \u003c03lvctsn1hjanvg49pfv7zrvt8zrzic2e135o0zeszcvywzf@receiver.cloud.kompira.jp\u003e; Thu,  7 Oct 2021 06:13:48 +0000 (UTC)",
    "from OSZPR01MB7066.jpnprd01.prod.outlook.com (2603:1096:604:13f::8) by OSAPR01MB2580.jpnprd01.prod.outlook.com (2603:1096:603:3c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Thu, 7 Oct 2021 06:13:46 +0000",
    "from OSZPR01MB7066.jpnprd01.prod.outlook.com ([fe80::f943:bd2d:53ba:7cd2]) by OSZPR01MB7066.jpnprd01.prod.outlook.com ([fe80::f943:bd2d:53ba:7cd2%8]) with mapi id 15.20.4587.019; Thu, 7 Oct 2021 06:13:46 +0000"

    ② ①のデータはどういうものかご教示いただけますか?
      見たところですが、SendGrid を経由してたどった通信情報でしょうか?

    ③ 以下の見解をいただきましたが、今回イレギュラーとして見ている①のデータは、全てwebhook 架電のものでした。
         
    >一方で、元々は上記の形ではなく Pigeon アクションを用いた連携を行なわれたとも思い、そちらを利用した場合は先に提示いただいたの 5 フィールドが自動的に parameters へ指定されます。

    何度もやりとりさせていただいて申し訳ありませんが、よろしくお願いいたします。
    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    ① item>parameters>message>metadata>headers>Received に表示される
    3種もしくは4種のデータによって、別レコードとして成型しています。

    ② ①のデータはどういうものかご教示いただけますか?
      見たところですが、SendGrid を経由してたどった通信情報でしょうか?

    AlertHub のメール受信スロットでのメール受信は SendGrid にて行なっており、 Received は SendGrid により付与されたメールヘッダの内容となります。この Received ヘッダは SendGrid に限らずメール受信サーバーが付与する一般的な仕様となり、詳しい意味については下記の記事の説明が比較的易しいかと存じます。

    Received【メールヘッダ】 - 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

    ③ 以下の見解をいただきましたが、今回イレギュラーとして見ている①のデータは、全てwebhook 架電のものでした。

    最初に「イレギュラーデータ」として提示いただいた連絡結果(本スレッドの 3 つめのコメントに記載いただいた、 resultId = e27188cc-0ade-4d21-9c22-de396709db5e のデータ)についてより細かく履歴を追跡させていただきましたが、少なくともこちらは Webhook ではなく Pigeon アクションによる架電であることが確認されております。

    こちら、 Webhook アクションによる架電であると判断した「イレギュラーデータ」に関して、どういった流れでそう確認されたものでしょうか。
    また、そう判断された連絡結果についてあらためて正確に調査いたしますので、該当データの resultId を(一部で構いませんので)いただいてもよろしいでしょうか。

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。

    ①の Recieved ヘッダについて、ご教示ありがとうございました。
       やはり通信経由情報なのですね。
       野暮な質問とはなりますが、Kompira の稼働統計を取る目的としては、あまり必要な情報ではない、とみておりますが、この理解に何か帰任ることなどありましたら、教えていただけると助かります。

    ②については、こちらでも再度確認をいたしました。
    item >parameters >scope >displayName の情報では、ご指摘の通り、Pigeon のスコープ名(callpocUN_s)が記載されておりました。
    私どもが参照していたのは、
    item >parameters >displayName の情報で、WebHookアクションを利用したスコープ名(WebHook_change_s)です。
    ただ、これはツールで出力した情報を見ていたもので、APIで採取したJSONデータを直接見ると、
    item >parameters >scope の階層情報が見るべき箇所として正しいのかなと考えております。
    scopeId もPigeon のスコープ名(callpocUN_s)

    0
    コメントアクション Permalink
  • 原井麻有

    と一致しておりますので。

    そうなると、現在把握しているデータは全て「Pigeon」での架電情報となります。ご指摘ありがとうございました。
    結論としては、 Pigeon架電であれば、5 フィールドが自動的に parameters へ指定され、その results 情報を採取した時に、Recieved 情報が当方のツールでは問題となる、といった状況ですね。

    だいぶ情報の整理ができてきました。ご協力ありがとうございます。
    また質問するかもしれませんので、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

       野暮な質問とはなりますが、Kompira の稼働統計を取る目的としては、あまり必要な情報ではない、とみておりますが、この理解に何か帰任ることなどありましたら、教えていただけると助かります。

    こちらに関してご理解の通りで、稼働統計を取る上で Received ヘッダの情報を読む必要はないものと思われます。

    お役に立てた様で何よりでございます。
    引き続きよろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    恐縮ですが、また教えてください。

    /api/apps/pigeon/results の指定方法で、アクション別、すなわち、
    WEBHOOK/Pigeon/mail それぞれのアクションカテゴリに分けて、一括で連絡履歴を取得することは可能でしょうか?


    ①の質問は、WEBHOOK/Pigeon の取得したJSONツリー構成情報が異なっている故の質問です。
    WEBHOOK/Pigeon のJSONツリー構成情報を混在させたくない、という要望があるためなのですが、
    API による採取データの扱いについて、一般的な見解を教えていただけますでしょうか?

    まず、
     /api/apps/pigeon/results からもたらされる情報は、各フィールド情報が架電時に取得されているか、されていないかの違いがある。
    また、/api/apps/pigeon/results は、その仕様に応じて、各データが持つ情報をJSONツリー化して提供している

    ただ、その提供情報を、読込プログラムが再帰呼び出しで成型しているので、出力はどうしても発生した情報(データとして存在する情報)のみを持つことになります。
    その、異なったJSONツリー構成が混在しているJSONファイルを、有効に分解・レコード化するのは、皆さんどのようになさっているのでしょうか?

    もし何か良い事例があれば、ご教示ください。よろしくお願いします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    /api/apps/pigeon/results の指定方法で、アクション別、すなわち、
    WEBHOOK/Pigeon/mail それぞれのアクションカテゴリに分けて、一括で連絡履歴を取得することは可能でしょうか?

    こちらに関しては残念ながら不可能となります。

    /api/apps/pigeon/results は Pigeon の API ですが、この API は呼び出し元が AlertHub のどのアクションであるか、さらに言えばそもそも呼び出し元が AlertHub か、全く異なる別のシステムであるかといった点について感知せず、これに沿った絞り込みも出来ない、という立ち位置となります。

    ①の質問は、WEBHOOK/Pigeon の取得したJSONツリー構成情報が異なっている故の質問です。
    WEBHOOK/Pigeon のJSONツリー構成情報を混在させたくない、という要望があるためなのですが、
    API による採取データの扱いについて、一般的な見解を教えていただけますでしょうか?

    JSON という形式は Web API のデータ形式としてよく使われますが、このデータ形式はそもそもツリー構造を柔軟に定義することができることが強みの 1 つであり、特に parameters のように利用者により自由に設定できる項目が含まれる場合に、データごとにツリー構造が異なる、というのは弊社 API に限らず、 JSON 形式を利用する API においてよくあるものとなります。

    これに対して、固定のツリー構造を期待してデータ全体を解析し、個々の情報に分解しようとするのは確かに厳しいと思います。こういった非固定仕様のデータを扱う場合には、データ全体の解析ではなく、必要なデータだけを部分的に抽出する、という戦略が採られます。

    こちらの方針において使われる方法の一例としては jq というコマンドを用いてシェルスクリプト・バッチファイル等を書く形です。 CUI ツールとなるため取り回しが少々難しいですが、参考となる記事を以下に記載します。

    jqを活用してAPIレスポンス等から欲しい情報だけを抽出する【初級編】

    少しでもご参考になれば幸いです。
    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    ご丁寧な回答をありがとうございました。

    ご紹介いただいた記事を拝読いたします。
    またよろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。

    先日ご紹介いただいた jq について質問をお願いいたします。
    Windows 環境にインストールし、コマンドとして動作するように設定いたしました。
    申し訳ありませんが、以下2点の質問についてご教示ください。


    ①jq にてJSONを加工する場合の指定方法について

    ・環境:windows10

    ・利用API:api/apps/pigeon/results

    ・取り出したいパラメータ:item>resultId, item>parameters>callflowId, item>status, item>createdAt, item>updatedAt


    コマンドプロンプトにて、 以下のように実行しましたが、syntax error となりました。
    D:\harai\python>type API_pigeon_results_list_20220420_1000.json | jq . の場合は、json形式でデータが標準出力されるのは確認しています。

    インストール環境が Windows なので、Linux との読み替えもあり、どこが間違っているのかご教示願えますでしょうか。よろしくお願いします。

    ②curl コマンドでの条件を追加する場合の、”?” の構文を調べるには、キーワードは何にすれば出てくるでしょうか?
    コマンド例:/apps/pigeon/calls?limit=1000 

    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    コマンドプロンプトにて、 以下のように実行しましたが、syntax error となりました。

    コマンドプロンプトで使用できないシングルクォーテーション( ' )を使用していることが原因と考えられます。
    コマンドの後半のみ抜粋しますが、下記のようにダブルクォーテーションに直すことで解決する可能性がございます。

    jq ".items[].resultId"

     

    ②curl コマンドでの条件を追加する場合の、”?” の構文を調べるには、キーワードは何にすれば出てくるでしょうか?
    コマンド例:/apps/pigeon/calls?limit=1000 

    これは「クエリパラメータ」や「クエリ文字列」と呼ばれるものですので、これらのキーワードで調べるのが良いかと存じます。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっています。
    ご教示ありがとうございます。やってみます。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    jq の使い方でご教示ください。


    /api/apps/pigeon/resultsのjsonファイル |  jq ".items[].parameters       や
    /api/apps/pigeon/resultsのjsonファイル |  jq ".items[] | [.parameters.callflowId]"    のように、item配列からその単一要素を抽出するのはわかったのですが、
    以下の例)の複数要素を一度に抽出する場合はどうすればよろしいでしょうか?

    例):Pigeon のresults のケースで、以下の要素を一括で抽出する場合
    items>resultId
    items>parameters>callflowId
    items>parameters>hostname

    items>parameters>scope>displayname

    items>createdAt

    items>updatedAt

     

    ②パイプを使った時、/api/apps/pigeon/resultsのjsonファイル |  jq ".items[] | [.parameters.callflowId]" 

    のように、 [.parameters.callflowId]と記載できますが、
    /api/apps/pigeon/results のツリー構造では、配列はitem[] のみのようです。
    パイプを通す先の指定 [.parameters.callflowId] の記述の意味は、配列の中の要素 という意味でしょうか?

    申し訳ありませんが、以上2点のご教示をよろしくお願いします。

    0
    コメントアクション Permalink
  • 原井麻有

    何度も申し訳ありません。数分前の質問①は以下の指定で可能となりました。
    (同一性フィルター . と、カンマ ,  の指定)

    C:\Users\t7462872>type D:\harai\jq\調査用JSONデータ\編集\VSCode_edit_15_API_pigeon_results_list_20220420_1000.json | jq ".items[].resultId,.items[].parameters.callflowId"

    ですが、結果は、それぞれのレコードを室力してしまうので、データの再構成が必要になります。
    現在の出力例)

    上記の形態ではなく、指定した要素を1レコードずつ出力できますか?
    もしくはJSON構造に再構成をするなど。

    申し訳ありませんが、先ほどの質問①は、こちらに変更させてください。
    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    昨日出させていただいた、①②の質問ですが、こちらでもなんとか確認がとれました。

    ファイル.json | jq ".items[] | [.resultId, .parameters.callflowId, .parameters.date, .parameters.hostname, .parameters.scopeId, .parameters.scopedisplayName, .parameters.time, .status, .reason, .createdAt, .updatedAt, .parameters.callflow, .parameters.scopedisplayName, .parameters.scopeId] | @csv">csv_20220428.csv

    といった指定で、JSON構造の Parameters の内部も抽出できました。
    こちらについては、当方でもう少し精査して、改めて質問させていただおうと思いますので、
    一旦キャンセルとさせていただいてもよろしいでしょうか?

    お手数をおかけし申し訳ありません。
    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    かしこまりました。
    引き続きよろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。

    ご存じの通り、JSONや jq を使って、実運用データの保存や活用を行っているのですが、 /api​/apps​/pigeon​/calls(架電結果の一覧取得)のデータを精査していてわからないことがあるので、ご教示願います。

    【データ種別】/api​/apps​/pigeon​/calls(架電結果の一覧取得)の JSON
    【採取時刻】    2022/04/28 19:03

    【その時のPigeon連絡履歴最古データ】resultId:3FC4A783-1A1E-420B-80E5-1F87FF06C734(createdAt: 2021/11/1 16:42) ※jsonの最古データと、Kompira cloud画面上の最古データは一致


    【その時のPigeon架電結果最古データ】calls:F184CFFD-0F5E-496D-9A69-4793F201DD4A

    (createdAt: 2021/11/29 15:44) ※画面からの確認は困難なため、jsonの最終データから最古データと判断(results も calls も sortキーの指定は無し。追加指定は limit= 1000 のみ。)

    以上のような結果が得られました。
    【質問】
    ①results も calls も保存期間は半年で、日付でのコントロールなので、どちらも最古データは同じものになるのではないのでしょうか?
    今回得られた calls の最古データが、results の最古データとは28日も離れた日付のデータであることが解せません。

    以下に両者の画面コピーを添付いたしますので、ご回答のほどよろしくお願いいたします。
    最古データなので、調査いただくときは消えているかもしれません。
    その場合は別データか、もしくは仕組みの解説をお願いいたします。

    〔results 最古データ〕

    〔calls 最古データ〕

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。もう1件追加の質問をお願いいたします。

    /api​/apps​/pigeon​/results(連絡処理結果の一覧取得)の構文機能で、特定の createdAt の日付データだけ参照することは可能でしょうか?

    0
    コメントアクション Permalink
  • Kompiraサポートチーム

    ①results も calls も保存期間は半年で、日付でのコントロールなので、どちらも最古データは同じものになるのではないのでしょうか?
    今回得られた calls の最古データが、results の最古データとは28日も離れた日付のデータであることが解せません。

    「results も calls も sortキーの指定は無し。追加指定は limit= 1000 のみ。」とありますが、御社のデータを確認したところ(ご質問時点とは多少異なるかとは思いますが) results は 847 件、 calls は 1,117 件ございます。 limit=1000 を指定することで取得されるデータは 1,000 件に絞られますので、 results の方は全件が取得されますが、 calls は古い方から 117 件が取得されない、という結果となります。

    なお limit 指定は最大値が 1000 のため、こちらを一度のリクエストで取得することはできません。残りの 117 件を取得するには limit に加えて offset=1000 を指定してください。こちらのオプションにより 1001 件目以降のデータを取得することになります。

    なお、履歴の総数は( limit / offset の指定内容に関わらず)取得結果の total に出力されます。こちらの値が 1000 を超える場合には今回と同様のケースにあたるとお考えください。

    /api​/apps​/pigeon​/results(連絡処理結果の一覧取得)の構文機能で、特定の createdAt の日付データだけ参照することは可能でしょうか?

    こちらに関しては現時点では不可能となります。

    よろしくお願いいたします。

    0
    コメントアクション Permalink
  • 原井麻有

    お世話になっております。
    以下2点のご教示をお願いいたします。

    ①Pigeon の架電履歴データで、「﨑」(unicode ufa11) が python でエンコードエラーとなりました。
    shift_jis から UTF-8 に変換し対処したのですが、
    この「﨑」の文字だけひっかかってしまったのは、何が原因かもしお分かりになるようでしたら
    教えてください。
    また、APIで採取される文字は shift_jis だと認識してよろしいでしょうか?

    ②jq の用法をご教示ください。
    jq の機能(インデックス付出力:map 指定)で JSON形式 から csv形式へ変換を行っています。
    必要なフィールドを取り出しているのですが、Pigeon のparameters直下より下のフィールド指定では、エラーになってしまいます。
    どのように指定すれば良いのかご教示ください。

    【状況】
    ・入力ファイル.json は ​/api​/apps​/pigeon​/results  の実行結果

    ・WEBHOOK で指定したJSONツリーと、pigeon が採取したJSONツリーが混在

    ・以下の "email","receiveSlotId",event の "createdAt"  などの指定でエラーになります。

    【入力データ】

        {
          "resultId": "e27188cc-0ade-4d21-9c22-de396709db5e",
          "taskId": "fca89e5e-4e69-45d6-9274-d80699956bd2",
          "parameters": {
            "callflow": "callpocPJ_test",
            "date": "2021/12/21",
            "error": "種別 これはテストです。アラートではありません。テストです",
            "event": {
              "createdAt": "2021-12-21T05:42:07.265228Z",
              "createdBy": "876edf0e-593e-0f26-a669-184b265afa8b",
              "eventId": "10661376-cdba-460a-af4d-140feef66afb",
              "messageId":
    ~中略~
     
                "to": [
                  {
                  }
                ]
              },
              "receiveSlotId": "32877ce0-7a3d-4d79-8c1c-617cfede50cb",
              "receiveSlotKind": "email",
              "receivedAt": "2021-12-21T05:42:06.492740083Z"

    【使用例とエラーメッセージ】
    (base) C:\Users\xxx >type 入力ファイル.json | jq -r ".items | map({resultId: .resultId, Pcallflow: .parameters.callflow, Pevent: .parameters.event.createdAt})" > 出力ファイル.json
    jq: error (at <stdin>:18833): Cannot index string with string "createdAt"


    以上、よろしくお願いいたします。

    0
    コメントアクション Permalink

サインインしてコメントを残してください。