Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Rw ui tabs macro
Rw tab
isMissingRequiredParameterstrue
titleConfigure EC
image-20240213-142111.png

EC Deployment

Set the EC Deployment name.

image-20240213-142415.png
Info

Info!

The EC Deployment name must start with a letter and not end with a dash "-".

Memory Configurations

You can tweak the JVM Xms and Xmx value of your EC. The default value for the Xms and Xmx are 512mb.

image-20240213-142518.png

CPU Configurations

You can set the CPU request and limit values for the EC.

image-20240213-142534.png

Advanced Settings

Under Advanced Settings, there are additional options which you can use to further customize the EC.

image-20240213-142553.png

Setting

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 Usage Engine to choose from any available nodes.

Java Arguments

You can add additional JVM arguments for the EC's in your EC Deployment.

Use this format to add into the insert value window for JVM Arguments

Code Block
-XX:MaxDirectMemorySize=4096M

System Properties

System properties for your EC can also be added.

Use this format to add into the insert value window for System Properties

Code Block
max.cached.prepared.statements=true

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.

Automatic Rolling Update

Enabling Automatic Rolling Update will allow Usage Engine to automatically update the EC pods in an EC Deployment whenever the Platform image is updated.

Automatic Rolling update Update will also help redeploy any dynamic Real Time workflow templates that are in the EC Deployment.

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. The user interface will display a warning for the EC Deployment in question stating that “EC version is out of sync with platform“.

Automatic Rolling Update is enabled by default when creating a new EC Deployment.

This option is called “manualUpgrade” in the ECD specification and is the inverse of this checkbox.

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.

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 Adding Labels, Anotations and Patches (4.12) for more information.

Rw tab
isMissingRequiredParameterstrue
titleConfigure Auto Scale
image-20240213-142659.png

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.

image-20240213-142644.png

To enable auto scaling, tick the Enable Auto Scaling checkbox and fill in values for the following properties:

Setting

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.

Scaling 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 Autoscaling ECD with Metrics (4.0).

Additional Values

Additional options to apply Kubernetes annotations, labels and patches to your EC, see Adding Labels, Anotations and Patches (4.12).

Rw tab
isMissingRequiredParameterstrue
titleConfigure Workflow
image-20240213-142726.png

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 Dynamic Real-Time Workflow section will be greyed out, since this option cannot be used with real-time workflows.

image-20240213-142749.png

Dynamic 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.

image-20240213-142826.png

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.

Creating a Dynamic Real-Time Workflow

To add dynamic real-time workflows, click on the New Dynamic Real-Time Workflow button. This will open a side panel where you can select and configure your workflow.

image-20240213-142932.png

Setting

Description

Workflow Template

Contains a list of valid, dynamic real-time workflow templates.

Add a Dynamic Real-Time Workflow

To add a dynamic real-time workflow, click on the New Workflow button in the Dynamic Real-Time Workflow panel to open another panel where you can add workflows to your workflow template.

image-20240213-142955.png

Fill in a name for the workflow and click on the Apply button to add the workflow into the list.

Setting

Description

Workflow Name

Enter a name for the dynamic real-time workflow. The name must be unique for the chosen Workflow Template.

image-20240213-143027.png

These are the actions you can take for each workflow added to the table.

Option

Description

Edit

Opens the Dynamic Real-Time Workflow 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 on, 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.

Dynamic Real-Time Workflows Table Actions

image-20240213-143136.png

These are the actions you can take for each dynamic Real-Time workflow templates that are added to the table.

Option

Description

Edit

Opens the Dynamic Real-Time Workflow 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.

Delete

Removes the workflow template and all the number of workflows that are configured to it.


Batch Workflow Group

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 Workflow Group Web Interface(4.0), 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 New Batch Workflow Group button on the Batch Workflow Group table. This will open a dialog where you will go through 6 steps to add and configure a workflow group.

Rw step

Define

Step 1 allows you to define the properties of the workflow groups.

image-20240213-143217.png

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.

Rw step

Select Members

Step 2 allows you to create a new dynamic workflow or select any existing workflows, workflow templates or workflow groups that will be part of the new workflow group 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.

image-20240213-143253.png

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.

Create Dynamic Workflow

To create a new dynamic workflow, click on the Create Dynamic Workflow button. This will open a side panel where you can select your workflow template and add workflows.

image-20240213-143338.png

Adding Existing Workflows, Templates or Groups

Clicking on the Existing Workflow GroupExisting Workflow Template or Existing Workflow will open another panel where you can add groups, templates and workflows to your Batch Workflow Group.

Fill in the required fields and click on the OK button to add the item into the list.

image-20240213-143402.png

Select Members Table Actions

image-20240213-143708.png

These are the actions you can take for each members that are added to the table.

Option

Description

Edit

Opens the Dynamic Batch Workflow panel and allows you to add more workflows to the template. You will not be able to change the workflow package or the workflow template.

Delete

Removes the selected member and all the number of workflows that are configured to it.

Info

The workflows will only be created upon successful creation of the EC Deployment.

Info

Workflows and Workflow Groups that were created from a different EC Deployment cannot be selected and will be greyed out.

Info

You must have at least one member in your workflow group to proceed to the next step.

Rw step

Order & Prerequisite

Step 3 allows you to arrange the members in a certain order and select any prerequisites for executing the member workflows.

image-20240213-143840.png

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.

Rw step

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.

image-20240213-143933.png

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, these settings will also control when the ECD is enabled and not, ensuring it is not enabled when not needed.

Info

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.

Setting

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.

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

This option is only available when setting an Execution plan.

Enter the interval between execution start time in seconds, minutes, or hours.

If a member in a group is delayed for some reason, and not finished 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 time setting.

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.

Rw step

Execution

Step 5 allows you to set the execution strategy for the members within the workflow group.

image-20240213-144350.png
Info

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.

The following table describes the fields found in the execution step:

Setting

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.

Info

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 Workflows is 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.

Info

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 not finished execution.

This may be useful in case one member is delayed for some reason, whereby preventing the remaining workflow members from executing on schedule.

Info

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.

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 Distribution rules 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.

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.

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.

Action on Error

Continue - Enabling this option will cause the workflow group to continue to run until all its members are fully executed or all are aborted.

Info

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.

Batch Workflow Group Table Actions

image-20240213-145612.png

These are the actions you can take for each workflow group that is added to the table.

Option

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.

Rw tab
isMissingRequiredParameterstrue
titleConfigure Network
image-20240213-145648.png

Network

You can choose to create your own network services using EC Deployment by clicking the Net Network button.

image-20240213-145747.pngimage-20240213-145812.png

There are 4 network types that you can add and these are:

  • Ingress

  • ClusterIP

  • LoadBalancer

  • 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.

image-20240213-150004.png

Before setting up this ingress, you will need to have performed the necessary TLS certificate configuration for your ingress and Kubernetes instances.

Code Block
#!/bin/bash
KEY_FILE=TLS_key_name.pem
CERT_FILE=TLS_ce_name.ce
HOST=hostname.domain.name
CERT_NAME=tlscertname
  
NAMESPACE=
  
if [ -z "$NAMESPACE" ]
then
      echo "You must set a namespace!"
      exit
fi
  
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ${KEY_FILE} -out ${CERT_FILE} -subj "/CN=${HOST}/O=${HOST}"
  
kubectl create secret secret-name ${CERT_NAME} --key ${KEY_FILE} --cert ${CERT_FILE} -n ${NAMESPACE}

The following are the properties to be filled in when creating an ingress. Only 1 ingress per EC Deployment will be allowed.

Setting

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.

Port Path

The HTTP path being used by the HTTP2 Server agent in the dynamic workflow that you have added into your EC Deployment.

Port Number

The port being used by the HTTP2 Server agent in the workflow that you have added into your EC Deployment.


ClusterIP

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  environment.

image-20240213-150055.png

The following are the properties to be filled in when creating a cluster IP:

Setting

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 Number

The port number used by the service in within the EC Deployment that you will want to expose to the Usage Engine environment.

Protocol

Choose the protocol used by the port, either TCP or UDP.


LoadBalancer

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.

image-20240213-150123.png

The following are the properties to be filled in when creating a load balancer:

Setting

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 Number

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   environment.

image-20240213-150148.png

The following are the properties to be filled in when creating a NodePort:

Setting

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 Number

The port number used by the service in within the EC Deployment that you will want to expose to the Usage Engine 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, see Adding Labels, Anotations and Patches (4.12) .

Network Table Actions

image-20240213-150529.png

These are the actions you can take for each network services that are added to the table.

Option

Description

Edit

Opens the side panel for editing the network services, allowing you to update the configuration.

Delete

Removes the network service.

...