Kompira Cloud APIサイトでJSON投入・実行した際にエラーが発生する（ルールの作成）
完了
お世話になっております。
標記の件について確認よろしくお願いします。
Kompira APIドキュメントサイトにて新規登録予定のJSONを投入・実行した際にエラーになるケースがあります。
何故エラーになっているか教示よろしくお願いします。
実行対象API：ルールの登録
※すみません。
ルール登録時の話なので本来はAlertHubかもしれませんが、此方に投稿します。。
投入JSONイメージ ※白抜き部分は任意値（値あり）：
実行結果：
エラー部分拡大：
→displayNameですがJSON内の設定は30文字を超えていません。
→flow.steps[0]のF1は設定されている認識です。
→flow.steps[0]のN1は設定していないが必要？
以上、よろしくお願い致します。
-
お世話になっております。
すみません。いったんクローズさせていただいたのですが、追加確認よろしくお願いします。
【前提】
・AlertHub及びPigeonに各設定が行われており、自動架電が実現・運用されている
・追加で以下の順序でCloud環境に設定を追加する
①AlertHub 受信スロット新規作成
②AlertHub スコープ新規作成
③AlertHub ルール新規作成 （①で作成した受信スロットと関連付ける）
④Pigeon ガイダンス新規作成
⑤AlertHub アクション新規作成
⑥AlertHub トリガー新規作成 （⑤で作成したアクションと関連付ける）
【確認事項】
・追加設定を行なう予定ですが
a)追加設定時にエラーが発生した際、例えば受信スロットやアクションへの関連付けを
間違った際などに、追加設定前の時点にリカバリする方法はあるでしょうか？
b)追加設定はJSONのアップロードにて実施する予定ですが、別のスレッドでこの
アップロードにて今回で言う運用環境を壊すことはないという回答はいただいています。
この壊れていないことを確認する術がありましたら教示よろしくお願いします。
以上、よろしくお願い致します。 -
お問い合わせありがとうございます。
ご質問の件以下回答させていただきます。
a)追加設定時にエラーが発生した際、例えば受信スロットやアクションへの関連付けを
間違った際などに、追加設定前の時点にリカバリする方法はあるでしょうか？お客様自身でエクスポート機能を用いて設定内容のバックアップを取得し、
問題発生時にそのバックアップファイルをインポートしてリストアする方法がございます。b)追加設定はJSONのアップロードにて実施する予定ですが、別のスレッドでこの
アップロードにて今回で言う運用環境を壊すことはないという回答はいただいています。
この壊れていないことを確認する術がありましたら教示よろしくお願いします。設定についての値を目視で確認するとか、実際にテストしてレスポンスコードが2xxであることを
確認する方法はございます。また、過去に回答させていただきました「環境を壊すことはない」についてですが、
AlertHubにおいてはdry-run的な機能はなく、不正な値を設定している場合には
設定拒否され変更は行われませんが、正しい値の場合は実環境は変更されるという意図で
回答させていただいておりますので、念のためご認識のほどよろしくお願いします。以上、よろしくお願いします。
-
お世話になります。
回答ありがとうございます。助かります。a)追加設定時にエラーが発生した際、例えば受信スロットやアクションへの関連付けを
間違った際などに、追加設定前の時点にリカバリする方法はあるでしょうか？お客様自身でエクスポート機能を用いて設定内容のバックアップを取得し、
問題発生時にそのバックアップファイルをインポートしてリストアする方法がございます。
⇒何点か確認させてください。
①エクスポート機能及びインポートしてリストアの操作手順は存在するでしょうか？
存在するようでしたら提供等をよろしくお願いします。
②エクスポート機能はCSV形式でのデータ取得だったと記憶しますが
エクスポートという観点では、APIを使用したJSON形式のデータ取得も可能という認識です。
齟齬はないでしょうか？
③リストアはJSON形式のデータでも可能でしょうか？
可能な場合、各定義毎（ルール、アクション等）になる想定ですが、対象定義を総入れ替え
してくれるのでしょうか？
※設定内容を一括でリストアが出来ればベストですが、そのような機能はない想定です。
以上、よろしくお願い致します。 -
お世話になっております。
①についてはAlertHub ⼀括操作マニュアルの2.3.一括操作の流れにありますのでそちらをご参照いただけますでしょうか。
②については、JSON 形式で取得したデータ (REST API の GET メソッドで取得したもの) は、そのまま作成や更新 (POST や PUT) に流用は可能ですが、他のリソースを参照するようなものについては、参照が再作成されたときに追随できないませんので、注意が必要です。
ですので、ある程度のバックアップとしては使用できるかと思います。③の質問の意図については、参照している他のリソースのIDが変わった時に自動的に追従できるかという意図と思われますが、②で回答した通り追従はできませんので難しいです。
以上、よろしくお願いします。
-
お世話になっております。
回答ありがとうございます。②について確認よろしくお願いします。
他のリソースを参照するようなものについては、参照が再作成されたときに追随できないませんので、注意が必要です。
→ここで言う「他のリソースを参照するようなもの」は、例えばルール作成時に他要素であるスコープIDを指定しているものという意味で問題ないでしょうか？
また、「参照が再作成されたときに追随できない」というのは、ルール内で指定したスコープIDを持つスコープが削除→再追加がなされ、別のスコープIDが付与された場合は繋がりがなくなるという意味で追随出来ないと捉えました。
齟齬はないでしょうか？
※齟齬がない場合、スコープが再作成されても、ルールに定義されているスコープIDを新しいものに
更新すれば問題ない認識です。以上、よろしくお願い致します。
-
お世話になっております。
回答ありがとうございます。
つまりは以下のように解釈しましたのが齟齬はないでしょうか？
・CSVでもJSONでも、事前にバックアップ及びバックアップからのリストアは可能である。
上記が正しい場合、APIでもバックアップしたJSONをもとに、各要素（例えば受信スロット）を
一括ではなくて、個別にリストア（アップロード）が可能という解釈で問題ないでしょうか？
※更新系のAPIのURLがID指定なので個別と解釈しました。
もし一括アップロードが可能（例えば一覧取得で取得したJSONをリストア（アップロード）すれば
一括更新が可能なもの）等がありましたら教示よろしくお願いします。
以上、よろしくお願い致します。 -
お世話になっております。
・CSVでもJSONでも、事前にバックアップ及びバックアップからのリストアは可能である。
JSONの場合は可能ですが、前に回答させていただきました通り、他のリソースを参照するようなものについては、参照先が再作成されたときに追随できないリスクがあるため、絶対に変えないという確約があることが条件となります。
CSV の場合は ID を直接記述せず、インポート・エクスポート用に割り振ったキーで要素の特定を行っています (※)。このキーは ID と異なり、指定した値で作成できますので、再作成時も参照先を見失うことはありません。
(※) ただし、Pigeonアクションのコールフローの ID とガイダンスの ID は例外で ID が直接用いられていますので、再作成した場合は CSV の手直しが必要になります。
以上、よろしくお願いします。
-
お世話になっております。
回答ありがとうございます。
JSONの場合は可能ですが、前に回答させていただきました通り、他のリソースを参照するようなものについては、参照先が再作成されたときに追随できないリスクがあるため、絶対に変えないという確約があることが条件となります。
⇒承知しました。JSONだと加えて１つ１つをアップロードが必要になる認識です。
CSV の場合は ID を直接記述せず、インポート・エクスポート用に割り振ったキーで要素の特定を行っています (※)。このキーは ID と異なり、指定した値で作成できますので、再作成時も参照先を見失うことはありません。
(※) ただし、Pigeonアクションのコールフローの ID とガイダンスの ID は例外で ID が直接用いられていますので、再作成した場合は CSV の手直しが必要になります。
⇒このキーはエクスポート時にユニークな値が自動付与されて、インポート時の各内容の識別用に使用していると捉えました。
このキーをエクスポート後に変えるのも厳禁という認識です。
やりとりはリカバリ手法ですが、再作成時（既存定義を参考に全く別の定義を作成）には
このキーがあるCSVについては、CSV内でユニークにする必要がある想定です。
（キーを空にするのもOKなのかは不明）
※CSV内にキーがないものについてはIDを空にする等の対応が必要。
以上、よろしくお願い致します。
サインインしてコメントを残してください。
コメント
44件のコメント