Customizing ODM for production
Before you install the Helm chart, customize some settings, for example, to protect your
containers or define the users and groups that access Decision Center and Decision Server .
Customizing your Liberty configuration
You can customize your WebSphere Liberty installation to use your own parameters.
Creating dedicated runtime pods for specific rulesets
You use this feature to create dedicated runtime pods for specific rulesets, and define paths that route the rulesets to the pods. This configuration provides greater isolation, improved scalability, and optimized performance for your decision service deployments. You get fine-grained control over resource allocation and configuration.
Defining scripts for container starts and stops
Operational Decision Manager (ODM) containers support Kubernetes lifecycle hooks, which allow users to inject scripts that are executed at key points in the lifecycle of a container.
Defining the security certificate
By default, IBM Operational Decision Manager is delivered with self-signed certificates. You can replace the default certificates with your own certificates, either CA signed or self-signed. You do so with certificate tools such as OCP native certificate management capabilities or cert-manager , or with the Java™ keytool.
Collecting and sending usage metrics
To maintain compliance with IBM licensing terms and conditions, collect and send Operational Decision Manager usage metrics to IBM Software Central .
Importing the certificate of an external service
To integrate with an external service, you must first import its Transport Layer Security (TLS) certificate into the containers trusted list.
Configuring user access
By default, IBM Operational Decision Manager is provided with a set of predefined users. To provide customized user access through an LDAP directory, you must configure the Liberty server and Decision Center by using Kubernetes secrets.
Configuring the database
Operational Decision Manager must persist data in a database.
Optimizing the execution unit (XU)
The Decision Server execution unit (XU) can be configured at installation time and also applied to an existing Operational Decision Manager instance. You can avoid deadlocks by adjusting the predetermined length of timeouts, restricting the number of rule instances to evaluate, and limiting the number of rules that can fire.
Emitting runtime events
Decision Server can send Kafka events to Business Automation Insights for use in dashboards as key performance indicators or to an Apache Kafka service for flexible integration with various other systems.
Configuring the Decision Center Business console
You can configure the Decision Center Business console to use your customized dynamic domains, custom value editors, or custom ruleset extractor.
Customizing Decision Server
You can customize the behavior of the Decision Server components through configuration maps.
Customizing Decision Center
You can customize the Decision Server behavior through a configmap that references a properties file with context parameters.
Customizing Decision Runner
In a topology where ODM is deployed in several namespaces inside a cluster or on several clusters, you might want to design decision services in a development environment (in a given namespace), to do tests and simulations in a staging environment (in another namespace), and finally to deploy the decision services to production on another cluster.
Configuring multi-zone support
You configure multi-zone support by setting the nodeAffinity parameter.
Configuring topology spread constraints on Operational Decision Manager pods
By defining topology spread constraints, you can control how the pods are spread across your cluster among failure domains such as regions, zones, and nodes. This facilitates high availability and fault tolerance in distributed systems.
Configuring custom pod anti-affinity on Operational Decision Manager pods
In Operational Decision Manager deployments (except the Decision Server console), a default pod anti-affinity setting is applied to spread the pods across the nodes by using preferredDuringSchedulingIgnoredDuringExecution . You can use the customPodAntiAffinity parameter to override this default setting.
Scheduling Operational Decision Manager pods onto tainted nodes
Taints and tolerations are used to ensure that pods are not scheduled on inappropriate nodes.
Configuring pod disruption budget on ODM deployments
The pod disruption budget (PDB) is part of the Kubernetes API for specifying safety constraints on pods during voluntary disruptions.