• Chapter 1: Getting Started with Stylus Studio®
• Chapter 2: Editing and Querying XML
• Chapter 3: Converting Non-XML Files to XML
  • Introduction
  • DataDirect XML Converters
  • Custom XML Converters
  • The Custom XML Conversion Definition Editor
  • Parts of an Input File
  • Working with Regions
  • Working with Fields
  • Controlling XML Output
  • Creating a Custom XML Conversion Definition
  • Using Custom XML Conversion Definitions in Stylus Studio
  • Working with EDI Conversions
    • Supported EDI Dialects
    • Creating Custom EDI Message Types
      • Overview
      • Specifying the Extension File Location
      • The ex.xsd XML Schema
      • The Root Element
      • The Message Element
      • The Group Element
      • The Segment Element
      • Composite Fields
      • Elements
    • Understanding Separator Characters
    • Validating XML from/to EDI
  • The Converter URL Scheme
  • Custom XML Conversion Definitions Properties Reference
• Chapter 4: Working with XSLT
• Chapter 5: Creating XSLT Using the XSLT Mapper
• Chapter 6: Debugging Stylesheets
• Chapter 7: Defining XML Schemas
• Chapter 8: Defining Document Type Definitions
• Chapter 9: Writing XPath Expressions
• Chapter 10: Working with XQuery in Stylus Studio
• Chapter 11: Composing Web Service Calls
• Chapter 12: Building XML Pipelines
• Chapter 13: Publishing XML Data
• Chapter 14: Integrating with Third-Party File Systems
• Chapter 15: Extending Stylus Studio
• Chapter 16: The Stylus Studio Java API
• Chapter 17: Stylus Studio GUI Reference

Home >Online Product Documentation >Table of Contents >Creating Custom EDI Message Types

Creating Custom EDI Message Types

You can define extensions to standard EDI message types in Stylus Studio. This allows the EDI XML Converter to convert proprietary EDI message types that are based on an extension (or restriction) to a standard EDI message type.

You can create custom EDI message types for

The message types you create must be either EDIFACT- or X12-style messages, since the auto-detection feature of the EDI XML Converter depends on the initial segments of those dialects as well as on the general syntax of the document. You cannot, for example, create an HL7 EDI message, since HL7 is structurally different (it allows messages to span documents, it allows segments to be split and continued, it has a sub-field structure, and so on).

Overview

The process for using a custom EDI message type includes the following steps:

Figure 185. Specifying a Custom EDI Message Type

Specifying the Extension File Location

You can specify the XML document that contains the custom message type definition using

Note that if you are using a relative path, it must be relative to the same directories in which the XML Converters executables (XMLConverters.jar for the Java version of the XML Converters, XMLConverters.dll for the .NET version).

In environments in which the location of the XMLConverters.* file cannot be determined, you must specify the location:

The ex.xsd XML Schema

You add custom EDI message types to Stylus Studio by creating XML files that conform to the XML Schema ex.xsd. This XML Schema is located in the \bin\Plugins\Configuration Files folder where you installed Stylus Studio.

This XML Schema is for a completely described message type, which can include one or more messages, one or more segments, zero or more composites, and one or more elements. The XML Schema assumes that all pieces needed are described within the XML.

The Root Element

The root element of the custom EDI message type XML document is <edi>. Within the root element, you can define each of the following components: <message>, <segment>, <composite>, and <element>. When one component references another, it will always be in the form of a <use-...> element. For example, a <message> will have one or more <use-segment> elements within it, which will refer to the <segment>s defined elsewhere in the file.

The Message Element

Each EDI message is composed of one or more <message> elements (or messages). Within each message there are groups of segments, which can be nested, so each group can contain other groups, segments, or a mix. Within each segment there can be a mix of composite fields and elements, and composite fields are also made up of elements.

The <message> element will have a mandatory attribute, @name, which is the name of the EDI message. This must match what is found in the file in a UNH/UIH segment for EDIFACT, or in an ST segment for X12. Something like "ORDERS" or "811", for example.

The <message> element should also have a @title attribute, which sets the human-readable title. It can also have a child <description> element, which can contain an arbitrarily long description.

Next should be one or more <group> or <use-segment> elements. They can be mixed, although order does matter. The <use-segment> elements have three attributes:

The Group Element

The <group> element can contain one or more <group> and/or <use-segment> elements. The <group> element allows also an optional <description> element for documentation purposes.

Group elements also have two attributes, @count and @mandatory, which behave as described in <xHyperlink>The Message Element.

The Segment Element

The <segment> element, like messages, has @name and @title attributes. The name should be the name of the segment as it will appear in the EDI document, such as "NAD" or "F6X" or "ID1", for example. It also supports the optional <description> element.

Each <segment> contains one or more elements - either simple elements referred to by the <use-element> construct, or component elements referred to by the <use-composite> construct. The order is very significant. Both <use-element> and <use-composite> take two attributes, @name and @mandatory:

Composite Fields

A <composite> element is like a <segment>, except that it cannot contain <use-composite> elements. It can only contain <use-element> elements. It is used to build up more complicated structures of related information. One use is to hook together a date and a time field, or a date and a date-format and a purpose-of-date.

Composite names usually look like C???, E??? or S???, with the ??? being a three-digit number. While this is true for both X12 and EDIFACT, it is neither a rule nor a requirement.

Elements

An <element> describes the most basic component of an EDI message.

Element names are typically numbers, although X12 has a number of elements in which the first character is the letter 'I' followed by a two-digit number. The name is in the mandatory @name attribute. The @title attribute is a human-readable description of the element's purpose.

The mandatory @type attribute describes the datatype. EDIFACT and X12 both use:

X12 expands on the list of types with these additional types:

The mandatory @maxLength attribute indicates how many characters at most can be in the value. The optional @minLength sets the minimum length. The default for the latter is "0".

Optionally, each element can have its values further constrained by an enumerated list. That list is denoted by a series of <item> elements within the <element>.

Each <item> has a @key attribute which holds the value that would appear in the EDI, and the text content of the <item> element is the description of that value.