EdiSax issues/improvements offered by Dave Degroff

Is there a way at present, to be able:
a) To parse the ISA segment - because it contains the sub-element separator which should be considered as meta-data and not data.
b) To change the segment, element and sub-element separators after a Smooks object is created from an xml config file.

Kishore... please direct questions to the user mailing list.

This issue needs to be broken out into separate individual issues.

I would like to comment the 3th point feature is mandatory and will increase the number of EDI formats possible to process.

Thanks again Ivan.

So at the moment, this would be possible with the EDIParser + Smooks, but not with the EDIParser on it's own. The EDIParser is quite "dumb" and so the event stream generated by the segments in that example would be the same for the 2 "Provider" types. The "intelligence" would be implemented in the Smooks components:

1. If you were binding the data to a Java Object model: You can use Expression based bindings to bind the data to different models (or different parts of the same model) depending on that "85" or "87" value.
2. If you want an XML/whatever data stream to be generated, with those collections named appropriately, you could use something like a Groovy scripted fragment processor to rename the fragment based on the "85" or "87" value. Example: http://milyn.codehaus.org/Smooks+Example+-+groovy.

What would you think of those options?

Hi Tom,

First of all, thanks for the "dumb" EDI parser I like when simple things are kept simple. I'm more interested in the EDI parser independent of other "context" solutions. In the short amount of time after I did comment, I was able to come up with a solution for the 3th point. Here is my proposal:

1. Extend segcode attribute of segment element in the configuration to accept specifications like these:

segcode="NM1*85"

and

segcode="NM1*87"

Where * separator can be different, depending on the specified field delimiter.

Then modify the the existing parser line 298:

			if(!currentSegmentFields[0].equals(expectedSegment.getSegcode())) {

to

			if ( !equalSegment( currentSegmentFields, expectedSegment.segcode ) )

Here is the code for equalSegment function:

		/**
		 * Return true if current segment equals segcode.
		 * @param currentSegment Current segment fields.
		 * @param segcode Segment code to match.
		 */
		private boolean equalSegment( String[] currentSegment, string segcode )
		{
			bool result = false;

			String[] segcodeFields = StringUtils.splitPreserveAllTokens(segcode, mappingModel.getDelimiters().getField());

			int fieldsCount = segcodeFields.length;
			if ( currentSegment.Length > fieldsCount )
			{
				result = true;

				for ( int fieldIndex = 0; fieldIndex < fieldsCount; fieldIndex++ )
				{
					String segcodeField = segcodeFields[fieldIndex];
					if ( segcodeField == "" )
					{	// Field not specified. Skip it.
						continue;
					}

					if ( !currentSegment[fieldIndex].Equals( segcodeField ) )
					{	// Current segment doesn't equal segcode.
						result = false;
						break;
					}
				}
			}

			return result;
		}

In this way the parser will be able to handle a requirement like in the 3th point. Tom, let me know what do you think about the proposal?

So how would that work if the field you wanted to "switch" on was not the first field in the segment?

I wonder how it would work if you had an optional XPath like condition variable. So you could define something like (see the "where" attribute):

<medi:segment segcode="NM1" where="field4/a=85" xmltag="xxxxx">
	<medi:field xmltag="field1" />
	<medi:field xmltag="field2" />
	<medi:field xmltag="field3" />
	<medi:field xmltag="field4">
		<medi:component xmltag="a" />
		<medi:component xmltag="b" />
	</medi:field>
	<medi:field xmltag="field5" />
</medi:segment>

Tom,

If you take a closer look at equalSegment function you will see that in case the delimited value is empty, it will skip it. So let's say you want to check for the second value instead. You will specify it like this:

segcode="NM1**85"

Now it will check for the second delimited value to be 85.

I was thinking about more extensive solution like the one you are proposing. The question is whether it is worth at this point, if we don't have a good business case for it? I know for sure that the solution I suggest will work in my particular case and it is not very intrusive to the current source code. A second benefit is that the specification is very similar to the incoming input data and it somehow feels natural.

Ah OK... I missed that Ivan, thanks.

Yeah, this does seem nice and clean. I prefer it to the "where" attribute. We can do this

Added support for matching segments using a regex pattern. See MILYN-220.