Docker-Betrieb
Neben der Anwendung von xSuite Interface unter Microsoft Windows ist eine Programmvariante verfügbar, die für eine plattformübergreifende Nutzung kompiliert ist. Der primäre Zweck dieser Programmvariante ist der Einsatz im Docker-Betrieb mit Linux als Betriebssystem im Rahmen der xSuite Private und Public Clouds.
Das Setup-Programm und das Basiskonfigurationsprogramm sind reine Windows-Anwendungen und unter Linux nicht lauffähig. Stattdessen ist das fertige Docker-Image xsuite-interface in der internen xSuite-Docker-Registry verfügbar. Dieses Docker-Image enthält das vollständige Programmverzeichnis von xSuite Interface, das als Einstiegspunkt definiert ist. Beim Start eines Docker-Containers, das auf diesem Docker-Image basiert, wird das Programm automatisch ausgeführt.
Weitere Dateien, die für den Betrieb von xSuite Interface notwendig sind, müssen als separate Volumes in den Container eingehängt werden. Dazu zählen z. B. Lizenzdateien, Konfigurationsdateien, Zertifikatsdateien und Ordner für Log-Dateien und die temporäre Dateiablage.
Hinweis
In der Regel sollten getrennte Programminstanzen für die Webanwendungen des Statusmonitors und Konfigurators sowie für die eigentliche Ausführung der Verarbeitungsszenarien eingerichtet werden. Im Docker-Betrieb sollten analog dazu separate Container gestartet werden.
Einschränkungen und Besonderheiten im Docker-Betrieb
Die Funktionalität des Programms ist unter Linux weitgehend identisch mit der Funktionalität unter Microsoft Windows. Die bekannten Einschränkungen und Besonderheiten sind nachfolgend beschrieben.
Dem Einstiegspunkt für den Programmstart, der im Docker-Image verankert ist, ist kein Aufrufparameter mit dem Pfad der globalen Konfigurationsdatei beigefügt. Stattdessen kann für einen Container die Umgebungsvariable
XSI_CONFIG_FILEdefiniert werden, die genau diese Pfadangabe enthalten muss. Die Pfadangabe wird dem Programm im Windows-Betrieb über den Parameter/ConfigFilemitgegeben.Dateireferenzen auf andere Konfigurationen in der Form
file:///{Dateipfad}können nur absolute Pfade oder reine Dateinamen enthalten, aber keine relativen Unterverzeichnisse. Syntaktisch ist nicht erkennbar, ob ein führendes/die Wurzel des Pfades kennzeichnet oder nur Teil des Präfixesfile:///ist.Zugriffe auf SAP in Form von Ausgabesystem und Datenbank-Lookups sind nur über die SAP-NetWeaver-Schnittstelle und über die SOAP-Schnittstelle möglich. Ein Zugriff über den SAP .NET Connector ist nicht möglich. Die Schnittstellenbibliotheken des SAP .NET Connector sind nur unter Windows lauffähig. Für die SAP-NetWeaver-Schnittstelle werden zusätzliche Bibliotheken aus dem RFC SDK benötigt, die SAP in einer Linux-fähigen Variante bereitstellt. Das Docker-Image ist nur für den internen Gebrauch bei xSuite gedacht. Die betreffenden Dateien, die eigentlich nicht zusammen mit xSuite Interface ausgeliefert werden dürfen, sind bereits in das Image integriert. Damit die Dateien im Betrieb notwendige Abhängigkeitsdateien finden können, muss für den Container zusätzlich die Umgebungsvariable LD_LIBRARY_PATH definiert werden. Die Umgebungsvariable muss auf das Programmverzeichnis
/xSI5von xSuite Interface verweisen, in dem sich die Dateien befinden.Einige Funktionen der Aspose-Fremdbibliothek, die von bestimmten Dateimakros verwendet werden, erfordern unter Linux das Vorhandensein zusätzlicher externer Bibliotheken. Wenn diese Bibliotheken bekannt und von Seiten des Herstellers Aspose dokumentiert sind, sind diese in das Docker-Image integriert. Für Windows-Schriftarten, die unter Linux nicht verfügbar sind, müssen zusätzlich die Konfigurationseigenschaften
General.FileMacroOptions.DefaultFontundGeneral.FileMacroOptions.FontsFoldergesetzt werden. Die Schriftarten werden im Umgang mit Word-Dokumenten verwendet, z. B. bei der Visualisierung von E-Rechnungen auf Basis von Word-Vorlagen.Der Aufruf des KoSIT-Validators zur Prüfung von XRechnungen kann unter Windows per Kommandozeile oder als Webservice erfolgen. Der Validator ist nicht in das Docker-Image von xSuite Interface integriert. Dadurch sind beide Varianten im Docker-Betrieb nicht unmittelbar nutzbar. Der Validator kann in einem separaten Container im "Daemon"-Modus betrieben werden und so über einen Webservice-Aufruf angesprochen werden. Ein entsprechendes Image mit einer Java-Laufzeitumgebung und installiertem Validator ist unter dem Namen
kosit-validatorexemplarisch verfügbar. Dieses Image muss aber bei Bedarf angepasst werden, wenn der Versionstand des Validators oder des Prüfszenarios aktualisiert werden soll oder wenn die Kommandozeilenparameter zum Start des Validators beim Hochfahren des Containers geändert werden sollen, um ihn z. B. mit mehreren Prüfszenarien parallel zu betreiben oder die Adresse des Webservices anzupassen (derzeit HostKOSITauf Port9100).