OMServer parameter

Use the OMServer parameter to define the specification to run applications or agent and integration servers.

Each server can refer its own profile, property, affinityAndTolerations, and more. The following tables explain the attributes applicable to configure OMServer custom resource.

General properties

Table 1. General Properties for OMServer
Property	Default value	Value type	Required	Description
`name`		string	Yes	Specify the name of the OMServer. Ensure that the name is unique.
`appServeragentServerintegration`		object	Yes	Configure any one of the `appServer`, `agentServer`, `integration` for the OMServer custom resource. For more information, see Application server and Agent and integration server.
`replicaCount`	1	integer	Yes	Specify the number of instances to be deployed for this server. Deployment resource is created with this `replicaCount`. However, deployment can be scaled independently once it is created by Sterling™ Order Management System Operator.
`affinityAndTolerations`		string	No	Use the name of the affinityAndTolerations from attribute `affinityAndTolerations[].name` to be used by the server.
`image.tag`		string	No	Specify the image tag. This tag takes precedence over the tag defined in `OMEnvironment:spec.image.oms`. For more information about image precedence, see Image configuration precedence.
`image.name`		string	No	Specify the name of the image to be used for the selected server.
`image.variant`		string	No	Image variation to be used as a suffix. For example, `variant: "wsc"`. This will be combined with image name to form complete image name: `<imageName>-wsc`.
`image.digest`		string	No	Specify the image digest. If it is specified, it overrides the tag value. For more information about image precedence, see Image configuration precedence.
`pod.podAnnotations`		object	No	Specify any additional pod annotations as key-value pair. If the key specified in the OMServer `pod.podAnnotations` is same as the key specified in `common.pod.podAnnotations`, then this annotation is overridden.
`podLabels`		object	No	Specify additional pod labels as key-value pair. These pod labels are also copied to deployments.
`horizontalPodAutoscaler`		string	No	Specify the name of the pre-defined Horizontal Pod Autoscaler that is to be used. For more information, see horizontalPodAutoscalers parameter.
`topology`		array	No	Specify the names of the Topology Spread Constraints that are to be used for the server. For example, `topology: [constraint1, constraint2]`. For more information, see Examples to call Topology Spread Constraints from servers.
`profile`		string	No	Use the name of the profile from attribute `serverProfiles[].name` to be used by the server.
`property.customerOverrides`		string	No	Use the name of customerOverrides from attribute `serverProperties.customerOverrides[].groupName` or `serverProperties.customerOverrides[].derivatives[].groupName`. Set `multischema.enabled` to `true`, if you are setting up a multischema instance. If true, the installation looks for a customer-created multischema.xml file, which specifies database information for the Configuration, Metadata, Transaction, Master, and Statistics shards. Specify this property in lowercase only.
`property.envVars`		string	No	Use the name of envVars from attribute `serverProperties.envVars[].groupName` or `serverProperties.envVars[].derivatives[].groupName`.
`property.jvmArgs`		string	No	Use the name of jvmArgs from attribute `serverProperties.jvmArgs[].groupName` or `serverProperties.jvmArgs[].derivatives[].groupName`.
`upgradeStrategy`		string	No	Specify the deployment strategy to be used for upgrading the `OMServer` deployments. Available options are `RollingUpdate and Recreate`.

Application server

Table 2. Properties for Application server
Property	Default value	Value type	Required	Description
`appServer.dataSource.maxPoolSize`	50	integer	Yes	Specify the dataSource maximum pool size.
`appServer.dataSource.minPoolSize`	10	integer	Yes	Specify the dataSource minimum pool size.
`appServer.threads.max`	100	integer	Yes	Specify the maximum number of threads for app server.
`appServer.threads.min`	20	integer	Yes	Specify the minimum number of threads for app server.
`appServer.ingress.annotations`		object	No	Specify any additional annotations for ingress or routes resource as key value pairs.
`appServer.ingress.labels`		object	No	Specify any additional labels for ingress or routes resource as key value pairs.
`appServer.service.annotations`		object	No	Specify the additional labels for service resource as key value pairs.
`appServer.livenessFailRestartAfterMinutes`	10	integer	No	Specify the approximate time period in minutes after which the server restarts, if liveness check keeps failing for this period.
`appServer.serverName`	`DefaultappServer`	string	No	Specify the name of the app server.
`appServer.terminationGracePeriodSeconds`	60	integer	No	Specify the time period in seconds allowed for the pod to terminate gracefully, after which the processes running in the pod will be forcibly terminated.
`appServer.ingress.contextRoots`	`[smcfs, sbc, sma, isccs, wsc, adminCenter]`	array	No	Specify the context roots that can be accessed through ingress. If `contextRoots` are specified, the server startup is optimized such that the unused WAR files are automatically masked such that the application server does not load them. This saves valuable CPU and memory, and improves server startup time. By leveraging this feature, a single `om-app` image containing all the WAR files can be deployed with different `contextRoots` independently without affecting performance or resource utilization. If you are deploying IBM® Sterling Store Engagement (Next-generation), ensure to add `isf` to the list of `contextRoots`.
`appServer.ingress.customDomains`		array	No	Specify a list of `customDomains` with one or more Fully Qualified Domain Names (FQDNs) over which your application is exposed. For more information, see Creating multiple ingress hosts by using customDomains.
`appServer.libertyServerXml`	`default-server-xml`	string	No	Provide the configMap containing `server.xml` for Liberty. This parameter can be used to provide custom `server.xml` that contains customizations such as additional datasources for multischema and more. Note: If you use Order Management System property encryption, use this property to define your own server.xml file and configure your database passwords and any necessary encryption that you need.
`appServer.livenessCheckBeginAfterSeconds`	900	integer	No	Specify the approximate wait time in seconds to begin the liveness check.
`appServer.vendor`	`websphere`	string	No	Specify the vendor type.
`appServer.vendorFile`	`servers.properties`	string	No	Specify the vendor file.
`appServer.oidc.enabled`	false	string	No	Enable or disable OIDC.
`appServer.oidc.provider`		string	Yes	Specify the OIDC provider name.
`appServer.oidc.discoveryurl`		string	Yes	Specify the OIDC discovery URL.
`appServer.oidc.class`		string	No	Specify the OIDC class.
`appServer.oidc.uniqueClaim`	sub	string	No	Specify the OIDC unique claim details.
`appServer.oidc.secondaryid`	email	string	No	Specify the secondary ID.
`appServer.oidc.logouturl`		string	Yes	Specify the OIDC logout URL.

Agent and integration server

Generally, the agent or integration server is created as a deployment resource, so that the replicaCount is maintained. If the JVM running in the pod terminates for any reason, the deployment resource brings it back by creating another pod. Hence, the agent or integration servers remain active for servicing.

If an agent server is configured with Terminate on Idle, creating the agent server as a deployment resource causes conflict, as Kubernetes always keep matching the replicaCount. This conflict can be resolved by using the allowTermination.schedule property. If allowTermination.schedule is set to 'none', the Sterling Order Management System Software Operator creates a job resource, so that when the JVM terminates itself due to idle timeout, the pods are not brought back.

There can be scenarios when you want to start the agent servers such as purge agents, periodically. In such scenarios, a Kubernetes CronJob is an appropriate resource that can be created. To create a CronJob, specify a valid Cron string in the allowTermination.schedule property, as per your scheduling requirements.

For more information about the Cron scheduled pattern, see Cron schedule syntax.

Table 3. Properties for Agent and integration server
Property	Default value	Value type	Required	Description
`agentServer.namesintegration.names`		array	Yes	Specify the list of agent or integration servers to run. For example, `[searchCatalogIndex, scheduleAgent]`.
`agentServer.readinessFailRestartAfterMinutesintegration.readinessFailRestartAfterMinutes`	10	integer	No	Specify the approximate time period in minutes after which the agent or integration server restarts if readiness check keeps failing for this period.
`agentServer.terminationGracePeriodSecondsintegration.terminationGracePeriodSeconds`	60	integer	No	Specify the time period in seconds allowed for the pod to terminate gracefully, after which the processes running in the pod will be forcibly terminated.
`allowTermination.schedule`		string	No	Specify '`none`' to create the agent server as a `Job` resource. This ensures that when the JVM exits, the pod is not recreated. Specify a valid Cron string to create the agent server as a `CronJob` resource with the required scheduling time. Note: The `Job` resources are removed automatically after 300 seconds (5 minutes). When the agent server `Job` is complete, the `replicaCount` on the OMEnvironment and OMServer manifest is set to 0.

Image configuration precedence

The image configured at the OMServer level takes the highest precedence, overriding all others. If an image is not specified at the server level, the application uses the image details defined in spec.image.oms.  When both an image tag and an image digest are specified, the digest takes precedence over the tag.

Example:


  # Image information defined at the server level always take precedence 
  image:
    oms:
      appDefaultDigest: "sha256:123"
      tag: 10.0.2506.1-amd64-20250630-072948
  servers:
    - image:  
   # This tag takes highest precedence over the `image.oms.appDefaultDigest` and `image.oms.tag`
        tag: 10.0.2506.0-jdk21-amd64 
      name: apps

  # Digest always take precedence over tag
  image:
    oms:
      appDefaultDigest: "sha256:123"
      tag: 10.0.2506.1-amd64-20250630-072948
  servers:
    - image:
        tag: 10.0.2506.0-jdk21-amd64 
  # The following digest defined at server level takes highest precedence over all tags.
        digest: "sha256:456"  
      name: apps

Deploying smcfsdocs

The Sterling Order Management System Software Operator deploys Sterling Order Management System Software javadocs and exposes relevant ingress or routes for javadocs, if the following conditions are met:

image.name ends with docs
OR
image.variant equals to docs

Following routes are exposed for javadocs:

Core javadocs:
https://<ingress_subdomain>/smcfsdocs/yfscommon/core_javadocs/
API javadocs:
https://<ingress_subdomain>/smcfsdocs/yfscommon/api_javadocs/
Entity Relationship Diagram (ERD):
https://<ingress_subdomain>/smcfsdocs/yfscommon/ERD/HTML/

Examples to call Topology Spread Constraints from servers

Example 1: The following example demonstrates how server1 and server2 are spread evenly and independently, because of the matchLabelKeys.

spec:
  topologySpreadConstraints:
    - name: constraint1
      maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          app: oms
       matchLabelKeys: name

servers:
  - name: server1
    podLabels:
      name: server1
      app: oms # common
    topology: [constraint1]

  - name: server2
    podLabels:
      name: server2
      app: oms # common
    topology: [constraint1]

Example 2: The following example demonstrates how all the pods from server1 and server2 are considered together.

spec:
  topologySpreadConstraints:
    - name: constraint1
      maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          app: oms
  servers:
    - name: server1
      podLabels:
        name: server1
        app: oms # common
      topology: [constraint1]

   - name: server2
     podLabels:
       name: server2
       app: oms # common
     topology: [constraint1]