ERP Software mit Delphi

[mkinzler]

Zitat:

Leichter hat man's da, wenn man sich direkt mit der Datenbank des "Quell"-Systems verbinden kann, und auch da braucht man in der Regel Username und Passwort, was ja nicht jeder FiBu-Entwickler herauszugeben bereit ist.

Das birgt aber eine gewisse Gefahr, dass bei Änderungen an der Datenbank, abhängige Systeme nicht mehr funktionieren oder noch schlimmer, dass die Datenbank unbrauchbar wird.

Besser sind Schnittstellen, die die eigentliche Datenstruktur abstrahieren.

[Furtbichler]

Zitat von mkinzler:

Das birgt aber eine gewisse Gefahr, dass bei Änderungen an der Datenbank, abhängige Systeme nicht mehr funktionieren oder noch schlimmer, dass die Datenbank unbrauchbar wird.

Sei mir nicht böse, aber ganz so dämlich sind professionelle Systeme nun wirklich nicht.

Folgende Maßnahmen sind durchaus effektiv:
1. Virtuelle Tabellen bereitstellen. Einfach: Views, besser: updateable Views
2. Rechte des Anwenders genau definieren, d.h. Änderungen an Tabelle nicht zulassen (geht bei virtuellen Tabellen eh nicht)
3. Consumer-Bereich (aka Tablespace oder separate DB) erstellen und dort alle Rechte zuweisen.

Somit kann die DB nicht unbrauchbar werden.

Es gibt auch Systeme, die per Admin-Tool erweitert werden können. Dadurch wird die Integrität gewährleistet und nix kann kaputtgehen. Hier können Erweiterungen an Tabellen vorgenommen werden, alle Views und CRUD-Routinen werden automatisch angepasst. Systemrelevante Spalten/Tabellen können natürlich nicht verändert werden.

Ich kenne ein (BuHa-)System (nein, nicht meins), das in Delphi geschrieben ist und sehr flexibel ist. Hier können einfach zusätzliche Tabellen erstellt werden, die die individuellen Daten enthalten. Per Konfiguration werden die Dialoge angepasst, zur Not auch mit Customizing, aber das ist laut Hersteller etwas blöd, eben wegen der Upgradeproblematik.

Es geht aber auch ohne.

[mkinzler]

Wenn B direkt auf die Daten von A zugreift ohne das A B kennt kann so etwas bei Änderungen von A passieren. Es geht hier ja nicht um ein integriertes System, bei dem sich A und B absprechen.

[Furtbichler]

"Direkter Zugriff" ist das Zauberwort. Jedes halbwegs normale System wird hier den schreibenden Zugriff hinter einer -wie auch immer gearteten- API verstecken. Das reicht von einer klassischen API eben bis zu virtuellen Tabellen.

Lesen kann man ja alles, ohne das es zu Manipulationen kommt. Und Schreibzugriffe sollten *immer* über eine Fassade laufen.

[mkinzler]

Das meinte ich mich "Schnittstelle". Ob das nun eine API ist oder Views sind ist ja zweitrangig.

[Perlsau]

Zitat von mkinzler:

Zitat:

Leichter hat man's da, wenn man sich direkt mit der Datenbank des "Quell"-Systems verbinden kann, und auch da braucht man in der Regel Username und Passwort, was ja nicht jeder FiBu-Entwickler herauszugeben bereit ist.

Das birgt aber eine gewisse Gefahr, dass bei Änderungen an der Datenbank, abhängige Systeme nicht mehr funktionieren oder noch schlimmer, dass die Datenbank unbrauchbar wird.
Besser sind Schnittstellen, die die eigentliche Datenstruktur abstrahieren.

Tja, dann muß der Anbieter des abhängigen Systems eben nachziehen. Hab mal an einem solchen Fall gearbeitet: Datenbank war eine sehr komplexe MSSQL-Struktur, hunderte von Tabellen, die meisten gar nicht oder kaum benutzt/belegt. Bis ich überhaupt erst mal herausgefunden habe, welche Tabelle mit welcher in Beziehung steht, vergingen schon ein paar Tage. Der Betreiber des WiWa (denn darum handelte es sich), sprich: der Firmenchef konnte mir dazu auch nichts weiter sagen, der kannte nur seine Programm-Oberfläche, und davon auch nur einen geringen Teil, denn das meiste machten ja seine Angestellten. Meine Aufgabe bestand darin, eine Katalog-Software, die im Grunde durchgestilte Berichte für's Internet oder die Druckerei erstellt, an diese Datenbank anzupassen. Änderungen an der DB waren selbstverständlich tabu. Ich hab allein für die Anpassung gute drei Wochen gebraucht: Welche Daten, die das abhängige Programm benötigt, stehen wo, welche Daten sind veraltet (zwischendrin gab's auch Updates des WiWa-Betreibers), welche Artikel doppelt oder unvollständig usw. Das war fast schon als Chaos zu bezeichnen.

[Furtbichler]

Normalerweise, bzw. in meiner kleinen Welt, werden System nicht so gekoppelt, das man direkt ins Zielsystem schreibt.

Normalerweise gibt es den berühmten Pull/Push-Mechanismus, d.h. Import/Export-Dateien, wobei 'Dateien' auch ein Synonym für eigenen Tabellen sein kann. Natürlich gibt es auch die berühmten TXT/CSV/XML-Dateien in einem Verzeichnis deiner Wahl.

Der Import in die eigene DB wird dann von customized-Importprozessen vorgenommen. Meist behält sich der Anbieter vor, die Importe zu schreiben, was auch anzuraten ist. Bei SAP kann man das auch selbst machen, da die meines Wissens nach, das Paradigma der virtuellen Tabellen mit einer API verfolgen, d.h. man beschreibt bestimmte 'Tabellen', um Daten zu importieren.

[Perlsau]

Zitat von Furtbichler:

Normalerweise, bzw. in meiner kleinen Welt, werden System nicht so gekoppelt, das man direkt ins Zielsystem schreibt.

Mich hat das damals auch etwas gewundert, daß ich eine vollständige Kopie der Firmen-DB einfach so erhalten habe. Da waren auch Bankverbindungen und Kontenbewegungen drin. Selbstverständlich hab ich nichts programmiert, um da reinzuschreiben, es ging nur um's Auslesen des aktuellen Artikelbestandes nebst Preisen, Bildern, Attributen wie Länge, Breite, Höhe, Gewicht, Farbe usw. Irgendwelche virtuellen Tabellen waren da nicht zu sehen, alles war stark normalisiert, d.h. jede Möglichkeit, Subtabellen anzulegen, wurde genutzt. Ich weiß bis heute nicht mal, mit welchem WiWa-System dort genau gearbeitet wurde, ich hatte nur die DB als Zip-Datei erhalten.

Zitat von Furtbichler:

Normalerweise gibt es den berühmten Pull/Push-Mechanismus, d.h. Import/Export-Dateien, wobei 'Dateien' auch ein Synonym für eigenen Tabellen sein kann. Natürlich gibt es auch die berühmten TXT/CSV/XML-Dateien in einem Verzeichnis deiner Wahl.

Das würde aber auch bedeuten, daß bei einem Daten-Update des abhängigen Systems immer zwei Schritte notwendig sind: Export vom Quellsystem und Import ins Zielsystem. Bei meiner damaligen Entwicklung war immer nur der Importvorgang nötig, das Aktualisieren des Quell-Systems besorgten die Damen in der Fakturierung. Beim Start des Katalog-Programsm wurde dann automatisch dessen DB aktualisiert: Veränderungen übernommen, nicht mehr existierende Artikel gelöscht, neue Artikel eingefügt. Das war im Grunde eine doppelte Verwaltung, ging aber nicht anders, weil die Suche in der Quell-DB viel länger dauerte als in der Katalog-DB.

Zitat von Furtbichler:

Der Import in die eigene DB wird dann von customized-Importprozessen vorgenommen. Meist behält sich der Anbieter vor, die Importe zu schreiben, was auch anzuraten ist.

Mit Anbieter meinst du jetzt den Anbieter des zugrundeliegenden Systems, also des Quellsystems, z.B. die FiBu, die Daten für ein WaWi liefern soll? Wenn ja, wie kann ein Anbieter einer FiBu z.B. Importe für ein Warenwirtschaftssystem schreiben, das ein anderer entwickelt hat? Der müßte doch zumindest den Quellcode des WaWi haben, und zudem die entsprechende Entwicklungsumgebung, und sich dann noch mit der Programmiersprache auskennen.

Zitat von Furtbichler:

Bei SAP kann man das auch selbst machen, da die meines Wissens nach, das Paradigma der virtuellen Tabellen mit einer API verfolgen, d.h. man beschreibt bestimmte 'Tabellen', um Daten zu importieren.

Vielleicht gab es damals bei diesem WaWi ja auch eine entsprechende API, aber das konnte mir niemand sagen, ging ja alles fernmündlich bzw. via Teamviewer über die Bühne. Ich hab die dortige Clientsoftware nie richtig gesehen.

[Hansa]

Zitat von Perlsau:

...
also des Quellsystems, z.B. die FiBu, die Daten für ein WaWi liefern soll?

Perlsau, wie soll denn eine Fibu (zumindest eine klassische) Daten an ein WaWi liefern ? Auf mittlerweile glaube 9 Seiten wurde die Nomenklatur doch genau erläutert. Wie soll man nun aus Rechnungs/Mwst.-Beträgen (also aus der Fibu) einen Lagerbestand für WaWi rekonstruieren ? Holger Klemt hat das doch ausführlich beschrieben : FiBu hat nur am Rande etwas mit WaWi zu tun ! Das ist eine Einbahnstrasse. Aus dem Wawi werden sich vielleicht Daten für die Fibu ableiten lassen, umgekehrt aber wohl kaum.

[mkinzler]

Ein WaWi-System benötigt aber u.U. Zugriff auf die Nebenbücher ( Kreditoren, Debitoren) z.B. für das Bestellwesen