深い統合データ構造の作成
マイクロアプリを作成する際、親テーブルから2レベル以上離れたターゲットレコードシステム内のテーブルにアクセスする必要がある場合があります。HTTP統合に現在存在する制限であるため、これに関する解決策が提供されています。
この記事では、このようなユースケースが発生したときに、ターゲットのレコードシステムのテーブルにアクセスする方法について説明します。この解決策は単純ではありませんが、以下の説明に従うと、より深いデータ構造を作成できます。
使用例
ユーザーがServiceNowでリクエストを承認できるようにするマイクロアプリを構築するとします。このマイクロアプリを使用するには、ユーザーは以下が可能である必要があります：
- 通知を受け取って開く
- 承認するアイテムのリストを含むページを受け取る
- 各アイテムの詳細を見る
- リクエストを送信したユーザーを表示する
- これらのリクエストを承認する
これらの各ステップのアクションまたはページを作成するために必要な詳細は、エンドポイントを介して取得されるテーブルに保存されています。ただし、承認者のデータを含むテーブル（アイテムリストを含むデータが挿入されたテーブル）は、別のデータの場所から2テーブル以上離れています。
解決策の前提条件
この回避策を作成するには、「統合の構成」で説明されている子API呼び出しチェーンとテーブルのマージを組み合わせて使用する必要があります。
前提条件：
- マイクロアプリで実行が必要な処理とエンドユーザーが表示および操作する情報を把握して、エンドツーエンドのユースケースを定義した。
- ターゲットのレコードシステムから必要なテーブルデータを返すエンドポイントを作成した。
注：
構成済みのテーブルとプライマリキーは、初期設定後は編集できません。
- HTTP統合のAPI呼び出しの追加およびテーブルのマージ機能について十分理解した。
データ構造の表示と構築
マイクロアプリを構築する場合、マイクロアプリプラットフォームでサポートされている従来のモデルは、1ステップのみ離れたテーブル間で使用するモデル（N+1モデル）です。
これは、HTTP統合中に設定された統合構成をチェックすることで確認できます。たとえば、チケットはタグから1ステップ離れていますが、どちらも comments_w_users に直接接続されていないことがわかります。
一部の関係は、エンドポイントの構成中に自動的に作成され、統合のテーブルリファレンスに表示されます。ただし、この特定のユースケースでは、複数の手動定義を作成してテーブル間の関係を作成する必要があります。
データ構造マージ戦略
このようなシナリオでマイクロアプリを構築するようにデータ構造を設計する際は、次の重要な点を考慮してください：
- マイクロアプリを構築するために実現する必要があるデータ構造に応じて、親API呼び出しを選択します。更新されたデータ構造のみを返すデータセットとAPIの増分同期の使用方法を検討してください。このAPIは親として設定する必要があります。
- 可能な場合は、多対1ではなく1対多のみを構成してください。多対1の構成では、API呼び出しが繰り返され、データ同期の効率に影響します。
- 必要な通知のソースを検討すると同時に、テーブルのマージが構成されデータを複製できる場合に、ユーザーが通知を1つのみ受け取るように構成する方法を検討してください。
- 親APIは常に最も揮発性の高いオブジェクトである必要があります。
特定のケースでは、次のテーブルのマージ方法を使用します：
- 1対1 - ［詳細としてマージ］ を使用します。これにより、親APIと子APIのすべての属性を含む1つのレコードのみがデータベースに保存されます。子の値は、属性が親と子の両方のAPI呼び出しに存在する場合に使用されます。
- 1対多 - ［サブリストとしてマージ］ を使用します。すべての親属性がすべての子レコードとともに保存されます。
- 多対1 - 通常、多対1は子API呼び出しでは使用されません。テーブルのマージを使用するか、エンティティ関係の手動設定（マージは適用されない）を使用するかにかかわらず、最適な方法を検討する必要があります。マージが適用されない場合、最初の子のみが保存され、重複するプライマリキーの検出により他の子は無視されます。
関係の手動定義
関係を手動で定義するには、関係の構築に使用する両方のテーブルに共通の列が存在している必要があります。これは、データ統合の［テーブルと関係］セクションで確認できます。2つの個別のテーブルに共通の列がある場合には、それらのテーブル間の関係を手動で作成できます。共通の列がない場合は、次の手順に示す例に従って関係を作成する必要があります。
高度なユースケース
共通の列関係を使用してn+1を超えるデータ構造を作成できない場合、APIの子呼び出しとテーブルのマージを組み合わせて使用して、フラット化されたデータ構造を作成できます。一般的な「高度なユースケース」は、次の基本原則に従います：
- 統合を設定します。
- テーブル構造を編集します。
- プライマリテーブルから結合先テーブルへのAPI呼び出しチェーンを作成します。
- トップダウン方式（たとえば、親から子）でのテーブルのマージを介してテーブルをマージします。
- 大きなテーブルが作成されたら、親テーブルに戻り、すべてのテーブルエンティティに対して無視を設定します。
たとえば、request-list>item list>item details>approverを使用してマイクロアプリを構築する場合、マイクロアプリは承認者のリクエストと詳細を表示できる必要がありますが、n+1の関係のみという現在の制限があるため表示できません。テーブルのマージ機能を使用して、この問題を修正できます。
データエンドポイントを構築するときに、アイテムリスト内の親データエンドポイント（request-list）から子エンドポイント（approver）にテーブル構造を伝達します。
その後、テーブルマージ戦略を使用して、親データエンドポイントからこの子APIにすべてをマージするように設定できます。その結果、親テーブルにあったものがすべて子API（item-list）のデータ構造に表示されます。
この方法で構成すると、1つの大きなデータベーステーブルに3つのレベルのデータが含まれます。この新しいテーブルを使用して、マイクロアプリの構築を開始したときに定義したユースケースに従ってページを構築できます。この方法は、多数のレベルが必要な場合に使用できます。
API子呼び出しとテーブルのマージの例
次の例は、n+1の関係を超えるデータに到達するテーブル構造を作成する一般的なワークフローを示しています。個々の使用は、マイクロアプリ用に構築する個別のユースケースに基づいて構築する必要があります。ターゲット統合レコードシステムに精通し、この方法を使用する場合の構造の結果を十分に理解している必要があります。
API呼び出しチェーンを作成する
- 統合の ［データ読み込み］ ページに移動します：
- ルートエンドポイントから対象の子エンドポイントへの子API呼び出しを必要な数追加します：
完了すると、［データ読み込み］ページにデータ構造を表示できます。
親から子へのAPI呼び出しをマージする
対象テーブルに達するまで、ルート/親テーブルを子エンドポイントに順番にマージします：
- 統合の省略記号メニューから ［編集］ を選択します。
- ルート統合の子エンドポイントの省略記号メニューから ［編集］ を選択します。
-
［データエンドポイントの編集］ ページの下部に移動し、［編集］ を選択して構成テーブルのマージを選択します：
対象テーブルに達するまで、子テーブルごとに、この処理を順番に必要な回数繰り返します。それにより、マイクロアプリを構築できます。
繰り返されるAPI呼び出しを無視する
マージ「チェーン」が終了したら、ルートエンドポイントに戻ります。次の手順を実行します：
- ［編集］ を選択します。
- すべてのテーブルを ［無視］ ステータスに設定します：
これにより、テーブルがキャッシュに2回読み込まれることがなくなり、パフォーマンスが向上します。これで、チェーン/マージされたテーブルを使用してマイクロアプリを構築できます。
重要な注意事項
この方法を使用してデータを構築する場合は常に、次の点を考慮してください：
- すべての親および子API呼び出しには、独自のデータ構造があります。
- これらの構造は、異なるデータセットです。
- データ構造を（親から子に）マージした場合、子データ構造にすべての属性が表示されます。
- 完全なチェーンが維持される場合、データは「2回」保存されます。子データ構造にすべての属性が表示されるため、親呼び出しのデータ構造が完全に削除されていることを確認してください。
- 親API呼び出しのデータ構造はそのままにせず、可能な場合は削除してください。