このセクションでは、EDI Client ツールについて説明します。EDI Client ツールは EDI 形式でメッセージを送信します。EDI Client ツールは Enhanced Call Back および XML ツール と組み合わせて使用することができます。

EDI Client ツールおよび Enhanced Call Back ツールは、EDI に加えて CSV、固定長、行、およびプレーン テキスト形式をサポートしています。これらの形式を使用すると、形式に合わせてツール名が変わります (CSV Client と CSV Call Back、Fixed Length Client と Fixed Length Call Back、Lines Client と Lines Call Back、Plain Text Client と Plain Text Call Back)。 

XML Converter ツールもこれらの形式をサポートしています。形式および変換の方向によってツールの名称が変わります。たとえば、Convert Fixed Length to XML、Convert XML to Fixed Length、Convert EDI to XML、Convert XML to EDI などです。

このセクションの内容:


メッセージ パック ライセンスが必要

EDI 形式を使用するには、Message Packs ライセンス機能を有効にする必要があります。Message Packs ライセンス機能を有効にすると、EDI Client、Enhanced Call Back ツール、および XML Converter で EDI 形式を使用できます。  

ベーシック EDIFACT のサポート

SOAtest 9.1 でサポートされていた EDIFACT は、引き続き「ベーシック EDIFACT」として EDI Client、Enhanced Call Back、および XML Converter で利用できます。詳細については、「ベーシック EDIFACT のサポート」 を参照してください。

EDI を SOAtest で使用

企業や組織は EDI (Electronic Data Interchange) を使用してメッセージを交換できます。EDI は標準的なメッセージ形式を使用します。その 1 つが EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) です。 

EDIFACT も含め、多くの EDI メッセージ形式は、解析が難しく、人間にとっては読みづらいものです。

EDI Client、Enhanced Call Back、および XML Converter ツールを使用すると、 SOAtest で EDIFACT を使用するのが容易になります。XML からネイティブ形式に、またネイティブ形式から XML にシームレスに変換できるので、SOAtest の既存の XML 機能を利用して EDI メッセージの送信、検証、およびデータの抽出を行うことができます。

EDI 形式として次の標準がサポートされています。 

  • AL3 - ACORD AL3 とも呼ばれます。
  • CARGO - IATA Cargo-IMP とも呼ばれます。
  • EANCOM
  • EDIFACT
  • EDIFACT Basic - 次で説明: Basic EDIFACT Support
  • EDIGAS - Edig@s とも呼ばれます。
  • HIPAA
  • HL7
  • IATA - IATA PADIS とも呼ばれます。
  • NCPDP - NCPDP SCRIPT とも呼ばれます。
  • TELCO - NCPDP Telecommunication とも呼ばれます。
  • TRADACOMS
  • X12

各標準でサポートされるバージョンおよびメッセージ タイプの詳細については、「EDI サポートの詳細」を参照してください。

EDI Client の使用

EDI Client を使用すると、EDI メッセージをフォーム ビューでモデル化し、メッセージに含まれる特定のフィールドの値を容易に変更したり、フィールドをパラメータライズしたりできます。 

EDI Client は、Message Client ツールの機能のスーパーセットを備えています。EDI Client は、Message Client ツールのすべての機能を実行できるほか、自動的にリクエスト ペイロードを XML から EDI に (そしてレスポンス ペイロードを EDI から XML に) 変換します。 

EDI Client を使用すると、XML を活用し、読解が困難な場合が多い EDI を簡単に利用できます。EDI リクエスト ペイロードを XML ドキュメントとしてモデル化できます。EDI Client は、自動的に XML を EDI に変換してからメッセージを送信します。サーバーから EDI メッセージが返されると EDI Client がメッセージを XML に変換するため、XML Assertor および XML Data Bank などのツールをレスポンスに連結できます。

単にリテラルな EDI メッセージを送信する場合、EDI Client ではなく Messaging Client ツールを使用するほうがよいかもしれません。しかし、レスポンスとして EDI メッセージが返されることが期待されている場合、EDI Client には、Messaging Client にはない利点があります。それは、レスポンス ペイロードが XML 出力としてモデル化されることです。XML が出力されるため、XML Assertor、XML Data Bank、または XML モードの Diff ツールを連結し、容易にメッセージを検証することができます。Messaging Client では、レスポンス トラフィック出力に Text/XML Transformer を追加してから XML Assertor、XML Data Bank、または Diff ツールを連結するという余分な手間がかかります。

ワークフロー

EDI Client ツールの構成に使用できるワークフローは 2 つあります。

既存の Literal EDI メッセージ

(推奨) すでにリテラルな EDI メッセージがある場合には、次の操作を行います。

  1. 新規 EDI Client を作成します。
  2. リテラル モードに切り替え、EDI メッセージを貼り付けます。
  3. フォーム入力またはフォーム XML モードに切り替えます。すると、入力したメッセージに基づいてビューに値が設定されます。メッセージを任意に構成し、パラメータライズできます。詳細については、「リクエストの指定」 を参照してください。
  4. トランスポート設定を適切に指定します。詳細については、「トランスポート設定の指定」 を参照してください。
  5. 適切な検証ツールを出力に追加します。詳細については、「EDI メッセージの検証」 を参照してください。
  6. テストを実行します。

ゼロから EDI メッセージを作成

ゼロから EDI メッセージを作成するには、次の操作を行います。

  1. 新規 EDI Client を作成します。
  2. [ダイアレクト]、[バージョン]、および [メッセージ タイプ] フィールドを使用してメッセージ タイプを選択します。選択されたタイプに従ってフォーム入力ビューが設定されます。
  3. フォーム入力ビューを使用して手動でメッセージを指定します。詳細については、「リクエストの指定」 を参照してください。

フォーム入力ビューは、選択されたメッセージ タイプのスキーマに従ってメッセージを制限し、メッセージに含まれていないフィールドを追加できないようにします。また、フィールドに対してサポートされていない値型を使用しようとした場合、警告を発します (たとえば integer フィールドに string を入力しようとした場合など)。フォーム XML ビューでは、これらのチェックは行われません。

SOAtest は、選択したメッセージ タイプに従って、最小限の有効な EDI メッセージしか生成しないため、メッセージで使用されるフィールドを手動で追加する必要がある場合が多いでしょう。生成されるメッセージにはデフォルト値が含まれていますが、手動で変更することができます。フォーム入力ビューで右クリック メニューの [データ投入] オプション (「データ ソース値を使った要素のデータ投入とパラメータライズ」の説明を参照) を使用することは、通常は推奨されません。このオプションを使用すると、すべての任意フィールドがメッセージに追加されますが、有効なデフォルト値が追加されるとは限りません。 [データ投入] オプションを使用した後、メッセージを確認して各フィールドに値を入力する必要があります。多くの EDI メッセージの場合、そのような作業は非常に煩雑です。

ツール設定の詳細

ネイティブまたは XML 形式で送信

デフォルトのオプションを使用すると、EDI Client は常に [フォーマット] コンボ ボックスで選択されたネイティブ形式を送信します。しかし、フォーム入力およびフォーム XML モードでは、ネイティブ形式ではなく SOAtest の XML 形式で送信するよう設定できます。 

XML 形式で送信を行うには、EDI Client エディターの [XML 変換オプション] セクションにある [フォーム入力またはフォーム XML モード時は EDI の代わりに XML を送信] チェック ボックスをオンにします。  



  • このオプションがオフの場合 (デフォルト): SOAtest は自動的に XML モデルをネイティブ形式に変換してからメッセージを送信します。言い換えれば、SOAtest はネイティブ形式をサーバーに送信します (従って、その内容が Traffic Viewer に表示されます)。
  • このオプションがオンの場合: SOAtest は、UI で設定されたメッセージをリクエストとして送信します。リテラル ビューまたはスクリプト ビューを使用すると、ネイティブ形式でメッセージのペイロードを作成できます。このオプションをオンにして UI で XML を作成した場合 (たとえばフォーム入力ビューで)、SOAtest は XML をそのまま送信します。現在サポートされている形式では、通常はこのオプションをオンにすることはないでしょうが、SOAtest では、このような処理が可能です。

このオプションは、リテラル ビューまたはスクリプト ビューに対しては意味がないことに注意してください。EDI Client は常にリテラル ビューに表示されたテキストまたはスクリプト ビューのスクリプトから返されたテキストをそのまま送信します。

リクエストの指定 

リクエストを指定する際に推奨されるワークフローについては、「ワークフロー」を参照してください。

フォーム入力ビューまたはフォーム XML ビューからリテラルビューに切り替えた場合、フォーム入力ビューまたはフォーム XML ビューの内容は自動的にネイティブ形式に変換され、リテラル ビューに表示されます。リテラル ビューの内容をフォーム入力ビューまたはフォーム XML ビューで表示すると、自動的に XML 形式に変換されます。  

EDI 形式モードでは、EDI メッセージをリテラル ビューに貼り付けてからフォーム 入力ビューまたはフォーム XML ビューに切り替えた場合、メッセージタイプが自動的に検出され、[ダイアレクト]、[バージョン]、[メッセージ タイプ] コンボ ボックスに自動的に値が設定されます。 



利用可能なビューの詳細については、「Input Modes」を参照してください。


カスタム EDI メッセージの送信

カスタム EDI メッセージを送信する場合、フォーム XML ビューを使用すると、フォーム入力ビューでは入力できないカスタム フィールドを追加できます。

ビューを切り替えたときに値が自動で設定されない場合

リテラル ビューにメッセージを貼り付けてからフォーム入力ビューに切り替えてもフォーム入力ビューに値が表示されない場合、リテラル ビューからフォーム XML ビューに切り替えてください。貼り付けられた EDI メッセージに該当するスキーマを SOAtest が検出できなかった場合、フォーム入力ビューには値が設定されません。しかし、フォーム XML ビューでは、そのようなメッセージもサポートできる場合があります。

トランスポート設定の指定

利用可能なトランスポートの設定を構成する方法の詳細については、「さまざまなプロトコルによるテスト」を参照してください。

トランスポートが HTTP の場合、Content-Type HTTP ヘッダーには以下のどちらかが設定されます。

  • フォーム入力、フォーム XML、スクリプト モードの場合 - フォーマット タイプのデフォルトの MIME タイプが設定されます。デフォルト以外の MIME タイプを送信する場合、[トランスポート] タブの [HTTP ヘッダー] セクションで新しい Content-Type ヘッダーを追加し、MIME タイプを上書きする必要があります。
  • リテラル モードの場合 - リテラル ビューで MIME Type フィールドに設定された MIME タイプが使用されます。

各形式のデフォルトの MIME タイプは以下のとおりです。

  • CSV - text/csv
  • EDI - application/EDI-X12
  • ベーシック EDIFACT - application/EDIFACT
  • 固定長 - text/plain
  • 行 - text/plain
  • プレーン テキスト - text/plain

その他のオプションの設定

[Misc] タブをクリックして以下のオプションを設定します:

  • 有効な HTTP レスポンス コード: ツールの動作をカスタマイズし、200 番台以外のHTTPレスポンス コードを成功とすることができます。コードおよび/またはコードの範囲をカンマで区切って入力します。たとえば「302, 500-599」を使用した場合、「302 のコード」 または「500 番台の任意のコード」が許容されます。データ ソースに格納された値を使用する場合も、必ず同じフォーマットを使用してください (「302, 500-599」 など)。

  • タイムアウト (ミリ秒): FTP、telnet、または HTTP リクエストがタイムアウトしたとみなす時間を秒単位で指定します。デフォルトの設定は、[設定] パネルで指定した値と同じです。[カスタム] を選択すると、タイムアウト値を入力できます。タイムアウト時間を設定しない場合は、負の値を指定します。

    • タイムアウト時にテストは失敗する: タイムアウト時間に達したときにテストを失敗にします。
    • タイムアウトが発生した場合だけテストは成功する: 指定のタイムアウト時間に達したときに (つまりテストが指定時間内に終了しなかったときに) テストを成功にします。
  • 送信メッセージのエンコード: ドロップダウン メニューから [カスタム] を選択し、送信メッセージのエンコーディングを選択します。デフォルトでは、直接の親テスト スイートで設定されたエンコーディングを使用します (「クライアント オプションの設定」を参照)。このオプションは Parasoft 設定の [その他] でも指定できます。

変換オプションの指定

EDI 形式では、オプションが空の場合、オプションのデフォルト値を使用して変換が行われます。値が選択または入力されている場合、変換時にその値が使用されます。無効な値が手動で入力された場合、フォーム入力/フォーム XML ビューとリテラル ビューの間で切り替えを行ったときやテストを実行したときにエラーが発生する可能性があることに注意してください。

EDI には、以下の変換オプションがあります。

  • オプションとしてすべてのセグメントと要素を扱う - このオプションがオンの場合、すべての必須セグメントおよび必須データ要素はオプションとして扱われます。オフに設定された場合 (デフォルト値)、必須セグメントまたは必須データ要素がないとエラーが発生します。プロバイダーが EDI 仕様では必須とされるセグメントや要素を提供しない場合、このオプションをオンにすると役に立ちます。
  • 検証の有効化 - オンに設定すると (デフォルト値)、EDI ファイル (入力および出力) のバージョン、リリース、メッセージおよびセグメントが、対応する EDI リポジトリと比較されます。EDI リポジトリにない値が EDI ファイルに含まれている場合、エラーがスローされます。
    検証が無効な場合 (このオプションの値がオフの場合)、リポジトリにないバージョン、リリース、メッセージまたはセグメントが EDI ファイルに含まれていても、処理が続行されます。認識されないバージョン、リリース、メッセージ、またはセグメントを処理する場合、要求されるデータの構造が不明なため、一部のチェックを実行できない場合があります。
    たとえば、ファイルのバージョンはわかっているが、認識できないセグメントが含まれている場合、そのセグメントのデータ タイプのチェックは行われませんが、ファイルの残りの部分は通常通りチェックされます。同様に、EDI リポジトリに存在しないメッセージがある場合もファイルは処理されますが、セグメント順序のチェックは行われません。
  • コンポーネント値区切り - 要素が複合要素の場合、複合要素内のコンポーネント要素の区切りとして使用する文字を指定します。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • 行継続文字 - EDI メッセージのセグメントが複数の行に渡る場合にセグメントの終端に付加される文字を指定します。この文字は、通信がまだ最後に達していないことをホスト システムに通知します。最後を除き、通信のすべてのセグメントに追加されます。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。このオプションは、CARGO 以外のすべての EDI ダイアレクトでサポートされています。
  • 小数点記号 - 変換後のファイルで小数点として使用される記号です。通常はピリオドまたはカンマです。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • 要素区切り - セグメントの要素を区切るのに使用する文字です。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • セグメント名/コンテンツ区切り (TRADACOMS) - TRADACOMS データ ストリームでは、セグメント名とセグメントのコンテンツを区切るのに使用されるデフォルトの文字は等号 (=) です。このオプションを使用すると、デフォルトの文字を上書きできます。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。このオプションは TRADACOMS ダイアレクトにだけ適用されます。
  • 無効な文字の置換 - 無効な文字の置換に使用する文字を指定します。[文字レパートリの上書き （EDIFACT）] オプションの REPLACE 値と共に使用します。このオプションが指定されていない場合のデフォルト値はアンダースコア ("_") です。有効な値は次のとおりです。

    \u#### – Unicode 値を指定する場合に使用します (#### には適切な値を指定します)。

    \d#### – 10 進数値を指定する場合に使用します (#### には適切な値を指定します)。

    このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • リリース (エスケープ) 記号 - リリース (エスケープ) 文字です。次の文字の特別な処理を無効にします。たとえば、テキスト メッセージに区切り要素に使用するのと同じ文字が含まれているとします。指定されたリリース文字は、その区切り文字をテキストの終端としてではなく、通常の文字として扱うよう EDI プロセッサに指示します。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • リピート記号 - リピート記号を使用する EDI ファーマットに関して、リピート記号を指定します。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • セグメント区切り - セグメント区切りとして使用する文字です。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • EDI コンテンツ文字の処理を停止します - 出現したときに EDI コンテンツのすべての処理を停止する文字を指定します。たとえば、^Z (0x1A) が出現したときに EDI ストリームを終了する場合、terminate=26 (26 は 0x1A を 10 進数で表した値です) を指定すると、^Z が出現したときに EDI の解析が終了し、ファイルの残りのコンテンツは無視されます。
  • サブコンポーネント (三次の) 区切り - サブコンポーネントの区切りとして使用する文字です。このオプションは、EDI から XML へ、また XML から EDI への変換に影響を与えます。
  • 文字レパートリの上書き (EDIFACT) - EDIFACT ベースのドキュメント (EANCOM および IATA など) の変換時に文字エンコーディングを上書きし、変更することができます。
    以下の 1 つ以上の値を使用できます。複数の値を使用する場合は、"+" 記号で連結します (例: FINNISH+REPLACE)。

    DEFAULT – ファイルで指定されたエンコーディングが使用されます。この値は、他の値と組み合わせて使用することはできません。

    EANCOM – UNOA および UNOB への次の EANCOM 追加文字が追加されます: #、@、[、]、{、}、\、|、‘ および ^

    SYMBOL – 要素区切りおよびセグメント区切りなど、許可される可能性のある特殊文字も含めたすべての文字をエンコーディングに対して検証することを強制します。

    REPLACE – 無効な文字を [無効な文字の置換] オプションによって指定された文字に置換します。[無効な文字の置換] オプションが指定されていない場合、アンダースコア ("_") が使用されます。REPLACE が指定されていない場合、変換はエラーをレポートします。

    FINNISH – UNOA および UNOB の Finnish 文字セットに属する特定の文字の意味を変更します (また、UNOA および UNOB のシノニムとして UNOY および UNOZ を追加します)。

  • 拡張マップ ファイル - ベースとなる EDI 標準とは異なるカスタム/プロプラエタリ EDI メッセージ タイプを使用する場合、それらのメッセージ タイプを記述する拡張マップ ファイルへのパスを入力できます。拡張マップファイルでは、プロプラエタリな EDI メッセージ タイプを記述できるオープンな標準である EDI Standard Exchange Format (SEF) を使用できます。${ENV_VAR} という書式を使用してファイル パスを指定できます。

変換オプションは、ベーシック EDIFACT には適用されないことに注意してください。

EDI メッセージの検証

EDI メッセージを検証する場合、通常は XML 出力としてモデル化されたレスポンス ペイロードに XML Assertor、XML Data Bank、または Diff ツールを連結します。しかし、Extension ツールやその他のツールを出力に連結し、任意の検証を行うことができます。リテラルな EDI コンテンツを検証する場合、レスポンス ペイロード出力にツールを連結できます。すると、リテラルな EDI コンテンツが連結されたツールに送信されます。

EDI Client には以下の 2 つのレスポンス ペイロード出力があります。 

  • ペイロード: SOAtest がサーバーから受信したレスポンスです。通常は EDI メッセージです。Messaging Client ツールの「トラフィック」出力に相当します。
  • XML に変換されたペイロード: レスポンス ペイロードを XML に変換した結果です。EDIFACT などの選択された EDI 形式によって、SOAtest がメッセージを XML に変換する方法が決定されます。

たとえば、プレーン テキスト形式を使用し、サーバーが "delta" という文字列を返した場合、「ペイロード」出力に連結されたツールには、入力値として "delta" という値が送信されます。一方、[XML に変換されたペイロード] 出力に連結されたツールには、"<root>delta</root>" という値が送信されます。

リクエスト ペイロードの処理

リクエスト ペイロードの出力を追加

EDI Client には 2 つのリクエスト ペイロード出力があります。一方、Messaging Client の出力は 1 つだけです (単に「トラフィック」という名称です)。EDI Client はリクエストを XML から EDI 形式に自動変換する機能があるため、2 つの出力があります。

EDI Client のリクエスト出力は以下の 2 つです。

  • XML としてモデル化されたペイロード: XML モデル化されたリクエスト ペイロードです。通常、フォーム入力ビューまたはフォーム XML ビューを使用して作成されます。 [フォーム入力またはフォーム XML モード時は {フォーマット} の代わりに XML を送信] オプションを選択した場合、この出力には、XML から EDI に変換される前のリクエスト ペイロードが送られます。
  • ペイロード: サーバーに送信されるペイロードです。Messaging Client の「トラフィック」リクエスト出力に相当します。 [フォーム入力またはフォーム XML モード時は {フォーマット} の代わりに XML を送信] オプションを選択した場合、この出力は、XML を EDI に変換した結果です。

EDI の代わりに XML を送信することを選択した場合 ([フォーム入力またはフォーム XML モード時は EDI の代わりに XML を送信] モード)、[XML としてモデル化されたペイロード] 出力に連結された出力は実行されません。



リクエスト ペイロードの変更

Messaging Client の場合と同様に、リクエスト出力にツールを連結することで、リクエスト ペイロードを変更できます。たとえば、「ペイロード」出力に Extension ツールを連結して値を返すと、SOAtest はその値をリクエスト ペイロードとして使用します。つまり、SOAtest はその値をサーバーに送信し、Traffic Viewer でその値を参照することができます。また、[XML としてモデル化されたペイロード] 出力にツールを連結することで、メッセージの XML モデルを変更できます。

ツールの実行

EDI Client は「ペイロード」出力の前に [XML としてモデル化されたペイロード] 出力を実行します。

たとえば、次のツールがあるとします。

  • EDI Client
    • Request Payload Modeled as XML->Extension Tool 1
    • Request Payload->Extension Tool 2



EDI Client の UI で、XML から EDI への変換を行うよう選択し、プレーン テキスト形式を選択したとします。さらに、次の XML のようにリクエスト ペイロードをモデル化します。

<root>alpha</root>

EDI Client を実行すると、まず、XML としてモデル化されたリクエスト ペイロードに連結された Extension Tool 1 が実行されます。Extension Tool 1 には、次の Jython コードが指定されています。

from com.parasoft.api import Application
def main(input, context):
Application.showMessage("input: " + str(input))    
   return str(input).replace("alpha", "beta") 

Extension Tool 1 は、"input: <root>alpha</root>" をコンソールに出力し、"<root>beta</root>" を返します。

Extension Tool 2 には、次の Jython コードが指定されています。

from com.parasoft.api import Application
def main(input, context):
Application.showMessage("input: " + str(input))    
    return str(input).replace("beta", "gamma")def main(input, context):

ツールはコンソールに "input: beta" と出力します。これは、Extension Tool 1 によって返された値  

"<root>beta</root>" が、EDI Client によって root タグを削除したテキストに内部的に変換されるからです。Extension Tool 2 は文字列 "gamma" を返します。リクエスト ペイロードの Traffic Viewer で文字列 "gamma" を参照することができます。

チュートリアル

「EDI メッセージでの作業」を参照してください。

ベーシック EDIFACT のサポート

SOAtest 9.1 でサポートされていた EDIFACT は、引き続き「ベーシック EDIFACT」形式として 利用できます。



ベーシック EDIFACT 形式は、EDI Client、Enhanced Call Back、および XML Converter で利用できます。

ベーシック EDIFACT の利用には、Message Packs ライセンスは必要ありません。ベーシック EDIFACT は、Message Packs ライセンスがカバーするダイアレクトおよびバージョンの一部をサポートします。たとえば、ダイアレクトとしては EDIFACT だけがサポートされており、バージョンとしては 10B、96B、S3、S4 および S41 だけがサポートされています。 

以下の点に注意してください。

  • Load Test は「ベーシック EDIFACT」形式をサポートしていません。Load test は、Message Packs ライセンスを必要とする 「EDI」を含めた他のすべてのテキスト/XML 形式をサポートします。
  • ベーシック EDIFACT の変換と EDI の変換では、同じ EDI データから異なる XML 表現が生成されます。結果として、「ベーシック EDIFACT」を使用して EDI を XML に変換し、「EDI」の変換を使用して EDI に戻すことはできません。同様に、「EDI」を使用して EDI を XML に変換し、「ベーシック EDIFACT」を使用して EDI に戻すことはできません。
  • No labels

Need assistance? Visit our support page