Main-EVL-Command

5 Main EVL Command ¶

All command line EVL functionality is handled by the main command ‘evl’, which either run EVL jobs and workflows or serves other EVL subcommands.

evl project
handles EVL projects, like create new or sample one, source variables from ‘project.sh’, or get particular project variables. For details, check ‘man evl-project’.

evl <evl_command>
it calls particular EVL command/component, like ‘sort’, or ‘readjson’. All possible EVL components or commands are listed below and each has its own man page which explain usage and arguments. To see man page for a command, run ‘man evl-<evl_command>’.

evl run ( <job>.evl | <workflow>.ewf | <script>.sh )
To run an EVL job or workflow, for details check ‘man evl-run’. as the most common usage is to run a job, there is a shortcut:

evl job/<job>.evl

5.1 Usage ¶

evl
  <evl_command>  [<option>...]

evl
  <evl_command>  ( --help | --usage )

evl
  ( --init | --expiration-date | --help | --usage | --version )

5.2 Examples ¶

1. To run a job with yesterday Order Date:

   evl job/staging.invoices.evl --odate=yesterday

2. To run a workflow with yesterday Order Date:

   evl run workflow/staging.ewf --odate=yesterday

5.3 Options ¶

--init
to initiate EVL installation under your (i.e. non-root) user. To be run only once for each user, it creates or overwrite ‘$HOME/.evlrc’ file.

--expiration-date
return an expiration date of this version of EVL, empty output means no expiration

Commands for base and mapping components: ¶

aggreg
aggregate (and map) records by key

assign
assign the content of input flow or file into specified variable

cat
concatenate flows or files

cmd
run any system command with possibility to connect to flow

comp
run custom EVL component

cut
remove columns from input flow or file

departition
gather or merge partitioned flows or files into one partition

echo
write an argument into output flow or file

filter
split flows according to a condition or just filter records out

gather
gather multiple flows or files into one in round-robin fashion

generate
create artificial records

head
output the first part of input flow or file

join
join sorted inputs

lookup
create and remove shared lookup

map
generic mapping

merge
merge sorted inputs (by keeping the sort)

partition
partition input flow or file

sort
sort (and possibly deduplicate) records of input flow or file

sortgroup
sort input flow or file within a group

tac
write flow or file in reverse

tail
output the last part of input flow or file

tee
replicate input flow or file

trash
send flow(s) to /dev/null

uniq
deduplicate sorted input flow or file

validate
check data types and possibly filter out invalid records

watcher
catch flow content into text file, debugging purpose

Commands for read components: ¶

read
generic source reader, handle various file types (‘Avro’, ‘CSV’, ‘json’, ‘Parquet’, ‘QVD’, ‘xls’, ‘xlsx’ and ‘xml’), compression (‘gz’, ‘tar’, ‘bz2’, ‘zip’, ‘Z’) and URI Scheme for file storage (‘file:’, ‘gdrive:’, ‘gs:’, ‘hdfs:’, ‘s3:’, ‘sftp:’, ‘smb:’) and for tables (‘mysql:’, ‘mssql’, ‘postgres:’, ‘oracle:’, ‘sqlite:’, ‘teradata:’)

readasn1
read ASN.1 format

readavro
read and parse Avro file format

readevd
read and parse EVD file

readjson
parse JSON input

readkafka
consume Kafka topic

readmssql
read MS SQL table into flow or file

readmysql
read MariaDB/MySQL table into flow or file

readora
read Oracle table into flow or file

raedparquet
read Parquet files

readpg
read PostgreSQL table into flow or file

readqvd
read and parse QVD (QlikView, Qlik Sense) file

readredshift
read Amazon Redshift table into flow or file

readsqlite
read SQLite table into flow or file

readtd
read Teradata table into flow or file

readxls
read XLS (MS Excel) sheet

readxlsx
read XLSX (MS Excel) sheet

readxml
parse XML input

Commands for run SQL components: ¶

runImpala
run impala sql from file or from input

runmssql
run SQL in MS SQL database

runmysql
run SQL (or mysql command) in MariaDB/MySQL database

runpg
run SQL in Oracle

runpg
run SQL or psql command in PostgreSQL database

runredshift
run SQL query in Amazon Redshuft database

runsqlite
run SQL (or sqlite3 command) in SQLite database

Commands for write components: ¶

write
generic file and table writer, handle various file types (‘Avro’, ‘CSV’, ‘json’, ‘Parquet’, ‘QVD’, ‘QVX’, ‘xlsx’ and ‘xml’), compression (‘gz’, ‘bz2’, ‘zip’) and URI Scheme for file storage (‘file:’, ‘gdrive:’, ‘gs:’, ‘hdfs:’, ‘s3:’, ‘sftp:’, ‘smb:’) and for tables (‘mysql:’, ‘mssql’, ‘postgres:’, ‘oracle:’, ‘sqlite:’, ‘teradata:’)

writeavro
write input as Avro file

writeevd
write EVD file in proper format

writejson
write input as JSON

writekafka
produce Kafka topic

writemssql
write flow or file into MS SQL table

writemysql
write flow or file into MariaDB/MySQL table

writeora
write flow or file into Oracle table

writeparquet
write flow or file into Parquet files

writepg
write flow or file into PostgreSQL table

writeqvd
write flow or file into QVD (QlikView, Qlik Sense) file

writeqvx
write flow or file into QVX (QlikView, Qlik Sense) file

writeredshift
write flow or file into PostgreSQL table

writesqlite
write flow or file into SQLite table

writetd
write flow or file into Teradata table

writexlsx
write flow or file into XLSX (MS Excel) files

writexml
write input as XML

Standard options: ¶

--help
print this help and exit

--usage
print short usage information and exit

--version
print version and exit

5.4 Environment ¶

The list of all EVL variables with their default values. One can change these values in his ‘~/.evlrc’ file or in the project in ‘project.sh’.

EVL_BUILD_COMP=1 ¶
whether to build the job every time it runs or not. In production it is mostly safe to set to ‘0’, so the job is then built only the first time, and then only if the source files changed.

EVL_COLOURS=1 ¶
terminal output use colours, but in the case that it cause troubles, one can switch it off by setting environment variable ‘EVL_COLOURS=0’

EVL_COMPILER=gcc ¶
mappings are compiled either by GCC or Clang. By this variable one can specify which one to use. Possible valus are:

EVL_COMPILER=gcc
EVL_COMPILER=clang

If this variable is not set, then on Linux systems is GCC used by default, and on Windows and Mac it is Clang.

GCC must be at least in the version 7.4 and Clang at least 6.0.

EVL_COMPILER_PATH ¶
path to GCC’s or Clang’s ‘bin’, ‘include’, ‘lib’ and ‘lib64’ folder. Leave empty to use system-wide GCC/Clang.

EVL_CONFIG_FIELD_SEPARATOR=';' ¶
the default field separator used in config files when no ‘sep=’ attribute for a field in EVD file, use this character instead. This character might be any one of the first 128 ascii ones.

EVL_DEBUG_FAIL_RECORD_NUMBER=2 ¶
the number of records to show when fail with ‘EVL_DEBUG_MODE=1’

EVL_DEBUG_MODE=0 ¶
if set to 1, then it checks if you try to assign NULL value into not nullable field, and provide the most recently processed records in case of a failure. But it slows down the processing, so use only in developmnet or switch on temporarily in production in the case of investigation data problems.

EVL_DEFAULT_FIELD_SEPARATOR='|' ¶
when no ‘sep=’ attribute for a field in EVD file, use this character instead. This character might be any one of the first 128 ascii ones.

EVL_DEFAULT_RECORD_SEPARATOR ¶
when no ‘sep=’ attribute for the last field in EVD file, use this character instead. This character might be any one of the first 128 ascii ones. By default a Linux newline is used:

EVL_DEFAULT_RECORD_SEPARATOR=$'\n'

but to use Windows end of line (i.e. ‘\r\n’), use components’ options ‘--text-input-dos-eol’ and/or ‘--text-output-dos-eol’.

EVL_DEFAULT_DECIMAL_SEPARATOR="." ¶
decimal places separator for decimal data type, by default it is a dot. E.g. textual representation of decimal field would look like ‘21872.88’, and with decimal separator ‘,’ would look like ‘21872,88’.

EVL_DEFAULT_THOUSANDS_SEPARATOR="" ¶
for decimal data type thousands separator can be used, turned off by default. E.g. textual representation of decimal field would look like ‘21872.88’. Setting thousands separator to ‘,’ produce textual representation ‘21,872.88’.

EVL_DEFAULT_DATE_PATTERN="%Y-%m-%d" ¶
default date format string, e.g. ‘2024-11-07’

EVL_DEFAULT_DATETIME_PATTERN="%Y-%m-%d %H:%M:%S" ¶
default datetime format string, e.g. ‘2024-11-07 07:12:29’

EVL_DEFAULT_TIMESTAMP_PATTERN="%Y-%m-%d %H:%M:%E*S" ¶
default timestamp format string, e.g. ‘2024-11-07 07:12:29.123456789’

EVL_DEFAULT_TIME_PATTERN="%H:%M:%S" ¶
default time format string, e.g. ‘07:12:29’

EVL_DEFAULT_TIME_NANO_PATTERN="%H:%M:%E*S" ¶
default time_ns format string, e.g. ‘07:12:29.123456789’

EVL_ENV=DEV ¶
to specify an environment, usually one of ‘DEV’, ‘TEST’ or ‘PROD’.

EVL_FASTEXPORT_SLEEP, EVL_FASTEXPORT_TENACITY, EVL_FASTEXPORT_SESSIONS ¶
Teradata FastExport options.

EVL_FASTLOAD_ERROR_LIMIT, EVL_FASTLOAD_SESSIONS ¶
Teradata FastLoad options.

EVL_FR=1 ¶
if set to 0, then EVL File Register is not used, only provide debug messages, but does nothing.

EVL_FR_LOG_FILE ¶
file to be used for storing information for EVL File Register.

EVL_KAFKA_CONSUMER_COMMAND, EVL_KAFKA_PRODUCER_COMMAND ¶
paths to Kafka consumer and producer commands.

EVL_LOG_DIR="$HOME/evl-log" ¶
path to logs from job and workflow runs. The default is set in ‘/opt/evl/etc/evlrc’.

EVL_MAIL_SEND=1 ¶
send e-mails by default in the case of fails in a workflows or by the commmand Mail. To switch off, for example in non-production environments, set ‘EVL_MAIL_SEND=0’.

EVL_MONITOR_DBMS="sqlite" ¶
by default SQLite DB is used, but for production environment PostgreSQL recommended. In such case use ‘postgres’ value for this variable.

EVL_MONITOR_ENABLED=1 ¶
monitoring logging can be turned off by setting this variable to 0.

EVL_MONITOR_POSTGRES_DB="evl_monitor", EVL_MONITOR_POSTGRES_HOST="localhost", ¶
EVL_MONITOR_POSTGRES_PORT=5432, EVL_MONITOR_POSTGRES_USER="evl_monitor"

connection information when PostgeSQL DB is used for logging monitoring entries.

EVL_MONITOR_SQLITE_TIMEOUT=2000 ¶
when SQLite DB is used for logging monitoring entries, this value is used for timeout for SQLite.

EVL_MONITOR_SQLITE_PATH="$EVL_LOG_DIR" ¶
path to SQLite database for EVL Manager. The default is set in ‘/opt/evl/etc/evlrc’.

EVL_NICE=1 ¶
each EVL command and component is fired prefixed by:

eval nice -n $EVL_NICE

To change the priority of EVL processes, to have EVL jobs "nicer", one can set ‘EVL_NICE’ to the value between 0 and 19. Higher number means that processes will have lower priority. For details one can check ‘man nice’.

EVL_ODATE ¶
when no ‘--odate=’ option is used when running a job or workflow, it tries to use an Order Date from this variable. So calling:

evl job/some_job.evl --odate=20260121

is the same as:

export EVL_ODATE=20260121
evl job/some_job.evl

EVL_PARTITIONS ¶
to specify how many partitions to use in ‘Partition’ component. This EVL installation allows at most ‘1024’ partitions.

EVL_PASSFILE="$HOME/.evlpass" ¶
contains path to file with passwords. Must have ‘600’ permissions. Structure of the file:

server:port:database:username:encrypted_password

So for example:

10.0.0.10:5432:some_db:some_user:ka786_Ufzf5oaD9
10.0.0.10:1521:some_db:some_user:ka786_Ufzf5oaD9
100.10.9.8:22:/target/folder:user:LKKo-098
localhost:3001:impala_user:2_lLkPl_010
212.0.0.11:288:USR_0000:162534

For details see ‘man evl-password’.

EVL_PROCESSES_CHECK_SEC=0.4 ¶
how often (in seconds) check processes if they are still running. For very long running jobs it makes sense to increase this value to even 2.0 seconds. This default value is good for jobs with many steps (i.e. many Wait components) and quite short processing so each step finish as soon as possible. Possible range is from 0.1 to 2.0.

EVL_PROGRESS_REFRESH_SEC=2 ¶
when ‘--progress’ option is used, it refresh the state every 2 seconds by default. To change this default, set this variable to other number of seconds. Possible range is from 1 to 30.

EVL_PROJECT_LOG_DIR ¶
by default project’s log directory is set to:

EVL_PROJECT_LOG_DIR="$EVL_LOG_DIR/<project_name>"

EVL_PROJECT_TMP_DIR ¶
by default project’s temporary directory is set to:

EVL_PROJECT_TMP_DIR="$EVL_TMP_DIR/<project_name>"

EVL_RUN_ID_FILE ¶
path to file which stores incremental ‘RUN_ID’, a unique ID of each job or workflow run. It is unique within a project. By default it is:

EVL_RUN_ID_FILE="$EVL_PROJECT_LOG_DIR/evl_run_id.hwm"

EVL_TMP_DIR="/tmp" ¶
path to (local) temporary directory, to be used by jobs and workflows. Situate this folder on the same mount point as data will be, to make ‘mv’ command fastest as possible. The default is set in ‘/opt/evl/etc/evlrc’.

EVL_TRACE_LEVEL=0 ¶
specify number between 0 and 3 to say how detailed EVL Trace Messages should be:

0 - do not display trace messages
1 - code to be copy+paste and run from command line
2 - what is going to be enter to monitoring table or log
3 - very detailed information about PIDs numbers etc.

EVL_WATCHER=0 ¶
whether or not the component ‘Watcher’ is silent. In production this would be usually set to ‘0’, but in development, if ‘Watcher’ is used to investigate interim data, it is fine to set to ‘1’. Check ‘man evl-watcher’ for more details.

5.5 evl project ¶

Create new EVL project(s) or get project settings. Consider current directory as a project one, unless <project_dir> is specified with either full or relative path. Last folder in the <project_dir> path is considered as project name. Prefer to use small letters for project names, however numbers, capital letters, underscores and dashes are possible.

Projects can be included into another projects. But remember that parent’s project.sh is not automatically included (i.e. sourced) by subproject’s one.

create <project_name> [<project_name_2>...]
create <project_name> directory (directories) with standard subfolders structure and default ‘project.sh’ configuration file.

create --sample <project_name> [<project_name_2>...]
create <project_name> directory (directories) with sample data and sample jobs and workflows.

get <variable_name> [--path] [--omit-newline] [--project=<project_dir>]
get the value of <variable_name>, based on the project.sh configuration file. Search ‘project.sh’ in the current directory, unless <project_dir> if mentioned. With option ‘--path’, it returns path in a clean way (i.e. no multiple slashes, no slash at the end, no ‘/./’, no spaces or tabs at the end or beginning). With option ‘--omit-newline’, return value without trailing newline.

To drop the whole project simply delete the folder recursively.

Synopsis ¶

evl project create
  <project_name>... [--sample]
  [-v|--verbose]

evl project get
  <variable_name>
  [-p|--project=<project_dir>]
  [--path] [--omit-newline]
  [-v|--verbose]

evl project
  ( --help | --usage | --version )

Options ¶

--omit-newline
return value without trailing newline, good for example for assigning returned value into a variable

--path
it returns path in a clean way (i.e. no multiple slashes, no slash at the end, no ‘/./’, no spaces or tabs at the end or beginning)

-p, --project=<project_dir>
specify project folder if not the current working one

--sample
create project with sample configuration

Standard options: ¶

--help
print this help and exit

--usage
print short usage information and exit

-v, --verbose
print to stderr info/debug messages of the component

--version
print version and exit

Examples ¶

1. To create three main projects with couple of subprojects:

   # shared to all projects
   evl project create shared
   
   evl project create stage       # shared stuff only for "stage" projects
   evl project create stage/sap stage/tap stage/erp stage/signaling
   
   evl project create dwh         # shared stuff only for "dwh" projects
   evl project create dwh/usage dwh/billing dwh/party dwh/contract dwh/product
   
   evl project create mart        # shared stuff only for "mart" projects
   evl project create mart/marketing mart/sales

2. To create new project with sample data, jobs and workflows:

   evl project create --sample my_sample

3. To get the project path to log directory (i.e. ‘EVL_PROJECT_LOG_DIR’):

   evl project get --path EVL_PROJECT_LOG_DIR

5.6 evl run ¶

See Run for details.

5.7 evl workflow ¶

EVL Workflow is a code based orchestration tool. It fires EVL tasks in parallel and in specified order on specified target host and consider specific priorities.

EVL task ¶

Task is one of the following:

Shell Script (‘``*.sh``’)
any shell script with ‘.sh’ suffix

EVL job or workflow (‘``*.evl``’ or ‘``*.ewf``’)
EVL job is an ETL job, i.e. one or more DAGs (Directed Acyclic Graph) with data flows on edges and data modifying components as vertices. EVL workflow is also one or more DAGs, but vertices are Tasks (i.e. Shell Scripts, EVL jobs, other EVL workflows, or Wait for a file), edges are successors.

Wait for a file
to sniff for an existence of a file with given file mask.

The workflow consists (mostly) of ‘Run’ components, which are used in EWS workflow structure definition file, and which fires EVL jobs or other EVL workflows or wait for a file with given file mask. For details about this component, see ‘man evl-run’.

‘EWS’ is EVL workflow structure file (workflow template), for details see ‘man 5 evl-ews’.

‘EWF’ is EVL worflow definition file (a workflow), for details see ‘man 5 evl-ewf’.

Arguments ¶

run
run <workflow> with Order Date (‘ODATE’) equal to <odate>. In case that workflow with given ‘ODATE’ has been started in the past, it will fail. Use ‘continue’ or ‘restart’ in such cases. This command is intended to be scheduled by ‘crontab’ for example.

continue
continue <workflow> with Order Date equal <odate> from last failed step, i.e. do not run again already successfully finished steps. This command is useful for usual manual restart from failed point.

restart
restart whole <workflow> (with given ODATE) from the beginning, no matter what is the status of the workflow. Use this command with care, normally not to be used in production environment.

Order Date ¶

is a date for which the data are being processed. Every workflow has to be run with some <odate>. When no <odate> is specified, then current date is used. An <odate> can be of any form that standard GNU/Linux command ‘date’ can recognize as a date. Recommended is however to use format ‘YYYYMMDD’ or ‘yesterday’.

Synopsis ¶

evl
  ( run | continue | restart ) <workflow>...
  [-D|--define=<variable=value>]...
  [-o|--odate=<odate>] [-p|--project=<project_dir>]
  [-s|--progress] [-v|--verbose]

evl workflow
  ( --help | --usage | --version )

Options ¶

-D, --define=<definition>
the <definition> is evaluated right before running a workflow, but after evaluating settings from ‘ewf’ file, e.g. ‘-DSOME_PATH=/some/path’ will do ‘eval SOME_PATH=/some/path’, and overwrites then variable SOME_PATH possibly defined in ‘ewf’ file. Multiple ‘--define’ options can be used.

-o, --odate=<odate>
run evl workflow with specified <odate>, environment variable ‘EVL_ODATE’ is ignored

-p, --project=<project_dir>
specify project folder if not the current working one

-s, --progress
it shows the states of each component, refreshed every ‘$EVL_PROGRESS_REFRESH_SEC’ seconds. (2 seconds by default.)

Standard options: ¶

--help
print this help and exit

--usage
print short usage information and exit

-v, --verbose
print to stderr info/debug messages of the component

--version
print version and exit

Commands ¶

EVL workflow structure file (‘*.ews’ file) is resolved as Bash script. Following EVL commands can be used, see ‘man evl-<command>’ for details.

calendar
continue based on specified calendar file

Chmod
change file permissions, act by URI (file://, hdfs://, sftp://)

Cp
copy files, act by URI (file://, gdrive://, gs://, hdfs://, s3://, sftp://, smb://)

end
end up an EVL job or workflow structures (‘EVS’ or ‘EWS’ files)

Ls
list directory contents, act by URI (file://, gdrive://, gs://, hdfs://, s3://, sftp://, smb://)

Mail
send an e-mail

Mkdir
create directory, act by URI (file://, hdfs://, s3://, sftp://)

Mv
move (rename) files, act by URI (file://, gdrive://, gs://, hdfs://, s3://, sftp://, smb://)

Rm
remove files or directories, act by URI (file://, gdrive://, gs://, hdfs://, s3://, sftp://, smb://)

Rmdir
remove empty directories, act by URI (file://, hdfs://, sftp://)

Sleep
run previously defined EVL tasks and delay for a specified amount of time

Snmp
send a SNMP trap message

Test
check file types and existence, handle also hdfs and AWS S3.

Touch
change file timestamp, create file if not exist, act by URI (file://, hdfs://, sftp://)

Wait
split pieces of EVL job or workflow into steps

Run Component ¶

EVL workflow structure file (EWS file) is resolved as Bash script. Next to Commands above, which are run immediately, there is a ‘Run’ component which is just parsed, but fired later once ‘Wait’ or ‘End’ command is reached.

For details see ‘man evl-run’.

Environment Variables ¶

The list of variables which controls EVL workflow behaviour. With their default values. These variables can be set for example in user’s ‘~/.evlrc’ file or in the project’s ‘project.sh’.

EVL_RUN_FAIL=1 ¶
whether or not to fail given ‘Run’ command once an EVL task fails, so when zero is set, the ‘Run’ command continue regardless task failures

EVL_RUN_FAIL_MAIL=1 ¶
whether or not to send an e-mail when the task fails

EVL_RUN_FAIL_MAIL_SUBJECT="Project '$EVL_PROJECT' FAILED" ¶
subject of such e-mail, where variables are resolved by ‘envsubst’ utility in time of failure

EVL_RUN_FAIL_MAIL_MESSAGE ¶
message of such e-mail, by default it is:

Project:      $EVL_PROJECT
Top Level WF: $EVL_WORKFLOW_TOP
Current WF:   $EVL_WORKFLOW
Task:         $EVL_TASK
Order Date:   $EVL_ODATE
Sent to:      $EVL_MAIL_TO
Task log:     $EVL_TASK_LOG
Tail of log:  $(tail $EVL_TASK_LOG)

where commands ‘$(...)’ are resolved and also all variables are substituted (by ‘envsubst’ utility).

EVL_RUN_FAIL_SNMP=0 ¶
whether or not to send SNMP trap when the task fails.

EVL_RUN_FAIL_SNMP_MESSAGE='$EVL_PROJECT FAILED' ¶
SNMP message to be send.

EVL_RUN_RETRY=0 ¶
the number of times it retries to run the task again. Zero means no retry and fail ‘Run’ command once the given task fails.

EVL_RUN_RETRY_INTERVAL=5m ¶
the amount of time between retries. It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

EVL_RUN_TARGET_TYPE=local ¶
where to run EVL task(s), possible values are ‘k8s’, ‘local’, and ‘ssh’.

EVL_RUN_TIME=24h ¶
maximal run time, so if the task invoked by ‘Run’ command is not finished after this amount of time, it is killed. The time is counted since the task is really running, not since the invocation (i.e. waiting time is not included). It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

EVL_RUN_WAIT_FOR_LOCK=1 ¶
whether or not to wait for a lock file, i.e. if somebody is running the same task at the moment.

EVL_RUN_WAIT_FOR_LOCK_INTERVAL=5m ¶
the time interval between each check. It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

EVL_RUN_WAIT_FOR_LOCK_TIME=10h ¶
maximal amount of time to wait for a lock file. It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

EVL_RUN_WAIT_FOR_PREV_ODATE=0 ¶
whether or not to automatically wait for previous Order Date of given task. Setting to 1 might be useful when you must run daily processing strictly in right order.

EVL_RUN_WAIT_FOR_PREV_ODATE_INTERVAL=5m ¶
the time interval between each check. It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

EVL_RUN_WAIT_FOR_PREV_ODATE_TIME=10h ¶
maximal amount of time to wait for previous Order Date. It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

EVL_RUN_WARN_MAIL=0 ¶
whether or not to send an e-mail when there is warning

EVL_RUN_WARN_MAIL_SUBJECT='$EVL_PROJECT WARNING' ¶
subject of such e-mail, where variables are resolved by ‘envsubst’ utility in time of failure

EVL_RUN_WARN_MAIL_MESSAGE ¶
message of such e-mail, by default it is:

Project:      $EVL_PROJECT
Top Level WF: $EVL_WORKFLOW_TOP
Current WF:   $EVL_WORKFLOW
Task:         $EVL_TASK
Order Date:   $EVL_ODATE
Sent to:      $EVL_MAIL_TO
Task log:     $EVL_TASK_LOG
Tail of log:  $(tail $EVL_TASK_LOG)

where commands ‘$(...)’ are resolved and also all variables are substituted (by ‘envsubst’ utility).

EVL_RUN_WARN_SNMP=0 ¶
whether or not to send SNMP trap when there is a warning

EVL_RUN_WARN_SNMP_MESSAGE='$EVL_PROJECT WARNING' ¶
SNMP message to be send in such case

EVL_WAIT_FAIL=1 ¶
whether or not to fail the whole workflow when the ‘Run’ command fails, so when zero is set, the workflow continue regardless task failures

EVL_WAIT_INTERVAL=2s ¶
the time interval between each check for ‘Wait’ command. It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

EVL_WAIT_TIME=10h ¶
maximal amount of time to wait for a previous ‘Run’ commands to finish. It can be specified in seconds, minutes, hours or days, so suffix ‘s’, ‘m’, ‘h’ or ‘d’ need to be specified to the number. If no unit is specified, seconds are assumed.

Examples ¶

In all examples suppose an EVL project ‘our_project’ represented by folder ‘/home/tech_user/our_project’.

1. Following ‘ews/our_workflow.ews’:

   Run job.1.evl job.2.evl
   Run workflow.3.evl job.4.evl script.5.sh
   
   End

   with empty file ‘workflow/our_workflow.ewf’ would be called from command line:

   cd /home/tech_user/our_project
   evl workflow/our_workflow.ewf

   which is the usual way to run workflow when testing, but running for example from a script:

   evl /home/tech_user/our_project/workflow/our_workflow.ewf

   or better:

   evl run workflow/our_workflow.ewf --project /home/tech_user/our_project

---