4.2.7 MicroTx Workflows Server Configuration

In the values.yaml file, under workflow.server, provide information about the environment details in which you want to install MicroTx Workflows.

Property	Description
appName	Enter the name of the MicroTx Workflows application that you want to install. When you install MicroTx, Helm creates the MicroTx Workflows application with the name that you specify. Note down this name as you will need to provide it later. For example, workflow-server.
replicaCount	Specify the number of MicroTx Workflows pod replicas that you want to create. Oracle recommends a minimum of 3 replicas for production environments. Development or test environments may be able to use fewer replicas.
image	Enter the tag of the MicroTx Workflows image that you have pushed to the remote repository. For example, workflow-server:1.0-SNAPSHOT. See Push Images to a Remote Docker Repository.
imagePullPolicy	Enter Always to ensure that the image is pulled during the installation. For more information, see Image pull policy in Kubernetes documentation.
imagePullSecret	Specify the name of the Kubernetes secret that you have created. This secret is used to pull the Docker images from the remote repository. For example, regcred. See Create a Kubernetes Secret to Access Docker Registry.
service.port	Enter the port over which you want to internally access MicroTx Workflows within the Kubernetes cluster where you will install this service. Create the required networking rules to permit inbound and outbound traffic on this port. Note down this number as you will need to provide it later. For example, 9010.
config.queue	Enter the storage type used to persist the MicroTx Workflows queue. The only supported value is oracledb.
config.metadata	Enter the storage type used to persist metadata. The only supported value is oracledb.
config.indexing.enabled	Mandatory. Set this to true to enable indexing.
config.indexing.type	Mandatory. Type oracledb as the indexing storage type.
metrics.enabled	Set this to true so that Prometheus can scrape the metrics of the MicroTx Workflows server. The default value is true.
scheduler.enabled	Set this to true to create, edit, view, or delete schedule definitions in MicroTx Workflows. Schedule definitions enable workflows to be executed automatically based on a configured schedule. The default value is true. If set to false, workflow executions cannot be scheduled.
logging.core.level	Specify one of the following log levels for the core MicroTx Workflows server. info: Logs events that occur during the normal operation of the MicroTx Workflows. This setting logs the least amount of information. This is the default setting. warning: Logs events that may cause potentially harmful situations. error: Logs events to indicate that there is an issue that requires troubleshooting. debug: Logs all the events. Use this setting when you want to debug an issue.
logging.microtx.level	Specify the log level for AI-related tasks as info, warning, error, or debug. You may want to set the log level to info for the MicroTx Workflows server and debug for AI-related tasks when troubleshooting or debugging issues in a task.
resources	Tune requests or limits according to workload throughput and cluster quotas. For more information about the limits enforced by Kubernetes, see Requests and limits in Kubernetes documentation.

• Data Store Properties
  MicroTx Workflows uses Oracle Database as data store to persist metadata and to store logs.
• Encryption Properties
  Under workflow.server.encryption, specify the encryption key that MicroTx Workflows uses to encrypt the access and refresh tokens. You must provide values for these properties if you have enabled authTokenPropagationEnabled under tmmConfiguration.authorization.
• Task Configuration Properties
  Under workflow.server.taskConfig, enter task-level property values that are shared across all tasks within a specific task category.
• Event Handler Configuration
  Under workflow.server.eventHandler, enable event handlers in MicroTx Workflows to listen to messages sent by Transactional Event Queues (TxEventQ) within MicroTx Workflows or to listen to external message brokers, such as Kafka. By default, event handlers created in MicroTx Workflows do not listen to message brokers.
• File System Storage Properties
  Under workflow.config.storage.filesystem, provide information about the file system you mount the MicroTx Workflows server.