How To Use OBOE 
Open Business Objects for EDI From a Java Programmer's Perpective

Version 3.5.7

Author: Joe McVerry

Table Of Contents

1. Introduction
   
   1. Why Should You Use OBOE?
   2. Purpose Of This Document
2. What Is OBOE?
   
   1. Other Functionality
   2. Why The XML Rules Engine?
3. An Overview Of Classes
   
   EDI Envelope Hierarchy
   1. Envelope - Abstractly And Concretely
   2. Functional Groups
   3. About Dynamic And Static Classes
   4. Transaction Set Its Template And Factory Classes
   5. Tables and Templates
   6. Loops and Templates
   7. Segments and Templates
   8. Composite Data Elements and Templates
   9. Data Elements and Templates
   10. Other Classes
   11. Utility And Exception Classes
   12. External Classes You Need To Get On Your Own
4. EDI Structure Rules Are Defined in XML Files.
   1. The XML Rules
   2. The DTD File:TransactionSetRules.dtd
5. Installation
   1. Where To Place OBOE.properties File
   2. Where To Place The XML And DTD Files
   3. Transaction Set Rules DTD Description (Basic Edition)
   4. Transaction Set Rules DTD Description (Extended Edition)
   5. Validating Methods.
      
   6. The IDLISTxxx XML Files
   7. The IDListClass Class
   8. The XML File
   9. The OBOE Properties File
      1. The OBOE Properties Description
      2. Where To Define The OBOE Properties File
6. Programming
   
   1. Parsing An EDI Document
      Using the Properties File To Specify Specific Rules Files
      1. Using A Non Specific Rules File
      2. Using A Version Specific Rules File
      3. Using A Sender Specific Rules File
      4. Using A Receiver/Vendor/Production Specific Rules File
   2. Building An EDI Document
      1. Building An Envelope
      2. Adding Transaction Sets
         1. Method 1 - Building From A Local File Containing XML Rules
         2. Method 2 - Building from a transactionset object for a specific trading partner
         3. Method 3 - Building from a transactionset object for a specific version and production
         4. Method 4 - Building From A URL, File With XML Rules Are Not Local
         5. Using In Memory Stored Transactions Sets
      3. Instantiating The XML Parser
         1. Local File Example:
         2. Remote File Example:
         3. Returning A Transactionset
         4. How The Transaction Set Is Built
      4. Creating A Table
      5. Loops
      6. Segments
         
         1. Creating A Segment
         2. Getting To A Segment
      7. Data Elements
         
         1. Creating A Data Element
         2. Flavors Of Data Elements
         3. Getting To A Data Element
         4. Setting Data Element Values
         5. Assigning Default Value From The Rules File
         6. Getting Data Element Values
      8. Creating A Transaction Set XML File
         1. Requesting Other Formats.
   3. Parsing An XML/EDI Document
      1. The XML Rules And Document Files
         1. Transactionsets And Table Parsing
         2. Tables, Loops And Segment Parsing
         3. Loop Parsing
         4. Segment Parsing
         5. Segment And Data Element Parsing
      2. Creating A Transaction Set XML File
      3. Pulling Data From Segments And Data Elements
         1. Getting To The Data
   4. The OBOE Mail Classes
      1. Transmitting An EDI Document
      2. Receiving An EDI Document
      3. Other Considerations For An EDI Document
   5. The OBOE FTP Class
      1. FTP Transmission
      2. Receiving By FTP
   6. Sample Source Programs
      
      1. viewsamples And viewsample
      2. EDImailcall
7. Other Source Programs
   
8. Other Sources Of Information
   
9. Acknowledgments
   
10. Appendices
    

Introduction

OBOE - Open Business Objects for EDI is a collection of Java classes that build and translate EDI documents. By using OBOE, it becomes easier for you to create a powerful and flexible method to handle a variety of different data formats and translate them into EDI/XML documents or legacy EDI definitions. By using an XML-based rules engine to build and parse EDI documents, OBOE allows you the flexibility to respond to EDI/XML standards as they are developed. OBOE allows you to use existing components that are already widely available on the Internet for your Java Development Kit, XML Parser and more. OBOE also allows you to transmit and receive EDI documents by Internet Mail (Extended Edition only)

If you need to create an EDI program that can accept EDI data from other systems that use a different EDI format, or if you need to translate data from an EDI legacy system, OBOE is perfect for you. With OBOE, it is possible to have the OBOE rules files for specific customers, X12 versions or inbound/outbound type files.

The classes you need to run OBOE are available free for a 30 day trial period from this site for download (you will have to download some additional classes yourself). You can also arrange for American Coders, Ltd. to provide expert support for your OBOE development efforts.

This document shows how your Java programs and OBOE can be used to build EDI objects. The document explains how to write programs that interact with these objects through the package method calls.

The OBOE package contains several source sample programs. You should read these programs to learn how write OBOE based Java applications and applets. Reading and using the sample programs is the best way to become familiar with the OBOE System.

The sample programs won't teach you Java, or how to write a Java application or applet. The sample programs won't teach EDI implementations. Nor will the programs explain the inner workings of the OBOE classes.

The samples provide a guide on how to write to the OBOE API.

The document explains Open Business Objects for EDI and its inner workings.

Remember, the document does not show how you to write Java programs nor teach EDI. You should be very familiar with the Java programming language and EDI standards prior to using OBOE.

Return to Contents

What Is OBOE?

OBOE uses an XML parser for a rules based engine to create EDI Objects. The EDI objects, in turn, are used to build and parse an EDI document or an EDI/XML file.

OBOE XML files fuels the rules based engine. These XML files define the structure of EDI objects through a base set of classes. These rules files and the Java classes are based on legacy EDI Definitions, primarily ANSI/X12 and UN/EDIFact. OBOE can also be used to build EDI/XML objects. And just as OBOE can translate legacy EDI document, these new EDI/XML objects can translate EDI/XML documents into the EDI objects. Which, by the way, can be used to create legacy EDI objects.

Again, OBOE's primary use for XML is to build Java EDI Objects. The XML files map to existing EDI structures or definitions.

As the OBOE XML rules file is parsed and depending on the type of object, the OBOE runtime package creates literally hundreds of objects of two flavors, fixed and template. The fixed objects created are the TransactionSet object and from one to three Table objects. All other objects - loops, segments, composites and data elements are first defined through the template objects. As an EDI document is parsed the template objects are used to create the fixed objects that they represent.

When an incoming EDI document is passed to the TransactionSet object the  template objects contain methods to parse the document. Using the parsed text and the template characteristics a dynamic EDI object is built and attached to its parent object, an Envelope. So, for example, a template object representing a "name" data element, such as an X12 93 data element or an EDIFact C080, is used to create a DataElement object of the same type. Just as the template data element is attached to its parent segment, the DataElement object will become part of the same parent segment or composite. So, TemplateLoops are used to create Loops, TemplateSegments are used to create Segments; TemplateComposites are used to create CompositeDEs and TemplateDEs are used to create DataElements. So, in turn, Loop and Segment objects are attached to a table object or its parent Loop object by its template. Composite data element objects are attached to its parent segment object by its template. And data element objects are attached to a its parent segment or composite data element object by its template. This all occurs while the core objects parse an EDI document.

When you need to build an EDI object, your program will request that the dynamic objects be built through calls to the objects' parent object and, indirectly, to its template (or fixed) objects. Your program calls methods in the parent object of the to-be-built object. The parent object uses the same template objects, mentioned above, to build the requested object. For instance, if a segment needs a particular data element, a method call is made to the segment object. The method creates the data element object. The segment method knows about all the template data element objects that are part of its hierarchy. The segment method in turn calls a method of the appropriate data element template object. The template data element creates the fixed data element object. The fixed data element object is returned to the requesting segment method.

Available in the Extended Edition version is another OBOE function is to transmit and receive EDI Documents using Internet Mail. The How To and the Why For is discussed later.

What's not implemented in OBOE is an external database interface for storing and retrieving EDI documents. When I designed the system, I knew that most EDI systems have been around for a long time. For you folks that have to deal with legacy systems, there are plenty of available hooks in OBOE to provide an interface between your legacy systems and OBOE. How? Well, most of these systems are using SQL databases, such as MySQL, DB2 and Oracle. By using Java's JDBC classes, connecting to these legacy databases access is easy and already available. For those who don't have a legacy systems to deal with, the design allows you build a OBOE application to your own specifications without requiring OBOE to bind to a specific data store.

Early in the release of the product, several people noted how some computer systems use rule engines. Not knowing how to write a rules engine, I went ahead and designed the system so that each EDI object had its own Java class source file -- such as a Purchase Order Object, a Request Validation segment, and a Message Direction Code data element. This created a rather large and cumbersome system of several-hundred source programs. Which, in turn, became very difficult to maintain. So, it was time for a rules engine. But what tool to use, a database, a flat file,... ahhh XML. It was an easy choice. XML is a great data definition tool and several web sites offered Java classes for parsing XML files. (see Apache, IBM, SUN, and Microsoft)

Little did I realize that others were doing the same. But I went ahead a designed a DTD and XML file to map to EDI. Thus a XML file is used to create the OBOE objects, from the same objects designed in earlier OBOE releases. These OBOE objects form the basis of the static classes, as mentioned above.

As it turns out, the best thing about XML is that it is so easy to use.

Return to Contents

Overview of Classes

This abstract class represents an entire EDI Document Object.
This class represents a X12 EDI Envelope Object.
This class represents an EDIFact EDI Envelope Object.

This class is a container class for an EDI transmission. It contains 3 primary objects -- Interchange Header segment, Functional Group container and a Interchange Trailer. Note outside the U.S. EDIFact does not require functional groups. The OBOE application still utilizes the concept even though it does not require Functional Group Headers or Trailer segments. Functional groups are stored in a Vector of the Envelope class. An envelope may contain several functional groups. The Envelope class provides methods to add, get and remove functional groups from the Vector as well as return the number of functional groups in the Envelope.

The Envelope class can also contain several other optional segments depending on whether it represents an X12 document or an EDIFact document.

The primary or super Envelope class is actually an abstract class used by the X12Envelope and EDIFactEnvelope classes. The Envelope class contains several attributes related to the internal representation of a message, such as EDI type, delimiters, etc.

X12Envelope Attributes

Name	Type	Purpose
ISA_Interchange_Control_Header	Segment	ISA segment
ISB_Grade_of_Service_Request	Segment	ISB segment (optional)
IEA_Deferred_Delivery_Request	Segment	IEA segment (optional)
InterchangeAcknowledgments	Vector of Segments	TA1 segments (optional)
ISE_Interchange_Control_Trailer	Segment	ISE Segment

Name	Type	Purpose
UNA_Service_String_Advice	Segment	UNA segment (optional)
UNB_Interchange_Header	Segment	UNB segment
UNZ_Interchange_Trailer	Segment	UNZ Segment

The FunctionalGroup object is a carry over from the X12 functional group concept which is grouping Transaction Sets into common groups. The FunctionalGroup object acts as a container for TransactionSet objects by storing them in a Vector object. The class provides methods to add, get and remove transaction sets from the Vector as well as get a count of the number of transaction sets within the functional group.

Functional groups are not required for EDIFact EDI. The OBOE EDIFact Envelope object utilizes this concept even though it does not required. If your application is EDIFact and your trading partners do not use functional groups then your programs can simply ignore the functional Group Headers or Trailer segments.

protected Segment header;
protected Vector transactionSets = new Vector();
protected Segment trailer;

As mentioned above OBOE creates two sets of classes -- dynamic (the real EDI objects) and static (the template classes).

Template Classes - The Static Classes

Template Classes are the internal representation of the XML rules file. Therefor they represent the structure of an EDI object. The OBOE EDI Objects (the dynamic class) objects are built by calls to the template classes. EDI data is not stored in the template classes. Also a template class know nothing about the status or content of its static counterpart.

The template classes extend java.IO.Serializable or java.IO.Externalizable. Serialization allows the template classes to be stored locally. Storing the classes on the local hard drive allows the package to reuse the objects and thereby reduce the need to reparse the XML rules file. The package date checks both the XML rules file and its serialized object file. If the XML rules file is newer then the package will reparse the XML file and recreate the serialized file. Otherwise the package will read the serialized file to create the template objects.

EDI Object Classes - The Dynamic Classes

The dynamic classes are the internal representation of an EDI document. The document parser or an OBOE program interacts with these classes to store and retrieve document data. The dynamic classes contain references to their static counterpart

This class represents an entire EDI Transaction Object
This class is the base for each transaction contained within an Envelope. It contains the EDI objects: tables, loops, segments, composite data elements, and data elements. The TransactionSet is also represented by its template class. The TemplateTransactionSet class is a container for the sub template classes starting with the TemplateTable class. The TransactionSet class' two primary functions are to parse and get. The parse method is used to parse an incoming EDI document. Get and getFormattedText methods are use to build an EDI document. To access children objects, such as segments, calls are made through the table object's methods.

Note: The OBOE design requires at least one table object within a TransactionSet. If a particular EDI document is defined without a table, meaning only segments, then the XML rule file for the TransactionSet must define a Header table.

TransactionSetFactory

This class builds a preliminary version of all the EDI objects based on an XML file that it parses.

This class reads in an OBOE XML rules file to build EDI objects. Processing is simple. As each element is read from the rules file a template object is built. If an object is contained within another such as a segment within a loop or a data element within a segment, a template object is created and assigned to the owning template object.

This class extends the SAX2 DefaultHandler parser class. The SAX2 parser is an event driven XML file parser.

The TemplateTransaction set class contains all the template objects needed for a particular transaction set. This class, like the other template classes, is an extension of java.io.serializable. To reduce processing time of reading and parsing the XML rules file every time a transaction set needs to be built the factory class does two things.

1. The template file is stored in an external format. The TransactionSetFactory searches the local directory structure for rules files based on its Transaction set ID and an XML prefix. (for instance 840.xml or ORDERS.xml.) Then the factory class searches for an associated object file with the same filename prefix but with the filename suffix of "object" (for instance 840.object or ORDERS.object.) If the object file is not found the factory class will parse the OBOE rules file and then store the OBOE EDI objects for that particular transaction set into an object file. Thereby allowing the class to simply read in the rules and removing the parsing step the next time the transaction set class is requested to be built.
2. While the application is active, the TransactionSetFactory stores the parsed template objects in a Hashtable object. When subsequent calls are made for a rules file that has already been parsed or loaded the factory simply passes the in-memory stored object. This one step alone reduces file input processing time considerably.

Tables are containers for loops and segments. Tables provide access methods to the loops and segments it holds. Likewise Template Tables are containers for template loops and template segments. TemplateTable provides access methods to the template loops and template segments it holds.

As mentioned above, if an EDI document does not define a table you must define a header table in the XML TransactionSet. The document's segments to this table.

Classes that dynamically represent the 3 EDI tables, header, details, summary.

Classes that contain TemplateSegments and statically represent the dynamic tables.

Loop

A class that represents an EDI Loop. Loops are containers for other segments and other loops.

TemplateLoop

Class represents a fixed or static version of an EDI Loop. Used by the TransactionSetFactory class.

Constructed when the XML rules file is read. This class is used to build the dynamic loop class it represents. As a loop and segment container it also contains child TemplateLoops and TemplateSegments.

ITemplateLoopContainer

An interface for describing methods for storing and accessing TemplateSegments. This interface defines TemplateLoops containership

Segment

A class that represents an EDI segment. Segments are containers for composites and data elements.

TemplateSegment

Class represents a fixed or static version of an EDI segment. Used by the TransactionSetFactory class.

Constructed when the XML rules file is read. This class is used to build the dynamic segment class it represents. Like its dynamic counter part which contain composite and DataElement objects the TemplateSegment object may contain template composites and template data elements.

ISegmentContainer

An interface for defining how Segments are stored.

This interface defines segment containership

ITemplateSegmentContainer

An interface for describing methods for storing and accessing TemplateSegments. This interface defines TemplateSegments containership

CompositeDE

A class to represent an EDI Composite Data Element. A CompositeDE is EDI's way of defining a special type of Data Element container.

A class to statically represent an EDI Composite Data Element. This class is used to create its composite counterpart.

This is a collection of classes used to describe the various data element types defined in EDI. This super class provides for all the externalized methods used by the subordinate classes, DateDE, CharDE...

DataElement

A class to describe all EDI Data Elements. Used as a super class to specific data element types.

TemplateDE

A class to provide preliminary definitions of a data element. Constructed with XML data this class provides no real purpose to the general application. It is used to build its data element counterpart.

IDataElementContainer

An interface describing methods for storing data elements.

This interface defines segment containership

Character Data Elements

A class for EDI Character Data Elements.

Binary Data Elements

A class for EDI Binary Data Elements.

Date Data Elements

A class for EDI Date Data Elements.

ID Data Elements

A class for EDI ID Data Elements.

Numeric Data Elements

A class for EDI Numeric Data Elements.

Real Data Elements

A class for EDI Real Numeric Data Elements

Time Data Elements

A class for EDI Time Data Elements.

ValidXMLEDIParser

This class builds an EDI object from a valid XML file. The OBOE application can create output to represent an EDI object is several formats. One format is in a valid XML format which is validated against by the DTD file. Your application uses this class to parse the XML/EDI file into EDI objects.

This class builds an EDI object from a well formed XML file. Unlike its valid XML counter part a well formed XML file is not validated against a DTD. Your application uses this class to parse the XML/EDI file into EDI objects.

DocumentParser

This abstract class describes how EDI objects are extracted from an EDI Document.

DocumentHandler

This interface describes how the parser class notifies EDI object events when parsing EDI objects from an EDI Document.

X12DocumentParser

This class extracts X12 EDI objects from an EDI Document.

X12DocumentHandler

This class stores X12 EDI objects from an EDI Document in an envelope container. When working with X12 documents you would work with class most of the time.

EDIFactDocumentParser

This class extracts EDIFact EDI objects from an EDI Document.

EDIFactDocumentHandler

This class stores EDIFact EDI objects from an EDI Document in an envelope container. When working with UN/EDIFACT documents you would work with class most of the time.

Tokenizer

Class with methods to break down an EDI Document into tokens.

DocumentErrors

This class is used to track errors while parsing an incoming EDI object. Also it is used in conjunction with the base classes validate method to track errors with an EDI object and the rules defined for that object.

Utility classes to format date and time fields.

Also contains an XML normalizer method. You use this method to normalize a String representing XML data. Normalization is the process of replacing XML specific markers, such as '>' with text '>'

Byte Conversion Utility This class provides static methods to convert bytes to base64 characters. It is only used by the mail classes.

OBOE Exception Class Exception class for throwing OBOE errors. This class extends the Java RuntimeException class. By using runtime exceptions if an exception is uncaught the class allows a failing program to continue.

OBOE is built using components from other Java package providers. To build code using the OBOE classes you must visit several other web sites to get their classes. I don't provide these external classes with the OBOE product because some of the other package owners do not provide a general license agreement to distribute their development environment. Specifically you will need a Java Developer Kit (JDK) Java2 (for the Swing classes), the Java Mail package (Extended Edition only), the Java Activation Framework package (Extended Editoin only), the Java Cryptography Extensions (Extended Editoin only), and a XML parser.

JDK

To compile the OBOE files you will need a Java Developer's Toolkit. If you plan on using the mail classes supported by OBOE you need the Java2 environment. The mail viewer requires Swing and mail encryption requires the Java Cryptography Extensions of Java2.

There are several JDKs on the market. Some free, some you have to pay for.

Java Mail

To use the OBOE Extended Edition, let alone compile the Extended Edition source files, you will need the Java mail jar file from Sun. It is available at http://java.sun.com/products/javam ail/ these classes provide access to SMTP mail server, for outgoing mail, and to IMAP mail server, for incoming mail. If you need access to a POP3 incoming mail server you need to download the POP3 package class at the same site.

Java Activation Framework (JAF)

One of the requirements for the Java Mail package is another package from Sun called Java Activation Framework or JAF. It is available at http://www.javasoft.com/be ans/glasgow/jaf.html The primary purpose of this class to act as an agent between a MIME specified document and a Java application or class.

Java Cryptography Extension (JCE)

One of the requirements for the Java Mail package is another package from Sun called Java Cryptography Extension. It is available at http://www.javasoft.com/products/jce . The primary purpose of this class to support encryption of mail documents. This package may be supplemented by another vendor's cryptography extension.

XML Parser

SAX - Simple API

OBOE uses the SAX (Simple API for XML) API (application programming interface) XML parser. By using the TransactionSet DTD and a validating SAX parser your TransactionSet XML file is validated prior to being loaded into OBOE objects.

Why Not DOM?

I didn't choose DOM for two reasons. First, DOM returns a tree structure of your document. Since the OBOE already builds a tree structure of an EDI document This is redundant. Second, SAX has a faster start-up. Since SAX starts returning document objects immediately the objects created by OBOE would share this immediacy also.

Return to Contents

EDI Structure Rules Are Defined in XML Files.

As you have read elsewhere in this document OBOE uses XML files to define the structure and rules of all EDI objects.

The XML Rules

Each element object in an OBOE XML file represents an EDI object. These elements map one-for-one. As OBOE receives an XML element from the SAX parser it creates a Java object. Some objects, such as transaction sets, are used through-out the life of the EDI object life, others use, such as TemplateSegments, are created to create a real or usable object when needed, in this case a segment.

Since a DTD file is used with the validating parser a lot of up-front editing is reduced for the OBOE processor. For instance, the validating parser insures that a data element is correctly related to a transaction set.

The DTD File:TransactionSetRules.dtd

One DTD file is used to define one complete EDI transaction set. The file describes the transaction set, from one to three tables, the loops and segments within tables and other segments, composite data elements and data elements. The description generally includes a name, id, description and xmltag attribute. Some of the elements may have other attributes.

Since the 2.5.0 release a second rules file, envelope.dtd, was introduced. This rules file describes the format of envelopes by the structure of the envelope segments (e.g. ISA or UNB), functional groups and its segments. Do note that the OBOE package still uses the static class definitions for envelopes and the other envelope structures you can create a envelope rules file in case the OBOE definitions do not meet your needs.

Since OBOE is available in two packages, there are two distinct DTD files. While the structure is similar the Extended Edition contains several nodes not found in the Basic Edition.

Installation

The parser looks for the rules files in a location as specified by the xmlPath in the OBOE.properties file. Refer to

Transaction Set Rules DTD Description (Basic Edition)

Transaction Set Rules DTD Description (Extended Edition)

Validation Methods

How To Write A Validation Method

Which Object To Associated The Method With.

What If I Need More Than One Method For An Object.

Example

The OBOE data element objects IDDE use a secondary XML rules file called IDList files. These files provide a complete list of used ID and Value pairs associated with the IDDE object. For instance in X12, the ID element 353 defines all the Purpose Code for transaction sets. The name/value pair for 353 are the transaction sets id and the description for the transaction set. In the idlist file there would be an entry for each purpose code
EXAMPLE

     	<idlist>
     	<idcode>00</idcode>
     	<idvalue>Original</idvalue>
     	<idcode>01</idcode>
     	<idvalue>Cancellation</idvalue>
     	<idcode>02</idcode>
     	<idvalue>Add</idvalue>
     	</idlist>

In the rules file you may use one of three optional nodes to specify the name/value pairs.

			/* assume document passed in as a java.io.Reader object inRDR */
			com.americancoders.edi.x12.X12DocumentHandler dh1 =
           					new com.americancoders.edi.x12.X12DocumentHandler(inRDR);
			X12Envelope env = dh1.getEnvelope();
			Segment interchangeHeader =
				env.getInterchange_Header();
			for (int fgCursor = 0; fgCursor < env.getFunctionalGroupCount(); fgCursor++)
				 { /* don't forget to work with the functional group header and trailer */
					FunctionalGroup fg = env.getFunctionalGroup(fgCursor);
					for (int tsCursor = 0; tsCursor < fg.getTransactionSetCount(); tsCursor++)
						{
							TransactionSet ts = fg.getTransactionSet(tsCursor);
							Table tbl = ts.getHeaderTable();
							Segment seg = tbl.getSegment("BEG");
							DataElement de = seg.getDataElement(0);
						}
				}
			Segment interchangeHeader = env.getInterchange_Header();
		

		/* example to create an envelope with a non-specific 840 transaction set.*/
		X12Envelope xenv = new X12Envelope();
			xenv.setInterchange_Header(Interchange_Control_Header.getInstance());
		FunctionalGroup fg = X12FunctionalGroup.getInstance();
		xenv.addFunctionalGroup(fg);
		fg.addTransactionSet(TransactionSetFactory.buildTransactionSet("840"))
		xenv.setInterchange_Trailer(Interchange_Control_Trailer.getInstance());
		

		/* example to create an envelope with a partner specific 840 transaction set.
		  "R" - look in subdirectroy specified by receiver parameter
		  null - ignore version parameter
		  "0900098" - receiver parameter - look in this subdirectory
		  null - ignore sender parameter
		  null - ignore test/production parameter
		  */
		X12Envelope xenv = new X12Envelope();
		xenv.setInProcess();
		xenv.setInterchange_Header(Interchange_Control_Header.getInstance());
		FunctionalGroup fg = X12FunctionalGroup.getInstance();
		xenv.addFunctionalGroup(fg);
		fg.addTransactionSet(TransactionSetFactory.buildTransactionSet("840","R",null,"0900098",null,null))
		xenv.setInterchange_Trailer(Interchange_Control_Trailer.getInstance());
		

		TransactionSetFactory.buildTransactionSet("840","S","TESTERONE",null,null,null))
		

			Properties properties = new Properties();
			FileInputStream inStream = new FileInputStream("OBOE.properties");
			properties.load(inStream);
			String path = properties.getProperty("xmlPath");
			org.xml.sax.Parser parser = new
					com.ibm.xml.parsers.ValidatingSAXParser();
			TransactionSetFactory me = new TransactionSetFactory(parser);
			parser.setDocumentHandler(me);
			parser.parse(path + inTSID + ".XML");
		

			Properties properties = new Properties();
			URL url = new URL(inURL + inTSID + ".XML");
			System.out.println("URL is " + url );
			org.xml.sax.Parser parser = new com.ibm.xml.parsers.ValidatingSAXParser();
			TransactionSetFactory me = new TransactionSetFactory(parser);
			parser.setDocumentHandler(me);
			parser.parse(url.toString());
		

			Loop currentLoop =
		  		new Loop((TemplateLoop) templateLoopVector.elementAt(i));
		

			TemplateLoop tsg = (TemplateLoop) templateLoopVector.elementAt(i);
			Loop currentLoop = tsg.createLoop("AK9");
		

			headerTable.addLoop(currentLoop);
		

			Segment currentSegment =
		  		new Segment((TemplateSegment) templateSegmentVector.elementAt(i));
		

			TemplateSegment tsg = (TemplateSegment) templateSegmentVector.elementAt(i);
			Segment currentSegment = tsg.createSegment("AK9");
		

			headerTable.addSegment(currentSegment);
		

			TransactionSet transactionSet = TransactionSetFactory.buildTransactionSet("840");
			Table currentTable = transactionSet.getHeaderTable();
			Segment currentSegment = currentTable.createSegment("ST");
			currentTable.addSegment(currentSegment);
			DataElement currentDE = (DataElement) currentSegment.buildDE(0);
			System.out.println(currentDE);
			currentDE.set("840");
			currentDE = (DataElement) currentSegment.buildDE(1);
		

			method: public void set(int field, int value)
		

			method: public void set(int field, int value)
		

		method: public int get(int field)

			java.util.Calendar.YEAR java.util.Calendar.MONTH java.util.Calendar.DAY_OF_MONTH

			

			method: public int get(int field)
			java.util.Calendar.HOUR java.util.Calendar.MINUTE java.util.Calendar.SECOND

			

<?xml encoding="ISO-8859-1"?>
<!-- OBOE release 3.0.0 -->
<!-- used by ValidXMLEDIParse -->
<!ELEMENT envelope (segment+, functionalgroup+, segment+)>
<!ATTLIST envelope
	format (X12 | EDIFact) #REQUIRED
>
<!ELEMENT functionalgroup (segment?, transactionset+, segment?)>
<!ELEMENT transactionset (table+)>
<!ATTLIST transactionset
	code CDATA #REQUIRED
	name CDATA #IMPLIED
>
<!ELEMENT table (loop?, segment?)*>
<!ATTLIST table
	section CDATA #REQUIRED
>
<!ELEMENT loop (loop?, segment?)*>
<!ATTLIST loop
	code CDATA #REQUIRED
	name CDATA #IMPLIED
>
<!ELEMENT segment (composite?, element?)*>
<!ATTLIST segment
	code CDATA #REQUIRED
	name CDATA #IMPLIED
>
<!ELEMENT composite (element)+>
<!ATTLIST composite
	code CDATA #REQUIRED
	name CDATA #IMPLIED
>
<!ELEMENT element (#PCDATA | value)*>
<!ATTLIST element
	code CDATA #REQUIRED
	name CDATA #IMPLIED
>
<!ELEMENT value (#PCDATA)>
<!ATTLIST value
	description CDATA #IMPLIED
>

			<!ATTLIST TransactionSet id CDATA #REQUIRED>

			<TransactionSet name="Request_for_Quotation" id="840"
				revision="!!!"
				functionalGroup=""
				description="Request_for_Quotation">
				<table section="header">...
					</table>
				<table section="detail">...
					</table>
				<table section="summary">...
					</table>
			</TransactionSet>
		

			<table section="header"></font>
				<segment name="Transaction Set Header"
					id="ST"
					description="Transaction Set Header"
					...
				</segment>
				<segment name="Beginning Segment for Request For Quotation"
					id="BQT" description="Beginning Segment for Request For Quotation"
					...
				</segment>
			</table>
		

        	<loop  name="Identification Reference" id="N9"
        	  occurs="1000"
        	  required='O'
        	  xmlTag="IdentificationReference">
        	    <segment name="Identification Reference" id="N9"
				</segment>
			</loop>
		

        	<loop  name="Identification Reference" id="N9"
        	  occurs="1000"
        	  required='O'
        	  xmlTag="IdentificationReference">
        	    <segment name="Identification Reference" id="N9"
				</segment>
			</loop>