UN EDIFACT Contrl Message
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
UN EDIFACT Contrl Message
by Tim Sparg
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi all I’ve been experimenting with Smooks for a little bit now, parsing CUSRES and CUSDEC type messages with very little issue (just outputting the resulting xml to a file…) I’m now trying to parse a UN EDIFACT Contrl Message (UNH+00000003500001+CONTRL:D:3:UN+CONTRL' ) but I can’t find it in your prepackaged binding jars (d03a-binding-1-4 and d03b-binding-1-4). Am I looking in the wrong place, or is there no binding defined for a Contrl Message? Thanks Tim |
|
|
Re: UN EDIFACT Contrl Message
by Thomas K.
::
Rate this Message:
Hi Tim,
i came across this problem too and have a great interest in finding a solution here too. As far as i know CONTRL is not a plain UN/EDIFACT Format and is a "dialect?" that is defined in ISO 9735. So there is no default binding provided i think. I am new to EDI data processing too so my knowledge is more on a novice level. I don't know if there exist prepared maven bindings and mappings for ISO 9735 d3 "directory". Is there someone who has a solution or a description how to read / generate CONTRL messages with smooks in a convenient way?
|
|
|
Re: UN EDIFACT Contrl Message
by TomFennelly
::
Rate this Message:
Hi guys.
The EDIFACT artifacts that we publish are based purely on the UN/EDIFACT specifications. If CONTRL is defined outside the UN/EDIFACT specs, then the artifacts that we publish will not contain CONTRL. If you study how we generate these artifacts (ECT and EJC tools), you'll see that most of the code is generic. There's a UN/EDIFACT specification reader implementation of the a specification reader interface... after that it's all generic code. So if ISO 9735 uses a different format for specifying it's message structures, then it's possible that you could implement a specification reader for that. Regards, T. On 21/12/2011 16:44, Thomas K. wrote: > Hi Tim, > > i came across this problem too and have a great interest in finding a > solution here too. > > As far as i know CONTRL is not a plain UN/EDIFACT Format and is a "dialect?" > that is defined in ISO 9735. So there is no default binding provided i > think. > > I am new to EDI data processing too so my knowledge is more on a novice > level. > > I don't know if there exist prepared maven bindings and mappings for ISO > 9735 d3 "directory". > > Is there someone who has a solution or a description how to read / generate > CONTRL messages > with smooks in a convenient way? > > > > Tim Sparg wrote: >> ... >> >> I'm now trying to parse a UN EDIFACT Contrl Message >> (UNH+00000003500001+CONTRL:D:3:UN+CONTRL' ) but I can't find it in your >> prepackaged binding jars (d03a-binding-1-4 and d03b-binding-1-4). >> >> Am I looking in the wrong place, or is there no binding defined for a >> Contrl Message? >> ... >> >> >> --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: UN EDIFACT Contrl Message
by Thomas K.
::
Rate this Message:
Hi.
I am a bit confused. CONTRL (syntax and service report message) follows UN/EDIFACT syntax specifications. It is defined by the Joint Syntax Working Group but is not contained in any directory published on unce but seems to be associated to a "service message type directory". See this link for Syntax definition 4.1 (is also defined in syntax definition 3 but this is not supported by smooks isn't it?) Link to CONTRL jswg definition Beside the known message segements UNA,UNB, UNT and UNZ it only defines an additional segment UCI for syntactically acknowledging the reception of a EDI message and is located between reception of an EDI message and sending APERAK message back to sender. Regards, Thomas
|
|
|
Re: UN EDIFACT Contrl Message
by TomFennelly
::
Rate this Message:
Sorry about any confusion.... if the segment is not defined in the
directories published on unce, then the artifacts we publish will not have it. That's the only point I was trying to make. T. On 22/12/2011 14:56, Thomas K. wrote: > Hi. > > I am a bit confused. CONTRL (syntax and service report message) follows > UN/EDIFACT syntax specifications. > It is defined by the Joint Syntax Working Group but is not contained in any > directory published on unce > but seems to be associated to a "service message type directory". > > See this link for Syntax definition 4.1 (is also defined in syntax > definition 3 but this is not supported by smooks isn't it?) > http://www.gefeg.com/jswg/v41/mt/ml1.htm Link to CONTRL jswg definition > > Beside the known message segements UNA,UNB, UNT and UNZ it only defines an > additional > segment UCI for syntactically acknowledging the reception of a EDI message > and is located > between reception of an EDI message and sending APERAK message back to > sender. > > > Regards, > > Thomas > > > TomFennelly wrote: >> Hi guys. >> >> The EDIFACT artifacts that we publish are based purely on the UN/EDIFACT >> specifications. If CONTRL is defined outside the UN/EDIFACT specs, then >> the artifacts that we publish will not contain CONTRL. If you study how >> we generate these artifacts (ECT and EJC tools), you'll see that most of >> the code is generic. There's a UN/EDIFACT specification reader >> implementation of the a specification reader interface... after that >> it's all generic code. So if ISO 9735 uses a different format for >> specifying it's message structures, then it's possible that you could >> implement a specification reader for that. >> >> Regards, >> >> T. >> >> >> On 21/12/2011 16:44, Thomas K. wrote: >>> Hi Tim, >>> >>> i came across this problem too and have a great interest in finding a >>> solution here too. >>> >>> As far as i know CONTRL is not a plain UN/EDIFACT Format and is a >>> "dialect?" >>> that is defined in ISO 9735. So there is no default binding provided i >>> think. >>> >>> I am new to EDI data processing too so my knowledge is more on a novice >>> level. >>> >>> I don't know if there exist prepared maven bindings and mappings for ISO >>> 9735 d3 "directory". >>> >>> Is there someone who has a solution or a description how to read / >>> generate >>> CONTRL messages >>> with smooks in a convenient way? >>> >>> >>> >>> Tim Sparg wrote: >>>> ... >>>> >>>> I'm now trying to parse a UN EDIFACT Contrl Message >>>> (UNH+00000003500001+CONTRL:D:3:UN+CONTRL' ) but I can't find it in your >>>> prepackaged binding jars (d03a-binding-1-4 and d03b-binding-1-4). >>>> >>>> Am I looking in the wrong place, or is there no binding defined for a >>>> Contrl Message? >>>> ... >>>> >>>> >>>> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >> --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: UN EDIFACT Contrl Message
by Thomas K.
::
Rate this Message:
sorry.
you did not confuse me. :-) The way of defining a service message like CONTRL, (and AUTACK and KEYMAN which are defined by jswg too) and not publishing it in a directory by unce confuses me. This looks like a non-consistent way of offering definition data to me. Of course the artifacts generated from the directories can't contain the message definitions. Maybe i find some time to get deeper in this field of data definitions and see if i find a suitable solution.
|
|
|
Re: UN EDIFACT Contrl Message
by hajue
() ::
Rate this Message:
directory provided at http://www.unece.org/trade/untdid/down_index.htm. But I could build such a directory zip by downloading the specifications made by the Joint Syntax Working Group (JSWG) from http://www.gefeg.com/jswg/. After some modifications the ECT plugin (described in http://blog.smooks.org/2010/06/28/processing-unedifact-message-interchanges/) was able to process my ZIP and build a mapping JAR. Please find attached the resulting d3-mapping-1.5.jar to parse the CONTRL message. To configure this mapping along with e.g. the d96b mapping you could code: Smooks smooks = new Smooks();
smooks.setReaderConfig(new UNEdifactReaderConfigurator("urn:org.milyn.edi.unedifact:d3-mapping:*,urn:org.milyn.edi.unedifact:d96b-mapping:*"));And here are the steps to reproduce my approach... Please note: The new specification file names must fulfill the RE pattern "^([A-Z]+)_([A-Z])\\.([0-9]+[A-Z])$" defined in class org.milyn.ect.formats.unedifact.UnEdifactSpecificationReader which means that the correct file names CONTRL_D.3, TRCD.3, etc. will not be recognised by ECT. My workaround is to add a "V" as final character: CONTRL_D.3V, TRCD.3V, etc. But as a side effect wrong namespace names have been generated which is fixed with step 9. (1.) download from http://www.gefeg.com/jswg/v3/data/v3.html (+) v3-smed.zip (Service message type directory) (+) v3-ssed.zip (Service segment directory) (+) v3-sced.zip (Service composite data element directory) (+) v3-sded.zip (Service simple data element directory) (+) v3-cross.zip (Cross references; not used) download from http://www.gefeg.com/jswg/v3/data/v3_docs.htm (+) v3-contrl.zip (PDF documentation) (2.) convert v3-smed.zip\Contrl.s3 => TRMD.zip\CONTRL_D.3V (+) amend missing version info "Version : D" (+) amend missing release info "Release : 3" (3.) convert v3-sced.zip\Sced.s3 => TRCD.zip\TRCD.3V v3-sced.zip\Scedi1.s3 => TRCD.zip\TRCDI1.3V v3-sced.zip\Scedi2.s3 => TRCD.zip\TRCDI2.3V (+) rename data element tags from "S..." to "C..." ("S001" => "C001", ..., "S011" => "C011") (+) remove all headlines "POS TAG Name S Repr. Notes" (+) remove all trailing blanks from the field definition lines (no characters may follow the type declarations!) (4.) convert v3-ssed.zip\Ssed.s3 => TRSD.zip\TRSD.3V v3-ssed.zip\Ssedi1.s3 => TRSD.zip\TRSDI1.3V v3-ssed.zip\Ssedi2.s3 => TRSD.zip\TRSDI2.3V (+) rename data element tags "S..." to "C..." ("S001" => "C001", ..., "S011" => "C011") (+) remove all headlines "POS TAG Name S Repr. Notes" (+) remark: this archive seems not to be used by ECT !? (5.) convert v3-sded.zip\Sded.s3 => TRED.zip\TRED.3V v3-sded.zip\Sdedi1.s3 => TRED.zip\TREDI1.3V v3-sded.zip\Sdedi2.s3 => TRED.zip\TREDI2.3V (+) no additional changes required (6.) create from scratch => UNSL.zip\UNSL.3V (+) refer to http://www.gefeg.com/jswg/v3/data/v3-contrl.htm section "5.5 Code Lists" (+) copy code list for 0013 from (e.g.) UNSL.98B (and remove unused codes) (+) copy code lists for 0083 and 0085 from (e.g.) UNSL.96B (and remove unused codes) (+) remark: this archive seems not to be used by ECT !? (7.) create directory archive d3-contrl.zip by adding the files (+) TRCD.zip (+) TRED.zip (+) TRMD.zip (+) TRSD.zip (+) UNSL.zip (8.) run ECT (target "package") on d3-contrl.zip to build the mapping lib d3-mapping-1.5.jar (+) pom.xml (9.) after packaging of d3-mapping-1.5.jar: don't forget to replace the wrong 'd3v' namespace component by 'd3' in these files: (+) .\fragment.xml (+) .\org_milyn_edi_unedifact\d3-mapping\1_5\common.xsd (+) .\org_milyn_edi_unedifact\d3-mapping\1_5\contrl.xsd (+) .\org_milyn_edi_unedifact\d3-mapping\1_5\__modelset_definitions.xml (+) .\META-INF\services\org\smooks\edi\mapping-model.lst |
|
|
Re: UN EDIFACT Contrl Message
by TomFennelly
::
Rate this Message:
Hey.... thanks for the information.
Regards, Tom. On 23/03/2012 11:01, hajue wrote: > Yes, unfortunately the version 3 syntax and service report message CONTRL is > not part of any UN/EDIFACT > directory provided at http://www.unece.org/trade/untdid/down_index.htm. > > But I could build such a directory zip by downloading the specifications > made by the Joint Syntax > Working Group (JSWG) from http://www.gefeg.com/jswg/. After some > modifications the ECT plugin > (described in > http://blog.smooks.org/2010/06/28/processing-unedifact-message-interchanges/) > was > able to process my ZIP and build a mapping JAR. > > Please find attached the resulting > http://old.nabble.com/file/p33544649/d3-mapping-1.5.jar d3-mapping-1.5.jar > to parse the CONTRL message. > > To configure this mapping along with e.g. the d96b mapping you could code: > > <pre> > Smooks smooks = new Smooks(); > smooks.setReaderConfig(new > UNEdifactReaderConfigurator("urn:org.milyn.edi.unedifact:d3-mapping:*,urn:org.milyn.edi.unedifact:d96b-mapping:*")); > </pre> > > And here are the steps to reproduce my approach... > > Please note: > The new specification file names must fulfill the RE pattern > "^([A-Z]+)_([A-Z])\\.([0-9]+[A-Z])$" > defined in class > org.milyn.ect.formats.unedifact.UnEdifactSpecificationReader which means > that the > correct file names CONTRL_D.3, TRCD.3, etc. will not be recognised by ECT. > My workaround is to add > a "V" as final character: CONTRL_D.3V, TRCD.3V, etc. But as a side effect > wrong namespace names > have been generated which is fixed with step 9. > > (1.) download from http://www.gefeg.com/jswg/v3/data/v3.html > (+) v3-smed.zip (Service message type directory) > (+) v3-ssed.zip (Service segment directory) > (+) v3-sced.zip (Service composite data element directory) > (+) v3-sded.zip (Service simple data element directory) > (+) v3-cross.zip (Cross references; not used) > download from http://www.gefeg.com/jswg/v3/data/v3_docs.htm > (+) v3-contrl.zip (PDF documentation) > > (2.) convert v3-smed.zip\Contrl.s3 => TRMD.zip\CONTRL_D.3V > (+) amend missing version info "Version : D" > (+) amend missing release info "Release : 3" > > (3.) convert v3-sced.zip\Sced.s3 => TRCD.zip\TRCD.3V > v3-sced.zip\Scedi1.s3 => TRCD.zip\TRCDI1.3V > v3-sced.zip\Scedi2.s3 => TRCD.zip\TRCDI2.3V > (+) rename data element tags from "S..." to "C..." ("S001" => "C001", > ..., "S011" => "C011") > (+) remove all headlines "POS TAG Name > S Repr. Notes" > (+) remove all trailing blanks from the field definition lines (no > characters may follow the type declarations!) > > (4.) convert v3-ssed.zip\Ssed.s3 => TRSD.zip\TRSD.3V > v3-ssed.zip\Ssedi1.s3 => TRSD.zip\TRSDI1.3V > v3-ssed.zip\Ssedi2.s3 => TRSD.zip\TRSDI2.3V > (+) rename data element tags "S..." to "C..." ("S001" => "C001", ..., > "S011" => "C011") > (+) remove all headlines "POS TAG Name > S Repr. Notes" > (+) remark: this archive seems not to be used by ECT !? > > (5.) convert v3-sded.zip\Sded.s3 => TRED.zip\TRED.3V > v3-sded.zip\Sdedi1.s3 => TRED.zip\TREDI1.3V > v3-sded.zip\Sdedi2.s3 => TRED.zip\TREDI2.3V > (+) no additional changes required > > (6.) create from scratch => UNSL.zip\UNSL.3V > (+) refer to http://www.gefeg.com/jswg/v3/data/v3-contrl.htm section > "5.5 Code Lists" > (+) copy code list for 0013 from (e.g.) UNSL.98B (and remove unused > codes) > (+) copy code lists for 0083 and 0085 from (e.g.) UNSL.96B (and remove > unused codes) > (+) remark: this archive seems not to be used by ECT !? > > (7.) create directory archive d3-contrl.zip by adding the files > (+) TRCD.zip > (+) TRED.zip > (+) TRMD.zip > (+) TRSD.zip > (+) UNSL.zip > > (8.) run ECT (target "package") on d3-contrl.zip to build the mapping lib > d3-mapping-1.5.jar > (+) http://old.nabble.com/file/p33544649/pom.xml pom.xml > > (9.) after packaging of d3-mapping-1.5.jar: > don't forget to replace the wrong 'd3v' namespace component by 'd3' in > these files: > (+) .\fragment.xml > (+) .\org_milyn_edi_unedifact\d3-mapping\1_5\common.xsd > (+) .\org_milyn_edi_unedifact\d3-mapping\1_5\contrl.xsd > (+) .\org_milyn_edi_unedifact\d3-mapping\1_5\__modelset_definitions.xml > (+) .\META-INF\services\org\smooks\edi\mapping-model.lst > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free embeddable forum powered by Nabble | Forum Help |
