ソース システム (性別) の値を、宛先システムの別の値にマップする必要がある状況があります。
これは非常に便利な機能であり、データベースの使用率と組み合わせて、すべてのリスト値に対してこれを実装することにしました。単一の宛先値に対して複数のソース値を持つ値リストにこれを利用しようとすると、問題が発生します。
システム エラーの一意のキー制約により、送信先メッセージで正当な保護者/継母と継父を「その他」にマッピングできません。私が見つけたすべての例は、単純な値リストを参照しており、上記の複雑な値の例を参照していないようです。これが相互参照で実装できるかどうか、またはカスタマイズされたコードを作成する必要があるかどうかは誰にもわかりません。
ID クロス リファレンス (1 対 1 のマッピング) の代わりに、値のクロス リファレンス (多対 1 のマッピング) を使用します。また、Value Cross Referencing がキャッシュを使用するため、パフォーマンス上の利点も得られます。
以下に引用されている値と ID の相互参照の違いを参照してください(細かいスペル修正あり)。
「id」と「value」の相互参照の違いを知るために時間を費やし、共有する価値があると思われる以下のポイントを得ることができました。
大まかに言えば、これら 2 つの概念は似ています。しかし、ほとんど違いはありません。
値相互参照
これらは実行時に変更できません。
これは、アプリの種類間で発生します。
この相互参照は、通常、列挙フィールド間で行われます。
これはキャッシュメカニズムを使用します。データベースに変更を加えた後、対応するホスト インスタンスを再起動して変更を確認する必要があります。
これは、多対 1 のマッピングです。
マッピングは一方向のみで保証されます。
複数の入力にマップされている値の逆マッピングにそれらを使用する場合、外部参照テーブルに格納されている最初の値がフェッチされます。
以下のマッピングが許可されます。したがって、この場合、リバース マッピングでは期待どおりの出力が得られない可能性があります。
りんご – フルーツ
バナナ – フルーツ
グレープフルーツ
マップで GetCommonValue & GetApplicationValue Functoid を使用する必要があります。
ID相互参照
これらは実行時に設定できます。これには Set Common ID functoid を使用します。
これは、appinstance タイプ間で発生します。
この相互参照は、通常、エンティティの一意の識別子間で行われます。
これで、呼び出しごとにデータベースにヒットします。
これは 1 対 1 のマッピングです。
マッピングは両方向で保証されます。
リバース マッピングは常に初期マッピングと同期しています。
上記のマッピングは許可されておらず、ID 相互参照テーブルの制約によって制限されています。
りんご – フルーツ
バナナ – フルーツ
グレープフルーツ
マップで GetCommonId & GetApplicationId Functoid を使用する必要があります。