Nachrichten Repository mit variablen Klassen

[takki]

Hallo!
Ich soll ein Repository für Nachrichten aufsetzen und die entsprechenden Java-Klassen schreiben. Das bedeutet ich muss ne Datenbank aufsetzen und für die verschiedenen Nachrichtentypen Klassen erstellen. Leider weiss ich nicht so recht wie ich das am elegantesten lösen soll und erhoffe mir hier ein paar Hinweise.

Erstmal generelles zu den Nachrichten:

1. Es gibt ca 20 verschiedene Nachrichtentypen
2. Jede Nachricht besteht aus einer Ansammlung von Segmenten.
3. Die Abfolge von Segmenten in einer Nachricht ist vorgegeben, jedoch gibt es viele Optionale Segmente
4. Es gibt ca 25 verschiedene Segmente
5. Jedes Segment besteht wiederrum auf verschiedensten Datenelementen.
6. Die Abfolge der Datenelemente ist wieder vorgegeben, allerdings auch hier wieder optionale Sachen.
7. Desweiteren ist die vorgegebene Abfolge von Datenelementen abhängig davon wo das Segment in der Nachricht steht

Im Prinzip hab ich 2 Möglichkeiten:
Die "Gute" wäre, wenn mein System einhergehende Nachrichten parst und überprüft ob diese gültig wären. Die "schlechte" wäre, wenn mein System lediglich die Daten einliest, aber nicht überprüft.

Mein Ansatz war nun der, für jedes Segment eine Klasse zu schreiben, die alle möglichen Datenelemente als Attribute beinhaltet. Jede dieser Klassen hätte dann ne parse-Funktion die das jeweilige Segment parst und gleichzeitig überprüft. Da kommt mir aber nun Punkt 7 in die Quere, da ich beim erstellen der Klasse ja noch nicht weiss wie die Abfolge der Datenelemente sein muss (hängt ja davon ab wo das Segment nachher in der Nachricht steht).
Insgesamt wäre diese Lösung eine extrem aufwendige, da sehr viele Klassen erstellt werden müssen.
Evtl könnte ich auch ein XML-Schema der verschiedenen Nachrichten & Segmente bekommen, könnte man daraus vielleicht die Klassen automatisch generieren lassen?

Gruß,
Christoph

 

[jeipack]

Hi
Also die Struktur sieht so aus:
Nachricht 1 <-> n Segmente 1 <-> n Datenelemente. (Richtig?)

Die Frage ist jetzt wie die einzelnen Objekte aussehen.

Du sagst ja es gibt unterschiedliche Segmente und Datenelemente mit unterschiedlichen Strukturen. Poste doch mal ein paar (fake)Nachriten um das zu verdeutlichen.. ansonsten wird es schwierig hier eine vernüftige Antwort zu geben..

Gruss

 

[takki]

Hallo nochmals.
Also die einzelnen Objekte würden im Prinzip nur Strings sein.
Es handelt sich dabei um das EANCOM-Nachrichtenformat, welches eine Teilmenge des EDIFACT-Standards darstellt.

Ich nehme als Beispiel mal das aus Wikipedia:

UNA:+.? '
UNB+UNOC:3+Senderkennung+Empfaengerkennung+060620:0931+1++1234567'
UNH+1+ORDERS:D:96A:UN'
BGM+220+B10001'
DTM+4:20060620:102'
NAD+BY+++Bestellername+Strasse+Stadt++23436+xx'
LIN+1++Produkt Schrauben:SA'
QTY+1:1000'
UNS+S'
CNT+2:1'
UNT+9+1'
UNZ+1+1234567'

Jede Zeile stellt ein Segment dar, zu Beginn steht immer was es für ein Segment ist, dann folgen durch "+" getrennt die verschiedenen Datenelemente des Segments. Datenelemente können durch ":" gruppiert werden. Abgeschlossen wird ein Segment durch "' ' ".
Das Segment "UNH+1+ORDERS:96A:UN' " wäre also ein UNH-Segment, welches als erstes Datenelement ne 1 hätte (die Bedeutung des 1. Datenelementes müsste ich in der Referenz nachschauen, spielt aber gerade ja keine Bedeutung). Als zweites Datenelement hätte dieses Segment ne Elementgruppe, bestehend aus "ORDERS", "D", "96A" und "UN". Auch hier müsste ich die Bedeutungen wieder nachschlagen. Desweiteren könnte das Segment UNH noch weitere Datenelemente enthalten, die Optional wären, hier aber weggelassen.

Viele der Datensegmente haben einen vorgegebenen Wertebereich, auch wenn in diesem Nachrichtenbeispiel einige Zahlen vorkommen, so wird es meistens wohl doch auf Strings hinauslaufen, da im Wertebereich dann auch Strings liegen.

Eine wichtige Sache hatte ich vorhin leider noch vergessen:
Manche Segmente und Datenelemente sind nicht nur optional, sondern können auch mehrfach hintereinander vorkommen.

Gruß,
Christoph

 

[jeipack]

Und wenn ein optionales Datenelement nicht angegeben wird dann steht einfach "++"
Wie z.B. bei:

LIN+1++Produkt Schrauben:SA'

Zwischen 1 und Produkt Schrauben:SA liegt ein optionales Element?

Hmm und wo genau brauchst du nun Hilfe?
Das ganze zu Parsen ist ja relativ einfach.

Das in Klassen abzubilden sollte doch auch nicht all zu schwer sein.
Eine Segmentklasse die den Namen speichern kann und die Elemente in einer Liste entweder direkt als Strings speichert oder als Objekte einer eigenen ElementKlasse.
Du willst ja nur ein Repository (Die Nachrichten aufbewahren) Also ganz blöde Frage.. wieso lässt du die nicht einfach im Textformat?
Oder geht es dir darum die Nachriten zu validieren? Also erst zu prüfen ob diese überhaupt im EANCOM Format sind?

 

[takki]

Und wenn ein optionales Datenelement nicht angegeben wird dann steht einfach "++"
Wie z.B. bei:

LIN+1++Produkt Schrauben:SA'

Zwischen 1 und Produkt Schrauben:SA liegt ein optionales Element?

Richtig!

Hmm und wo genau brauchst du nun Hilfe?
Das ganze zu Parsen ist ja relativ einfach.

Das in Klassen abzubilden sollte doch auch nicht all zu schwer sein.
Eine Segmentklasse die den Namen speichern kann und die Elemente in einer Liste entweder direkt als Strings speichert oder als Objekte einer eigenen ElementKlasse.

Das wäre die einfachste Variante, allerdings könnte ich dann nachher (siehe unten) nur immer direkt auf die Liste zugreifen und müsste mir die einzelnen Elemente aus der Liste herauspicken. Ein direkter Zugriff wäre da doch schöner.

Du willst ja nur ein Repository (Die Nachrichten aufbewahren) Also ganz blöde Frage.. wieso lässt du die nicht einfach im Textformat?
Oder geht es dir darum die Nachriten zu validieren? Also erst zu prüfen ob diese überhaupt im EANCOM Format sind?

Also das Ganze ist eigentlich eine Nebenaufgabe. Ich habe ein System welches mit diesen Daten der Nachrichten umgehen soll (Nachrichten interpretieren, darauf reagieren, Nachrichten erzeugen, usw). Damit es dies kann muss ich natürlich erstmal Klassen haben, die die verschiedenen Daten und Nachrichten repräsentieren. Wenn ich das nun so mache wie Du oben vorgeschlagen hast, dann wäre diese Nebenaufgabe zwar sehr einfach zu lösen, die Verwendung in meinem Hauptsystem später jedoch schwierig/aufwendig, da ich mir dann die notwendigen Datensätze erst in der Liste suchen müsste usw.
Allerdings rücke ich mehr und mehr vom Gedanken ab, eine große Library zu erstellen, bei der man jedes Element direkt über Funktionen ansprechen kann, weil das wohl viel zu viel Aufwand ist -.-

Das Repository ist halt damit ich nicht jedesmal die Daten dann neu Parsen muss.

Gruß,
Christoph

Edit: Eine Validierung der Daten wäre natürlich richtig gut, aber das halte ich für nicht machbar ^^

 

[jeipack]

Guten Morgen

Also ich weiss nicht so recht was ich dir jetzt als Vorschlag geben soll.. Einerseits kenne ich das EANCOM-Format überhaupt nicht und andererseits weiss ich ja auch gar nicht wie du die Daten nachher brauchst.Vielleicht kann dir hier ja jemand anders weiter helfen!

Kleiner Ansatz vielleicht:

class Segment {
  public static final int UNB=1;
  public static final int UNH=2;
  //hier alle Segmenttypen als static deklarieren

  int typ=0;
  String[] ele;

  Segment(int typ, String elemente) {
    this.typ=typ;
    this.ele=elemente.split("+");
  }

  boolean validate() {
    boolean returnvalue=false;
    switch (typ) {
      case(UNB):
        //irgendwo brauchst du eine Referenz welche Segmente welche Elemente
        //zwingend haben müssen und welche optional sind.
        //dies kannst du dann hier irgendwie prüfen
        returnvalue=mitReferenzVergleichen(ele);
        break;
     case(UNH):
        usw();
        break;
     }
return returnvalue;
  }