Kompira Cloud APIサイトでJSON投入・実行した際にエラーが発生する（ルールの作成）
完了
お世話になっております。
標記の件について確認よろしくお願いします。
Kompira APIドキュメントサイトにて新規登録予定のJSONを投入・実行した際にエラーになるケースがあります。
何故エラーになっているか教示よろしくお願いします。
実行対象API：ルールの登録
※すみません。
ルール登録時の話なので本来はAlertHubかもしれませんが、此方に投稿します。。
投入JSONイメージ ※白抜き部分は任意値（値あり）：
実行結果：
エラー部分拡大：
→displayNameですがJSON内の設定は30文字を超えていません。
→flow.steps[0]のF1は設定されている認識です。
→flow.steps[0]のN1は設定していないが必要？
以上、よろしくお願い致します。
-
お世話になっております。
補足情報です。
そもそものお話なのですが、今回curlで以下のコマンドを実行して新しい架電環境作成する想定でいます。
しかし、この想定が間違っている可能性があると判断しました。
この点も齟齬がないか（さらに必要な情報がないか等）確認よろしくお願いします。
実行順 登録環境 登録情報 実行API APIエラー
=========================================================================
１ AlertHub 受信スロット /api/apps/alerthub/receive-slots（POST） なし
２ AlertHub スコープ /api/apps/alerthub/scopes（POST） なし
３ AlertHub ルール /api/apps/alerthub/rules（POST） あり
４ Pigeon ガイダンス /api/apps/pigeon/guidances（POST） なし
５ AlertHub アクション /api/apps/alerthub/actions（POST） なし
６ AlertHub トリガー /api/apps/alerthub/scopes/{scopeId}/triggers（POST） あり
以上、よろしくお願い致します。 -
お世話になっております。
確認しましたが、最初の画面の白抜きされていない部分については問題は見当たりませんでした。
足りていない情報もなさそうです。
白抜き部分の記述次第ではエラーになる可能性がありますので、以下の点について問題ないか確認してください。・2行目:
receiveSlotIdに指定している受信スロットは存在しますか？
・6行目:eventParamsのキーは深刻度を設定する対象のスコープのIDです。対象のスコープは存在しますか？
・17行目:operatorIdは処理フローによって決まった値を設定する必要があります。parametersの内容から推測するに、「フィールドが正規表現にマッチするかどうか確認する」だと思います。
このoperatorIdは1c9ac850-6bc1-4c02-b69a-b072f6ba13afですが合っておりますでしょうか？
・21行目:P1にはおそらく正規表現を指定しているものと思われます。正規表現のために\という文字を記述したい場合、JSON 文字列としてはエスケープが必要なことに注意してください。例えば正規表現としてfoo:\s*barと記述したい場合、foo:\\s*barと\を二重に書く必要があります。特に6行目
eventParamsに存在しないスコープIDを設定した場合と、21行目のP1で\を二重にするのを忘れた場合 (JSON として正しく解釈できなくなる) は、エラーメッセージにどのパラメーターがおかしかったか表示されませんので、ご注意ください。よろしくお願いします。
-
お世話になっております。
回答ありがとうございます。
確認しましたが、最初の画面の白抜きされていない部分については問題は見当たりませんでした。
足りていない情報もなさそうです。
→確認ありがとうございます。
白抜き部分の記述次第ではエラーになる可能性がありますので、以下の点について問題ないか確認してください。
・2行目:receiveSlotIdに指定している受信スロットは存在しますか？
→API実行時には存在する受信スロットのIDを設定しています。
また、ルールに対するcurlコマンドを実行する際には、事前に受信スロットを新規作成したうえで
作成した受信スロットIDを指定する予定です。
・6行目:eventParamsのキーは深刻度を設定する対象のスコープのIDです。対象のスコープは存在しますか？
→API実行時には存在する既存スコープIDを設定しています。
こちらについても、ルールに対するcurlコマンドを実行する際には、事前にスコープを新規作成したうえで
作成したスコープIDを指定する予定です。
・17行目:operatorIdは処理フローによって決まった値を設定する必要があります。parametersの内容から推測するに、「フィールドが正規表現にマッチするかどうか確認する」だと思います。
→ご認識の通りです。
このoperatorIdは1c9ac850-6bc1-4c02-b69a-b072f6ba13afですが合っておりますでしょうか？
→operatorIdは上記の通りでした。
・21行目:P1にはおそらく正規表現を指定しているものと思われます。正規表現のために\という文字を記述したい場合、JSON 文字列としてはエスケープが必要なことに注意してください。例えば正規表現としてfoo:\s*barと記述したい場合、foo:\\s*barと\を二重に書く必要があります。
→ご認識の通り正規表現ですが、稼働中の設定をそのまま使用しているので設定自体は問題ない想定です。
参考までに正規表現内容は以下のようになっています。
"P1": "^{内部変数名}:\\s*(\\S+)$" ※{内部変数名}にアルファベット変数名を設定しています。
念のためにですが・・・
Kompira APIドキュメントサイトにて新規登録予定のJSONを投入・実行した際にエラーになるケースが
あります。
何故エラーになっているか教示よろしくお願いします。
→本件は記載の通り、curlコマンドを実行したのではなく、以下のURLでJSON内容の確認した結果の
確認となります。
実際にcurlコマンド実行時に同様のエラーになることを懸念視しています。
https://fixpoint.cloud.kompira.jp/docs/apidoc/#/alerthub/post_api_apps_alerthub_rules
レスポンスコードとして201が帰ってきているので、登録は出来る想定ですが400も帰ってきて
いるのでこの点が謎です。。
以上、よろしくお願い致します。 -
お世話になっております。
再現結果を添付します。
【JSON】
{
"receiveSlotId": "8020f01b-ea83-4f84-b884-c511d1f8b1a7",
"displayName": "WEBHOOK_KENCHI_Shared_r",
"remarks": "検知切り分け地区LAN対応に伴う自動架電ルール",
"eventParams": {
"01531d15-8426-43e4-8611-6aa487e197aa": {
"severityName": "K-severity",
"method": "set",
"value": 0
}
},
"conditionalEventParams": [],
"flow": {
"steps": [
{
"comment": "",
"operatorId": "1c9ac850-6bc1-4c02-b69a-b072f6ba13af",
"parameters": {
"F1": "message.content.text",
"O1": "does",
"P1": "^callflow:\\s*(\\S+)$"
}
}
]
},
"disabled": false
}
【API実行結果（スクリーンショット）】
さらに必要な情報がありましたら、連絡よろしくお願いします。
以上、よろしくお願い致します。 -
お世話になっております。
いただいた JSON の
receiveSlotIdとeventParamsを弊社開発担当の手元の環境に合わせて調整したものを curl コマンドライン実行で試したところ問題なく成功しましたのでJSONそのものには問題ないかと思われます。頂いたAPI実行結果（スクリーンショット）の状況からですと、恐らくネットワークエラーが発生し、たとえ正しい内容を送信したとしてもうまく内容を送受信できていない上程であると思われます。もし、他のネットワークは問題がないのにもかかわらず、ここだけうまくいかないという場合は、ブラウザを再起動して再度試していただくとうまく動作する可能性があります。
また、ブラウザを再起動した後は認証情報が外れていると思われますので、実行前にAuthorize のし直しをお願いいたします。以上、よろしくお願いします。
-
お世話になっております。
お忙しい中、検証等ありがとうございます。助かります。
JSONが問題ない件、承知しました。安心しました。
ネットワークエラーの件は、生憎現在別環境のネットワークがないため確認が出来ません。
現存ネットワーク環境でもキャッシュクリア等を行なって再度実行していてみます。
追って結果は連絡します。
一方で気になった事があります。
ステータス201と400が順に帰ってきており、201が帰ってきた時点で目的である
ルールの追加は完了しているはずなのに、その後400が帰ってきている認識です。
①この400のステータスが帰ってきている処理は何をしているのでしょうか？
差し支えなければ教示よろしくお願いします。
②①で行なっている処理次第ですが、ステータス201が帰ってきている時点で
400は別途帰ってきているが、無視しても問題ないという解釈もできると思います。
この解釈は楽観視しすぎでしょうか？
以上、よろしくお願い致します。 -
お世話になっております。
回答ありがとうございます。
直接原因は「Undocumented TypeError: Failed to fetch」ということは承知しました。
エラー内容もネットワーク関係ということで再認識しました。
使用しているブラウザはGoogle Chromeですが、同ブラウザの開発者ツールでAPI実行時のネットワークエラーがないかを確認したところ、以下の結果でした。
以下のURLにアクセスした際に404のエラーが出ているようでした。URLにアクセスしてもページはなさそうです。
何か関係はないでしょうか？
https://www.googletagmanager.com/gtm.js?id=GTM-5W9B6FH
以上、よろしくお願い致します。 -
お世話になっております。
矢次早にすみませんが、Edgeでも同API、同JSONで実行したところ、開発ツール・コンソールで以下のメッセージが表示されました。
（メッセージ内容）
Access to fetch at 'https://ajs-kompira.cloud.kompira.jp/api/apps/alerthub/rules' from origin 'https://fixpoint.cloud.kompira.jp' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
CORS（Cross-Origin Resource Sharing）ポリシーに違反しているため、ブラウザがリクエストをブロックしたものと思われるのですが、如何でしょうか？
＃外していたらすみません。
もし原因がそうでしたら、対応が必要であればその内容を教えてください。
以上、よろしくお願い致します。 -
お世話になっております。
CORSポリシーの件ですが、エラーメッセージから推測するに参照している API ドキュメントの URL が https://fixpoint.cloud.kompira.jp/docs/apidoc/ になっているようです。
API ドキュメントこのドメインの URL の先頭部分をお客様のスペースIDと合わせてもアクセスできますので、その URL を利用すると CORS に抵触しないと思いますので、一度ご確認いただけますでしょうか。
(おそらく https://ajs-kompira.cloud.kompira.jp/docs/apidoc/ になるかと思います。)
また、上記 URL を直接入力せずとも、お客様の Kompira Cloud スペースのヘルプメニューから API ドキュメントに遷移していただくとドメインが一致した URL に飛ぶことができますので、それを活用する方法もございます。以上、よろしくお願いします。
-
お世話になっております。
Response以下に記載されている201や400は解説のためのドキュメントであり、
レスポンス結果ではございません。
実行結果はServerResponseにございますが、201となっており特に問題はございません。
→問題ないと解釈しました。承知しました。
スコープ登録時にエラーとならずに、ルール登録時にエラーとなったのは、登録対象データによって
登録時のふるまいが異なるためと想定しています。
（ルールの場合、受信スロットやスコープの存在確認等も行なっているから）
１点確認があります。
APIページで設定するアクセストークンですが、URLにアクセスする都度設定が必要なのでしょうか？
毎回設定している気がしているので、情報を保持する方法がありましたら教示よろしくお願いします。
以上、よろしくお願い致します。 -
お世話になっております。
まず、API ドキュメントの Try it out は、実際に API 呼び出しを行う機能となっております。
API キーを要求する理由も、本物の API 呼び出しをするためです。
そのため、正しく実行されると、結果が実際にスペースに反映されます。APIページで設定するアクセストークンですが、URLにアクセスする都度設定が必要なのでしょうか？
毎回設定している気がしているので、情報を保持する方法がありましたら教示よろしくお願いします。一度設定した後は、設定を解除する操作 (トークン設定ダイアログで Logout を選択) をするか、API ドキュメントページを閉じたりリロードしたりするまでは有効です。
それまでは API トークン設定を保持したまま連続で API を呼び出すことが可能です。本APIサイトですが、稼働環境に各定義体が実際には出来ない想定でしたが出来てしまうのでしょうか？
API ドキュメントからの Try it out の結果は、スペースに反映されます。
稼働環境に影響せずにJSONの正当性を確認する方法はあるでしょうか？
残念ながらございません。
よろしくお願いします。
-
お世話になります。
回答ありがとうございます。
APIが呼び出されるので実際に反される旨承知しました。
「Try it out」という言葉のニュアンスから、実際にAPIは実行されても実環境には
反映されないと想定していました。
正当性を確認する方法もない旨も、残念ですが承知しました。
ー追記ー
仮に現在使用している環境が本番環境で、別途検証環境を用意したいというお話になる場合は
別途契約が必要になる想定です（URLを変えるだけで検証環境等の別環境になるわけではない）。
齟齬はないでしょうか？APIページで設定するアクセストークンですが、URLにアクセスする都度設定が必要なのでしょうか？
毎回設定している気がしているので、情報を保持する方法がありましたら教示よろしくお願いします。一度設定した後は、設定を解除する操作 (トークン設定ダイアログで Logout を選択) をするか、API ドキュメントページを閉じたりリロードしたりするまでは有効です。
それまでは API トークン設定を保持したまま連続で API を呼び出すことが可能です。
→承知しました。リロードでも消えてしまうんですね。。
以上、よろしくお願い致します。
実行結果：
→エラー内容としては初回投稿時のもの同じ認識です。
→Server Responseは201となっている。サインインしてコメントを残してください。
コメント
44件のコメント