View Full Version : XML Beschreibung
CL? ;-)
... bei REXX hätte ich ja noch "eher als mit RPG" geantwortet. Mal ohne Fez: von den CAMT Formaten gibt es wohl eine XSD, da würde ich mal über Java und XOM aufsetzen und das dann halt in meine RPG Anwendung integrieren, falls ich es da brauche...
D*B
Zuerst mal: Lassen Sie sich nicht von diesen "ordentliche Programmiersprache" und dämlichen Vergleichen verwirren. Die Umstellung von den DTAUS/MTxxx-Dateien auf SEPA-,CAMT-XML-Dateien machen derzeit alle, und wer weder zu viel Zeit noch Spieltrieb hat, macht es in seiner Programmierwelt. Es mag Gründe geben, diese irgendwann zu wechseln / zu erweitern, aber diese Kleinigkeit ist keiner. Sie programmieren mit RPG wie ein sehr großer Teil IBMi-Anwender, damit kann man das problemlos machen, und es werden keine Ihrer komplexen Programme werden, sondern einfache.
Unser Zeitaufwand war 1 Woche für alles: Überweisungsdateien, Abbuchungsdateien erstellen, Kontoauszüge importieren.
Wie importiert man Kontoauszüge?
XML ist nichts weiter als eine Datei mit 1 Zeile, die riesig breit ist. Damit ist klar: die Datei kommt ins IFS und wird zeichenweise gelesen. Bordmittel, isi RPG-Programming.
Drin ist, was immer drin war (evtl. sind mehrere dieser Kapitel erlaubt):
- Kopfsatz
- 1...x Transaktionen
- Endesatz
Weil wir auf der IBMi so eine nützliche Datenbank haben, machen wir uns eine Datei mit einer String-Spalte in Breite eines XML-Transaktionsteiles und ein paar Key- und Statusfelder, z.B. Timestamp oder lfd. Vorgangsnummer. Da hinein zerhacken wir den XML-String aus der IFS-Datei: 1 Satz für den Kopfsatz, je einer pro Transaktion und einer für den Endesatz. Das Zerhacken geschieht durch Finden der entsprechenden XML-Tags, isi RPG-Programming.
Der eigentliche Import ins Zielsystem geschieht in einem getrenntem Programm. Gründe:
1) Getrennte Entwicklung und Tests möglich.
2) Die Datei aus Schritt 1 kommt ins an die IBMi angeschlossene revisionssichere Archivsystem, damit ist die gesetzliche Archivierungspflicht für Geschäfts-/Zahlungsverkehrsdaten erfüllt.
Der Import ist einfach: Schleife in der Datei über einen Vorgang, benötigte Felder aus dem Kopfsatz merken, jeder Transaktionssatz löst einen Schreibvorgang im internen System aus, wenn Endesatz, dann Log schreiben und tschüss.
Das XML-Parsing (toller Name, banaler Vorgang), erledigt eine Tabellenvariable mit 2 Spalten: XMLTAG, XMLWERT, die für jeden Dateisatz neu gefüllt wird. Der Parser ist nur ein Zeichenleser und Stringbastler: von < bis > ist der XMLTAG, danach XMLWERT bis < / gefunden wird.
Pfeifen Sie auf XSDs und XML-interne Metadaten. Sie wissen, welche XMLTAGs sie erwarten, und was als Wert dahinter stehen muss, woraus sich der Vailidierer ergibt. Wenn XMLWERT nicht valide: Ab ins Fehlerlog.
Alles in allem ein denkbar einfacher Vorgang für jeden gestandenen RPG-Programmierer. Consultants und Tool-Hausierer blasen nur viel Dampf rein.
Danke,
ähnlich hat unser ältester Entwickler auch argumentiert.
Alles, bis zu einem best. Punkt in einen String einlesen, auswerten und den String nachladen(oder so ähnlich).
Dachte nur, das es (grade weil ja fast jeder CAMT verarbeitet) das es da was einfacheres mit den öfter erwähnten Bordmitteln im RPG gibt. Nur hat bei uns damit noch keiner gearbeitet.
DiBe
Prinzipiell stimme ich zu, dass man "bloß wegen XML" nicht gleich auf eine andere Sprache umsteigen muss.
Aber das Spitze-Klammern-Suchen sollte man wirklich XML-SAX überlassen.
Denn der kann mit Kommentaren, Referenzen, CDATA
usw. auch umgehen, was viele selbstgebastelte Lösungen schlicht vergessen, weil es in den Beispiel-XMLs nicht vorkam.
Warum sollte man ein perfekt rundes Rad nicht benutzen und stattdessen ein eckiges nehmen?
Keine Angst, es bleibt noch genug über zum Selbermachen.
camouflage
16-04-14, 17:09
... oder wenn V7R1 im Einsatz ist, kann man auch die Funktionen des SQL verwenden. Insofern sollte man sich schon mit den neusten Features auf der Power i auseinander setzen, ansonsten wirklich ein gleiches Ende wie jenes der Dinos droht. TR8 ist nämlich schon angedroht!
Prinzipiell stimme ich zu, dass man "bloß wegen XML" nicht gleich auf eine andere Sprache umsteigen muss.
... hat das irgendjemand empfohlen? Ich habe halt mehrere Programmiersprachen zur Auswahl und nehme am liebsten die, die mir da die beste Unterstützung bietet - und das ist bei XML nicht gerade RPG und auch nicht SQL. Beim abbilden von geschachtelten Strukturen sind Objekt orientierte Sprachen da klar im Vorteil.
D*B,
der gerade an die deutsche Eiche und Schwarzwild denkt...
Auch die Rinde einer Eiche hält nicht ewig, wenn sich nur genug Wildschweine dran reiben. :-)
Hallo,
ich klinke mich hier mal ein, da ich nun auch CAMT einlesen muß.
Soweit meine momentane Recherche richtig ist, muß ich sowohl bei XML-Into als auch bei SAX wissen, was in dem XML für Felder kommen. Ich kann zwar allowmissing / allowextra setzen, das führt jedoch dazu, das die Verarbeitung bei einem Fehler (fehlendes / zuviel Element(e)) beendet wird.
(ist für mich zwar unlogisch, aber gut, die Verwendung von XML an sich ist für mich auch nicht 'Die Ideale Schnittstelle'. Vermutlich habe ich irgend etwas noch nicht verstanden.)
Alle Beispiele die ich gefunden habe 'kennen' das XML-Dokument.
Von der Bank haben wir die Info, das 'natürlich' nicht jedes Feld in jedem 'Datensatz' eines jeden Kontoauszuges vorkommt.
Damit hab ich nun ein Problem.
Wie löst Ihr das?
Leider habe ich bisher auch kein vernünftiges(komplexes) BSP für einen Sax-Hander gefunden.
Selber Parsen kommt hier nicht in Frage, Java verwenden auch nicht.
Danke für weitere Tips,
Robi
Da nun mal die XML-Integration in RPG nur mehr rudimentär ist, kommst du bei solchen Schnittstellen um Sprachen, die XML vollständig unterstützten leider nicht drum rum.
Wenn Java oder selber parsen nichts ist, musst du ggf. ein kommerzielles Produkt kaufen.
Beispiel: http://www.goering.de/de/i4xml.html
andreaspr@aon.at
24-04-14, 13:10
Wenn du beim XML-SAX mit einer Handler-Prozedur arbeitest, brauchst du über das XML selbst (theoretisch) überhaupt nichts zu wissen.
Angenommen du willst die Werte für die Tags <sender> und <recipient> haben, so kannst du diese im Handler für jedes Tag welches aktuell verarbeitet wird abfragen und wenn dann das entsprechende Tag "dran kommt" kannst du dessen Wert verarbeiten/speichern.
Dafür musst du z.B. gar nicht wissen wie oft oder wo genau im XML dieses Feld vorkommt.
Natürlich sollte da eine entsprechende Logik dahinter stehen ...
Was passiert wenn das Tag eben öfters vorkommt? Welches wird genommen?
Welche Suchkriterien gibt es? Usw.