Eigenes Entwicklungswerkzeug Framework Studio

ERP-Software-Hersteller stehen vor der Herausforderung, webbasierte Anwendungen nach dem neuesten Stand der Technik zu entwickeln. Außerdem sollen die Lösungen BI-fähig sein, also Schnittstellen zu Auswertungstools wie Management Informations Systemen (MIS) anbieten. Dieser Artikel beschreibt den Weg zur neuen ERP-Software über ein eigenes Entwicklungswerkzeug.

Ende der 90er Jahre hatten die Bedeutung und die Geschwindigkeit des Internets so stark zugenommen, dass eine Veränderung in der Architektur betriebswirtschaftlicher Software-Lösungen absehbar war. Dennoch sind Systeme, die eine mehrschichtige, internetfähige Architektur aufweisen, noch immer die Ausnahme. Dies mag an den hohen Anforderungen liegen. Wir definieren diese folgendermaßen: Die Produkte müssen internetfähig sein, plattformunabhängig, mehrsprachig, beliebig skalierbar, datenbankunabhängig, sie sollten mit Smart-Clients laufen und auf Standards aufbauen. Ist das neue System eine Standardsoftware, sind zusätzlich Anforderungen an die Anpassungs- und Releasefähigkeit gestellt.

Auch kleinere Unternehmen kommen oft nicht mit dem Standard aus und benötigen Erweiterungen. Die Software bläht sich auf oder bildet Spezialversionen aus, die separat gepflegt werden müssen. So bindet sie immer mehr Ressourcen für die Wartung und Pflege, was die Effizienz sinken und die Kosten steigen lässt. Dieser Herausforderung kann man mit einer kleinen Armee von Entwicklern und Beratern begegnen oder man sucht einen technischen Weg. Eine Möglichkeit besteht darin, den Entwicklungs- und den Customizingprozess durch ein entsprechendes Werkzeug zu unterstützen. Was bei der Spieleentwicklung längst üblich ist - niemand wird eine eigene Grafik-Engine schreiben, um anschließend seine Spielidee zu realisieren - , lässt sich auf den Entwicklungsprozess von Standardsoftware übertragen.

Über die Entwicklungsumgebung zur ERP-Software

Für die Entwicklung der neuen ERP-Software eNVenta war im Jahr 2001 kein Werkzeug in Sicht, das die gestellten Anforderungen erfüllte. Also entwickelte man selbst eines. Die Verwendung eines Frameworks ist für Hersteller von Standard-Software sicherlich nichts Ungewöhnliches. Neu an dem gewählten Ansatz ist allerdings, dass das Tool nicht nur den Entwickler unterstützen soll, sondern das Produkt über den gesamten Lebenszyklus.

Um ausufernde Strukturen zu vermeiden und gleichzeitig mehr Flexibilität für individuelle Wünsche zu gewinnen, muss eine Trennung zwischen Hersteller- und Kunden-Logik erfolgen. Zusätzlich kann Länder-, Branchen- oder Konzernlogik zur Abbildung der Geschäftsprozesse notwendig sein. Da die Anzahl der Logik-Ebenen nicht fest steht, muss diese variabel gehalten werden. Bei Standardsoftware werden zudem auch Integrationspartner und Kunden ein Interesse am Erstellen von Ebenen haben, die den Standard ändern und erweitern.

Das Problem kann gelöst werden, indem nicht wie üblich auf Quellcodedateien basierend entwickelt wird, sondern in einer Datenbank, einem Repository. Alle Klassen werden dort in ihrer Struktur erfasst und als Datensätze gespeichert. In diesen Datensätzen wird festgehalten, zu welcher Logik-Ebene die Klasse gehört und welche Version diese hat. Die Entwicklungssoftware Framework Studio nennt die Logik-Ebenen Packages. Diese Packages erben voneinander, wobei die Vererbungshierarchie zwischen den Packages variabel ist. Bei der Generierung des C# - Quellcodes wird die Hierarchie der Packages berücksichtigt und die Klasse entsprechend erstellt.

Die Erfassung der Klassen in ihrer Struktur hat außerdem den Vorteil, dass der Generierungsprozess aus der Struktur an technologische Neuerungen angepasst werden kann. So konnten beispielsweise Generics, die mit dem .NET Framework 2.0 eingeführt wurden, zentral implementiert werden.

Objektvererbung weiter gedacht

Zwischen den Packages sind alle Operationen der objektorientierten Programmierung zulässig. Soll z.B. die Logik eines Objekts geändert werden, kann dieses in einem neuen Package abgeleitet und die gewünschten Methoden überschrieben werden. Die normale Ableitung nützt allerdings nichts, wenn die Anwendung weiterhin die Klasse aus dem Originalpackage instanziiert.

Deshalb sind Klassen, die von der Entwicklungssoftware für diesen Fall erstellt werden, zweigeteilt. Sie bestehen aus einer Data-Class und einer Link-Class, wobei die Link-Class von der Data-Class erbt. Die Link-Class des Package, in dem die Klasse zum letzten Mal abgeleitet wurde wird immer zur Used-Class. Der Unterschied ist, dass die Benennung der Used-Class dem Klassennamen entspricht, den der Entwickler in seinem geschriebenen Code verwendet. Die Entwicklungsumgebung nennt diese Art der Vererbung, bei der das Innenleben durch Vererbung erweitert wird, Objekt-Customizing.

Als Ergebnis kann Logik und Funktionalität gezielt aus der Applikation herausgenommen oder hinzugefügt werden. Da die einzelnen Packages beliebig hinzugefügt oder entfernt werden können, liefert der Hersteller einen Standard, der selbst bei tief greifenden Anpassungen durch Kunden und Partner releasefähig bleibt. Zudem kann er sich auf einen sauberen Kern konzentrieren und diesen optimieren. Die Flexibilität für spezielle Erweiterungen wird durch die Entwicklungsumgebung geliefert.


Verbindungen zur Außenwelt

Bei einer webfähigen Anwendung mit mehrschichtiger Architektur ist die Nutzung von Clientressourcen schwieriger, als wenn diese direkt am Server zur Verfügung stehen, besonders wenn verschiedene Plattformen unterstützt werden. Clientseitige Programmierung kann trotzdem nicht einfach ignoriert werden, da sie z.B. für die Office-Integration oder das Ansteuern der TAPI-Schnittstelle unumgänglich ist. Die gesamte Kommunikation mit den Clients findet in der von Framework Studio vorgegeben Architektur über einen Webservice, den "Broker" (Mischung aus Broadcaster und Receiver), via SOAP statt. Das Tool bietet die Möglichkeit, funktionale und grafische Controls clientseitig zu implementieren, die dann - wie der Client selbst - über Click-Once-Deployment oder Java Webstart an den Client verteilt werden. Ein solches Control ist eine Klasse, die das von Framework Studio bereitgestellte Interface IFSGraphicalControl bzw. IFSFunctionalControl implementiert und dann am Client registriert wird. Der Client lädt diese Klasse, wenn er die entsprechende Definition in einer Antwort vom Server findet. Zuvor muss diese Definition auch auf dem Server abgebildet werden, was durch den speziellen Komponenten-Typ Custom Control geschieht.

Generell wird in Framework Studio das Oberflächen-Objektmodell des Clients nicht auf dem Server vorgehalten. Dies bringt Speicher- und Geschwindigkeitsvorteile bei der Verarbeitung der Anfragen, da die Formulare serverseitig aus einer zusammengesetzten XML-Definition bestehen, die an den Client gesendet und dort gerendert wird. Manipulationen der Darstellung zur Laufzeit geschehen durch Funktionen, die in dem jeweiligen Client-Control implementiert sind. Die Verfügbarkeit dieser Funktionen hängt vom Fleiß des Control-Entwicklers ab und ist kein technisches Hindernis. Möchte ein Entwickler etwa einen Button deaktivieren, kann er dies mit dem Befehl Button.IsEnabled(false); tun.

Die serverseitige Einbindung von Ressourcen ist dagegen einfacher. Die Serialisierung der Informationen in XML entfällt, stattdessen können COM-Komponenten und .NET-Assemblies direkt referenziert werden. Auch die von der Entwicklungsumgebung generierten .NET-Assemblies und damit die Geschäftslogik kann in externen Anwendungen genutzt werden.

Bei der Kommunikation mit externen Ressourcen muss zunächst nach dem kleinsten gemeinsamen Nenner für eine sinnvolle Zusammenarbeit gesucht werden. Diese kann sich auf die Business-Datenbank beschränken. Für die Extraktion von Daten in eine OLAP-Datenbank macht es z.B. wenig Sinn, diese zunächst in das ERP-System einzulesen, um sie anschließend aus den Objekten in die OLAP-Datenbank zu laden. Fertige Tools der Datenbankhersteller sind für den ETL-Prozess schneller und besser geeignet.

Ein Webshop dagegen kann die Geschäftslogik für die Preisfindung, Lagerbestandsanzeige und Ähnliches nutzen, weshalb in diesem Fall die Nutzung der Business-Komponenten zu empfehlen ist.

Implementierung eines MIS-Moduls, dass auf einer OLAP-Datenbank basiert

Die Entwicklung eines Management Informations System (MIS) Moduls, das für die Analyse eine OLAP-Datenbank nutzt, hat Vorteile für Hersteller und Anwender. Das Modul ist auf das Datenmodell des ERP-Systems hin entwickelt. Damit muss dieses sicherstellen, dass Informationen korrekt ermittelt werden. Zusätzlich kann der Pflegeaufwand für das Analysesystem reduziert werden, indem z.B. der ETL-Prozess automatisiert wird. Wenn der Funktionsumfang für den Anwender nicht ausreicht, hat dieser die Möglichkeit mit Auswertungstools von Drittherstellern auf die genutzte OLAP-Datenbank zu verbinden und sich ein BI-System nach seinen Bedürfnissen zu gestalten.

Von der Architektur der ERP-Software aus gesehen, empfiehlt sich die Nutzung von Standardschnittstellen für die Kommunikation mit einer OLAP-Datenbank. Derzeit gibt es zwei Möglichkeiten, die man als Standard bezeichnen kann: OLE DB for OLAP (ODBO) oder XML for Analysis (XMLA). ODBO ist der zurzeit weiter verbreitete Zugriffsstandard, was daran liegt, dass er schon länger existiert. Dagegen wird XMLA erst von relativ wenigen Herstellern unterstützt. In der neuen ERP-Software eNVenta wird der Weg über XMLA bevorzugt, da die Kommunikation wie im gesamten System über XML stattfindet. Microsoft bietet den Zugriff auf XMLA-Datenquellen via ADOMD.NET an. Die API kann genutzt werden, um auf eine Datenquelle zu verbinden, Abfragen abzusetzen und sich die Ergebnisse als XMLReader, DataReader oder CellSet verfügbar zu machen. In eNVenta wird für den Zugriff auf die jeweilige Datenquelle ein Adapter ausprogrammiert, der die Ergebnisse an das Objektmodell des MIS-Moduls mappt.

Soll datenbankspezifische Funktionalität genutzt werden, müssen die von den Datenbanken angebotenen APIs anprogrammiert werden. Die Verfügbarkeit von .NET-APIs ist derzeit noch die Ausnahme. Da sich die OLAP-Datenbank konsequenterweise auf einem separaten System befindet, ist es aber möglich, den Technologiebruch über Webservices zu lösen.

Fazit

Über den Umweg einer eigenen Entwicklungssoftware werden die Anforderungen erfüllt, die an moderne ERP-Produkte gestellt werden. Da die Geschäftsobjekte in ihrer Struktur und nicht als Quellcode definiert werden, ist es möglich, technologische Neuerungen im Generierungsprozess zentral zu berücksichtigen. Durch einen erweiterten Vererbungsmechanismus verbessern sich zudem Anpassbarkeit und Update-Fähigkeit der Business-Software. Die Neuentwicklung auf dieser Basis gibt dem Produkt die Chance, die technologischen Entwicklungen der letzten Jahre konsequent für sich einzusetzen.

Frameworkt Studio im Detail