X12 ビジネス・プロセスの設定
概要
X12 ビジネス・プロセスには以下の設定があります。
グループ | 設定 | 参照先 |
---|---|---|
基本設定 | [検証] | このトピック内の節 |
[ビジネス・ルール名] | "プロダクション内での仮想ドキュメントの使用法" の "ルーティング・プロセスに関する設定" | |
追加設定 | [不正メッセージに警告]、[不正メッセージ・ハンドラ]、[Forward Generated Response To Target]、[レスポンス・ターゲット構成名]、[レスポンス From]、[レスポンス・タイムアウト]、[強制同期送信]、[変換エラー時のアクション]、[妥当性検証エラーで動作] | "プロダクション内での仮想ドキュメントの使用法" の "ルーティング・プロセスに関する設定" |
開発とデバッグ | ルールのロギング | "プロダクション内での仮想ドキュメントの使用法" の "ルーティング・プロセスに関する設定" |
残りの設定はすべてのビジネス・プロセスに共通のものです。"すべてのビジネス・プロセスに含まれる設定" を参照してください。
[検証]
X12 ドキュメント・ルータの [検証] 設定は、ルータによる受信メッセージの検証方法を制御します。受信メッセージが指定された検証に失敗した場合、InterSystems IRIS® によってイベント・ログにその失敗がレポートされ、X12 ルーティング・プロセスはそのメッセージを不正メッセージ・ハンドラのみに渡します ([不正なメッセージ・ハンドラ] 設定を参照してください)。メッセージが指定された検証に失敗したが、不正メッセージ・ハンドラがない場合、エラーがログに記録されますが、そのメッセージはどのターゲットにも送信されません。メッセージが検証に合格した場合、X12 ルーティング・プロセスはルーティング・ルールで指定されたターゲットにそのメッセージを送信します。
ルーティング・ルールとデータ変換を使用して、メッセージごとにターゲット・システムで受理可能かどうかを確認することができ、その結果として検証の使用を避けることができる、というのが理想的です。 これにより、すべてのメッセージが適切なターゲットで処理されます。検証を有効にした場合、ルーティング・ルールの前に検証テストが適用されます。検証に失敗したメッセージは、ルーティング・ルールに従ってターゲットに送信されず、不正なメッセージ・ハンドラのみに送信されます。ただし、X12 メッセージ検証がメッセージのフィルタリング方法として適している環境も存在します。例えば、以下の状況では、X12 検証を使用することが正しい選択です。
-
インタフェースを開発またはデバッグしており、システムで処理が必要なメッセージに類似する形式を判定する必要がある場合。
-
ターゲット・アプリケーションで、仕様と相違があるメッセージを処理できず、ルーティング・ルールおよび変換でその相違を解決できない場合。
-
規制やその他のビジネスの要件があり、メッセージがその仕様に従っている場合。
X12 検証はルーティング・プロセスにオーバーヘッドを付加します。このオーバーヘッドが大きな影響を与えるために、プロダクションで処理可能なメッセージの最大量が減少する可能性があります。
Validation プロパティでは、以下を制御するフラグを指定できます。
-
メッセージが有効なドキュメント・タイプを持つかどうか
-
メッセージ構造が検証されるかどうか
-
セグメント内のフィールドおよび複合構造内のコンポーネントがスキーマに適合しているかどうか
Validation プロパティ値に空の文字列を指定した場合、メッセージ・ルータは検証を省略し、すべてのメッセージをルーティングします。管理ポータルで新しい X12 ルーティング・プロセスを作成すると、[検証] 設定が空の文字列に初期化されます。
指定された [検証] フラグによっては、検証に合格したメッセージでも、厳密にはスキーマ定義に適合しない場合があります。
以下のテーブルは、X12 検証フラグを示しており、それぞれが指定されたときに、ルーティング・プロセスがメッセージをどのように検証するかを説明しています。
フラグ | ルーティング・プロセス |
---|---|
d | ドキュメントの DocType プロパティを調べ、値が指定されているかどうかを確認します。 |
m | ドキュメントのセグメント構造が適切に構築されており、ドキュメントの DocType プロパティで識別されたスキーマを使用して解析できることを確認します。スキーマ定義内のすべての必須セグメントがメッセージ内に含まれており、そのメッセージにスキーマで許可されていない間違ったセグメントが含まれていないことを確認します。 |
dm | d と m の両方が適用されます。これは、ビジネス・プロセス (ルータ) のデフォルトです。 |
s | セグメント構造 (セグメント内のフィールドの数と繰り返し) を強制します。 |
c | 複合構造 (コンポーネントの数) を強制します。 |
x | セグメントやフィールドに関係条件を適用します。関係条件は、他のフィールドやコンポーネントの存在に基づいて、どのフィールドやコンポーネントが必要か、または除外されるのかを示します。少なくとも、セグメントレベルの検証用には s を追加で指定する必要があります。また、コンポーネントレベルの検証用には c を指定することもできます。 |
r | 必要な要素の存在を強制します。s も指定されている場合は、必要なフィールドがセグメント内に存在しているかどうかをテストします。c も指定されている場合は、必要なコンポーネントが複合構造に指定されているかどうかをテストします。s も c も指定されていない場合、r には何の効果もありません。 |
u | [使用されていません] とマークされる要素が存在するかどうかをテストします。s も指定されている場合はフィールドの存在をテストし、c も指定されている場合はコンポーネントの存在をテストします。これらの要素がどちらも存在しない場合、検証は失敗します。唯一使用可能なスキーマが新しいスタイルのスキーマである場合、これは従来のスキーマにのみ格納される情報が必要なため、テストは実行できません。 |
l | 要素の長さをテストします。s も指定されている場合はフィールドの長さをテストし、c も指定されている場合はコンポーネントの長さをテストします。 |
t | 要素のデータ型が正しいかどうかをテストします。s も指定されている場合はフィールドのデータ型をテストし、c も指定されている場合はコンポーネントのデータ型をテストします。 |
v | 要素の値がコード・テーブルで使用できるかどうかをテストします。 s も指定されている場合はフィールドのコード・テーブルに対してテストし、c も指定されている場合はコンポーネントのコード・テーブルに対してテストします。唯一使用可能なスキーマが新しいスタイルのスキーマである場合、これは従来のスキーマにのみ格納される情報が必要なため、テストは実行できません。 |
n | dmscrlt と同じです。新しいスタイルのスキーマのみを使用して実行できるすべての検証です。 |
a | dmscrultv と同じで、すべての検証です。 |
e | エラーが発生しても、ドキュメント全体を通して検証を継続します。e が指定されていない場合、最初のエラーが発生した後、検証は停止します。 |
(空の文字列) | 検証を省略し、すべてのメッセージをルーティングします。これは、ビジネス・サービスとビジネス・オペレーションのデフォルトです。 |