X12RecordReader Class (Extends EDIRecordReader)

Overview

The EDIRecordReader is the generalized base class for several derived classes dealing with specific EDI syntaxes. The X12RecordReader has attributes and methods that deal specifically with X12 control segments. The current implementation is hard-coded to support version 004010 of X12. One of the Babel Blaster 1.0 requirements is to enable support for different versions.

Attributes:

• String array for data elements from the ISA Interchange Control Header segment

• String array for data elements from the GS Functional Group Header segment

• String array for data elements from the ST Transaction Set Header segment

• String array for data elements from the GE Functional Group Trailer segment

Methods:

• Constructor

• getControlSegmentElement

• logGE

• logGS

• logIEA

• logISA

• logSE

• logST

• parseGE

• parseGS

• parseIEA

• parseISA

• parseSE

• parseST

Methods

Most of the methods do very little, so with a few exceptions I'll discuss them only in general terms. The constructor method calls the EDIRecordReader constructor, initializes the class member attributes, and exits. The parse methods simply use the language-specific string token routines to parse the Record Buffer and load the class member attributes corresponding to the data elements in the segment. The log methods in this initial implementation display segment information from the appropriate class member attributes. A requirement for later Babel Blaster versions is to enhance these log routines to write output to a data store. We may not use or call all the methods in this version, so some of them exist for future requirements.

Note when examining the code that the text strings in the log methods are hard-coded and not set by parameters. The X12 standards are most commonly used by English speakers. Expressing all of the message text as parameters adds coding complexity. Since these methods will probably be completely rewritten in the next version I didn't think it appropriate.

getControlSegmentElement

Since there are several values that other classes need to retrieve from the header and trailer control segments, we develop a generalized method to retrieve them.

Logic for the X12RecordReader getControlSegmentElement Method

Arguments:
  String Segment ID
  Integer Element position within segment

Returns:
  Status or throws exception

IF Segment ID = "ISA"
  Return ISA[Element position]
ENDIF
IF Segment ID = "GS"
  Return GS[Element position]
ENDIF
IF Segment ID = "GE"
  Return GE[Element position]
ENDIF
IF Segment ID = "ST"
  Return ST[Element position]
ENDIF
IF Segment ID = "SE"
  Return SE[Element position]
ENDIF
Return failure

parseISA

The parseISA method is perhaps the most important method in the X12Record Reader class. It parses the Interchange Control Header segment and loads the base class delimiters based on the parsing results.

Logic for the X12RecordReader parseISA Method

Arguments:
  None

Returns:
  Status or throws exception

Record Buffer <- call language-specific routines to read 106
    bytes from input file stream
Buffer Length <- 106
IF character at Record Buffer index 93 = '-'
  Get one more byte from input file and append to Record Buffer
  Buffer Length <- 107
ENDIF
IF Record Buffer doesn't start with "ISA"
  Return Error for not an ISA segment
ENDIF
Element Separator <- Record Buffer at index 3
Component Separator <- Record Buffer at index
    Buffer Length - 2
Record Terminator1 <- Record Buffer at index
    Buffer Length - 1
Using language-specific string token routines,
    load class attributes ISA01 through ISA16

Once again this method is hard-coded to process version 004010 of X12 since it doesn't look for the Repetition Separator in ISA11.

One other little bit of code deserves comment. It is a common belief that the ISA segment has a fixed length of 106 bytes. Most commercially available EDI translators rely on this assumption. Strictly speaking, the ISA segment doesn't have a fixed length; all the data elements within it do since their minimum length is the same as their maximum length. However, the N0 data type of the ISA13 Interchange Control Number allows a leading minus sign, and X12.6 says that leading minus signs are not counted against maximum length requirements. So, in nearly all circumstances an actual data stream has a control number of 9 bytes. However, I do know of at least one usage (to me, an odd one) where a negative control number can appear and ISA13 is 10 bytes long, yielding a 107-byte ISA segment. It takes only a couple lines of code to support this little quirk, so I thought I would throw it in.