# Datenübernahme in XML Struktur



## spaghetti (15. Feb 2012)

Moin zusammen,
ich muss (strukturell unterschiedliche) Datensätze aus einer einzigen DB2-Tabelle abziehen und in eine XML Struktur übernehmen. Für das XML Marshalling habe ich mir per JaxB eine "Marshallingklasse" generiert. Die daten werden (momentan) per JDBC ausgelesen.

Ich habe in der Table 5 Felder, im 5. Feld stehen Rohdaten die aber inhaltlich nochmal nach fester Breite getrennt sind und im Ziel-XML Elemente oder Attribute darstellen.

Durch die anderen 4 "einfach gefüllten" Felder lässt sich die Struktur ableiten, anhand der die "Rohdaten" aus dem 5. Feld in Strings gesplittet werden können.

Es könnte also z.B. im 5. Feld "123456.99€" stehen und anhand der vorderen 4 Felder erkenne ich, das es sich um eine Rechnungsposition handelt, die aus einer 1-stelligen Positionsnummer, einer 4-stelligen Artikelnummer sowie dem 3-stelligen Preis besteht. 
Mein ergebnis soll also nach JaxB Marshalling so aussehen:

Also in <Position Nummer=1><Artikel =2345>6.99€</Artikel></Position>
Genauso könnte in Feld 5 aber auch ein Datensatz mit der Kundenadresse stehen, der eine eigene Struktur hat und mit in die selbe Ziel-XML Datei übernommen werden muss.

Momentan gibt es für jede dieser Strukturen eine eigene Klasse, die ihre "Feldbreiten" im SQL-Resultset sowie ihr Zielattribut im JaxB-Objekt kennt und ein Interface implementiert, dass eine Methode bietet die als Parameter eine Referenz auf das JaxB Objekt erhält und "ihre" Informationen dort hinzufügt. Die Interfacemethode "setXMLData(JaxBObj meinObj)" führt also "meinObj.addPositionsNummer(this.posNr)" usw. aus). 

Eine Schleife läuft durch das Resultset, lässt sich von einer Factory das zum jeweiligen Datensatz gehörende Verarbeitungsobjekt geben und dieses schreibt seine Informationen ins JaxB Objekt. 
Ist das Resultset durchlaufen wird gemarshalled und ich habe meine XML Datei.

Das ganze funktioniert und ist auch von der Performance sicht, aber aus OOP-Sicht und in Hinblick auf Erweiterbarkeit wird mir schlecht. Das ganze ist viel zu hart verdrahtet und ich müsste für ein weiteres Zieldokument (z.B. Lieferschein) pro Datenstruktur (im Falle der Rechnung sind das schon ca. 20 verschiedene) eine Klasse mit den einzelnen Feldern und Feldbreiten erzeugen und diese auch noch der Factory bekannt machen.

Ich hoffe das war einigermaßen verständlich, ansonsten gerne weiter nachfragen. Wäre klasse, wenn jemand ne elegantere Lösung vorschlagen kann!


----------



## Wildcard (20. Feb 2012)

Hört sich für mich nach einem EDI Format an?
Gibt es Regelmäßigkeiten die man ausnutzen kann? Sind es zB eine überschaubare Anzahl an Attributen und strukturell brauchst du immer nur Feldlängen?
Wenn sich solche Eigenschaften ausarbeiten lassen (eine halbwegs generische Lösung also grundsätzlich vorstellbar ist), dann liese sich sicherlich einiges mit EMF (statt Jaxb) und Annotations im Ecore erreichen.


----------



## spaghetti (21. Feb 2012)

Moin,
ja geht schon in die Richtung soll allerdings eher eine Standardlösung für verschiedene EDI (XML, kein EDIFACT o.Ä.) Formate werden. Dahinter könnten sich dann auch unterschiedliche Formulare mit verschiedenen Attributen verstecken und dadurch brauche ich neben der Feldlänge eben auch eine Möglichkeit die Felder zu Mappen (passiert aktuell über den Feldnamen). 
Die Klassen für das Mapping zw. den Quelldatensätzen mit fester Breite und den Java Feldern kann ich weitestgehend aus den Datenstrukturen generieren, die für die ursprüngliche Befüllung der Tabelle verwendet werden. Der Ansatz mit den Annotations klingt da aber ziemlich cool, um ein Mapping zwischen diesen Java-"Strukturklassen" und der Marshallingklasse (Sorry, mir fallen hier beim Besten Willen keine präziseren Bezeichnungen ein) zu generieren.
Ich mache mich da mal weiter auf die Suche, wenn du oder jemand anders da noch ne Idee zu hat bin ich weiter für jede Hilfe dankbar.


----------



## Wildcard (21. Feb 2012)

EMF ist im Prinzip eine bessere Version von Jaxb. Du erzeugst dort (aus einer XSD, annotierten Java Interfaces, UML, oder sonstigem) ein ecore das dein Modell beschreibt. Das Ecore enthält die Klassen (EClasses) und deren Features (EAttributes und EReferences). Aus diesem ecore kann dann Java Code generiert werden. An jedes Strukturelement kannst du im Ecore dann zusätzliche Annotations hängen die dir zur Laufzeit zur Verfügung stehen.
In solche EAnnotations könntest du dann die benötigten Mapping Regeln hinterlegen um den String aufteilen und zuweisen zu können.
Auf die Art lassen sich dann neue Klassen und deren Zuordnungsvorschrift komfortabel in einem Baumeditor einpflegen, ohne Code schreiben zu müssen.


----------

