Docker Operation
xSuite Interface can be used not only in a Microsoft Windows context, but also across other platforms. The primary purpose of the variant compiled for cross-platform use is Docker operation with Linux as the operating system as part of the xSuite Private Cloud and the xSuite Public Cloud.
The setup program and the basic configuration program are pure Windows applications and cannot be run with Linux. Instead, the ready-made Docker image xsuite-interface is available in the internal xSuite Docker registry. This Docker image contains the entire program directory of xSuite Interface, which is defined as the entry point. When a Docker container based on this Docker image is started, the program is executed automatically.
Other files that are necessary for the operation of xSuite Interface must be mounted as separate volumes in the container. Among other things, these include license files, configuration files, certificate files and folders for log files, and temporary file storage.
Notice
Make it a rule to set up separate program instances for the web applications of the Status Monitor and Configurator and for the actual execution of the processing scenarios. In Docker operation, separate containers should be started in the same way.
Restrictions and Special Aspects to Docker Operation
The functionality of xSuite Interface on Linux is largely identical to the functionality in Microsoft Windows. Known limitations and special considerations regarding Docker operation are described below.
The entry point for program start, which is anchored in the Docker image, does not have a call parameter attached specifying the path of the global configuration. Instead, the environment variable
XSI_CONFIG_FILEcan be defined for a container, which must contain this exact path specification. Communicate the path specification to the program in Windows mode via the/ConfigFileparameter.When entering file references to other configuration in the form
file:///{file path}, only include absolute paths or pure file names, but no relative subdirectories. The reason is that, syntactically speaking, it is not clear whether a leading/indicates the root of the path or is only part of the prefixfile:///.Access to SAP in the form of output system and database lookups is only possible via the SAP NetWeaver interface and via the SOAP interface. The interface libraries of the SAP .NET Connector can only be run in Windows. Additional libraries from the RFC SDK are required for the SAP NetWeaver interface, which SAP provides in a Linux-compatible version. The Docker image is only intended for internal use at xSuite. The relevant files, which may not actually be delivered together with xSuite Interface, are already integrated into the image. The LD_LIBRARY_PATH environment variable must also be defined for the container so that the files can find the necessary dependency files during operation. The environment variable must refer to the program directory
/xSI5of xSuite Interface in which the files are located.Some functions of the Aspose external library, which are used by certain file macros, require additional external libraries on Linux. If these libraries are known and documented by the manufacturer Aspose, they will be integrated into the Docker image. Windows fonts must be set if they are not available in Linux, with the configuration properties
General.FileMacroOptions.DefaultFontandGeneral.FileMacroOptions.FontsFolder. The fonts will be used for Word documents (e.g., when visualizing e-invoices based on Word templates).The KoSIT validator for checking XRechnungen can be called up on Windows via the command line or as a web service. The validator is not integrated into the Docker image of xSuite Interface. This means that neither variant can be used directly in Docker operation. The validator can be operated in a separate container in "daemon" mode and thus accessed via web service call. A corresponding image with a Java runtime environment and installed validator is available as an example under the name
kosit-validator. However, this image must be adapted as required if the version of the validator or the test scenario is to be updated or if the command line parameters for starting the validator are to be changed when the container is booted (e.g., to operate it with multiple test scenarios in parallel or to adapt the address of the web service [currently hostKOSITon port9100]).