Ein bisschen Theorie für Erweiterungen

Wollen Sie in-STEP BLUE erweitern? Kein Problem, können Sie tun. Aber beim Entwickeln von Komponenten ist es ist ein bisschen wie beim Schwimmen: Ohne theoretische Kenntnisse wird man beim Sprung ins Wasser vielleicht untergehen. Werfen wir also gemeinsam einen Blick auf die theoretischen Grundlagen von in-STEP BLUE.

in-STEP BLUE hat eine Client-Server-Architektur

Das heißt, über einen in-STEP BLUE Server werden ein oder mehrere in-STEP BLUE-Systeme zur Verfügung gestellt. Der in-STEP BLUE-Client auf Ihrem Rechner greift über den in-STEP BLUE Server auf das jeweilige System zu. Der Client kommuniziert dabei per XML via TCP mit dem Server. Der Zugriff auf die Datenbank, in der ein System gespeichert wird, – das kann eine isf-Datei oder ein Oracle-Schema sein – wird dabei ausschließlich vom in-STEP BLUE Server und seinen Komponenten vorgenommen. Der in-STEP BLUE-Client hat keinen direkten Zugriff auf die Datenbank.

Wenn ich also von einer Client-Komponente schreibe, meine ich damit eine Funktionalität, die ausschließlich auf dem in-STEP BLUE-Client-Rechner abläuft. Mit einer Server-Komponente meine ich im Umkehrschluss eine Funktionalität, die nur auf dem Server-Rechner abläuft und damit i.d.R. direkt auf die Datenbank zugreift.

Sie setzen in-STEP BLUE ohne den in-STEP BLUE Server ein?

Keine Angst, wenn Sie in-STEP BLUE ohne den in-STEP BLUE Server einsetzen und Ihre Systeme (isf-Dateien) über einen Dateiserver bereitstellen oder nur die Personal Edition einsetzen, können Sie natürlich auch Erweiterungen entwickeln. In diesem Fall greift in-STEP BLUE selbst direkt auf die Datenbank zu. Der in-STEP BLUE-Client ist dann sowohl Client als auch Server. Die Funktionen werden dabei immer auf dem Client-Rechner ausgeführt.

Hallo Produkt! Hallo Thomas!

Zur Veranschaulichung können wir ein kleines Hallo-Welt-Programm nutzen. Dazu führe ich einen Befehl Hallo <Produkt> auf einem Produkt aus, wobei <Produkt> der Name des gewählten Produkts ist. Nach dem Ausführen des Befehls bekomme ich eine Meldung.

Wie läuft das Ganze technisch ab? Zuerst öffne ich das Kontextmenü auf einem Produkt, worauf in-STEP BLUE die möglichen Befehle identifiziert und anzeigt. Mein Befehl (Schnittstelle ICommand aus der isExtension.tlb) aus meiner Client-Komponente bekommt den Namen des Produkts direkt von der inStep.exe mitgeteilt, sodass ich diesen ohne Abfrage an die Datenbank in die Bezeichnung des Befehls einfließen lassen kann. Anschließend muss meine Client-Komponente den Namen des angemeldeten Benutzers ermitteln. Ein Zugriff auf die Datenbank ist notwendig.

Der Zugriff kann dabei nur über die Modell-Schnittstelle (inStepModelIntf -> model.tlb) erfolgen. Die inStep.exe hat meinem ICommand bereits die Schnittstelle übergeben. Dabei wurde von in-STEP BLUE festgelegt, ob dahinter die isRemoteModel.dll (Zugriff über in-STEP BLUE Server) oder die InStepLocalModel.dll (direkter Zugriff auf eine isf-Datei) steht.

Mein Befehl weiß über die verwendeten Dlls nichts, sondern kommuniziert mit dieser nur über die Modell-Schnittstelle.

Wie praktisch: Bei der Schnittstelle ISystemModel gibt es die Funktion CurrentUserFullName, die mir genau den gewünschten Namen zurückliefern wird.

Mein Befehl ruft jetzt die Funktion CurrentUserFullName der Schnittstelle ISystemModel auf. Je nachdem, welche Dll gerade verwendet wird, wird entweder die Funktion aus der isRemoteModel.dll aufgerufen, die dann übers Netz/Internet die inStepLocalModel.dll aufruft oder es wird direkt die Funktion aus der inStepLocalModell.dll aufgerufen.

Egal, welcher Weg verwendet wird, am Ende befindet sich die Operation auf der Server-Seite. Die inStepLocalModel.dll (besser gesagt die Funktion CurrentUserFullName) ermittelt über die isKernel20.dll den entsprechenden Name des angemeldeten Benutzers aus der Datenbank:

Nun gibt es noch eine Besonderheit, die nicht unerwähnt bleiben sollte. Es wird garantiert Anwendungsfälle geben, für die die Modell-Schnittstelle keine passende Funktion bereitstellt oder mehrere Funktionen nacheinander ausgeführt werden müssen.

Hierfür bietet in-STEP BLUE in der isExtension die Schnittstelle IServerCommand an. Eine Server-Komponente, die diese Schnittstelle erfüllt, ist ein Befehl, der direkt auf dem Server ausgeführt wird und damit auch direkt auf die Datenbank (über die isKernel20.dll) zugreifen kann.

Um einen Server-Befehl aufrufen zu können, bietet die Modell-Schnittstelle die Funktion ExecuteCommand in der Schnittstelle ISystemModel an.

Die Funktion erwartet eine ProgID und eine XML-Struktur und liefert wieder eine XML-Struktur zurück. Mit der ProgID ist meine Server-Komponente auf dem Server unter Windows registriert. Diese muss natürlich meiner Client-Komponente bekannt sein.

Die inStepLocalModel.dll instanziiert den Server-Befehl aus meiner Server-Komponente über die ProgID und übergibt dem Befehl die XML-Strukur, dessen Inhalt meine Client-Komponente frei definieren kann.

Mein Server-Befehl muss natürlich die Struktur ebenfalls kennen, um sie auswerten zu können. Anhand dessen führt der Befehl nun Lese- und/oder Schreiboperationen über die isKernel20.dll auf der Datenbank aus und teilt dem Client ebenfalls über eine XML-Struktur das Ergebnis (Rückgabewert von ExecuteCommand) mit:

Soweit die Theorie, beim nächsten Mal geht es dann ins Schwimmbecken.