Integration Server
Auf dem Integration Server läuft einerseits Lobster Integration selbst als Anwendung. Zudem laufen dort alle Services, die der Kommunikation zwischen Lobster Integration und der Aussenwelt dienen und der Service, der Lobster Integration an seine Datenbank anbindet.
Verwaltet wir der Integration Server wird über die Admin-Konsole.
Verzeichnisorganisation des Integration Servers
Unterhalb des Installationsverzeichnisses des Integration Servers befinden eine Reihe von Unterverzeichnissen.
./as2
Enthält MDN-Dateien der gesendeten und empfangenen AS2-Nachrichten.
./asm
Enthält Dateien für das Asynchrone-Sende-Modul (ASM).
./backup
In diesem Verzeichnis werden bei einem Versionsupdate oder Patch die in dem Vorgang angefassten Dateien vorab in einer .zip-Datei gesichert.
./bin
Hier befinden sich alle Startprogramme für das Ausführen des Integration Servers und damit verbundenen Rahmenapplikationen, die zum Teil bereits im Abschnitt Allgemeines zur Konfiguration beschrieben wurden. Prinzipiell kann hier zwischen zwei Arten von Skripten unterschieden werden.
Skripte für den Betrieb unter Windows. Diese erkennt man anhand der Dateiendung .bat.
Skripte für den Betrieb unter Unix-artigen Systemen. Diese erkennt man an der Dateiendung .sh.
Damit diese Skripte ausgeführt werden können, ist das Vorhandensein der Standardshell /bin/sh notwendig. Das Unterverzeichnis shared mit allen darin befindlichen Dateien und die Dateien starter.jar, wrapper.jar und wrapper.exe werden für den Betrieb als Windows Service benötigt und sollten nicht ohne explizite Aufforderung vonseiten Lobster verändert oder entfernt werden.
./conf
Konfigurationsdateien, die nicht zum Standardumfang des Integration Servers gehören, sollten in diesem Verzeichnis abgelegt werden, damit das Gesamtsystem releasefähig bleibt und keine Probleme entstehen, wenn in dem Standardkonfigurationsverzeichnis neue Dateien entstehen, deren Namen mit einer projektspezifischen Datei kollidiert.
Direkt nach Installation des Integration Servers befinden sich bereits eine Reihe von Dateien in dem Verzeichnis, die an eigene Bedürfnisse angepasst, bzw. als Beispiel für neue Konfigurationsdateien heranziehbar sind.
./datawizard
Unterhalb dieses Verzeichnisses befinden sich Template- und andere Dateien, die zur Laufzeit von Lobster Integration verwendet werden.
/backup |
Verzeichnis zum Halten von Eingangsdaten einzelner Profile. Pro Profil ist hierbei jeweils ein Unterverzeichnis angelegt worden. |
/moved |
Enthält veraltete Backup-Dateien, falls der Parameter moveBackUpFiles in der Konfigurationsdatei ./etc/startup.xml auf true gesetzt ist. |
/settings |
Allgemeine Bedienelemente der GUI und exportierte Quell- und Zielstrukturen. |
/swap |
Ist ein Profil dahingehend konfiguriert, dass Daten während des Mappings ausgelagert werden dürfen, werden die ausgelagerten Daten in diesem Verzeichnis abgelegt. |
/templates |
Von Lobster bereitgestellte Template-Dateien, die über Vorlage laden im Mappingbereich von Lobster Integration für die Quell- und Zielstruktur geladen werden. |
./dmz
Enthält Event-Dateien, wenn auch ein Lobster-DMZ-Server installiert ist.
./etc
Angelehnt an das etc-Verzeichnis von Unix-Systemen, befindet sich in diesem Verzeichnis alles zur Konfiguration notwendige. Direkt im Verzeichnis sind dies vor allem die XML-basierten Konfigurationsdateien der einzelnen Services des Integration Servers, bzw. Zusatzdateien, wie die Benutzerdefinitionen der Kommunikationsdienste. Üblicherweise gibt es vier Unterverzeichnisse von ./etc.
admin |
Enthält im Unterverzeichnis datawizard Konfigurationsdateien zur Einstellung von Lobster Integration. Unterverzeichnis webapps: Bei Neuinstallationen (nicht Updates) ab Version 4.6.9 ist hier nun teilweise auch zu finden, was davor im Verzeichnis ./webapps war. |
dtd |
Enhält DTDs (XML-Beschreibungen), die für den Betrieb des Integration Servers notwendig sind. Siehe auch Abschnitt Format von XML-Konfigurationsdateien. |
realms |
Enthält Konfigurationsdateien für den HTTP-Server bzw. zur Festlegung des Passworts der Admin-Konsole. |
scripts |
Dieses Verzeichnis ist nur noch für die Wahrung der Abwärtskompatibilität vorhanden und kann daher ignoriert werden. |
./ext
Dieses Verzeichnis ist vorgesehen für das Ablegen eigener Klassen, die für den Integration Server erreichbar, d. h. auffindbar sein sollen. Verwendung findet dies beispielsweise bei der Ausführung von Klassen über die Tools der Admin-Konsole.
Der Vorteil des ext-Verzeichnisses ist, dass neue Klassen auch dann gefunden werden, wenn der Server nicht neu gestartet wurde. Der Austausch einmal geladener Klassen erfordert aber weiterhin einen Neustart des Servers, damit die Änderung auch ihren Weg in die Virtual Machine findet.
Achtung: .jar-Dateien werden in diesem Verzeichnis ignoriert, hierfür existiert das Verzeichnis ./extlib.
./extlib
Dieses Verzeichnis ist vorgesehen für das Ablegen eigener Bibliotheken, die für den Integration Server erreichbar, d. h. auffindbar sein sollen.
Achtung: Das extlib-Verzeichnis hat beim Ermitteln von Klassen eine höhere Priorität als das Standard-lib-Verzeichnis. Werden Bibliotheken eingespielt, die ebenfalls vom Integration Server selbst verwendet werden, sind bei einer Verwendung von anderen Versionen Probleme möglich, die nicht sofort auf diese Tatsache zurückgeführt werden können. Vor dem Einspielen eigener Bibliotheken sollte daher zuvor immer überprüft werden, ob eine gleichartige Bibliothek nicht schon vorhanden ist, die mitverwendet werden kann. Beachten Sie bitte, dass Sie selbst für die Pflege dieses Verzeichnisses verantwortlich sind.
Blacklists und Whitelists für Dateiendungen
Siehe Abschnitt Blacklists und Whitelists für Dateiendungen.
./index
Ist der FileSearchService aktiviert, ist dieses Verzeichnis das Basisverzeichnis für das Ablegen von Indexdateien. Bei deaktiviertem Service oder direkt nach der Installation ist das Verzeichnis normalerweise leer.
./lib
In diesem Verzeichnis befinden sich alle für den Basisbetrieb des Integration Servers notwendigen Bibliotheken. Dieses Verzeichnis sollte vom Benutzer unberührt gelassen werden, d. h. eigene Dateien sollten hier nicht abgelegt werden.
./logs
Eines der für den laufenden Betrieb wichtigsten Verzeichnisse. Direkt nach der Installation ist dieses zwar leer, einzelne Bereiche des Servers erzeugen aber im Laufe der Zeit Unterverzeichnisse, in denen eine Reihe von Logdateien angelegt werden.
Für weitere Informationen hierzu sei auf die Beschreibung des LogServices verwiesen.
Neben Logdaten werden darüber hinaus weitere Daten anderer Services in diesem Verzeichnis abgelegt. Hier sei nur eine kurze Übersicht gegeben, eine genaue Beschreibung der Funktionalität kann beim jeweiligen Service in dieser Dokumentation gefunden werden.
Unterordner |
Service |
Beschreibung |
events |
Bei der Verwendung von persistenten Nachrichten werden im Verzeichnis events Nachrichten abgelegt, die nicht sofort weitergeleitet werden können. |
|
storage |
Daten, die über den StorageService persistent gehalten werden, werden in diesem Verzeichnis abgelegt. |
./patch
Wird von Lobster ein Hotfix geliefert, wird dieser üblicherweise in dieses Verzeichnis entpackt. Der Integration Server leert dieses Verzeichnis im Rahmen eines dann später stattfindenden Updates, sodass Versionsinkompatibilitäten vermieden werden. Details finden Sie auf der entsprechenden Download-Seite für Patches im Kundenbereich beschrieben.
Achtung: Werden eigene Dateien in diesem Verzeichnis abgelegt, werden auch diese im Rahmen eines Updates gelöscht, unabhängig davon, ob diese im Update enthalten sind oder nicht. Dieses Verzeichnis sollte daher auf keinen Fall für einen anderen Zweck als beschrieben verwendet werden.
./tmpIO
Auslagerungsort für Java, zum Beispiel für verschiedene Client-Jetty-Dateien.
./training
Dieses Verzeichnis enthält ein Demo-Profil mit Testdaten.
./transfer
Default Root Home der User für FTP, OFTP und SSH.
./webapps
Dieses Verzeichnis dient zur Aufnahme von Webapplikationen. Weitere Webapplikationen können hier hinzugefügt werden, wie z. B. Axis.
Direkt nach der Installation befinden sich dort die folgenden Unterverzeichnisse.
root |
Dies ist das Basisverzeichnis des HTTP-Servers. |
Wichtiger Hinweis: Bei Neuinstallationen (nicht Updates) ab Version 4.6.9 siehe auch ./etc/admin/webapps.
Zu sichernde Verzeichnisse
Für das Sichern aktueller Arbeitsdaten des Integration Servers im Rahmen einer Backupstrategie, wird empfohlen folgende Verzeichnisse täglich zu sichern.
./conf |
Zur Sicherung der eigenen Konfigurationsdateien. |
./etc |
Zur Sicherung der Standardkonfigurationsdateien. |
./datawizard |
Zur Sicherung der Lobster-Integration-Daten. Um Speicherplatz für das Backup zu sparen, kann hierbei auf das Verzeichnis templates verzichtet werden. |
./index |
Auf dieses Verzeichnis kann verzichtet werden, sollte der FileSearchService nicht verwendet werden. |
./logs |
Sollen nicht alle Logverzeichnisse gesichert werden, da z. B. das Datenaufkommen zu groß wird (größere Lobster-Integration-Installationen erzeugen bis zu 1 GB Logdaten pro Tag), kann die Sicherung auch auf die Verzeichnisse ./logs/events und ./logs/storage eingeschränkt werden. |
System-Properties
Permanentes Setzen in Dateien
Die allgemeine Syntax für System-Properties beim Start des Integration Servers und damit von Lobster Integration, ist die folgende.
-D<Property-Name>=<Property-Wert> |
System-Properties werden in den folgenden Konfigurations-Dateien gesetzt.
./bin/hub.bat (Integration Server wird mit Windows-Batchdatei gestartet).
./etc/wrapper.conf (Integration Server läuft als Windows-Service) (meistens der Fall).
./bin/execute.sh (unter Linux/Unix).
Vorübergehendes Setzen in der Admin-Konsole
Alternativ können System-Properties auch in der Admin-Konsole gesetzt werden.
Auch hier tragen Sie den Namen und den Wert der Property ein. Das -D am Anfang entfällt hier!
Änderungen können hier auch während der Laufzeit gesetzt werden. Achtung: Die Änderungen gehen nach einem Neustart verloren!
Prüfungen nach Konfigurationsänderungen
Nach Änderungen an den Konfigurationsdateien ./etc/*.xml muss geprüft werden muss, dass dabei keine Fehler entstanden sind.
Die Prüfung ist nach Start/Neustart des Integration Servers erforderlich, im besten Fall etwa 5 Minuten, nachdem der Server völlig hochgefahren ist.
Wie erfolgt die Prüfung?
Das ist vom Betriebssystem und der Startart des Integration Servers abhängig.
Unter Windows bei Start im Vordergrund (nicht als Service). |
Beobachten Sie die Meldungen, die in der Eingabeaufforderung erscheinen. |
Unter Windows bei Start als Service. |
Kontrollieren Sie die Datei ./logs/Wrapper.log. |
Unter Unix/Linux bei Start im Vordergrund (run). |
Beobachten Sie die Meldungen in der Konsole. |
Unter Unix/Linux bei Start als Dienst. |
Kontrollieren Sie die Datei ./hub.txt. |
Hinweis: Lassen Sie diese Dateien bitte nicht mit einem blockierenden Editor länger geöffnet. Verwenden Sie einen nicht-blockierenden Editor oder kopieren Sie die Datei und öffnen Sie die Kopie.
Wenn während oder kurz nach der normalen Startmeldung Fehlermeldungen (Exceptions) ausgegeben werden, besteht dringender Handlungsbedarf. In diesem Fall steht der Integration Server und damit Lobster Integration eventuell nicht mit der gesamten Funktionalität zur Verfügung. Oft ist bei einem fehlerhaften Start keine Anmeldung mit dem Client möglich. Folgend mögliche Ursachen.
Lizenz ungültig.
Datenbank hub nicht bereit oder nicht erreichbar.
Fehler in einer Konfigurationsdatei nach Änderung.
Ungenügender Arbeitsspeicher.
Sonstiger schwerer Fehler, z. B. eine Klasse in falscher Version.
Fehlerausgaben aus Klassen, die der Anwender (nicht nach Vorgabe) selbst entwickelt hat.
Fehler, die hier ausgegeben werden, deuten immer auf ein ernstes Problem hin und sollten umgehend analysiert werden. Es handelt sich hier nicht um ein Log, sondern um Terminalausgaben. Deshalb haben Fehlerausgaben, die hier erscheinen, keinen vorangestellten Zeitstempel. Im normalen, störungsfreien Betrieb gibt es hier keine Meldungen nach der Startmeldung, die etwa folgendermaßen endet.
Lobster Integration Server (IS) started in 32453 ms , system is ready ...
--------------------------------------------------------------------------
Wenn im laufenden Betrieb nicht genügend Arbeitsspeicher verfügbar ist, können OutOfMemoryExceptions erscheinen. Häufig führt dieser Fehler nur zum Abbruch des Profil-Jobs, der zu viel Speicher gebraucht hat. In seltenen Fällen ist es möglich, dass andere Funktionen beeinträchtigt sind. Nach einer OutOfMemoryException sollte daher bald ein Neustart des gesamten Integration Servers durchgeführt werden. Wenn sich solche Fehler wiederholen, sollte der Speicher vergrößert werden.
Hinweis: Um OutOfMemoryExceptions zu erkennen, sollte nicht nur nach einem Neustart kontrolliert werden, sondern auch danach, z. B. einmal pro Tag, bei Dauerbetrieb, sowie auch dann, wenn ein Profil-Job mit einer OutOfMemoryException endet.
Proxy-Server
Der Lobster Integration Server (und dadurch auch Lobster Integration) kann ausgehende Netzwerkverbindungen über Proxy-Server aufbauen. Kriterium ist hier die Richtung des Verbindungsaufbaus der TCP-Connection, nicht die Datenrichtung. In der Java Virtual Machine werden drei Proxy-Typen unterstützt.
HTTP-Proxy. Kann HTTP-Verbindungen vermitteln.
FTP-Proxy. Kann FTP-Verbindungen vermitteln.
SOCKS-Proxy. Für die Vermittlung aller TCP-Verbindungen.
Sobald ein SOCKS-Proxy konfiguriert ist, gehen alle TCP-Verbindungen über ihn, auch HTTP(S)- und FTP-Verbindungen.
Falls eine zusätzliche Authentifizierung am Proxy erforderlich ist, verfügt der Integration Server (und dadurch Lobster Integration) über einen Authenticator, der die Anmeldung am Proxy durchführt. Der Authenticator akzeptiert Passworte in Klartext oder obfuscated.
Andernfalls muss der Proxy nicht-authentifizierte Verbindungen zulassen.
Da wir nicht alle Funktionen der Standard-Implementierung so verifizieren konnten, wie sie von Oracle beschrieben werden, wurde zusätzlich zum Authenticator auch ein Proxy Selector entwickelt, mit dem u. a. auch Proxy-Ausnahmen für SOCKS konfiguriert werden können. Diese spezielle Lobster-Implementierung kann über die folgende System-Property (siehe Kapitel oben) deaktiviert werden.
-Dhub.disableProxyHandling=true
Dann fällt das Verhalten zurück auf die Standard-Implementierung, die hier beschrieben wird (und an anderen Stellen, teilweise abweichend).
http://docs.oracle.com/javase/6/docs/technotes/guides/net/proxies.html
http://docs.oracle.com/javase/6/docs/technotes/guides/net/properties.html
Die Verwendung von Proxies wird zur Startzeit des Integration Servers über System-Properties gesteuert. Nachfolgend eine Liste der Property-Namen für die drei Proxy-Typen.
HTTP-Proxy
System-Property |
Beschreibung |
-Dhttp.proxyHost |
IP-Adresse oder DNS-Name des HTTP-Proxys. Default: <none>. |
-Dhttp.proxyPort |
Portnummer des HTTP-Proxys. Default: 80, wenn -Dhttp.proxyHost gesetzt ist. |
-Dhttp.nonProxyHosts |
Liste der Hostnamen/Adressen, die nicht über HTTP-Proxy, sondern direkt verbunden werden sollen. Mehrere Einträge werden mit | getrennt. Jeder Eintrag kann einen Platzhalter * enthalten. Default: <none>. |
-Djava.net.http.username |
User für die Authentifizierung beim HTTP-Proxy. Default: <none>. |
-Djava.net.http.password |
Passwort für die Authentifizierung beim HTTP-Proxy in Klartext oder obfuscated. Default: <none>. |
FTP-Proxy
System-Property |
Beschreibung |
-Dftp.proxyHost |
IP-Adresse oder DNS-Name des FTP-Proxys. Default: <none>. |
-Dftp.proxyPort |
Portnummer des FTP-Proxys. Default: 21, wenn -Dftp.proxyHost gesetzt ist. |
-Dftp.nonProxyHosts |
Liste der Hostnamen/Adressen, die nicht über FTP-Proxy, sondern direkt verbunden werden sollen. Mehrere Einträge werden mit | getrennt. Jeder Eintrag kann einen Platzhalter * enthalten. Default: <none>. |
-Djava.net.ftp.username |
User für die Authentifizierung beim FTP-Proxy. Default: <none>. |
-Djava.net.ftp.password |
Passwort für die Authentifizierung beim FTP-Proxy in Klartext oder obfuscated. Default: <none>. |
SOCKS-Proxy
System-Property |
Beschreibung |
-DsocksProxyHost |
IP-Adresse oder DNS-Name des SOCKS-Proxys. Default: <none>. |
-DsocksProxyPort |
Portnummer des SOCKS-Proxys. Default: 1080, wenn -DsocksProxyHost gesetzt ist. |
-Djava.net.socks.username |
User für die Authentifizierung beim SOCKS-Proxy. Default: <none>. |
-Djava.net.socks.password |
Passwort für die Authentifizierung beim SOCKS-Proxy in Klartext oder obfuscated. Default: <none>. |
Leider erlaubt die Standard-Implementierung in der Java Virtual Machine keine Ausnahmen für SOCKS-Proxies. Wir haben deshalb, durch die Lobster-Implementierung von Authenticator und ProxySelector, eine Möglichkeit geschaffen, solche Ausnahmen für alle drei Proxy-Arten in der Konfigurationsdatei ./etc/exclude_proxy.properties zu definieren. Hier wird die IP-Adresse oder der DNS-Hostname für Computer erwartet, zu denen die Verbindung direkt erfolgen soll, also ohne Proxy. Pro Zeile wird eine Ausnahme erwartet. Der Platzhalter * ist zulässig.
Wenn die gesamte Datei nicht existiert, werden per Default die Adressen 127.0.0.1 (Loopback-Adresse) und 0.0.0.0 (alle lokalen Adressen dieser Maschine) und der Name localhost (Name für Loopback) angenommen.
HTTP-Server des Integration Servers
Der Integration Server stellt eine Möglichkeit zur Verfügung, über Konfigurationsdateien (und vorübergehend in der Admin-Konsole) einen oder mehrere HTTP-Server einzurichten. Siehe hierzu den Bereich HTTP-Server der Admin-Konsole.