Server bundle overview
The application can be deployed in one or more workloads called server bundles. A server bundle isolates the workload processes so that they can be independently managed.
Server bundles can be independently scaled and managed based on your needs. For example, the user interface server bundle ui allows users to access the user interface by using a web browser. A cron task server bundle allows users to run background jobs. When a user interface workload and cron task workload are deployed as two separate server bundles, the CPU and memory that are consumed by these workloads do not affect each other.
A pod can be composed of one or more server bundles. The server bundles in a pod share the same database, network interface, storage volume, and resources, such as CPU and memory.
One server bundle that you deploy is designated as the default server. The server bundle that you designate as the default is used to establish the default URL, or route, that links to the Manage application in the workspace.
- You cannot have two server bundles that have the same bundle type. For example, you can specify only one server bundle of type ui. However, you can create a server bundle of type all in addition to another bundle type.
- If only one server bundle is specified, you must specify a bundle type of all. If you have only one bundle and do not specify type all for the default, the deployment might appear successful, but the application will not function properly.
- The default server bundle must have a bundle type of either all or ui. If you do not specify one of these types for the default, the deployment might appear successful, but the application will not function properly.
- If you create only one server bundle and do not specify a default, that bundle is selected as the default.
- If you create multiple server bundles and do not specify a default, a server bundle that has the type all is randomly selected as the default server.
When you deploy the application, you specify parameters that control deployment of the server bundle pods and their associated services and routes.
You can specify the following server bundle parameters to configure the deployment:
- Name
- The user-defined name for the server bundle. You can also specify whether the server bundle is the default server bundle.
- Pod count
- The number of pods to deploy for the server bundle.
- Type
- The type of the server bundle.
The following five bundle types are available:
- all - includes ui, cron, mea, and report bundle types.
- ui - includes the user interface components.
- cron - includes components that are required for cron tasks.
- mea - includes the enterprise web services API.
- report - includes components for reports.
- Additional server properties
- As an option, you can add the following properties:
- Route subdomain
- If you specify a subdomain, it is added as a prefix to the main domain when the route is created for the server bundle. For example, if you specify maximoui as a subdomain, your full domain is similar to the following example: maximoui.workspaceid.manage.domain.com.
- Additional server configurations
- To configure the WebSphere® Application Server Liberty
application server, you can provide custom parameters, as shown in the following example:
server-custom.xml: |- <!-- Enable features --> <featureManager> <feature>jsp-2.3</feature> </featureManager> <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" --> <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" /> <!-- Automatically expand WAR files and EAR files --> <applicationManager autoExpand="true"/>
- Bundle-level properties
- To add Manage system properties to specific server bundles, you can specify property names and values when you deploy the application.