Setting up the resource configuration for an EC pod
Adding specific Adding Image Added specific EC properties or Java related properties for an EC pod
Configuring the criteria for scaling the EC pod
Adding Dynamic Real-Time workflows
Adding Batch workflow groups to your EC Deployment
Creating services for your EC Deployment
Adding Annotations, Labels and Patches to your EC pod or services.
...
Ui tabs
Ui tab
title
Deployment Name
Deployment Name
Set the EC Deployment name in the field provided in this section.
Note!
The EC Deployment name must start with a letter and not end with a dash "-".
Ui tab
title
Configure EC
Execution Context
Set the properties for the Execution Context in this section.
Memory Configuration
You can tweak the JVM Xms and Xmx value of your EC. The default value for the Xms and Xmx are 512mb.
CPU Configuration
You can set the CPU request and limit values for the EC.
Advanced Settings
Under Advanced Settings, there are additional options that will allow you to further customize the EC.
Properties
Description
Node Host
Node Host will allow you to choose a node from your Kubernetes cluster to deploy the EC Deployment. Leaving this field empty will allow to allow to choose from any available nodes.
JVM Arguments
You can add additional JVM arguments for the EC's in your EC Deployment.
Example!
Use this format to add into the insert value window for JVM Arguments
System Properties
System properties for your EC can also be added. For a list of available system properties that you can configure for your EC, see .
Example!
Use this format to add into the insert value window for System Properties
Persistent Storage
Select a Kubernetes PersistentVolumeClaim to have your EC Deployment store its runtime data in a permanent storage option. This keeps the runtime data intact in case the EC Deployment faces an issue that requires it to be recreated. The data will be stored in the /opt/mz/runtime/persistent directory.
Rolling Update
Enabling Automatic Rolling Update will allow to allow to automatically update the EC pods in an EC Deployment whenever the Platform image is updated.
Rolling update will also help redeploy any dynamic Real Time workflow templates that are in the EC Deployment.
Note!
The workflow template will only be redeployed when you have added a new 'Per Workflow' configurable field to it or when you removed a 'Per Workflow' configurable field.
When you have disabled Automatic Rolling Update, you will still be able to update the EC Deployment by using the Upgrade button in the individual EC Deployment cards from the EC Deployment Overview page. The button will only be visible when the EC Deployment has detected a change in the image version or on the dynamic Real-Time workflow template.
Automatic Rolling Update is enabled by default when creating a new EC Deployment.
Enable on Schedule
If you select this option, the ECD will automatically be enabled according to the schedule of any workflow groups inside the ECD. This option is only available for batch workflows, and once the workflows finish running, the ECD will be disabled until the next run of the workflow group.
If there is a workflow group in the ECD with workflows running in sequence, the ECD will not start and stop between them. You can configure the minimum time interval required between runs for the ECD to disable, using the platform property dr.autoec.max.idle.wait, see fro more information.
This will allow you to save resources, since you can ensure that ECDs will not run when not needed, without requiring manual operations.
Additional Values
Additional options to apply Kubernetes annotations, labels and patches to your EC. Refer to for more information.
Enabling Auto Scaling
Enabling auto scaling will deploy a Kubernetes Horizontal Pod Autoscaler (HPA) on your EC Deployment. Auto scaling will tell your EC Deployment to create more EC pods, when the current EC Deployment has reached the threshold set by the metrics that are defined in this section.
To enable auto scaling, tick the Enable checkbox and fill in values for the following properties:
Properties
Description
Min Replicas
This value will indicate the minimum amount of EC pods that will be replicated for the initial set up.
Max Replicas
This value will indicate the maximum amount of EC pods that can be replicated for the EC Deployment.
Add/Edit Metrics
This button allows you to create or update a threshold for autoscaling. These thresholds are based on metrics values that are exposed by the Prometheus adapter. Once the threshold is reached, the EC Deployment will then create more EC pods to scale with the threshold.
By default, CPU Utilization is used but you can create your own custom metrics to be used instead. You can read more about what the Prometheus adapter does and how metrics are used from
Additional Values
Additional options to apply Kubernetes annotations, labels and patches to your EC. Refer to for more information.
Ui tab
title
Configuring Workflow
Workflow
Add dynamic real-time workflows or batch workflow groups to your EC Deployment in this section. If you have selected the Enable on Schedule option, the Real-Time Workflows section will be greyed out, since this option cannot be used with real-time workflows.
Real-Time Workflows
With EC Deployment, you can add workflows to your dynamic real-time Workflow Templates.
You configure a real-time workflow template to be dynamic in the Workflow Properties dialog when creating the Workflow Template in Desktop.
When your Workflow Templates are created, valid, and saved, they can be selected in the ECD configuration and workflows can be added.
With a load balancer and auto scaling configured, the EC Deployment will also be able to automatically scale additional workflows for your workflow template and distribute the load among several dynamic real-time workflows.
Select a Real-Time Workflow Template
To select dynamic real-time workflows, click on the icon in the Real-Time Workflows table. This will open a side panel where you can select and configure your workflow.
Setting
Description
Workflow Package
Contains a list of available workflow packages. By selecting a workflow package, you can select from the workflow templates within the package. See for more information regarding workflow packages.
Workflow Template
Contains a list of valid, dynamic real-time workflow templates in or in or in the selected workflow package.
Adding a Dynamic Real-Time Workflow
To add a dynamic real-time workflow, click on the icon in the Select a workflow template panel to open another panel where you can add workflows to your workflow template.
Fill in a name for the workflow and click on the Add Workflow button to add the workflow into the list.
Settings
Description
Workflow Name
Enter a name for the dynamic real-time workflow. The name must be unique for the chosen Workflow Template.
These are the actions you can take for each workflow added to the table.
Action
Description
Edit
Opens the Editing dynamic workflow side panel where you can edit any of the Configurable Fields that are present for the workflow. You will not be able to change the name of the workflow.
Delete
Removes the workflow from the workflow template.
Info!
From here, the real-time workflow is added into the workflow template but not created. The workflow will only be created when the EC Pod decides to run the workflow. To which it will exist until the workflow aborts or is forced to stop.
Real-Time Workflows Table Actions
These are the actions you can take for each dynamic Real-Time workflow templates that are added to the table.
Action
Description
Edit
Opens the Editing Workflow Template side panel and allows you to add more workflows to the workflow template. You will not be able to change the workflow package or the workflow template.
View
Opens a side panel that allows you to view the workflow template.
Delete
Removes the workflow template and all the number of workflows that are configured to it.
Adding Workflow Groups
You can add batch workflow groups into your EC Deployment. A workflow group is a collection of several workflows scheduled to execute at a certain time. You can create and schedule any batch workflow groups and have it assigned to the EC Deployment as an alternative to the , and you can configure the ECD to automatically be enabled/disabled based on the scheduling settings for the workflow group by selecting the option Enable on Schedule option in the previous Execution Context step to avoid having ECDs running when not needed.
When creating batch workflow groups using EC Deployment, the workflow groups will be able to take advantage of the EC Deployment's resource management to balance the load between running workflows and currently available EC Pods.
Having all your batch workflow groups in the EC Deployment will provide you with one single place to configure your workflow groups, saving you from having to look through a huge list in the workflow group and figuring out which workflow groups to update.
Regardless of whether you are using the EC Deployment Web Interface or the YAML file to manage your workflow groups, any updates done will be reflected on both the Web Interface and the YAML file.
Create A Workflow Group
To create a workflow group, click on the icon on the Workflow Group (Batch) table. This will open a dialog where you will go through 6 steps to add and configure a workflow group.
small
Define
Step 1 allows you to define the properties of the workflow groups.
The field in the Define step will be described in the following table. All fields are mandatory in this step:
Setting
Description
Folder
Enter the name of the folder that you want your workflow group to sit in. If the folder you have entered does not exist, a new folder with the name will be created.
Name
The name of the workflow group. Only alphanumeric values, dashes and underscores are allowed in the name.
Group Type
Batch & Task - This option is selected by default, since batch and task workflows are the only workflows available when creating workflow groups.
Real-Time - This option is disabled for workflow groups. Use the Real-Time Workflows option above to add real-time workflows to your ECD.
Create Workflows
Step 2 allows you to create a new dynamic workflow for the EC Deployment. The workflow templates listed in the table here indicates that all the workflows in the workflow templates are created for this EC Deployment. This is an optional step and can be skipped if you just want to create a workflow group from existing workflows.
To start adding Workflows, click on the icon. This will open a side panel where you can select your workflow template.
Properties
Description
Workflow Package
Contains a list of available workflow packages. Selecting a workflow package allows you to select workflow templates inside the package. See for more information regarding workflow packages.
Workflow Template
Conatins a list of workflow templates in or in or in the selected workflow package.
View Template
Click on this button to view the workflow template.
Adding a Batch Workflow
Clicking on the icon in the Select a workflow template panel will open another panel where you can add Workflows to your workflow template.
Fill in the required fields and click on the Add Workflow button to add the Workflow into the list.
The workflow will only be created upon successful creation of the EC Deployment.
Properties
Description
Workflow Name
Enter a name for the workflow. The name must be unique for the chosen Workflow Template.
Configurable Fields
If there are any Export Aliases that you have configured in the Workflow Table when creating the workflow template, those fields will appear here and you can customize the values for the fields. These fields can also be configured using External References.
Members
Step 3 allows you to select any existing workflows, workflow templates or workflow groups that will be part of the new workflow group.
What can be constituted as a member is as follows:
A workflow, workflow template or workflow group of the same Group Type can be included in the workflow group, even if they are already part of another group.
Static and dynamic workflows can be added into the same group.
For Dynamic workflows, you can add the workflow template or any workflows that are already part of the template.
A workflow , workflow template or workflow group from a workflow package.
A workflow template or workflow belonging to the workflow template can be added into the same workflow group. However when setting the prerequisite, you will have to arrange the workflow above the workflow template and the workflow template must set the workflow above it as the prerequisite.
Note!
Workflows that you have created in the Step 2 are included as members by default and cannot be de-selected. These workflows will appear with the naming format of <workflow name>-<ecd name>.
Info!
Workflows and Workflow Groups that were created from a different EC Deployment cannot be selected and will be greyed out.
Info!
For Workflows created in Step 2, if you do not want them to be part of the workflow group when selecting members, you can return to Step 2 and remove the workflow.
You must have at least one member in your workflow group to proceed to the next step.
Order and Prerequisite
Step 4 allows you to arrange the members in a certain order and select any prerequisites for executing the member workflows.
For members with prerequisites, the members will only be executed once the prerequisites have successfully executed. Dynamic workflow templates cannot be assigned as prerequisites for other members, but templates can have prerequisite member workflows.
Schedule
Step 5 allows you to add the schedule for the workflow group. Adding a schedule rule here is the same as adding a Day Plan Schedule in the workflow group in the Desktop.
The following table describes the fields found when adding a new schedule. This step is optional and a workflow group can be created first without any schedule. For dynamic workflow templates, all generated workflows by the workflow template will follow the schedule set by the workflow groups that the dynamic workflow template is grouped into. If you have selected the option Enable on Schedule in step2 EC, these settings will also control when the ECD is enabled and not, ensuring it is not enabled when not needed.
Note!
Two scheduled rules should not contradict each another. An example of an invalid configuration: Rule A is set to Tuesdays Off, while Rule B is set to Every 5 minutes between 15:00:00 and 15:05:00 on Tuesdays.
Entry
Description
Schedule type
Execution plan - Select this to set up a normal Day Plan schedule for executing the workflow group.
Day off plan - Select this to set up a time for when the workflow group will suspend its execution. You can only set up a day off plan when there is already an execution plan configured in the workflow group.
Choose Frequency
Select the frequency in which the workflow group will execute.
For Execution plans, you will have the options for Day, Week or Month, where you will be able to set up frequencies like:
Every day
A specific weekday
A specific day of the month (1-31)
The last day of the month
For Day off plans, you will only be able to select Week or Month, where you will be able to set up frequencies like:
Days off for up to 6 days a week
A specific day or days in a week
A day in a month
Several days in a month
Execution Interval
This option is only available when setting an Execution plan.
Once - Select this if you want the workflow group to execute its members only once during the selected frequency.
Repeatedly - Select this if you want the workflow group to execute and stop its members within a certain time frame of the selected frequency.
Start Time
This option is only available when setting an Execution plan.
Enter a start time for the first execution.
Stop Time
This option is only available when setting an Execution plan.
Enter the time for when execution should stop.
Repeat Every
Enter the interval between execution start time in seconds, minutes, or hours.
Note!
If a member in a group is delayed for some reason, and notfinished at the time the execution is set to be repeated, all members in the group will have to wait until the next repeat time. To override this behavior, you can use the Continuous execution on scheduled timesetting.
Select Days
This option appears when you have selected the Day off plan. This option will set the interval of the day(s) off for the week or month.
Execution
Step 6 allows you to set the execution strategy for the members within the workflow group.
The following table describes the fields found in the execution step:
Note!
Execution settings that you configure here, will only apply for workflow members that have not been configured with any execution settings in the workflow properties. Any execution settings configured in the workflow properties will take priority over the ones configured in the workflow group.
Entry
Description
Max Simultaneous Running Workflows
No limit - There will be as many simultaneously running workflows in the workflow group as determined by your specific work environment and equipment.
Specify the Limit - Enter the maximum number of workflows you want to be able to run concurrently.
Note!
This value applies only to the workflow group that you are defining and will not affect members that are workflow groups.
Startup Delay
If Max Simultaneous Running Workflowsis set to a value larger than 1, enter the delay (in seconds) of the execution start for each of the workflows that may run simultaneously.
Note!
If no value is entered, a short delay will be applied by the system.
You can assign a Startup Delay regardless of the members status. Once the delay is up, if the member in turn is disabled, the Workflow group will attempt to execute the next member.
Continuous execution on scheduled time
Select this check box if you want to allow members in scheduled workflow groups to execute on schedule even though all workflow members in the group have notfinished execution.
This may be useful in case one member is delayed for some reason, whereby preventing the remaining workflow members from executing on schedule.
Note!
This feature is not supported for nested group members, only workflow members.
For a workflow group with a member that is delayed over the next scheduled time, this setting will make the member execute immediately when it is finished. The workflow group will be in a continuous Running state, not switching to Idle in between executions as is the default behavior.
This needs to be considered when making configurations based on workflow group states.
Workflow group specific execution settings
This check box is enabled to allow distribution rules to be configured by the EC Deployment.
Specify EC Groups
For EC Deployment, an EC Group with the EC Deployment name will be created and this field will display that EC Group. Only one EC Group for one EC Deployment will exist at any one time.
Any new EC pods created by the EC Deployment as a result of auto scaling will be automatically included in the EC Group for this EC Deployment.
You will not be able to edit this field.
Distribution rules
The Distribution rules are applied to all included group members, such as workflows and workflow group configurations. When there are conflicting settings, the members that are lowest in the workflow group hierarchy have precedence.
When the Distributionrules of the workflow group configurations are set on the same level in the hierarchy, they do not conflict with each other.
If an EC Deployment has multiple EC pods, the selected distribution rule will be applied on the EC pods within the EC Group for the EC Deployment.
Sequential - Starts the workflow on the first EC pod in the EC Group. If this EC pod is not available, it will proceed with the next in line.
Workflow Count - Starts the workflow on the EC pod in the EC Group running the fewest number of workflows.
Machine Load - Starts the workflow on the EC pod in the EC Group with the lowest machine load. Which EC pod to select is based on information from the System Statistics sub-system.
Round Robin - Starts the workflow on the available EC pods in the EC Group in turn, but not necessarily in a sequential order. This is the default option for Distribution rules.
Continue
Enabling this option will cause the workflow group to continue to run until all its members are fully executed or all are aborted.
Note!
This means that groups with real-time workflow members will continue to run until all the members are aborted or stopped manually.
Stop
Enabling this option will cause the workflow group to stop when a member aborts. A batch Workflow member will finish the current batch and then stop, while a real-time workflow will de-initialize and then stop.
Stop Immediately
Select this option to have the workflow group stop immediately when a member aborts. A batch workflow will stop even in the middle of processing a batch.
The workflow group with the naming format of <wfg name>-<ecd name> will be created once the EC Deployment is created. This is the same with workflows created with workflow templates in Step 2.
You can view the workflow group and its members in the Workflow Group Web Interface when the EC Deployment is successfully created. However, EC Deployment created workflow groups, including the workflows created under Step 2 will be read only on the Workflow Group Web Interface and will have to be edited or removed on the EC Deployment that it was created from.
Workflow Group (Batch) Table Actions
These are the actions you can take for each workflow group that is added to the table.
Action
Description
Edit
Opens the dialog window for editing the workflow group, allowing you to add or remove members or edit the workflow group's configuration.
Delete
Removes the workflow group. If you have created a dynamic workflow with this workflow group, it will also be removed.
Ui tab
title
Configuring Network
Network
You can choose to create your own network services using EC Deployment.
There are 4 network types that you can add and these are:
Ingress
Cluster IP
Load Balancer
NodePort
Ingress
Setting up the Ingress in EC Deployment will allow your EC Deployment to handle scaling and distribution of any incoming HTTP traffic for the Dynamic workflows that you have linked to your EC Deployment. The ingress will work only with the HTTP2 Server agent.
Before setting up this ingress, you will need to have performed the necessary TLS certificate configuration for your ingress and Kubernetes instances.
bash
The following are the properties to be filled in when creating an ingress. Only 1 ingress per EC Deployment will be allowed.
Properties
Description
Name
The name of your ingress. The suggested naming convention will have the ECD name followed by a -ingress at the end, like so <ECDname>-ingress.
You need not follow the suggested name and you can choose to name your service according to your own conventions. However, the name must start with a letter and not end with a dash "-".
TLS Secret Name
The name of the Kubernetes secret that you have created for your ingress.
Host Name
The hostname that has been set for the CN in the TLS certificate used to create the Kubernetes secret.
Port Name
The name of the port for your Ingress Rule.
Path
The HTTP path being used by the HTTP2 Server agent in the dynamic workflow that you have added into your EC Deployment.
Port
The port being used by the HTTP2 Server agent in the workflow that you have added into your EC Deployment.
Cluster IP
The cluster IP in EC Deployment will function much like the standard Kubernetes cluster IP service. The cluster IP will expose the services within the EC Deployment to other containers within the environmentthe environment.
The following are the properties to be filled in when creating a cluster IP:
Settings
Description
Service Name
The name of your Cluster IP service. The suggested naming convention will have the ECD name followed by a -clusterip and a sequence number at the end, like so <ECDname>-clusterip-<sequence number>. The sequence number will increase in sequence as you add more service of the same type.
You need not follow the suggested name and you can choose to name your service according to your own conventions. However, the name must start with a letter and not end with a dash "-".
Port Name
The name of the port for your Cluster IP.
Port
The port number used by the service in within the EC Deployment that you will want to expose to the environmentthe environment.
Protocol
Choose the protocol used by the port, either TCP or UDP.
Load Balancer
The load balancer in EC Deployment will function much like the standard Kubernetes load balancer service. It will allow your EC Deployment to handle the load and distribution of incoming TCP and UDP traffic for the Dynamic workflows that you have linked to your EC Deployment.
The following are the properties to be filled in when creating a load balancer:
Settings
Description
Service Name
The name of your Load Balancer service. The suggested naming convention will have the ECD name followed by a -loadbalancer at the end, like so <ECDname>-loadbalancer-<sequence number>. The sequence number will increase in sequence as you add more service of the same type.
You need not follow the suggested name and you can choose to name your service according to your own conventions. However, the name must start with a letter and not end with a dash "-".
Protocol
Choose the protocol used by the port, either TCP or UDP.
Port Name
The name of the port for your Load Balancer.
Port
The port number to be used by the collection agents in the Dynamic workflow.
NodePort
The NodePort in EC Deployment will function much like the standard Kubernetes NodePort service. The NodePort will generate an IP for itself and expose the services within the EC Deployment to any applications outside of the environmentthe environment.
The following are the properties to be filled in when creating a NodePort:
Settings
Description
Service Name
The name of your NodePort service. The suggested naming convention will have the ECD name followed by a -nodeport at the end, like so <ECDname>-nodeport-<sequence number>. The sequence number will increase in sequence as you add more service of the same type.
You need not follow the suggested name and you can choose to name your service according to your own conventions. However, the name must start with a letter and not end with a dash "-".
Port Name
The name of the port for your NodePort.
Port
The port number used by the service in within the EC Deployment that you will want to expose to the environmentthe environment.
Protocol
Choose the protocol used by the port, either TCP or UDP.
External Traffic Policy
You can set the NodePort to either have cluster or local policy.
Additional Values
You can also apply Kubernetes annotations, labels and patches to the network services. Refer to for more information.
Network Table Actions
These are the actions you can take for each network services that are added to the table.
Action
Description
Edit
Opens the side panel for editing the network services, allowing you to update the configuration.
Delete
Removes the network service.
Ui tab
title
Summary
Summary
Before you finish setting up your EC Deployment, you will be given the chance to review the configuration that you have set for your EC Deployment. From the Summary page, you can return to any of the previous pages to mend any of the configuration or to add more. You can download the yaml file of the EC Deployment for you to customize or to kubectl apply to any other enviother environment.
You can also switch to Yaml View to inspect the yaml syntax for the provisioning of the EC Deployment itself. However, you will not be able to edit the yaml syntax.
Clicking on the Create button will prompt you with a window to start the EC Deployment. Clicking on No will create the EC Deployment, but it will not be started. You can then start it on your own accord from the EC Deployment overview page. Clicking on Yes will create and start the EC Deployment.
specific EC properties or Java related properties for an EC pod