This topic covers the EDI Client tool, which sends messages in EDI format. It can be used in concert with the Enhanced Call Back and XML Tools.

In addition to EDI, the EDI Client and Enhanced Call Back tools support CSV, Fixed Length, Lines, and Plain Text. In these cases, the tool name changes to reflect the appropriate format (i.e., CSV Client and CSV Call Back, Fixed Length Client and Fixed Length Call Back, Lines Client and Lines Call Back, and Plain Text Client and Plain Text Call Back). 

The XML Converter tool supports these formats as well. It changes names depending on the format and direction—for instance, to Convert Fixed Length to XML, Convert XML to Fixed Length, Convert EDI to XML, Convert XML to EDI.

Sections include:


The EDI format requires the Message Packs license feature to be enabled. The Message Packs license feature enables the EDI format in the EDI Client, Enhanced Call Back Took, and XML Converter.  

The EDIFACT support that was available in SOAtest 9.1 is still available as the "Basic EDIFACT" format in EDI Client, Enhanced Call Back, and XML Converter. See Basic EDIFACT Support for details.

Using EDI with SOAtest

Business and organizations can exchange messages using EDI (Electronic Data Interchange), which uses several standardized message formats. One such format is EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport). 

Most EDI message formats, including EDIFACT, are difficult to parse and difficult for humans to read.

The EDI Client, Enhanced Call Back and XML Converter tools simplify the use of EDIFACT in SOAtest. By seamlessly converting from XML to native formats and from native formats to XML, SOAtest allows you to easily leverage SOAtest's existing XML functionality for sending, verifying, and extracting data from EDI messages.

The EDI format support covers the following standards: 

For details on what versions and message types within each standard are supported, see EDI Support Details.

Using EDI Client

EDI Client is designed for modelling EDI messages in a form view that allows you to easily change the values of specific fields within the message, or that allows you to parameterize fields within the message. 

EDI Client offers a superset of the Message Client tool’s functionality. It can do anything that the Messaging Client can—and it can also automatically convert the request payload from XML to EDI (and the response payload from EDI to XML). 

It simplifies the use of EDI, which is often difficult to read, by allowing you to utilize XML. You can model your EDI request payload as an XML document; the client then automatically converts the XML to EDI before sending the message. If the server returns an EDI message, the client can convert the message to XML so that you can attach tools such as the XML Assertor and XML Data Bank to the response.

If you simply want to send a literal EDI message, you might want to use the Messaging Client instead of this tool. However, if you are expecting an EDI message in return, the EDI Client has the following advantage over a Messaging Client: the Response Payload modeled as XML output. This output will allow you to chain an XML Assertor, XML Data Bank, or Diff Tool in XML mode to it so you can validate the message easily. With a Messaging Client, you would need one extra step: add a Text/XML Transformer to the Response Traffic output, and then add the XML Assertor, XML Data Bank, or Diff Tool.

Workflows

There are two expected workflows that can be used to configure the EDI Client...

Existing Literal EDI Message

(Recommended) If you already have a literal EDI message:

  1. Create a new EDI Client.
  2. Switch to Literal mode and paste in your EDI message.
  3. Switch to Form Input or Form XML mode, which will then get populated based on the message you entered. You can now configure and parameterize your message as you wish. See Specifying the Request for details.
  4. Set the appropriate transport settings. See Specifying Transport Settings for details.
  5. Add appropriate validation tools to the outputs. See Validating EDI Messages for details.
  6. Run the test.

Creating an EDI Message From Scratch

If you want to create an EDI message from scratch:

  1. Create a new EDI Client.
  2. Select a message type using the Dialect, Version, and Message type fields, which will populate the Form Input view.
  3. Manually specify  the message using Form Input. See Specifying the Request for details.

Form Input will constrain your message to the schema for the selected message type, and will not allow you to add fields to the message that are not part of the message. It will also warn you when you are attempting to use value types that are not supported in a given field (like trying to put a string into an integer field). Form XML does not perform either of these checks.

Note that you will likely need to manually add fields that your message uses because SOAtest generates a minimal valid EDI message based on the message type you selected. The message will include default values, which you might want to modify. Using the right-click Populate option (described in Populating and Parameterizing Elements with Data Source Values) in Form Input is generally discouraged. It will add all optional fields to the message, but it will not necessarily add valid default values. After using Populate, you would need to manually review and enter the value of each field. For most EDI messages, this can be quite tedious.

Tool Configuration Details

Sending in Native or XML Format

Using default options, the EDI Client always sends the native format that is selected in the Format combo box. However, in Form Input and Form XML modes, the EDI Client can be configured to send SOAtest's XML format rather than the native format. 

To do this, check the box Send XML instead of EDI when in Form Input or Form XML mode in the XML Conversion Options section of the EDI Client editor.  



Note that this option has no relevance to Literal or Scripted views—the client will always send the exact text that appears in Literal view or that is returned by a script in Scripted view.

Specifying the Request 

For recommended workflows for specifying the request, see Workflows.

Note that when you switch between Form Input or Form XML and Literal, the content in Form Input or Form XML is automatically converted to the native format, which is shown in Literal view. Content in Literal view is automatically converted to an XML format that is then shown in Form Input or Form XML.  

In EDI format mode, if you paste in an EDI message into Literal view and then switch to Form Input or Form XML, SOAtest will automatically detect the message type and automatically populate the Dialect, Version, and Message Type combo boxes. 



For details on the available views, see Message Tool and Responder Options.


If you want to send a custom EDI message, Form XML view will let you add custom fields that Form Input will not allow you to enter.

If you paste a message into Literal view, and switch to Form Input but Form Input does not get populated, then switch from Literal view to Form XML instead. Form Input will not be populated in the cases where SOAtest is not able to find a matching schema for the EDI message that was pasted in. However, with Form XML, SOAtest can often still support those messages.

Specifying Transport Settings

See Testing Through Different Protocols for details on how to configure settings for the available transports.

Note that when the transport is HTTP, the Content-Type HTTP header gets set to one of the following:

The default mimetype for each format is:

Specifying Success Criteria

Specifying Conversion Options

In EDI format, when an option is blank, the conversion will use the default option for that option. Otherwise, if a value is selected or typed in, the conversion will attempt to use that value. Note that if an invalid value is entered manually, you may get an error when trying to switch between Form Input/Form XML and Literal views, or when running the test.

For EDI, available conversion options are:

Note that no conversion options are applicable for Basic EDIFACT.

Validating EDI Messages

To validate EDI messages, you typically will attach a XML Assertor, XML Data Bank, or Diff tool in XML mode to the Response Payload Modeled as XML output. However, you can attach Extension tools or other kinds of tools to that output to do whatever you need to do. If you would like to validate the literal EDI content, you can attach any tool to the Response Payload output; this will send the literal EDI content to whatever tools are attached to it.

The EDI Client offers two outputs to the response payload: 

For example, if you use the Plain Text format and the server returns the string "delta", SOAtest will provide the value "delta" as input to tools attached to the "Payload" output. To the tools attached to the "Payload Converted to XML" output, the EDI Client will provide the value " <root>delta</root>".

Working with the Request Payload

Attaching Request Payload Outputs

The EDI Client offers two outputs to the request payload. In contrast, the Messaging Client offers a single output (simply named "Traffic"). The EDI Client has two outputs because of its support for automatically converting the request from XML to an EDI format.

The two request outputs of the EDI Client are:

If you have selected the option to send XML instead of EDI (Send XML instead of EDI when in Form Input or Form XML mode), then the outputs attached to the output "Payload Modeled as XML" will not run.



Modifying the Request Payload

As with the Messaging Client, you can modify the request payload by attaching tools to the request output. For example, if you attach to the Payload output an Extension tool that returns a value, then SOAtest will use that value as the request payload. In other words, SOAtest will send that value to the server and you will see that value in the Traffic Viewer. Additionally, you can modify the XML model of the message by attaching tools to the "Payload Modeled as XML" output.

Running the Tool

The EDI Client runs the "Payload Modeled as XML" outputs before the "Payload" outputs.

For example, assume you have the following tool:

In the EDI Client UI, you have chosen to convert from XML to EDI and have chosen to use the Plain Text format. You have modeled the request payload as the following XML:

<root>alpha</root>

When the EDI Client runs, it first runs Extension Tool 1, which is attached to the request payload modeled as XML. The Extension Tool 1 contains the following Jython:

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

The Extension Tool 1 prints "input: <root>alpha</root>" to the console and returns "<root>beta</root>".

The Extension Tool 2 contains the following 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):

The tool prints "input: beta" to the console because the EDI Client internally converted the value 

returned by Extension Tool 1, "<root>beta</root>", to text by removing the "root" tags. Extension Tool 2 returns the string "gamma". You will see the string "gamma" in the request payload in the Traffic Viewer.

Tutorial

See Working with EDI Messages.

Basic EDIFACT Support

The basic EDIFACT support that was available in SOAtest 9.1 is still available as the "Basic EDIFACT" format:



It is available in EDI Client, Enhanced Call Back, and XML Converter.

Basic EDIFACT support does not require a Message Packs license. It supports a subset of the dialects and versions that the Message Packs license covers. For example, EDIFACT is the only available dialect, and only versions 10B, 96B, S3, S4, and S41 are supported. 

Note that: