Ideen für die Umsetzung von einem Daten Importer.

[LebensAdler]

Hallo liebe DP-User,
durch eine Anpassung unseres Workflow können wir ein bei uns bestehende Programm umschreiben.
Dieses Programm importiert die Daten von mehren Hundert Partnerfirmen in unser Hauptprogramm. Da die Partnerfirmen diese Daten aus ihren ERP systemen und anderer Software exportieren haben die Liste die wir von den Enthalten alle Unterschiedliche Formate. In den Listen stehen Ausschließlich Kaufmännische Daten. (Sprich Simple Datentypen. Zeichenketten, Fließkomma Zahlen, und Ganze Zahlen )

Jetzt suche ich nach Design Pattern oder Strategien wie man Importroutinen schreiben kann die möglichst wenig Code erfordern und am Ende auch übersichtlich sind. Bisher waren die Import Routinen rein Prozendural geschrieben, also nichts mit Wiederverwendung von den alten Importroutinen.

Bisher.
Daten werden eingelesen und bestimmte Zeichen werden Ignoriert(Wenn man dies möchte). Dann gibt es eine Procedure die Daten so Maipuliert wie es soll. Preis durch Verpackungseinheit rechnen zum Beispiel oder nur die ersten 6 Zeichen der Spalte A ist eine Artikelnummer.Anschließend gibt es eine Procedure die Artikel die zusammengehören Zusammengefasst werden.

Hat jemand Ideen wie man so ein System aufziehen könnte ?

Gruß,
LebensAdler

[Frickler]

Ich habe sowas schon mal programmieren müssen. Ich habe das damals mit dem Schablonenmuster gemacht:

Zunächst sollte man Gemeinsamkeiten beim Import finden und zusammenfassen. Das wird dann die Template Klasse. Die ruft dann an jeder "konfigurierbaren" Stelle virtuelle Methoden auf, z.B. für das Einlesen der Datei in eine virtuelle Tabelle etc.
Für jedes Eingabeformat (also nicht für jede Datei) wird die Klasse dann abgeleitet und die virtuellen Methoden passend überschrieben. Praktischerweise nutzen ja doch viele Firme die gleiche ERP, d.h. die Import-Dateien sind gleichartig aufgebaut - die braucht man nur einmal programmieren, ggfs. mit Angabe der Feldreihenfolge (Felder EK und Rabatt vertauscht?).

Das Ergebnis ist dann ein "Filter" (kann ein separates Programm werden). Der nimmt eine Eingabedatei von Lieferant XY und erzeugt eine standardisierte Ausgabedatei, die dann das nachfolgende Programm einliest.

[jobo]

Ich würde für ein Konzept erstmal unterscheiden zwischen
Format
Transformation
~Konsistenz
Art
~Abgleich
Realisierung

Format wären CSV, TSV, FIX, XML, JSON ...
Transformation beschreibt welche Daten in welcher Form im Zielsystem weiterverendet und umgeform werden.
~Konsitenz soll den Datenbestand in sich prüfen können (Dubletten, Constraints, ..)
Art beschreibt die geplante Art und Weise der Weiterverarbeitung wie Aktualisierung von Bestandsdaten(Update, Upsert, Delete,..), Austausch, Append, ..
~Abgleich soll eine erweiterte Konsitenzprüfung gegen den vorhandenen Datenbestand inkl. Filterung sein
Realisierung betrifft am Ende die Umsetzung, also Technologie. Ich mach das bspw. meist alles per DB, die z.B. in der Lage ist, alle notwendigen Formate (CSV, FIX, XML, JSON..) nativ zu lesen. Ab da dann SQL.
Im ERP Bereich hab ich wenig Erfahrung. Da kann ich mir vorstellen, dass es viele Räder gibt, die man nicht neu erfinden muss und sie dann sinnvoll nutzt. Ähnlich sieht es evtl. in anderen etablierten EDV Bereichen aus, bspw. Banking (kleiner Scherz)

Ein besonderer Punkt wäre noch die Fehlerbehandlung bzw. die Unterscheidung, ob Importquellen maschinellen sind oder menschlichen Ursprungs. Fehler sollten zu allererst auf Formatebene, dann auf logischer Ebene (>~Konsitenz, >~Ablgeich) geprüft, gemeldet, behandelt werden.
Zuletzt im Rahmen von Workflows, Performance (Volumen) und Fehlerbehandlung dann noch die Frage, wie der Importvorgang als logische Transaktion gehandhabt werden muss (Reversibel, Voll-/Teilverarbeitung, Queuing, Revision/Feedback/Protokollierung).