[JAVA] pseudo-EDIFACT parser schrijven

[Ozzie]

Voor een projectje probeer ik een parser te schrijven die een AIR-bestand kan inlezen. Dit is een bestand wat wordt aangemaakt door Amadeus. Een veel gebruikt software pakket bij reisbureaus en luchtvaartmaatschappijen. Het is een reserveringssysteem voor o.a. vliegtickets en in zo'n AIR bestand staat alle informatie (en meer) die ook op een vliegticket staat.

code:

AIR-BLK205#7A##208#1900018128#GW3219280#001001
AMD 1900076428              
GW3219279#GW3219280
MUC1A 3L6Y24008#0202#HAGN22101#57210296#HAGN22101#57210296#HAGN22101#57210296#####################IR TLKX7 
A-IRAN AIR#IR 0965
B-TTP/ITR-EMLA
C-7906/ AASU-AASU-I-0
D-090518#090519#090519
G-X  ##AMSAMS#
H-001#003OAMS#AMSTERDAM        #IKA#TEHRAN KHOMEINI  #IR    0764 V V 09JUL1530 2330 09JUL#OK02#S #0#AB6###20K###ET#0530 #N#2532#  
H-003#004OIKA#TEHRAN KHOMEINI  #AMS#AMSTERDAM        #IR    0765 Q Q 08OCT0415 0850 08OCT#OK02#B #0#AB6###20K###ET#0605 #N#2532#  
K-FEUR584.00     ############EUR631.44     ###   
KFTF# EUR14.80    YQ AD# EUR14.52    RN DP# EUR12.94    CJ SO# EUR5.18     IR AE##########################
L-
M-V83H91         #Q83H91         
N-NUC377.77#358.85
O-XX31DEC#XX09OCT
Q-AMS IR THR377.77IR AMS358.85NUC736.62END ROE0.792803
I-001#01ACHTERNAAM/VOORNAAM MR##APAMS 31 70 1234567 - NAAM REISBUREAU - A//[e-mail]//[e-mail]##
T-K001-1234567890
FEIR NOT END#S3-4#P1-2
FM*P*9#S3-4#P1-2
FPCASH
FVIR
TKOK18MAY/HAGN22101
I-002#02TACHTERNAAM/VOORNAAM MRS##APAMS 31 70 1234567 - NAAM REISBUREAU - A//[e-mail]//[e-mail]##
T-K001-1234567890
FEIR NOT END#S3-4#P1-2
FM*P*9#S3-4#P1-2
FPCASH
FVIR
TKOK18MAY/HAGN22101
ENDX

Van de meeste waarden in het bestand weet ik ook gewoon wat ze betekenen. Als je het bestand en de daadwerkelijke boeking in Amadeus naast elkaar ziet is daar al erg veel uit af te lezen. Zo staat in dit bestand de ticketnummer, vertrek data. vertrek plaats, aankomst plaats, ticket prijs en belastingen en nog wat informatie.

Ik probeer dus een parser te schrijven voor zulk soort bestanden maar voor mijn gevoel ben ik heel erg inefficiënt bezig. Als ik op internet zoek naar informatie over parsers schrijven kan ik niet echt wat nuttigs vinden dus ik hoop eigenlijk dat iemand hier wat websites of boeken kent waar ik wat meer informatie kan vinden. Met de parser moet het dus mogelijk zijn om een bestand in te lezen en dan om te zetten naar een normale data structuur, eventueel een eigen object waarin gewoon alle waarden gezet kunnen worden.

Ik kan niets aanpassen aan het formaat wat Amadeus eruit gooit, behalve dan het instellen van een ander teken ipv een #. Helaas word er geen xml-formaat ondersteund of iets dergelijks.

Iemand die me een zet in de goede richting kan geven?

Edit: Owhja, ze noemen het zelf pseudo-EDIFACT. Is gebaseerd op de EDIFACT standaard maar volgens mij op een compleet eigen wijze geïmplementeerd ofzo.

[eamelink]

Smooks is een open source pakket waarmee je EDIFACT bestanden kan lezen. Wij hebben er niet zo'n goede ervaringen mee en we moeten wel EDIFACT bestanden parsen, dus mijn collega is momenteel een EDIFACT parsergenerator aan het schrijven, die vanuit de EDIFACT standaard parsers maakt voor alle berichtsoorten.

Hij gebruikt daar geen Java voor maar Scala. Scala heeft een fraaie ingebouwde parser combinator library, waarmee je dit waarschijnlijk goed kunt oplossen. Scala compileert naar standaard JVM bytecode en is compatible met Java, dus als je in Scala zo'n parser zou schrijven, kun je hem gewoon gebruiken vanuit je Java code als ware het een normale Java library.

Het beste boek over Scala is geschreven door de maker van Scala, Martin Odersky, en heet "Programming in Scala". Hierin staat ook een hoofdstuk over combinator parsing. Martin Odersky heeft ook aan de wieg gestaan van de standaard Java compiler

[pedorus]

Het ziet er allemaal vrij eenvoudig uit. Mocht er geen kant-en-klare oplossing zijn dan zou ik gewoon een Scanner gebruiken?

[Ozzie]

Hmm wist echt niet dat er zo'n Scanner standaard in het framework zit. Ga daar eens even in duiken.

Maar sowieso ga ik ook even naar Smooks kijken. Zo te zien kan je daar heel veel handige dingen mee doen. Komen vast in de toekomst nog wel een keer van pas. Het probleem is alleen denk dat dit bericht niet echt EDIFACT is dus ben bang dat smooks er niks van kan maken.

Scala leren zou wel leuk zijn maar denk niet dat ik daar tijd voor heb Zal het boek wel even op mijn wanted-lijstje zetten. Verjaardag komt er weer aan

[wouwie]

I would use jflex to do the parsing/scanning to tokens (see http://jflex.de/) and on top of that use cup for syntax checking/getting everything to objects. (see http://www2.cs.tum.edu/projects/cup/).

These are not the most easy to use frameworks, but they are used a lot in large projects.

[Ozzie]

Met die scanner kom ik er toch niet uit. Het lukt me daarmee wel om heel makkelijk het bericht op te splitsen (op newline of #) maar hoe kan ik de data die daar uit komt op een handige manier gebruiken?
Ik verzand dan al snel in een hele hoop if-statements om te kijken of een bepaalde code op die regel in het bestand staat.

Dat moet toch handiger kunnen?

[pedorus]

Zo te zien zijn er eerst 4 regels startdata, dan A-Q aan beginletters gescheiden door "-" en dan I,T,5 regels per persoon, gevolgd door ENDX. Aangezien de boel gewoon op volgorde staat lijkt het me dat je geen IF-jes nodig hebt, hooguit iets als findWithinHorizon als je dingen wil skippen?

Post anders eens wat code war je die if-jes gebruikt.

[wouwie]

Ozzie schreef op dinsdag 07 februari 2012 @ 18:53:
Ik verzand dan al snel in een hele hoop if-statements om te kijken of een bepaalde code op die regel in het bestand staat.

Dat moet toch handiger kunnen?

Wel, daar dient cup nu net voor. Je kan het zelfs gebruiken om bij herkende stukken bepaalde methoden op te roepen.

[Kwistnix]

Ik ken geen gratis oplossing die EDI berichten helpt verwerken, maar heb wel ervaring met de data converters en xquery oplossing van DataDirect. Weet niet of dat geschikt is voor jouw situatie, maar wellicht kan je er naar kijken. De data converters bevatten strikte definities van EDI-standaarden, welke omgezet worden naar een XML structuur. Eventueel kan je ook SEF (standard exchange format) definities aan de converter voeren, zodat je allerlei afwijkingen op de standaard kan verwerken. Dat is helaas meer regel dan uitzondering in de praktijk. Tegen de gegenereerde XML output kan je in principe iedere XML verwerkingstrategie aangooien. Mijn ervaring met XQuery is dat het redelijk goed werkt, vooral in het geval van berichtvulling die van de standaard afwijkt. Moet ik er wel bij zeggen dat XQuery in dit geval een manier was om van de door DataDirect geXMLiseerde EDI naar een genormaliseerde XML structuur te gaan die door het systeem verwerkt werd. Klinkt wellicht erg inefficiënt, maar werkte wel aardig.

[Hydra]

Het kost je waarschijnlijk meer tijd om een bestaande parser uit te zoeken en te snappen dan dat het je kost om gewoon de regels te splitten ('#' is een separator kennelijk) en op basis daarvan een simpele parser te maken. De structuur ziet er enorm simpel uit.