Overview

• EAC Home page offers an operational dashboard of recent task execution errors and provides access to the connected user’s favorite tasks. It is designed as a first screen for daily monitoring.
• You can check execution fails, identify concerned tasks, open relevant executions for deeper analysis.
• It is divided in three parts : Error execution gauges, Last 7 days tasks in error and user favorites tables.

Error Executions Gauges

At the top of the dashboard, EAC displays half-donut gauges showing recent executions that ended in errors.
They are grouped by periods:

• Errors in the last 24h
• Errors in the last 7 days
• Errors in the last 30 days

Gauges color help identify error types:

Use these to quickly detect if failures are isolated or if they increase over time.

Last 7 days execution tasks on error

This table gives you quick access to the last execution tasks that failed within the last 7 days. KILLED and TERMINATED error statuses are included in this table.

Available information:

• ID — Task ID
• Project — Project related to the executed task
• Task — Name of the task that was executed
• Scope — ///
• JobVersion — Semantic/Talend job version (e.g., 0.1, 0.2, 1.0).
• Start date — The exact date and time when the task was launched
• End date — The exact date and time when the task ended
• Duration — Execution duration
• Type — ///
• Origin — Way the task was launched (Manually, automatically)
• Identifier — ///
• Server — Execution server on which the task ran
• Status — Final execution status
• Action — Remove the task from the database

Search, pagination and column sorting are available.

Favorite tasks

The table lists tasks added to the user’s favorites. Useful for accessing recurring, critical or frequently monitored tasks.

Available information:

• Project — Project related to the executed task
• Name — Name of the task that was executed
• Scope — ///
• Context — Talend context with specific variables if any.
• Last exec. start date — Date and time of the last execution
• Last exec. end date — Date and time of the last execution end
• Last exec. duration — duration of the last execution
• Last exec. status — Last status of the task
• Enabled — ///
• Planned — Whether or not the task is planned for future launch
• Action —
  • Edit task
  • Duplicate task
  • Remove the task
  • Launch the task
  • Remove from favorites tasks

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

Activate encryption

To activate the encryption system, you must run the command php bin/console eac:generate-encryption-key.

After running the command for the first time, you will need to pass the argument --force at the end of the function to overwrite a key and generate a new one.

Note: If you overwrite an existing key, all previously encrypted data will not be able to be decrypted anymore, please proceed with caution when using the command.

Usage

Once activated, you can use the encryption in:

• Task setup:

When writing a variable to overload, you will have access to a ‘Encrypt’ button that will automatically encrypt your data. Then press ‘Save’ to save the context configuration. All your data will be safely stored crypted, and automatically decrypted only when launching a task.

• Context files

If you create a new context file or edit an existing one, you will have access to a crypt/decrypt system.

Trailing white spaces are automatically removed by default but you can change this behavior if you need to keep them in your context files with the checkbox.
Encrypted values are automatically copied in the clipboard to be pasted in the context area.

Note: Only users with role admin can decrypt values.

L’article Encryption system 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.

Server status

This service must be install on all servers. It retrives memory and cpu usage in order to determine what will be the best server to launch a task.

Copy /var/www/html/current/deployment/systemd/eac-server-status.service file into /etc/systemd/system/ with the following command

sudo cp /var/www/html/current/deployment/systemd/eac-server-status.service /etc/systemd/system/

Edit the file and change ExecStart parameter in order to specify the full path to php according to your installation.

ExecStart=/usr/bin/php /var/www/html/current/bin/console eac:server-status --every=3

You can change option « every« . This value must be set between 1 to 10 (seconds to save memory usage and cpu on database).

Assignment server

This service determines the best servers available for tasks with status « SEND TO QUEUE ». It must be installed only on the main server.

Copy /var/www/html/current/deployment/systemd/eac-execution-assign-server.service file into /etc/systemd/system/ with the following command

sudo cp /var/www/html/current/deployment/systemd/eac-execution-assign-server.service /etc/systemd/system/

Edit the file and change ExecStart parameter in order to specify the full path to php according to your installation.

ExecStart=/usr/bin/php  /var/www/html/current/bin/console eac:execution-assign-server --nextSecondsToAssign=90 --pastSecondsToAssign=60 --frequence=10

You can change options:

• nextSecondsToAssign: assign server to tasks which will executed in the next 90 seconds
• pastSecondsToAssign: assign server to tasks sent to queue and the start date is in the past of 60 seconds
• frequence: to this action all 10 seconds

Consume task

This services consumes / execute the task with status « SEND TO QUEUE ». It must be installed on all execution servers.

Copy /var/www/html/current/deployment/systemd/eac-consume.service file into /etc/systemd/system/ with the following command

sudo cp /var/www/html/current/deployment/systemd/eac-consume.service /etc/systemd/system/

Edit the file and change ExecStart parameter in order to specify the full path to php according to your installation.

ExecStart=/usr/bin/php  /var/www/html/current/bin/console eac:consume --launchForTheNextInSeconds=0 --launchForThePastInSeconds=60

You can change options:

• launchForTheNextInSeconds: execute tasks exactly on time : at 0 second. You can change to 1 if you prefer to execute task one second before
• launchForThePastInSeconds: execute tasks sent to queue and the start date is in the past of 60 seconds

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

crontab -e -u eac

1. Status Purge – on main server only

To clean up old memory and cpu usage on servers. We recommended retention of 4 days:

0 0 * * * {path_to_php} /var/www/html/bin/console eac:server-status:purge --days=1 >> /var/www/html/var/log/eac-master-server-status-purge.log 2>&1

Replace {path_to_php} by the full path to php. For example: /usr/bin/php

2. Deployment Verification – on all servers

When a job version is deployed in EAC, each execution servers must retrieve and keep a local copy of that version.
This scheduled verify that every execution server holds the correct copy; if not, EAC shows a visual alert and avoids launching an execution on any out-of-sync server.

0 1 * * * {path_to_php} /var/www/html/bin/console eac:check-jobversion-deployment --force >> /var/www/html/var/log/eac-master-check-jobversion-deployment.log 2>&1

Replace {path_to_php} by the full path to php. For example: /usr/bin/php

3. Check executions are still alive – on all servers

This schedule allow to kill all executions with status « IN PROGRESS » which no longer have any os pid running on the system.

* * * * * {path_to_php} /var/www/html/bin/console eac:check-background-task  --secondsToConsiderOutdatedAndKill=90 --secondsToConsiderOutdatedAndReaffectServer=10 >> /var/www/html/var/log/eac-master-check-background-task.log 2>&1

Replace {path_to_php} by the full path to php. For example: /usr/bin/php

You can adjust options

• secondsToConsiderOutdatedAndKill: reduce or increase the number of seconds after what an execution with the status « SENT TO QUEUE » is considering oudated because on server is available to launch it.
• secondsToConsiderOutdatedAndReaffectServer: reduce or increase the number of seconds to reaffect a task to an available server

4. Enable scheduler – on main server only

If you schedule tasks on EAC you need this to launch task on time.

* * * * * {path_to_php} /var/www/html/bin/console eac:scheduler --planForTheNextInSeconds=90 >> /var/www/html/var/log/eac-master-scheduler.log 2>&1

Replace {path_to_php} by the full path to php. For example: /usr/bin/php

You can adjust option « planForTheNextInSeconds » to provision tasks to be launched more or less than the next 90 seconds.

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

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.

For paths, parameters, and response schema, refer to the in-app documentation at the address above.

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

Run a new job version safely while your scheduled task keeps using the current, stable version.

Prerequisites

• You have a scheduled task already running on version A.
• You’ve deployed job version B that you want to test.
• Role: Admin (to edit tasks and versions).

Steps

1. Pin the current scheduled task to its version

• Go to Task › Task setup of your scheduled task.
• Select the desired Job version = A.
• Uncheck “Follow the new version”.
  This pins the task to version A even if new versions are deployed.

2. Create a separate test task for the new version

• From the Job or Tasks list, create a new task (e.g., MyTask_test).
• In Task setup, choose Job version = B.
• Leave the test task unscheduled (manual runs only), or schedule it off-hours for testing.

3. Run and validate

• Launch the test task manually.
• Check logs, status, and metrics as usual.

4. Promote the new version to production

• When satisfied, go back to the scheduled task:
  • Either re-check “Follow the new version” (so it will pick up version B now and future versions),
  • or explicitly select Job version = B to stay pinned to B.

5. Clean up

• Delete the temporary test task if no longer needed.

Notes & Tips

• Why this works: unchecking “Follow the new version” freezes a task on a specific job version, so your schedule remains stable while you test elsewhere.
• Use a clear naming convention for test tasks (e.g., *_test) and keep them manual to avoid accidental runs.
• If contexts differ between versions, review Task setup › Context before testing.
• Rollback is instant: just switch the scheduled task back to version A (or keep it pinned).

L’article Test a New Job Version Without Impacting the Schedule est apparu en premier sur ETL administration console.

• Fixed batch purge.
• Fixed execution logs and status in specific edge cases.
• No longer sends error emails when a task is in WARNING.
• Excluded Log4J warnings from error reporting.

v1.10.3 — 2025-07-08

• Launched batch purges to better handle large data volumes.

v1.10.2 — 2025-07-07

• Fixed single-server launch.
• Fixed refresh of DB log streams for a task.
• Added CLI check for the PHP binary path.

v1.10.1 — 2025-07-07

• Purge tasks are launched by the best execution server.
• Purge history now uses creationDate instead of modificationDate.

v1.10.0 — 2025-07-04

• Admins can download application logs.
• Execution and purge task logs are stored in the database by default (configurable via APP_TASK_LOG_TYPE).
• Purge mode history keeps the last X days; mode total keeps a fixed number of executions.
• Purges also clean up old purge records, not only old executions.
• EAC-306 Task type labels clarified — exec: Normal execution, purge: Purge past executions.
• Fixed task kill behavior.
• Fixed verification of jobVersion deployment across all execution servers.
• Fixed log generation.
• Fixed scheduler launches when the PHP executable is not in PATH.
• EAC-368 Improved 4xx/5xx error pages.
• EAC-375 Fixed timeline filtering and grouped executions by task.
• EAC-214 If a server hasn’t updated its status for >30s, show a warning on Home, Servers list, and Server detail.
• EAC-365 Server status on the execution detail page updates live while the run is in progress.
• EAC-369 Allow killing multiple executions from the list.
• EAC-345 Added filters (status, scope, etc.) on Tasks and Executions lists.
• CPU and memory charts can be enlarged on click.
• eac:server-status considers active servers only.
• Fixed server deletion.

v1.9.2 — 2025-07-01

• Fixed second-level scheduling for purges.
• Fixed history purge mode filtering that could miss items to delete.

v1.9.1 — 2025-06-30

• EAC-363 When no server is available, redirect to the launched task page.
• EAC-360 Don’t mark EAC as failed when a non-blocking Talend subprocess errors.
• EAC-366 Hide the delete button for job versions that are used by a task.
• EAC-96 ExecutionTask now stores the jobVersion used.
• EAC-251 When deleting a jobVersion, delete related execTasks and warn users beforehand.

v1.9.0 — 2025-06-06

• EAC-96 Consolidated jobVersion at task execution time.
• EAC-360 eac:check-background-task rechecks a task after 5s before killing it.
• EAC-246: If a task/job/project is disabled, nothing related can be launched (API/Scheduler/manual).

v1.8.7 — 2025-05-28

• Fixed a display issue on task detail with uncommon contexts.
• UI performance optimizations: Tasks/Executions tables, Scheduler, Servers list.
• Home page executions list shows errors only by default.
• EAC-343 Disabled accounts can’t sign in.
• Fixed status filtering on PostgreSQL.
• Task detail: hide crontab planning panels when unused.
• Task detail: show the last failed execution.
• EAC-346 Fixed errors on the Users list (PostgreSQL).

v1.8.6 — 2025-05-26

• Optimized Tasks list rendering for large datasets.
• Introduced an internal stateless API for AJAX calls (lower resource usage).

v1.8.5 — 2025-05-20

• EAC-329 Added sidebar scroll when the screen is too small.
• EAC-312 New command to recalculate context typings for older jobs.
• EAC-311 Use context typing to customize task form fields.
• EAC-310 Fixed search on the task-executions table.
• EAC-309 Fixed sorting on the Tasks table.
• Removed stray “dump” in the search bar.

v1.8.4 — 2025-05-12

• EAC-308/309 Fixed defective sorting on the Tasks table.
• EAC-305 Added bulk delete for execution tasks.
• EAC-298 Added switch toggles for activation in tables.
• EAC-297 Reduced table font sizes.
• EAC-287/288 Fixed wrong default sort for ExecutionTask.
• EAC-270 Standardized date formats (EN/FR).

v1.8.3 — 2025-05-06

• EAC-307 Recomputed MD5 for job versions in addition to checking versions deployed on slaves.

v1.8.2 — 2025-04-25

• API: added hasExecutionInProgress.
• API: added /api/version to check API availability.
• Added a URL to open Task detail by name (not only by ID).
• Restored seconds in execution lists.
• Fixed a scheduling anomaly.

v1.8.1 — 2025-04-23

• Scheduler supports second-based ranges like 10-59/20 (not just */20).
• Scheduling expressions are validated and highlighted when invalid.
• EAC-293 Crontab checks use the user from EAC_CRON_USER.
• EAC-272 No need to comment an AppExtension line during installs.
• EAC-303 Project’s jobVersion list is visible again.

v1.8.0 — 2025-04-15

• EAC-135 Migrated execution logs UI to StimulusJS (from jQuery).
• EAC-80 Added validation on the task name field.
• EAC-122 Display context params in a table (collapsible when multiple).
• EAC-214 Show a warning on Servers page if a server has no update for >30s.
• EAC-227 Syntax highlighting for context files in comments + auto-resize textarea.
• EAC-239 Info bubble on uploaded zips list.
• EAC-240 Select/Deselect all uploads on the deployment page.
• EAC-261/258 Show screenshots of jobs/sub-jobs in JobVersion detail; full-screen on click.
• EAC-264 Option to hide “null value affected” in logs.
• EAC-262 Icon refresh.
• EAC-260 Validate context variables before launching a task.
• EAC-242 Info bubble on Project pages.
• EAC-243 Added Project column on Tasks/Jobs/Executions lists when multiple projects exist.
• EAC-248 Horizontal scroll for long contexts on the Tasks page.
• EAC-249 Show roles on the Users page.
• EAC-244 Improved breadcrumbs site-wide.
• EAC-253 Periodicity now includes seconds and never shows empty.
• EAC-268 Live refresh (logs/stats/etc.) on execution detail no longer breaks on server errors.
• EAC-216 Server statistics are more consistent and update correctly.
• EAC-156 Launch a purge from task detail.
• EAC-179 Executions list correctly filters the last X days (aligned with the home pie chart).
• Tooltips added to all actions; colors aligned with the logo.
• Show poorly deployed versions only on execution servers.

v1.7.3 — 2025-03-26

• Don’t display poorly deployed job versions with single-server license.
• EAC-215 Can disable GIT status check in eac:server-status.
• EAC-217 Scheduler doesn’t relaunch too-old tasks on resume.
• EAC-223 Purge tasks can be scheduled and no longer use the task’s contexts.
• EAC-224 Emphasize context values from the context file in task settings.

v1.7.2 — 2025-03-24

• Hide the Logs tab for purge tasks.
• Added OS PID for purge tasks.
• Added copy task action.

v1.7.1 — 2025-03-12

• Post-v1.7.0 fixes for SQL Server.
• EAC-221 Scheduler no longer controls purge tasks.

v1.7.0 — 2025-02-24

• Multi-server support.

v1.6.2 — 2025-01-22

• Fixed JSON error responses from the API.
• Fixed purge when the log file is missing.
• Fixed purge when history option wasn’t applied.

v1.6.1 — 2024-09-11

• EAC-166 Added a Makefile for development.
• EAC-163 New command eac:check-background-task — verifies background executions; otherwise stops them and sends an email.
• EAC-164 Reworked pagination, sorting & search for ETL logs, metrics and stats tables.

v1.6.0 — 2024-07-11

• EAC-24 Added API to start/stop tasks (docs at /api/doc).

v1.5.4 — 2024-07-08

• EAC-161 Prevent password managers from auto-filling context credentials on task edit.
• EAC-162 No default start date in the tasks listing.

v1.5.3 — 2024-06-19

• EAC-149 List unscheduled tasks.
• EAC-155 Check that the scheduler is present in the server crontab.
• EAC-157 After editing a schedule from the Scheduler view, return to it (not to task edit).

v1.5.2 — 2024-06-03

• EAC-142 Don’t disable the scheduler on each EAC update.
• EAC-158 Fixed scheduler end date handling.
• EAC-159 Scheduler now launches purge tasks correctly.
• EAC-160 Purge tasks are logged in EAC.

v1.5.1 — 2024-05-13

• EAC-150 Include duration-less tasks in purges; fix end date when launch aborted due to disallowed parallelism.
• EAC-154 A killed task becomes WARNING (was stuck on killed).
• EAC-152 Task execution list is no longer a dynamic table (filter/pagination/sort removed).
• EAC-153 Fixed missing task-launch dropdown for jobs with multiple tasks.

v1.5.0 — 2024-04-17

• EAC-18 Internal scheduler (php bin/console eac:scheduler) + ability to stop it from the UI.
• EAC-112 A disabled task cannot be launched.
• EAC-78 Added Allow parallel launch option on tasks.
• EAC-73 Show Talend stats/logs/metrics tables.
• EAC-114 Fixed reading JVM params at deployment.
• EAC-115 Preserve active menu after deployment.
• EAC-116 “Upload” becomes “Upload & Deploy” when requested.
• EAC-113 Remove temporary folder after unzip.
• EAC-118 New tasks default to Email on error only.
• EAC-81 Add a context file from the Project or the Context files view.
• EAC-130 Tabs update browser history.
• EAC-137 New tasks are active by default.
• EAC-119 Added /check-requirements.php page.
• EAC-138 Fixed special characters in ETL launch feedback.
• Limit ExecutionTask lists to 500 items max to avoid memory issues.
• Added Support page.

v1.4.1 — 2024-03-13

• EAC-77 Allow overriding JVM values (Xmx, Xms, -XX:MaxPermSize, -XX:PermSize); run php bin/console eac:jobversioninitjvmparam at deployment.
• EAC-101 Show job description under the task form title.
• Show Project and Job in task breadcrumbs.
• Restyled Task edit form.
• EAC-87 User form redesign + delete action.
• EAC-88 If no password is provided on user edit, keep the existing one.
• EAC-98 Show Ack button only when relevant.
• EAC-99 Minor spacing fix on deployment page.

v1.4.0 — 2024-03-11

• EAC-62 Upgrade to Symfony 7 (PHP ≥ 8.2).
• EAC-86 Better rendering of active contexts.
• EAC-85 Show only distinct flash messages.
• EAC-91 Changed ETL execution method (removed Messenger/supervisord dependency).
• EAC-95 Link to download an archive from uploads.
• EAC-97 Visual loading indicator during archive upload.

v1.3.0 — 2024-01-31

• EAC-10 Licensing.
• EAC-39 Migrated SQLite → MySQL.
• EAC-64 Two DB connections: core EAC entities vs. Talend log entities.
• EAC-34 Upload workflow includes auto-deployment.
• EAC-68 Show current product version.
• EAC-69 Show the meaning of the EAC acronym.

v1.2.0 — 2024-01-22

• EAC-59 Include execution errors in notification emails.
• EAC-60 Fixed sorting on Tasks + Executions tables.
• EAC-61 Visual improvements to execution logs (dates toned down, non-selectable; highlight command-generated logs).
• EAC-33 Allow multi-delete of uploads.
• EAC-63 In Task › Additional information, display current rather than the release name.

v1.1.0 — 2024-01

• EAC-36 After deleting a jobVersion (from Jobs view), redirect to the Job (not the jobVersion).
• EAC-17 Added executions timeline.
• Licensing system.
• EAC-35 Version tracking page.
• EAC-30 Visual distinction of environments.
• EAC-18 Human-readable crontab schedules.
• EAC-37 Date-sorting enabled on tables.
• EAC-32 Show size of uploaded ZIPs.
• EAC-21 Fixed missing logs issue.

v1.0.0 — 2023-09

• Log visualization.
• Job deployment.
• Job versioning.
• Start/stop tasks.

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