One of the most important requirements of JKHLE was a centrally managed rollout and deployment for Lotus Expeditor integrator instances. This implements the "plug-and-play" principle, meaning only a base deployment (copy of run-time) is necessary. Afterwards all further configuration and deployment tasks will be controlled by a central instance at the head office.
Lotus Expeditor integrator provides an example scenario for custom deployment (see the picture below).
Custom Deployment Scenario
This example allows for the deployment of the Lotus Expeditor integrator run-time to many machines with base configuration values. During the very first start up (boot strap), the Lotus Expeditor integrator run-time contacts the Backbone Service Bus in order to retrieve a unique customized configuration. Every Lotus Expeditor integrator run-time is identified by its Boot Strap ID. The Boot Strap ID is based on a unique ID locally available on the remote server on which the Lotus Expeditor integrator is installed (for example, the MAC or IP address). This unique ID can be retrieved by the Lotus Expeditor integrator run-time. Based on this ID, the Backbone Service Bus is able to identify the remote Lotus Expeditor integrator instance and select the corresponding configuration file (that must be available at the back-end). Therefore, the Backbone Service Bus requires a directory of some kind to do the mapping between the Boot Strap ID and the real LocationId and the corresponding XPDinteg.xml
configuration file. The application that does this assignment is not part of the Lotus Expeditor integrator product. However, the Lotus Expeditor integrator tools contain a Custom Deployment Tool that can be used for testing this scenario. For details please refer to the Administrators Guide.
Lotus Expeditor integrator is based on the standard OSGi Configuration Admin implementation. All application configuration data is stored in the local configuration stores of the OSGi application bundles. The OSGi Configuration Admin enables remote configuration management using the OMA/DM standard protocol (see http://www.openmobilealliance.org
It is highly recommended to use a central configuration management tool that maintains the configuration levels of the different stores and enables the administrator to update and remotely manage the Lotus Expeditor integrator configuration directly through the standardized OSGi Configuration Admin.
IBM has two server components in its product portfolio that can be used for remote configuration updates.
- IBM Lotus Expeditor Server (Expeditor Client Manager)
- IBM WebSphere Premises Server
The IBM Lotus Expeditor Server also allows for remote management of the Eclipse RCP features and plug-ins. Please note that the current Lotus Expeditor integrator use case configuration is based on OSGi Configuration Admin rather then Eclipse Preferences Service. Direct configuration through the Preferences Service is not possible. But, the Lotus Expeditor Server can be used to manage Lotus Expeditor integrator's configuration through updating the XPDinteg.xml
The IBM WebSphere Premises Server was initially developed for remote management of the RFID reader concentrators at remote locations (Edge Devices or Data Capture Devices). Since the Data Capture Devices were built on the same technology stack as Lotus Expeditor integrator and also use the OSGi Configuration Admin as configuration store, the Premises Server can also manage Lotus Expeditor integrator's configuration. To do this, WebSphere Premises Server licenses and two further Data Capture bundles are required (Please, contact your IBM Representative for further information about the WebSphere Premises option.).
For small environments without a Device Management Server the additionally developed Custom Configuration Service allows for using a local configuration file to update Lotus Expeditor integrator configuration (config/XPDinteg.xml
). Details about available configuration parameters and their possible values are given in the Administrators Guide.
It is important to understand that the configuration through the XPDinteg.xml file and the Custom Configuration Service approach is only for environments without a Device Management Server (DMS). A mix of both approaches is not recommended since configuration changes applied by the DMS are not reflected in the XPDinteg.xml file and will be overwritten as soon as the XPDinteg.xml file is changed.
file can be changed in multiple ways:
- Option 1: locally in the Expeditor integrator installation folder (on the remote server; that's we've already done in this chapter)
- Option 2: remotely through Expeditor integrator ConfigUpdate message (see also JKHLE's use case UC004 overview below)
- Option 3: through updating the XPDinteg.xml via file transfer (e.g. by using the Expeditor Server or software distribution tools).
Use case UC004 (Lotus Expeditor integrator configuration update through ConfigUpdate message)
Since the Lotus Expeditor integrator components are compliant to the OSGi / Equinox / Eclipse standard, they can be simply updated by using the standard OSGi bundle update mechanisms or Eclipse Plug-in Installation Manager. OSGi bundles and Eclipse Plug-ins can be remotely installed, started, stopped and updated without requiring the whole platform to be re-started. An OSGi bundle and service dependency resolution is automatically used to minimize the possibility of installation and deployment failures. Single application components might be remotely updated without effecting the running application. The IBM Lotus Expeditor Server offers remote OSGi bundle and Eclipse Plug-in management as well as configuration management. It is the recommended infrastructure component for large deployments in order to keep the operational effort minimal. The Lotus Expeditor integrator offers different update methods.
- Complete reinstall
This method is equal to the initial installation procedure that is described earlier in this document. All files in the original installation location are removed and replaced with a new Lotus Expeditor integrator package (all application files and configuration). This also involves the deletion of the local queues that might contain messages which belong to a transaction. Please, use this method with great care and only when no transactions are pending.
- Eclipse plug-in (component) update
This is the state-of-the-art method to update Eclipse RCP based applications. The Eclipse Rich Client Platform services ensure that only plug-ins (components/services) with resolved dependencies are finally started. They also allow application components updates without requiring a re-start, re-configuration of the platform / application nor the deletion of local queues (apart from the case when micro broker related services and components are affected; please
refer to the Administrators Guide for details).
Example: The file footer Activity BuildPriceUpdateFileFooterActivity in a FileTransfer Flow needs to be modified because the file footer creation algorithm was changed. This can be dynamically done by remotely updating the com.ibm.rcp.integrator.acsactivities application component (bundle) with a new version.
- Installation of new components to extend the application (bundles)
This is an extension of method 2 above. The Lotus Expeditor integrator can be simply extended with new Flows by providing new Flow definition files through the FileTransfer methods and adding new Activities by installing the components (plug-ins) that implement them using the remote Eclipse plug-in or OSGi bundle installation. This gives the Lotus Expeditor integrator powerful extension options and allows for remote adjustment of flows and use case implementations.