一括操作機能について（他 pigeon）
回答済み
①[AlertHub]
アップデート情報の「一括操作機能 (CSV インポート・エクスポート) を追加しました」について、どのあたりの機能なのか、記事などありましたら教えてください。
②Pigeon の連絡履歴について、
501-666件目で一覧を表示し、その明細を確認した後、ブラウザの戻る（←）で画面を戻したところ、501-666件目が表示されている一覧画面に戻らず、かなり前の一覧を表示する位置に戻ってしまいます。
使い勝手が悪いので、開いていた明細の一覧に戻りたいのですが （501-666件目の一覧）何か方法はありますか？
また、一覧画面に戻らなくても、明細画面だけで前後のデータに移動する方法はないでしょうか？
※今回の画面sortは以下のように指定しましたので、添付いたします。
③以下の添付画面上の、"79741cb0-6610-4557-a152-453d2a47c979" は
"callId
"contactId"
"taskId"
"resultId
のどれに当たりますか？
/api/apps/pigeon/results/{resultId}の Example Value を見ると、上記4つのID全てに同じ値が入っているようです。
-
ご質問ありがとうございます。
回答させていただきます。AlertHub 一括操作機能について
こちらはAlertHubの各種設定（スコープ、ルール、アクション等）を CSV のエクスポート・インポートにより一括で追加・変更・削除をできる機能となっております。下記にマニュアルを用意してありますので、ご一読ください。
連絡履歴の一覧・詳細について
一覧の UI に関して、ご不便をおかけして申し訳ございません。
確かに詳細画面に移動しますと、画面内右上の戻るリンクを使用しても、ブラウザの戻るボタンを使用しても、一覧の1ページ目に戻ってしまうことになります。また、一覧のページ移動に関しても1ページずつ辿っていく必要があり、特定のページへジャンプするような操作をすることも現状できません。
こちらについては改善項目として改めて社内検討するようにいたします。また代替手段としては陳腐ですが、現状の画面において、一覧の表示ページを維持しつつ詳細を見る場合は Ctrl+クリック 等で別タブにて開くのが良いかと存じます。
また、一覧画面に戻らなくても、明細画面だけで前後のデータに移動する方法はないでしょうか？
こちらに関しても現状ではできない操作となりますので、検討事項とさせていただきます。
連絡履歴詳細画面右上の ID 表示について
こちらは連絡履歴の ID を示しておりますので、API のフィールド名で言う「resultId」が該当します。
API ドキュメント上では現状データ形式の提示に留まっている都合上、他のIDと同じ値が例示されておりますが、実際の API の出力としては全て異なる値が出力されることとなります。混乱を招いてしまい、大変申し訳ございません。
以上、よろしくお願いいたします。
-
ご返答ありがとうございました。
関連する質問をさせてください。
【/api/apps/pigeon/results におきまして】
①items>Resultlist>status は連絡履歴画面でいう「ステータス」列の表示
②items>Resultlist>reason は連絡履歴画面でいう「理由」列の表示
だと思うのですが、
③items>Resultlist>isActive （架電状況）は連絡履歴画面でいうどの部分を指定することになりますか？
true（架電中）/false（何らかの終了状態）として使い分けるのかと思いますが、「ステータス」列と混同してしまうので、具体的な使用例を教えていただけますでしょうか？
また、
④items>Resultlist>createdBy と updatedBy は、なんのコードから「架電開始日時」と「最終更新日時」を作成したと言っているのでしょうか？【/api/apps/pigeon/results/{resultId} におきまして】
①callId→連絡履歴明細において、コールフロー内の各架電に充てられたID（歯車から表示追加）
taskId→連絡履歴一覧において、コールフロー全体に充てられた単一架電ID（歯車から表示追加）
だと思いますが、contactId はどこから探せばよいですか？またどのように使うのかご教示ください。
以上、たくさんで申し訳ありませんが、よろしくお願いいたします。 -
③items>Resultlist>isActive （架電状況）は連絡履歴画面でいうどの部分を指定することになりますか？
true（架電中）/false（何らかの終了状態）として使い分けるのかと思いますが、「ステータス」列と混同してしまうので、具体的な使用例を教えていただけますでしょうか？「isActive」は画面上には出していない値で、今まさに連絡が処理中である場合は true 、連絡が実行待ちをしていたり終了済みであるなど、連絡が処理中ではない場合は false が出力されます。
status の値で示しますと、「processing（架電中）」「aborting（中止待ち）」の場合は isActive が true 、それ以外のステータスにおいては false となります。
基本的には status の方がより細かい状況を示しますので、人が見る上ではそちらを確認することになりますが、この isActive が true であるか false であるか、というのは「同時架電数」の判定に使われており、例えば同時架電数が 1 というのは、厳密に言えば「 isActive が true である連絡を同時に取り扱える数が 1 」となります。（これを超過する場合、連絡の待ちが発生します）
またこのフィールドは API ドキュメントにも記載の通り sort パラメータとして使用可能ですので、（ API によるリクエスト時に限られますが）今まさに処理中の連絡を最優先で取得する、といったことが可能となります。
④items>Resultlist>createdBy と updatedBy は、なんのコードから「架電開始日時」と「最終更新日時」を作成したと言っているのでしょうか？
「createdBy」「updatedBy」は該当データを作成したユーザー（が持つ一意な ID ）と、最後に更新したユーザーを示すフィールドとなります。
連絡履歴においてはどちらも連絡のリクエストを行ったユーザーが割り当てられ、両者に異なる値が割り当てられることはほぼございません。（リクエストを行ったユーザーと異なるユーザーが中止操作を行った場合など、例外はございます）
なおここで言うユーザーは、正確に言えば「 Pigeon へのリクエストに使用する API トークンを作成したユーザー」となります。
いずれにせよ操作の証跡にあたる情報であり、こと Pigeon の連絡において複数のユーザーにより発行された API トークンを使い分けるようなことは現状行わないかと思いますので、さほど意識をする必要のない情報と言えます。
contactId はどこから探せばよいですか？またどのように使うのかご教示ください。
こちらも連絡履歴の画面出力においては使用しておりませんが、これは「連絡先」が持つ ID となります。そのため、この ID を元に「連絡先の取得」API 、
GET /api/apps/pigeon/contacts/{contactId}から情報取得をすることで、各架電において使用された連絡先の情報を特定することが可能です。
-
丁寧なご回答をありがとうございました。
現在移行期なため、オペレータにて自動架電の記録をした上で、Pigeonの連絡履歴も確認しております。
その人的作業をAPIデータを利用して、記録とアンマッチチェック作業を自動化しようと考えております。
【/api/apps/pigeon/results】が複数架電の一覧なので一番適している API なのですが、
オペレータが記録しているデータは事象のデータばかりなのでマッチング条件としては弱く思っております。通常はunique なコードなりでマッチングするものかと思います。オペレータ記録例（一部）：
アラート発生日時（メールより）
アラート発生サーバ（メールより）
受電者（Pigeon 連絡履歴より）
架電開始時刻（Pigeon 連絡履歴より）最終更新時刻（Pigeon 連絡履歴より）
そのため、Pigeon と alertHub 共通のコードやID は無いか探しております。
以前ご説明していますが、
弊社では最初の移管業務の架電宛先が多数に上ったことから、
定義体の構築工数削減のため、WEBHOOKを利用した単一構成で現状の架電を行っております。
そのため、scope,rule,trigger,action の4構成は全て同一の定義体で処理されています。それらのIDやコードを利用して、Pigeonの情報を出すことは出来ないでしょうか？
できれば【/api/apps/pigeon/results】のような一覧情報が良いのですが。
更に、AlertHubのAPI情報と PigeonのAPI情報を併せてマスター化するなど考えても、やはり両者の共通のID やコードが必要になります。
何か良いお知恵があればご教示ください。
よろしくお願いいたします。 -
ご回答遅くなりまして申し訳ございません。
色々と検討してみましたが、残念ながら現時点でご要望に対して完全に満足いただける方針を提示するのが難しいところです。最も近いのは AlertHub に対して送信するリクエストに対して何らかの一意な ID を含めておく、という方法ですが、要望内容と比較検討しますと、下記のような問題があります。
- AlertHub へリクエストを送信するシステム側に、一意な ID の生成に関する考慮が必要となる
- Pigeonの連絡履歴画面上からは、AlertHub のメッセージ受信内容全文を確認するのが困難（ API からの情報取得結果に含まれる parameters からであれば可能）
- 「一意な ID 」から Pigeon の連絡履歴を逆引きすることができない
ご要望を読ませていただく限り3つめの点が最も重要かと思いますが、これがやはり現時点では困難となります。
現在 AlertHub のアクションを複数組み合わせ、より柔軟な処理フローを実行する新しい機能を開発中となり、そちらが実現しますと、 Pigeon の連絡リクエストを行った上で、そちらの連絡結果 ID の情報を含める形で通知メールの送信を行う、といったことが可能となります。
ただしこちらに関しては今年の夏頃までのリリースを予定しているものの、具体的な日付は未定のうえ、時期としてもまだ先の話となり、残念ながら御社の「移行期」に利用していただくには間に合わないと考えております。力及ばず、大変申し訳ございません。
何卒よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
5件のコメント