Frequently Asked Questions

I was going through your website to check on any documentation on repeating segments in the 5010 format, and can't find anything. Can you point to me or tell me how to handle this? Example : The EB segment in the 270/271 transaction below, where EB03 has repeated data using the Repetition Separator ‘^’. EB*1**1^33^35^47^86^88^98^AL^MH^UC~
1. The data element object remains a singularity; there is only one data element at the position at the defined position of the segment object.
2. To add data to a repeating data element use the setNext(String) method. The package uses a cursor to know the next position where the data is to be placed.. If you use the set(String) method then the package will always place the data in the first position of the object's array.
3. To get data from a repeating data element use the get(int) method where the int is the position in the array. If you use the get() method you will always get the value in the first position in the array. At the present time when the data object is built an array is created to the size as specified by the occurs value of the element. So if you use the get(int) and there is no data there a null is returned. If the integer is larger than the occurs value for the data element you'll get an array index out of range exception. This is not too effective so in the next release there will be a getRepeatUseCount() that will return the number of positions with valid data in the array.

I imagine we are not your only customer who will need to support 4010 and 5010 at the same time in their application. Do you have a strategy you can share? Specifically, two versions of OBOE.jar, addon.oboe.jar, and x12.envelope.xml.
1. The oboe.jar file is the same; it is not version specific. So there's no difference/conflict there.
2. The oboe.addon.jar file - rename one of the jars. The method names are version specific so there won't be a conflict.
3. Place the envelope file in a version specific subdirectory. The subdirectory must be a child of the directory specified by the xmlPath property. The package uses the I11 field aka ISA12 to get the version and uses the value as the subdirectory name. So the 4010 subdirectory should be named 00401 and 5010 should be named 00501 and the respective envelope rules file in each.

If you look at loop 2300 in 004010X098A1, there are multiple REFs in the loop. If I add a REF, it will over write the old REF. I assume there is some sort of a vector or something. There is no single example on how to do a vector, and then add it to the loop.
This only works for the HIPAA for OBOE package or if you wrote your own rules files with repeating segments
As for the repeating segment be sure to use the other oboe property doPrevalidate and set it to true; such as doPrevalidate=true. I call these segment equivalent segments. What makes them different is their primary id field. A primary id field is the first ID field in the segment that is also a mandatory or required field for the segment. For instance in the REF the primary id field is REF01 (id = 128) Reference Identification Qualifier. If you look (and I hope I'm right) no two segments share the same REF01 id code.
So how to create these segments - use the SegmentContainer method createSegment(String, String)
Segment createSegment(String id, String primaryIDValue)
brief example.
In your HIPAA package there are some xml files that are not directly under the X12 version directory. For example "004010X094A1/request/278.xml" and "004010X094A1/response/278.xml". How should I use the transactionSetFactory to create the transactionSet for these kind of files that are under the "request" or "response" directories ?
The 278 is in two different directories because there are two flavors of the 278.
1. scenario #1 you are making 278 requests and expect to get back a response.
  leave the request 278 file in 004010X094A/request. In your Java code when instantiating the transaction set object use
  TransactionSet ts = TransactionSetFactory.buildTransactionSet("004010X094A/request/278");
  move the 278 file in the response subdirectory to the 004010X094A directory.
2. scenario #2 you are accepting 278 requests and sending back a response.
  move the request 278 file to the 004010X094A directory
  leave the response in 004010X094A/response. In your Java code when instantiating the ts use
  TransactionSet ts = TransactionSetFactory.buildTransactionSet("004010X094A/response/278");
I am using X12 transactions in both 004010 and 005010 versions, and the ISA11 segment of the Interchange control header changed from element I10 to I65, but it seems that oboe uses the same envelope.xml file for both versions, is that right ? When I call getDataElement("I65") in the isa segment it returns null because it's not defined in the xml file. Is there any problem if I keep working with getDataElement("I10") in the 5010 version ?
Get the data element by its position.
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 payers 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 separately, 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 separate 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 Wednesday, August 04, 2010

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.