Page tree

Versions Compared

Key

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

...

UI Tabs


UI Tab
titleDeployment Name

Deployment Name

Set the EC Deployment name in the field provided in this section.

Note
titleNote!

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



UI Tab
titleConfigure 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.

PropertiesDescription
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

Drx product name
to choose from any available nodes.

JVM Arguments

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

Info
titleExample!

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. For a list of available system properties that you can configure for your EC, see EC Properties[hide]2.2[/hide].

Info
titleExample!

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.

Rolling Update

Enabling Automatic Rolling Update will allow

Drx product name
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
titleNote!

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.

Additional ValuesAdditional options to apply Kubernetes annotations, labels and patches to your EC. Refer to Adding Labels, Anotations and Patches[hide]2.2[/hide] 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:

PropertiesDescription
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 Autoscaling ECD with Metrics[hide]2.2[/hide]

Additional ValuesAdditional options to apply Kubernetes annotations, labels and patches to your EC. Refer to Adding Labels, Anotations and Patches[hide]2.2[/hide] for more information.



UI Tab
titleConfiguring Workflow

Workflow

Add dynamic Real-Time workflows or Batch workflow groups to your EC Deployment in this section.

Adding Real-Time Workflows

Using EC Deployment, you can add workflows to your dynamic Real-Time workflow template.

Additionally, with a load balancer and auto scaling configured, the EC Deployment will then be able to automatically scale additional workflows for your workflow template and distribute the load among more dynamic Real-Time workflows. 

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.

ActionDescription
EditOpens the Select a 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.
ViewOpens a side panel that allows you to view the workflow template.
DeleteRemoves the workflow template and all the number of workflows that are configured to it.

Select A Workflow Template

To start adding dynamic Real-Time workflows, click on the icon on the Real-Time Workflows table. This will open a side panel where you can select and configure your workflow.

PropertiesDescription
Workflow Package

A list of workflow packages that are in your

Drx product name
. Selecting a workflow package will allow you to select the workflow templates from within it. You can refer to Workflow Packages[hide]2.2[/hide] for more information regarding workflow packages.

Workflow Template

A list of Real-Time workflow templates in your

Drx product name
or from the selected workflow package.

Select A Workflow Template Table Actions

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

ActionDescription
EditOpens the Editing dynamic workflow side panel and allows you to edit any of the Configurable Fields that are present for the workflow. You will not be able to change the name of the workflow.
DeleteRemoves the workflow from the workflow template.

Adding A Dynamic Real-Time Workflow

Clicking on the icon in the Select a workflow template panel will open another panel where you can add dynamic Real-Time workflows to your workflow template.

Fill in the required fields and click on the Add Workflow button to add the Workflow into the list.

Info
titleInfo!

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.


PropertiesDescription
Workflow Name

Name for the dynamic Real-Time workflow. The name must be unique for the chosen dynamic Real-Time Workflow template.

Configurable Fields

If there are any Export Aliases that you have configured in the Workflow Table when creating the dynamic Real-Time 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.



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 Workflow Group Web Interface[hide]2.2[/hide].

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 on the EC Deployment will provide you with only one 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.

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

Workflow Group (Batch) Table Actions

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

ActionDescription
EditOpens the dialog window for editing the workflow group, allowing you to add or remove members or edit the workflow group's configuration. 
DeleteRemoves the workflow group. If you have created a dynamic workflow with this workflow group, it will also be removed.

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.

UI Steps
sizesmall


UI Step

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:

FieldDescription
FolderEnter 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.
NameThe name of the workflow group. Only alphanumeric values, dashes and underscores are allowed in the name.
Group Type

Batch & Task - Select this type if your workflow group is comprised primarily of Batch or Task type workflows or workflow groups.

Real-Time - This option is disabled for EC Deployment. Use the Real-Time Workflows option above to create workflows for your Real-Time workflow templates.



UI Step

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.

To start adding Workflows, click on the icon. This will open a side panel where you can select your workflow template.

PropertiesDescription
Workflow Package

A list of workflow packages that are in your

Drx product name
. Selecting a workflow package will allow you to select the workflow templates from within it. You can refer to Workflow Packages[hide]2.2[/hide] for more information regarding workflow packages.

Workflow Template

A list of workflow templates in your

Drx product name
or from the selected workflow package.

View TemplateAllows you 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.

PropertiesDescription
Workflow Name

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.



UI Step

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
titleNote!

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
titleInfo!

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


Info
titleInfo!

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.


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



UI 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 on 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.

Note
titleNote!

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
titleNote!

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



UI Step

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
titleNote!

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
titleNote!

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.

Note
titleNote!
  • 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. 

Note
titleNote!

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

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
titleNote!

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.


UI Tab
titleConfiguring 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

Network Table Actions

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

ActionDescription
EditOpens the side panel for editing the network services, allowing you to update the configuration.
DeleteRemoves the network service.

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.

Code Block
languagebash
#!/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.

PropertiesDescription
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 NameThe name of the port for your Ingress Rule.
PathThe HTTP path being used by the HTTP2 Server agent in the dynamic workflow that you have added into your EC Deployment.
PortThe 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

Drx product name
environment.

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

PropertiesDescription
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 NameThe 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

Drx product name
environment.

ProtocolChoose 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:

PropertiesDescription
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 "-".

ProtocolChoose the protocol used by the port, either TCP or UDP.
Port NameThe 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 

Drx product name
environment.

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

PropertiesDescription
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 NameThe 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

Drx product name
environment.

ProtocolChoose the protocol used by the port, either TCP or UDP.
External Traffic PolicyYou 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 Adding labels, annotation and patch for more information.


UI Tab
titleSummary

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

Drx product name
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.


...