Running the Utility

This section provides instructions for running the X12 to XML utility from the command line.

For Java:

java X12ToXML InputFile.dat OutputDirectory

FileDescriptionDirectory

or

java X12ToXML -h

For C++ on Win32:

X12ToXML InputFile.dat OutputDirectory FileDescriptionDirectory

or

X12ToXML -h

Options follow the parameters except for the help option, which may be specified by itself.

Parameters:

  • First: File specification of the input interchange file (required). The specification may include the full or relative path name. If no path name is specified, the file is assumed to reside in the current working directory. The full file name must be specified, but there is no restriction on the extension name.

  • Second: Path specification of the output directory (required). The directory must exist. Either a relative or an absolute path name may be specified. The trailing directory separator character is optional. A subdirectory for each functional group is created beneath this directory. The subdirectories are named by concatenating the Functional Group Identifier Code in GS01 to the Application Sender's Code in GS02. Output files within these directories are named by appending the Transaction Set Control Number in ST02 to the Root name as specified in the file description document's Grammar Element.

  • Third: Directory path for the file description documents (required). The trailing directory separator character is optional. During processing the utility uses identifying information in the control segments to determine the file description document required to convert the transaction set currently being processed (see the discussion on naming requirements below). These file description documents must reside in this directory path.

Options:

  • -v (Validate): Validate the created XML documents before writing them to disk. The documents are validated against the schema specified in the file description document.

  • -h (Help): Display a help message and exit without further processing.

Naming requirement for file description documents:

File description documents used with this utility must conform to a specific naming convention for their local file names. Their names must be formed by concatenating the following values:

  • GS Application Sender's Code in GS02, followed by a hyphen

  • GS Functional Identifier Code in GS01, followed by a hyphen

  • ST Transaction Set Identifier Code in ST01, followed by a hyphen

  • GS Version/Release in GS08

  • A file type extension of .xml

(Note: Some values of GS Version/Release, such as those sometimes used for TDCC or UCS versions, may not yield valid file names for the operating system.)

As an example of the naming convention, suppose we receive an interchange from Big Box Discount Stores that contains 850 Purchase Orders in version 004010 of X12. Suppose they use BIGBOX for the sender ID in the GS segment. The X12ToXML utility will look in the passed directory for a file description document named:

BIGBOX-PO-850-004010.xml

A version 1.0 Babel Blaster requirement is to remove this naming restriction, but it's not a bad convention to follow anyway.

Naming convention for Functional Acknowledgments:

An XML representation of an X12 997 Functional Acknowledgment is created for each functional group the utility processes. The files for these XML documents are placed in an FA_Out subdirectory of the passed directory. Individual acknowledgments are named by concatenating the following values:

  • GS Application Sender's Code in GS02, followed by a hyphen

  • GS Functional Identifier Code in GS01

  • A file type extension of .xml

For example, the Functional Acknowledgment for Big Box Discount Stores purchase orders on a UNIX system would be named:

FA_Out/BIGBOXBUYER-PO.xml

Restrictions:

Unless otherwise noted, all numeric limits may be modified by changing parameters in the program source and appropriate type definitions in the file description document schemas.

  • An X12 data element may contain a maximum of 1,023 bytes.

  • A segment may be no longer than 16,383 bytes.

  • A maximum of 100 X12 data elements per segment is supported. This includes repeated elements and component data elements within composite data structures.

  • There is no absolute limit on the number of segments; the number is only practically limited by system memory.

  • Each X12 data element must be assigned a unique Element name.

  • XML Element names are limited to 127 characters.

  • Data element grammar Elements must be specified in their segment description Element in ascending order by their position within the segment or composite data structure.

  • Path lengths for complete file specifications are limited to 127 characters.

  • Schema location URIs are limited to 127 characters.

  • A maximum of 999 output XML documents from each functional group is supported.

  • The TA1 Interchange Acknowledgment control segment is not currently supported and will cause a parsing error if encountered. (It is very seldom used. Supporting it is among the Babel Blaster version 1.0 requirements.)

  • GS sender IDs must be valid directory names for the operating system where the utility is run.

  • In the current implementation there can be only one instance in an interchange of a functional group type per GS sender ID. This is due to the naming convention used for output directories.

  • Functional Acknowledgments are created only to indicate acceptance of a functional group. Neither transaction set acceptance nor error reporting are supported.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset