Frequently Asked Questions

Using your sample code and messages I would like to emulate a client side (jBuilder) process sending a message to a server (WebLogic). Can you provide a way to test this process?
1. We need to generate a "virtual database" for the jBuilder side.
  1. Run SampleX12DocumentHanlder passing the sample.output.840.1 file. Save the output as an xml file. This xml file will emulate a database on the jBuilder side.
2. On the jBuilder side
  1. Take a look at FileConverter.java. We are going to use the logic in...
  2. The call to EDIXMLParser will emulate building a x12 message from the virtual database ( the xml file above).
  3. You'll need to work with the statement to generate the X12 message to be passed to the AS2 sending process. To build the message use the following statement This call generates a String object that is the X12 message.
  4. Take the String object and pass it (somehow) to the AS2 process.
3. On the WebLogic side. This will emulate processing an X12 message.
  1. Using FileConverter again we use the logic in...
  2. After the AS2 receiver gets the message have SampleX12DocumentHandler parse the message.
  3. Again working with the env object use the following call: env.getFormattedText(Envelope.XML_FORMAT). This will generate a String object of the XML version of the message - just like the XML file in first step.
This should emulate the entire process you are trying to test.
I am testing your parser with messages that have missing segments. I assume that a parsing exception is thrown. But the exception is never thrown. Is this a bug?
For your situation the error you're tracking is a message error and not a parsing error. There's a distinction between two errors. A parsing error is thrown when the parser cannot figure out where to go or what to do next. A message error is when the message does not follow the structure of the particular message (see rules file), such as required fields or segments. Here's a subtle difference - UNH segment (in X12 this is the ST segment) while Mandatory but missing in a message would cause a parsing error because the parser cannot figure out where to start parsing the message since the parser needs that initial segment to indicate the start of the message.
I've recently learned of a new way payors are acknowledging files we send to them. They are sending "TA1 files" which are unique in the X12 world as they have no GS/GE or ST/SE. Here is an example: These are part of the X12 standard. I was wondering if OBOE handles these.

Yes.
But if you plan on building the message from a valid xml file you must make a change to the envelope.dtd. Replace the envelope node definition to...
Our client is sending us a text file with a bunch of edi files in it as shown in the attachment. When I ask them to send the individual edi files seperately, they claim this to be the standard way of transmitting edi files. Please let me know if you have come across similar such situation. Also do you have any utility that will read in or seperate the individual files from the single text file?

It is non-standard to send multiple transactions in one file. But since the first rule in business is "the customer is always right" forces this non-standard to be acceptable.
There is a utility class in the package called MessageStripper that will parse out the individual transactions.

The input file had problem with PID and that's why your parser caught it, which is good. I have been evaluating your product and so far it looks good. I would like know some performance metrics especially how much time the parser takes to parse an input file (X12/820) with 1000 transactions (size of the file 1MB).

I don't have a file such as you describe. Below are the results from a large file test:

Calling the static main method in X12DocumentHandler which produces a Validatable XML file.

Command used: java -Xmx300m com.americancoders.edi.x12.X12DocumentHandler \temp\large.edi >out
Note: stack space set to 300m. I just threw up a high number to get around memory overflow exception. Probably could be set lower.

Input File 753120 bytes
1 Functional Group
33 Transaction Set Messages

Output File 16626628 bytes
205919 XML elements

Machine OS CPU RAM JVM Time
1 Win 95 300 Mhz P-III 512K 1.3.1_04 12 mins. 02 secs.
2 Win XP 2.79 Ghz P-4 512M 1.4.1_03 11 secs.

First, let me appreciate the latest version of OBOE- its definitely very user friendly and helpful.
I have a question about the SVC segment in 004010X093A1. The problem i am facing is that while trying to build a 276 transaction, the method - SegmentContainer.java returns a Null Pointer Exception in this part It fails to add the segment to the loop.
The method, being called (addSegment(Segment)), assumes that the passed segment object has all of required data element fields populated.
Assuming the SVC segment is being passed to the method. If you look at the SVC segment the first element, a composite (id="C003") is required and C003's dataelement (id="235") is required also. So prior to calling the method please make sure that the "Product or Service ID Qualifier" is populated with one of the possible values in the idlist table.
A week ago I downloaded the OBOE and I've been tested the libraries with some case of our interest especially ORDERS(EDIFACT) and everything looks good but I have an EDI file (ORDER) with 1.8 MGB and when I execute the line
p2 = new Parser(new File("C:\\edi\\testdata\\test2.edi"));
I got an exception: java.lang.OutOfMemoryError <<no stack trace available>> When I cut the file (it has 147 ORDERS) to 45 ORDERS it works ok, so my question is if I have to limit the size of the EDI file? Is not so common this large file but could appear sometimes.
You have two options.
1. If you want to use the OBOE classes to generate the XML files for you then you will have to increase the JVM (java virtual machine) heap space using the -X options. The following is from the command line Java help output. Refer to you java documentation for more information about using this option.
2. You will have to write a customized EDIFactDocumentHandler (or X12DocumentHandler). Why? The generic DocumentHandler in OBOE stores the entire EDI document. TransactionSets are collected in a Vector object within the Envelope object. So to reduce storage requirements you will need to write your own document handler so that the transaction sets are not stored.
In either case there is a storage consideration regarding String objects. OBOE expects to parse EDI documents from a String object. In the next release (2.5.0) the parser will be able to parse EDI documents from a java.io.Reader object. This will reduce storage requirements considerable - since the OBOE parser and the JVM will not have to deal with a 1.8mg String object.
With OBOE, is it possible to have the OBOE rules files for specific customers, X12 versions or inbound/outboud type files.
For a complete discussion go here.
1. Create a rules file for each trading partner.
2. Place the rules file in a unique subdirectory off of the directory specified in the OBOE.properties variable xmlPath. The subdirectory name must be based on the trading partners ID in the ISA segment.
3. In the OBOE.properties file set the variable searchDirective to searchDirective=RS. For more information on the properties file.
Is it possible to have both the translator and s/mime related modules on the client applet side? I noticed rather slow to response on your demo applet with dial-up 56 k modem which will be connection used by most of our subscriber. Is there any suggestion or workaround?
Yes, you are correct the process of moving the jar files and XML files can be very slow at 56k. It is possible to place the OBOE rules files on the client machine. This is accomplished in two steps.
1. your client code would be a Java application stored on the client machine and not an applet pulled from a web site.
2. in the OBOE.properties files, you would specify the location, on the client machine, of the rules files.
There will be some maintenance issues you will have to address.
I have read docs on OBOE ("The How To's & Why For's of OBOE" as well as Java source files provided in OBOE.zip) but I fear I have misunderstood the aim of OBOE. That's why I ask you for some help. I'm actually working on EDI: my goal is to build an application which is constructed under the following schema: Input: a EDI document (or a EDI/XML document) which represents a message defined in EDIFACT or X12 Output: files ".Java" which correspond to the segments (tags) of the EDI (EDI/XML) file. Example: <Person> <Name> Georges</Name> <Age> 30</Age> <Adress> <Street> London Avenue<Street> <City> New York</City> </Adress> </Person> supposing that these lines represent an EDI/XML file, my application would create 2 EDI/Java files: (or even EDI/Java classes)
Person.java with 3 fields: String Name, Int Age, Address Address
Address.java with 2 fields: String Street, String City
I had understood that OBOE was able to do this. But in Java source files ("EDIXMLParser.java", "TransactionSetFactory.java" ...) I didn't see the building of EDI/Java files.
Have I misunderstood what's OBOE or haven't I well regarded the docs ? Could you help me to understand OBOE better ?
The EDI/XML parser built into OBOE assumes a one-to-one mapping between an XML file and an EDI protocol, X12 or EDIFact or SWIFT or ... Because EDI/XML is not well defined, I wrote an assumption into the program logic. The assumption being EDI/XML files map one-to-one to some type of already defined EDI format. Therefore, in the rules based XML file used by OBOE each element contains an attribute named "xmlTag." This attribute create the correlation between the EDI defined structure or element and an EDI/XML element.
To implement your sample Person.xml file into the XML rules file requires a definition of each element. First let's assume person and address are segments and name, age, street, and city are data elements. The XML rules file would like this: <transactionSet name="People" id="000" revision="000" functionalGroup="" description="A way to describe a database of people" xmlTag="People"> <table section="header"> <loop name="Person" id="PL"> <segment name="Person" id="PL" description="A record of a person" xmlTag="Person" <dataElement name="Name" id="001" type="AN" sequence="01" required="M" xmlTag="Name" description="Name of the person" minLength="30" maxLength="30"/> <dataElement name="Age" id="001" type="N0" sequence="02" required="M" xmlTag="Age" description="Age of the person" minLength="3" maxLength="3"/> </segment> <segment name="Address" id="AD" description="An address of a person" xmlTag="Address"> <dataElement name="Street" id="003" type="AN" sequence="01" required="M" xmlTag="Street" description="Street of the person" minLength="30" maxLength="30"/> <dataElement name="CityState" id="004" type="AN" sequence="02" required="M" xmlTag="City" description="City of the person" minLength="30" maxLength="30"/> </segment> </loop> </table> </trasnactionSet> Once the XML Rules parser has parsed the above file and produce the dynamic classes, the EDIXMLParser would use the rules classes to parse your XML file.
Do note that there are 3 parsers in the OBOE package:
1. The XML Rules Parser builds the rules and dynamic classes for the next two parsers:
2. The EDI Parser parses an EDI Document based on the structure defined by the XML rules based engine
3. The EDIXMLParser classes parses EDI/XML files on the structure and xmlTag definitions defined by the XML rules based engine
I'm wondering what/how the X12DocumentHandler.java class is used?
Your samples, SampleX12DocumentHandler and others, directly implement EDIDocumentHandler. What does X12DocumentHandler do? Where might I find some references regarding how to use it?
The DocumentHandler class is used in conjunction with the DocumentParser classes. Basically when using the DocumentParser class you register a handler. The parser object will call the handler object when certain parsing events happen - start of segment, end of segment, start of transaction set, end of transaction set, ... via prespecified method names (as defined in the EDIDocumentHandler Interface). Upon the method call it is then up to the registered DocumentHandler to do what it wants to do when the event occurs. Most of the time the "start" triggers are not used. But the "end" triggers are since the component they are getting triggered by will have useful (read populated) information - e.g. segments, transaction sets...
BTW, in the SampleX12DocumentHandler in the main method, at the bottom, you can see the creating of a parser, creating of a handler, registering the handler. And then above in the sample program you can see that it only does anything useful in the endTransactionSet method . All other trigger event methods don't do anything.
A typical run (using your sample 840 file) takes about 4.8 to 4.9 secs on a PIII 500, 512Meg of Ram. My time excluded the read and write to file IO. It only counts the time your parser is created as well as translate the doc.
Why it is taking so long is the reading in of the rules file. Two pieces of logic are used to improve speed. First, the package, after parsing the rules file, stores it in a Java external format. If you look in the directory where the xml file resides, there should be an 840.object file. This is the rules file in the externalizable format. So in the next instantiation of the package instead of parsing the XML rules file again the package simply reads in the object file. This improves rules file load time marginally. Second, and as of the 230 release, the TransactionSetFactory class will store rules objects in memory after the initial load for reuse. This logic is only effective for on-going processes, when the package's address space is not lost. So with the 230 release if you have a continually running application you will see dramatic improvement in rules file load times... after the initial load.
Here are results from a customer beta testing out the 230 package. The "File Size" is the size of the incoming EDI document. The larger files contain documents with repeating transaction sets. The beta application was running as a server so the OBOE package didn't lose its address space and therefore the rules objects remained resident for reuse.

Frequently Asked Questions

Updated Thursday, April 10, 2008

Publish or Perish

Input File	753120 bytes
	1 Functional Group
	33 Transaction Set Messages
Output File	16626628 bytes
	205919 XML elements

Machine	OS	CPU	RAM	JVM	Time
1	Win 95	300 Mhz P-III	512K	1.3.1_04	12 mins. 02 secs.
2	Win XP	2.79 Ghz P-4	512M	1.4.1_03	11 secs.