The Workflow feature allows you to automatically trigger one or more tasks after the execution of another task, based on the result status of that execution.
It enables conditional automation between tasks in the same project.

How It Works

After a task execution, you can define rules that specify:

• Status condition – The execution result that will trigger the rule.
  Possible statuses are:
  • Success
  • Warning
  • Error
  • Terminated
• Target task – The task(s) to launch automatically when the selected status condition is met.

Each rule defines a link between a source task and one or more target tasks, allowing complex workflows to be created across the project.

Rule Creation

• Select a status condition (e.g., Success).
• Choose one or several target tasks to execute when that status occurs.
• You can select any task in the project, except the current one.
• Optionally enable or disable the rule using the “Is active” switch.

• Click Add rule to save it.

You cannot create multiple rules with the same combination of status condition and target task for the same task.

If you launch a task with a workflow you’ll be prompted to launch it with the workflow or without it

Multiple Tasks per Status

You can assign several target tasks for the same status, as long as they are different tasks.
Each active rule will trigger independently when the matching status is reached.

Disabled Target Tasks

If a target task is disabled, the workflow will not execute it.
However, it will still appear in the workflow summary table and will be marked as disabled for visibility.

Linked Tasks Overview

At the bottom of the workflow configuration page, two tables are displayed:

• Workflow rules – Lists all rules defined for the current task, grouped by status (e.g., SUCCESS, WARNING, etc.).
• Tasks triggering this task – Shows all other tasks that have configured this one as a target.
  Each entry includes a direct link to the originating task.

Execution Logs and Workflow Tracking

When a task is executed as part of a workflow, the execution logs provide additional details to help you understand what triggered the task and what tasks will be triggered afterwards. This makes it easy to follow the entire chain of executions in a workflow.

Example setup

n the following example, when a task completes with a Success status, two target tasks are defined:

• wait_and_see
• EAC_testContextType_test_4

Trigger Information

At the top of the execution log of a workflow-triggered task, you will see which task caused this execution, under which status, and at what time.

For example:

The current execution was triggered following execution #6028 – EAC_testContextType_test_52, which ended with status SUCCESS at 11:38:41.

Triggered Tasks Table

At the bottom of the execution view of the initial task (the one that finished with the triggering status), a summary table lists all the tasks that have been launched as a result of its execution.

This table includes:

• Task ID and name
• Project
• Job version
• Start and end date
• Duration
• Type and server
• Current execution status

Once all target tasks are finished, you can return to the execution view of the original triggering task to see the completed summary of all triggered tasks.

Example

If task A completes with a Success status, and a workflow rule links it to task B,
then task B will be automatically triggered as soon as A finishes successfully.
If both B and C are defined for Success, both will be triggered in sequence.

Next see Retry auto.

L’article Workflow est apparu en premier sur ETL administration console.

Configuration

In the “Post process” tab, a new Retry auto section has been added.

Here, users can configure:

• Retry count → number of times the system should retry the task
• Delay between retries (in seconds) → waiting time between two retry attempts

If a task ends in ERROR or TERMINATED, it will automatically be retried according to these settings.

Execution Flow

When an execution fails:

• A new retry execution is automatically queued.
• The retry execution keeps the same Identifier but is shown as a new Execution ID.
• The system logs clearly show the relationship between the initial task and its retry executions, including the sleep duration applied based on the configured retry policy.

• On the initiating task, you can see the list of all related executions (the initial one and all retries) at the bottom of the page.

Next see Worflows.

L’article Retry auto est apparu en premier sur ETL administration console.

• EAC detects new versions of a job at deploy time and keeps all prior versions.
• You can run, compare, or roll back by selecting the desired version.
• Jobs list.

Access

• From a Job page, open the Versions tab.
• Click a version row to view its details.

Versions table

• Name – Job name inside the artifact.
• Version – Semantic/Talend job version (e.g., 0.1, 0.2, 1.0).
• Date – Build/deploy timestamp.
• Context – Context used when the version was compiled/deployed (e.g., Prod, Test, Dev).
• Deploy errors – Quick status (✓ when none).
• Deploy folder – Absolute path of the deployed payload on the server.
• Action –
  • Add execution task for this version.
  • Delete version.

Search, pagination, and column sorting are available.

Version detail

• Thumbnail/Screenshot of the job design (and subtasks if present).
• Compiled version banner: selected version, context, deploy time, and deploy folder.
• Context parameters matrix: values per context (columns like Default, docker), including encrypted values where applicable.

L’article Job Versions est apparu en premier sur ETL administration console.

In this page:

take a look at what is possible to do on a task setup

• Key concepts
• Properties (task setup)
• Notifications
• Contexts
• Create a task · Run a task
• Track executions
• Find & manage tasks (global list)
• Modify a task
• Duplicate a task

Key concepts

• Task – Runnable entity that references a Job/Version and a Context.
• Context – Key/value parameters the job runs with (e.g., endpoints, credentials).
• Overrides – Per-task key/value changes that supersede the selected context.
• Ack (Acknowledgement) – After a failure, require a manual “ack” before resuming schedules.
• Purge – Per-task retention to keep storage and UI fast.
• Scheduler – Engine that triggers runs (supports sub-minute intervals).

Properties (task setup)

Go to Task setup to configure the fields below.

Notifications

Notification status

Notification settings are available in the Post-process tab.

• Disabled — No emails sent.
• Enabled (failures only) — Email on failed/blocked/aborted runs.
• Enabled — Email on every run (success + failure).

Notification recipients
Comma or semicolon-separated list of emails. Spaces are ignored; duplicates are removed.
Examples:

ops@example.com; oncall@example.com
dev1@example.com,dev2@example.com;qa@example.com

Behavior

If status ≠ Disabled and the recipient list is empty/invalid, the run is logged with a notification warning (no email sent).

Contexts

Each task exposes all contexts defined in the Talend job at build time (e.g., Default, QA, Prod). You pick one and may override specific keys.

Precedence (last wins)

1. Selected context — the context chosen in the Context dropdown.
2. Task overrides — values you enter in Task::__overwrite.

Important: Don’t forget to enable Enable context overloading; otherwise, context overrides in Task::__overwrite won’t take effect.

Guidance

• Choose a custom context when you need a full alternative set.
• Use overrides for a few keys specific to this task.
• For deeper advice, see Good use of context.

Create a task

A task is the link between a job and an execution context.
When you deploy a job for the first time, EAC prompts you to create a task. You can also create tasks later from any job.

Procedure

1. Open the jobs’s page select the job and click Tasks tab.
2. Click the button [Add a task for this job]
3. From the job page click Versions tab, click the + (Create a new task) action button.
4. Then in Task setup, choose Job version, select a Context (see Contexts), optionally enable context overloading and add overrides.
5. By default, the task name inherits the job name. Rename it if needed for better tracking.
6. (Optional) Configure Scheduler, Notifications, Ack, and Purge.
7. Save.

Tip: Prefer contexts for big changes; use overrides for a small number of keys.

Run a task

• From the task page (Task setup), click Launch the task.
• From the Tasks list, click the Play icon in Action.

• from the job click Execute task, select your task from the dropdown menu.

You need at least one active execution server to run tasks, see execution servers.

Track executions (per task)

From the Tasks list, click the task ID to open the Last executions tab:

• Shows the latest 10 runs by default (use Show to display more).
• Bulk actions: select multiple runs to delete; per-row delete is also available.
• A small chart summarizes recent outcomes.
• Filters: by Status, From/To (start/end date & time).

Click an execution ID to open the Execution task page:

• Live Execution logs (and ETL logs if enabled).
• Main run metadata: start/end time, duration, server, status, and effective overwritten contexts.
• Actions: Remove execution task, Launch the task (rerun).

Find & manage tasks (global list)

The Tasks page provides:

• Filters: Scope, Last exec. status, Context, Period (From/To).
• Search box, sortable columns, Reset filters.
• Row Actions: Edit, Duplicate, Delete, Play.

Modify a task

• You can change context, overrides, schedules, retry policy, notifications, and purge at any time.
• Changes to context affect the next executions; ongoing runs keep the context they started with.
• Changing job version mid-stream is allowed; consider duplicating the task (see above) to A/B test versions safely.

Heads-up – Scheduling vs “Currently planned”: The list shows Currently = true only when a run is due within the look-ahead window. A future Friday schedule will show false until we approach that time; check Next run to confirm it’s correctly planned.

Duplicate a task

Use Duplicate when:

• You want the same pipeline with a different context (e.g. QA → Prod)
• You want to test a new Job Version or tweak overrides without touching the original
• You want a different schedule or purge policy for the same job

procedure:

1. From the task page (Task setup) click the kebab menu (⋮) → Duplicate task.
2. Or from the Tasks list, use the Copy icon in the Action column.

By default the new task is named with a suffix: _copy, _copy_2, etc. Rename it if needed.

Copied: job/version, context + overrides, notifications, purge, acknowledgement.
Not copied: execution history, schedules.

L’article Tasks est apparu en premier sur ETL administration console.

An execution is a single run of a task.

• A task can have many executions over time (manual runs, schedules, API triggers).
• A task belongs to a job; a job can expose multiple tasks (e.g., different contexts).

Where to view executions

• Global list: Executions page — shows all executions mixed together across projects/tasks.

• Per-task view: Task › Last executions tab — shows only the executions of the selected task.

Filtering & search

• Global list filters: Type (trigger source), Task, Scope, Period or From/To, Status + free-text Search.
• Per-task filters: Status + From/To date range.
• Use Reset filters to clear the current selection.

Columns (what you see)

• ID – unique execution id.
• Project – project of the job.
• Task – task name.
• Scope – logical scope/environment.
• JobVersion – job version used for this run.
• Start date / End date – timestamps of the run.
• Duration – computed wall time.
• Type – trigger source (e.g., manual/scheduled/API; displayed as EXEC).
• Identifier – optional business id passed to the run.
• Server – worker that executed the task.
• Status – IN_PROGRESS, SUCCESS, WARNING, ERROR (can be Acked).

Actions

• Per execution:
  • View details/logs.
  • Delete the execution record (and associated logs).
  • Acknowledge errors (mark as Acked) when applicable.
• Bulk (selection + Actions menu): apply operations to multiple executions at once (e.g., delete, acknowledge).
• Per task (top toolbar in task view):
  • Launch the task manually.
  • Kill all (terminate current in-progress executions of this task).
  • Purge the executions of the task (clean historical executions per your purge policy).

At-a-glance (task view)

• A small sparkline summarizes the most recent runs.
• Status badges are color-coded; in-progress items can be terminated; acknowledged errors remain visible but are flagged as Acked.

L’article Execution tasks est apparu en premier sur ETL administration console.

• directly into EAC
• on the system crontab

Schedule the task in EAC

With the internal scheduler you will be able to execute a task whenever you want and also under the minute (each second if you want).

Go into the task where you want to add a scheduler and click on « Cron planification » tab:

Click on [Add scheduler] button.

Keep the default task type option to « exec »:

Select the first execution date and time and if you want when it must be stopped. Don’t forget to enable the scheduler.

Specify the frequency:

Schedule the task in the crontab

With this method, the execution of the task is only possible in minimum at the minute. Use the internal scheduler to execute your task under the minute.

Open the crontab of the eac user with the following command line:

crontab -e

In EAC, go in the task > Additionnal informations tab and copy the first command line of the table identify by the « Execution command line (for your scheduler) « . Example:

Past this command line in the cron editor and define the frequency of the execution. You can use this online cron editor to help you: https://crontab.guru/weekdays-only.

L’article Schedule a task est apparu en premier sur ETL administration console.

What you see

• Grouped by task (collapsible rows). Use the dropdown to focus on a specific task; expand to see all its executions.
• Color-coded markers by status (e.g., success/warning/error).
• Tooltips on hover showing:
  • Task name
  • Execution ID
  • Status
  • Start timestamp
  • Duration

Controls

• Start at / End at: pick a date-time range (defaults to last 24h).
• Max execution tasks: cap the number of executions rendered (useful for performance).
• Scope: filter by a logical scope (e.g., environment/project/server depending on your setup).

Interactions

• Collapse/expand task rows to focus on specific tasks.
• Hover any marker to inspect details without leaving the page.

Notes

• Timestamps are shown in the UI’s current timezone.
• If purging is enabled in your system, older executions may no longer appear.

L’article Executions timeline est apparu en premier sur ETL administration console.

Root PID

The root pid of the job is used to display on the execution task ETL logs, meters and statistics.

Use the following code in a tJava component (but can be any other java componant you prefer):

System.out.println("@@eac@@root_pid="+rootPid);

Specific identifier

This value is « the main information » of the job. For example, you have 2 tasks on one job executed with to different values for a context. Use this option to display the value on the table which list execution task.

In a tJava component (but can be any other java componant you prefer):

System.out.println("@@eac@@identifier="+context.myParam);

L’article Exchange values between ETL and EAC est apparu en premier sur ETL administration console.