TRADACOMS EDI Connector

The TRADACOMS EDI Module uses a YAML format called ESL (for EDI Schema Language) to represent EDI schemas. ESLs define the structure of EDI messages in terms of structures (messages, in TRADACOMS terminology), groups, segments, composites, and elements.

The particular usage of ESL definitions for TRADACOMS has some differences from other EDI formats, particularly when working with the TRADACOMS concepts of "files" and "messages". Each file format defined by TRADACOMS gives the representation of data for some specific use. The file format is broken down into several message components, where one particular message component is allowed to repeat. Each message component is in turn broken down into segments and groups of segments, some of which may also be repeated.

In ESL terms, each TRADACOMS file format is represented by a particular schema definition. The supplied ESL schemas use the generic name for the file, which is the same as that of the repeating detail message. So for example, the Prince Information File structure is given by the PRIINF.esl schema definition. Within the file schema, each component message type is defined as a structure. The order of component messages within a file is given by the class value, which must be a string consisting of a single digit. The value '1' identifies the header message, the value '2' identifies the repeating detail message, and all higher values are successive messages within the file.

You can customize the TRADACOMS schema definitions to suit your data by defining an overlay schema. An overlay schema is a special form of ESL that allows you to modify a base schema, such as an TRADACOMS INVOIC schema, with your specific conventions. You don’t need an overlay schema if you’re using the structure defined by the standard.

You can also define your own schemas from scratch, or copy and edit a base TRADACOMS schema definition to suit your data.

To specify a schema according to your implementation convention, you can follow this process:

Overlay schemas list only changes instead of providing all the details of a schema structure. They specify how to use implementation conventions with a particular trading partner to extend and customize the standard.

By way of example, here’s a sample overlay schema modifying the basic TRADACOMS INVOIC file definition. This example adds a REBILL message at version 6 to the file, following all existing messages in the file (class value '5', since there are four message components normally present in an INVOIC file).

A structure overlay details modifications to the base schema definition of an TRADACOMS message. Most often these modifications take the form of marking segments or groups in the base definition as unused, but any usage or repetition count change is allowed.

The following is an example of a structure overlay:

The modifications in this example specify that the FDT (at position 7) and ACD (at position 8) segments are required in each INVFIL message (usage: M for mandatory). With this overlay, errors are reported if either the FDT or ACD segment is not present in a message.

The key-value pairs at the structure level are:

Each item in the list of structure data components is either a segment reference or a group definition. Both are shown here using a compact YAML syntax where the values for each reference are given as comma-separated key-value pairs enclosed in curly braces. The values are:

The values are:

The values in a group definition are:

A segment overlay again details modifications to the base schema definition. Most often these modifications take the form of marking elements or composites in the base definition as unused, but any usage or repetition count change is allowed. Here are some sample segment overlays:

This example modifies the base definition for the FDT segment, making both values defined in the segment required fields (they are optional in the base definition).

Segment modifications only effect structures included in the overlay with explicit references to the modified segments. That’s why the FDT segment reference needs to be included in the INVFIL message structure part of the schema, even though nothing (such as usage or repetition count) is being changed for how this segment is used within the message.

The key-value pairs in a segment overlay are:

The values list references values in the segment by position. The values for these references are:

To use the connector, you need to know the locations of the schemas in your project. If you’re using out-of-the-box TRADACOMS schemas and not customizing anything, the schema location follows the /tradacoms/{file}.esl pattern, so for the ORDERS file your schema location is "/tradacoms/ORDERS.esl".

If you’re using one or more custom schemas, you should put these under a directory in src/main/app and refer to the location using ${app.home}. For example, if you’ve put your CREDIT schema (either overlay or full) under src/main/app/mypartner/CREDIT.esl, your schema location is `${app.home}/mypartner/CREDIT.esl.

The Mule Runtime automatically checks src/main/app for any locations that contain the ${app.home} value.

The general tab lets you configure settings for reading and writing TRADACOMS messages, including identification information used in the STX segment:

All these identification values are optional. If any are configured, the values are verified when reading an input transmission and used as the defaults when writing an output transmission if no value is specified in the output data.

You can set the following options to control parser validation of receive messages if needed:

Settings for writing messages:

All values listed in the Anypoint Studio configuration can be set directly in XML.

General parameters control both send and receive document handling (all are optional):

Parser parameters control the parser operation and the types of error conditions which cause receive messages to be rejected (all are optional, with default values as shown):

Writer parameters control the writer operation (all are optional):