機械翻訳について

インバウンドEDIのスキーマ要素

インバウンドEDIユースケースでは、B2Bアクションへの入力はEDIペイロード要素を持ち、解析後に生成される出力はEDIドキュメントのXML形式を持ちます。

TranslateInputデータ要素はB2Bアクションへの入力メッセージを表し、TranslateOutputはアクションの出力を表します。 したがって、少なくともTranslateInputには、入力マップ・アクションを使用して値を割り当てるedi-payload要素が含まれている必要があります。 その後、TranslateOutputデータ要素はedi-xml-document要素を生成し、解析されたデータを検証エラー(ある場合)とともにXML形式で返します。

「図edi-translate-inbound.pngの説明」

次の表では、インバウンドEDIシナリオのTranslateInputおよびTranslateOutputに含まれる各要素について説明します。

TranslateInputの要素

要素	説明
edi-payload	ネイティブEDI X12ペイロード(ISAセグメントで始まりIEAセグメントで終わる)から生成されたbase64-encoded文字列値をこの要素に割り当てる必要があります。 EDIにはデリミタまたはイメージなどのバイナリ・コンテンツとして使用される印刷不可能な文字が含まれている場合があるため、Base64エンコーディングが必要です。 EDI X12ペイロードにトランザクションのバッチが含まれる場合、B2B処理とともにステージ・ファイル処理を使用してバッチを処理する必要があります。
tracking-info	この要素は、バッチ処理のステージ・ファイル・アクションでB2Bアクションを使用する場合にのみ必要です。 この要素には、ステージ・ファイル・アクションからB2Bアクションに渡される各EDIトランザクションのトラッキング情報が含まれます。
edi-encoding	EDI X12ペイロードの文字エンコーディング(デフォルトはUTF-8)。
accept-message-on-errors および reject-message-on-errors	デフォルトでは、入力EDIペイロードの構文エラーは、変換時に検証エラーとして扱われます。 この動作は、次の2つの方法で変更できます: 現在のメッセージの検証チェックをオフにします。 または 一般的な場合は、検証をオンのままにします。 ただし、特定のタイプの検証エラーには時間がかかり、検証エラーが発生した場合でもメッセージを正常に処理できます。 これらの要素は、無視する検証エラーのタイプをきめ細かく制御することで、前述の2番目のオプションを提供します。 たとえば、B2Bレイヤーが無効なデータを検出しても、バックエンド・アプリケーションにメッセージを転送する特定の状況では、このファイングレイン制御が必要になる場合があります。 これらの要素はどちらも文字列型であり、文字列の形式を使用すると1つ以上の検証エラー・タイプを指定できます。 これらの要素は互いに逆の意味を持ちます。 形式は次のとおりです。 error#<error_code1>,error#<error_code2>,... これはカンマ区切りの文字列で、各トークンはerror#で始まり、その後にB2B-01752などのエラー・コードが続きます(たとえば、トークンは: error#B2B-01752)。 accept-message-on-errors要素は無視する検証エラーを定義し、reject-message-on-errors要素は実際のエラーとして処理する検証エラーを定義します。 検証エラーが実際のエラーとして処理されると、B2Bアクションでは、拒否フラグ付きの確認メッセージ(EDI X12 997)も生成されます。 ただし、検証エラーが無視されると、997にはAccepted, but errors were notedステータスのフラグが付けられます。
validate	デフォルトでは、入力EDIペイロードの構文エラーは、変換時に検証エラーとして扱われます。 この動作は、次の2つの方法で変更できます: 現在のメッセージの検証チェックをオフにします。 または 一般的な場合は、検証をオンのままにします。 ただし、特定のタイプの検証エラーでは不十分であるため、検証エラーが発生した場合でもメッセージを正常に処理できます。 この要素は、前述の最初のオプションを提供します。 この要素をfalseに設定すると、検証チェックがオフになり、B2Bアクションの構成ウィザードでチェック・ボックス「入力データに対して検証を実行しますか」の選択を解除した場合と同じ効果があります。 ただし、この要素はチェック・ボックス設定をオーバーライドし、すべてのメッセージに設定できます(ただし、チェック・ボックス設定はすべてのメッセージに使用されます)。 この要素が設定されていない場合は、ウィザードのチェック・ボックス設定によって、検証をオンにするかオフにするかが制御されます。
functional-ack-required	この要素をfalseに設定すると、B2Bアクションは機能確認メッセージを生成しません。 trueに設定されているか、設定されていない場合、B2Bアクションがバッチ内の最後のメッセージ(つまり、機能グループ内の最後のトランザクション・セット)を処理するときに、機能確認メッセージがTranslateOutput要素に含まれます。
passthrough-errors	この要素は、バッチ処理のステージ・ファイル・アクションでB2Bアクションを使用する場合にのみ必要です。 この要素は、エラーが発生した場合に適切な機能確認メッセージを生成できるように、特定のエラーをステージ・ファイル・アクションからB2Bアクションに転送するだけです。 B2Bアクションをスタンドアロン・モードで使用する場合は、この要素を設定しないでください。
routing-info	この要素は、バッチ処理のステージ・ファイル・アクションでB2Bアクションを使用する場合にのみ必要です。 B2Bアクションをスタンドアロン・モードで使用する場合は、この要素を設定しないでください。
input-source-context	このオプション要素を使用するには、B2BアクションによってTranslateOutput要素にコピーされる任意の識別子文字列を割り当てることができます。 たとえば、B2Bアクションがファイルからのメッセージを処理している場合は、ファイル名をこの要素に設定します。 要素の目的は、出力で値を使用できるようにすることです。 そのため、統合内でさらにアクションをリレーしたり、トラッキング変数内に格納できます。

TranslateOutputの要素

要素	説明
edi-xml-document	この要素は、翻訳されたメッセージとともにXMLフォームで返されます。 「インバウンドEDI用のTranslateOutput XMLのサンプル」を参照してください。
edi-xml-document > headers > interchange-ctrl edi-xml-document > headers > group	これらのヘッダー要素は、EDI X12 ISAおよびGSエンベロープから解析された値とともに返されます。
edi-xml-document > func-ack-report	この要素は、ドキュメント・タイプが997 (機能確認)の場合にのみ返され、997に固有の特別なコンテンツを保持します。 子要素は次のとおりです: original-tracking-info: この機能確認から再構築された元のアウトバウンド・メッセージのトラッキング識別子。 このトラッキング識別子は、アウトバウンドEDIの場合にTranslateOutput > tracking-infoで生成されるtracking-infoと部分文字列が一致します。 これは、最初に取引パートナに送信されたアウトバウンド・メッセージに着信997を関連付けるために使用されます。 たとえば、original-tracking-infoの値はtc=1013;gc=1013;sn=SenderID;rc=ReceiverID;st=A;で、TranslateOutput > tracking-infoの対応する値はtc=1013;gc=1013;sn=SenderID;rc=ReceiverID;ic=000000015です(これらの値には部分文字列一致があります。つまり、両方の値のtc=1013;gc=1013;sn=SenderID;rc=ReceiverID文字列の一部に完全一致があります)。 func-ack-status: 取引パートナによって報告された全体的な受入ステータス。 値は: Accepted、RejectedまたはAccepted But Errors Were Notedのステータスに対応するSuccess、ErrorまたはWarning。 func-ack-details: 人間が読めるプレーン・テキスト形式での機能確認の解釈。
edi-xml-document > transaction-data	この要素は、STセグメントで始まり、SEセグメントで終わる、EDIメッセージ内のデータ・セグメントおよび要素の階層構造とともに返されます。 EDI X12データ内の各セグメントまたはループは親XML要素になり、その構成要素であるEDI要素は子XML要素になります。 たとえば、これはtransaction-data要素内に表示される場合があります: <ST> <ST01>850</ST01> <ST02>1234</ST02> </ST> 前述のXMLフラグメントは、この行を持つEDI X12データから解析されたデータ値を表します: ST*850*1234~ XML要素<ST01>および<ST02>には、EDIデータ内で発生する対応する要素の位置に基づいて値が割り当てられます。
edi-xml-document > trailers > group edi-xml-document > trailers > interchange-ctrl	トレーラ要素は、EDI X12 IEAおよびGEエンベロープから解析された値とともに返されます。
functional-ack-present	EDI X12 997の機能確認がfunctional-ack要素で生成された場合、この要素はtrueとして返されます。 この要素は、確認メッセージが不要または生成された場合にfalseとして返されます(TranslateInput > functional-ack-requiredがfalseに設定されている場合、確認メッセージは生成されません)。 B2B処理では、次のように機能確認メッセージが自動的に生成されます: シングルトン・トランザクションの場合(EDIメッセージまたはファイル内に単一のオーダーがある場合など): 機能確認は、トランザクションの処理と同時に即時に生成されます。 バッチ取引の場合(EDIメッセージまたはファイル内に50のオーダーがある場合など): 機能確認は、バッチ内の最後のトランザクションが処理されるときに生成されます。 バッチとは、複数のトランザクション(つまり、ST/SEセグメントの複数のペア)を含む単一のEDI X12機能グループを意味します。 機能確認では、複数のAK2セグメントおよびAK5セグメントを含めることで、そのバッチ内のすべてのトランザクションのステータスがレポートされます。 EDI X12標準によると、バッチごとに1つの機能確認のみが必要です。
functional-ack	functional-ack-presentがtrueとして返される場合、functional-ack要素は、取引パートナに送信する準備ができているBase64-encoded EDI X12 997 (機能確認)ドキュメントとともに返されます。 ネイティブEDIコンテンツを送信しようとしている時点(たとえば、取引パートナに配信するファイルに書き込む前)でネイティブEDIコンテンツを取得するには、Decode64関数を適用する必要があります。
functional-ack-tracking-info	この要素は、生成された機能確認メッセージの一意の送信識別子を表す文字列とともに返されます。 この文字列には、機能確認に使用される管理番号が含まれます。 この値は、取引パートナが997ドキュメントを処理できない場合にトラッキング目的で役立ちます。
validation-errors-present	入力ペイロードの解析中に検証エラーが検出された場合、この要素はtrueとして返されます。
validation-errors > error validation-errors > validation-error-report	error要素は、XML構造内の各検証エラーとともに検証エラーとともに返されます。エラー・コードとエラー・メッセージは、別々のXML要素として返されます。 最大100個の検証エラーが報告されます。 validation-error-report要素は、最大100個の検証エラーの連結リストとともに改行文字で区切られて返されます。
tracking-info	この要素は、入力EDIで発生する一意の伝送識別子を表す文字列とともに返されます。 この文字列には、入力EDIメッセージの(interchange/group/transaction-set制御番号で使用される制御番号が含まれます。 この値はトラッキング目的で役立ちます。
translation-status	この要素は、次のように値Success、WarningまたはErrorとともに返されます: Success: 入力EDIが正常に解析され、検証エラーが検出されなかったことを示します(検証がオフの場合も発生します)。 Warning: 検証エラーがあったが、それらがマイナーであったか、ユーザーが特定のエラーを厳密に処理するように選択したことを示します。これは、TranslateInput > accept-message-on-errors値によって制御されます。 Error: 翻訳中にクリティカル検証エラーが検出され、機能確認コンテンツでメッセージが拒否済としてマークされたことを示します。 統合では、後続の処理のためにバックエンド・システムにメッセージを送信しないでください。かわりに、メッセージをエラー処理にルーティングする必要があります。
transaction-summary	この要素は、トランザクションのバッチ全体にわたって、成功、警告またはエラーで解析されたトランザクションの合計数とともに返されます。
input-source-context	この要素は、後続の統合アクションに表示されるように、TranslateInput > input-source-contextの動詞コピーとして返されます。