Sample Collection Guide > Controlling the Behavior of FileTransfers by using Conditions in a Workflow

Controlling the Behavior of File Transfers by Using Conditions in a Workflow

Objective: A file transferTransfers files from one computer to another. A particular Automation Engine object type (FileTransfer object). should be started through a workflowAn object of the Automation Engine that can include several executable objects and which runs them in a specified order. [Formerly called "ProcessFlow" and "JobPlan."]. Within the workflow, the system should check whether the source and the target file are available and set the corresponding actions.

Used objects: Workflow, Job (Windows), FileTransfer

Used scriptA particular Automation Engine object type. elements: SYS_TIME_PHYSICAL, SYS_DATE_PHYSICAL, STR_CUT, STR_FIND, :SET, :PSET, :PRINT, :DATA, :PUT_ATT

This example describes how conditions and actions can be used in workflow tasks.


Examples

The Windows jobAn Automation Engine object type for a process that runs on a target system. JOBS.WIN.CON, which is part of a workflow, should call the file listShows entities in a grid view of a directory and write it to a text file. Then, the file transfer JOBF.CONDITIONS, which is also part of the workflow, is activated and transfers this file to a different computer.

Within the workflow, the system can check whether problems may occur during the file transfer and you can set the corresponding actions. You can do so in the Preconditions and Postconditions tab in the properties of the relevant workflow tasks.

This mechanism ensures that no errors occur and that the target files are not overwritten.

In the first step, create the workflow JOBP.CONDITIONS.

Open this objectAutomation Engine controlled activities and processes are structured in the form of objects. See also: Task and switch to the Variables & Prompts tab. Enter the object variablesPlaceholder for values that are stored in an object's "Variables & Prompts" tab/section. that store the values of the workflow tasks. The advantage is that the values are stored in one location and can easily be changed later on.

Variable name Value Description
&SAGENT# WIN01 File transfer's source agentA program that enables the de-centralized execution of processes (such as deployments) on target systems (computers or business solutions) or a service that provides connectivity to a target system (such as for databases or middleware). An agent is also an object type in the Automation Engine. [Formerly called "Executor."] See also: host.
&DAGENT# WIN02 File transfer's target agent.
&SLOGIN# GLOBAL.LOGIN Login object for logging on to the source computer.
&DLOGIN# GLOBAL.LOGIN Login object for logging on to the target computer.
&DFILE# C:\temp\test2.txt Path and name of the target file.

In the next step, create the objects that the workflow should include:

Windows job: JOBS.WIN.COND

Insert the following scripting lines into the job's Pre-Process tab:

:PUT_ATT HOST = &SAGENT#
:PUT_ATT LOGIN = &SLOGIN#

In doing so, the job's Agent object and its Login object are set at runtimeThe duration of a task's execution. It refers to the period between a task's start and end. It does not include its activation period (see also: activation and start).. The object variables are inherited from the workflow. Ensure that the setting "Inherit from parentThere are different ways of activating objects. The originator of an activation is referred to as the superordinate task (parent). See also: Child; Children" is set in the Variables & Prompts tab. Enter the following lines in the Process tab:

:SET &DATE# = SYS_DATE_PHYSICAL("YYYYMMDD")
:SET &TIME# = SYS_TIME_PHYSICAL("HHMMSS")

:PSET &SFILE# = "C:\temp\&DATE#_&TIME#.txt"

:DATA dir C:\ >> &SFILE#
:DATA @set retcode=%errorlevel%
:DATA @if NOT %ERRORLEVEL% == 0 goto :retcode

This script creates a text file whose name is composed of the current time and date. This text file is filled with the file list that is stored in C:\. The name of the text file is also stored in an object variableIt stores or retrieves values dynamically at runtime. An individual Automation Engine object type. and passed on to the workflow for the file transfer.

 

File transfer: JOBF.CONDITIONS

Switch to the FileTransfer tab and set the option "File exists" - "Cancel". All other attributes that are required are set at runtime using the workflow's inherited object variables. For this purpose, insert the following lines in the Process tab:

:PUT_ATT FT_SRC_HOST = &SAGENT#
:PUT_ATT FT_DST_HOST = &DAGENT#
:PUT_ATT FT_SRC_LOGIN = &SLOGIN#
:PUT_ATT FT_DST_LOGIN = &DLOGIN#
:PUT_ATT FT_SRC_FILE = &SFILE#
:PUT_ATT FT_DST_FILE = &DFILE#

 

Store the objects and add them to the workflow. The job must be processed before the file transfer.

 

Define the file transfer's conditions and actions in the workflow. Open the properties of JOBF.CONDITIONS and switch to the Preconditions tab.

JOBF.CONDITIONS - Preconditions tab

Define the condition CHECK FILE using the following parameters: agent *OWN, file name: &SFILE#, condition: exists.

Set the actionActions are predefined building blocks for recurring activities. They are commonly used for managing third party systems or in deployment scenarios. RUN TASK. Within CHECK FILE, insert an Else block with the action CANCEL PROCESSFLOW (scope: *OWN, subordinate tasks: including).

Verify that the setting "Generate at runtime" is not activated in the file transfer. Otherwise, an error occurs because the object variable &SFILE# is used in the Preconditions.

JOBF.CONDITIONS - Postconditions tab

In this tab, define the conditions that check whether the file transfer has been canceled (STATUS) and if the target file exists (CHECK FILE). The predefined variable &$RESTART_COUNT# returns the number of times that the taskAn executable object that is running. Tasks are also referred to as activities. has been restarted via this tab. To avoid the occurrence of an infinite loop, the task should be canceled after three restartA restart refers to the repetition of an object's execution. This action differs from a new start in some parts. attempts.

If a restart is successful before the specified maximum number has been reached, the job JOBS.WIN.COND2 starts and renames the existing target file. No data is overwritten. The file transfer is repeated (RESTART TASK).

The job starts with an alias that is composed of the target agent's name and the Login object's name (separated by an underscore). These values are read from the job's alias name in the Pre-Process tab and inserted in the attributes.

In the last step, create the Windows job JOBS.WIN.COND2.

This job changes the target file's name and only starts in the eventAction that is triggered if particular conditions apply. It can be an Automation Engine object type or an entry in a Policy Orchestrator EventBase. of an error using the file transfer's properties that have been defined in the workflow. The following script retrieves the Agent object and Login object from the alias name in the Pre-Process tab and sets them by using :PUT_ATT.

:SET &ALIAS# = &$ALIAS#
:SET &STRPOS# = STR_FIND(&ALIAS#,'_')
:SET &STRPOS# = &STRPOS#+1
:SET &LOGIN# = STR_CUT(&ALIAS#,&STRPOS#)
:SET &STRPOS# = &STRPOS#-2
:SET &AGENT# = STR_CUT(&ALIAS#,1,&STRPOS#)

:PUT_ATT HOST = &AGENT#
:PUT_ATT LOGIN = &LOGIN#

The Process tab lines are used to rename the particular target file (new file name = current time):

:SET &TIME# = SYS_TIME_PHYSICAL("HHMMSS")
:DATA rename "C:\temp\test2.txt" &TIME#.txt
:DATA @set retcode=%errorlevel%
:DATA @if NOT %ERRORLEVEL% == 0 goto :retcode

The target file name is not dynamically passed on to the job and must be changed manually if necessary.

Result

Starting the workflow JOBP.CONDITIONS has the effect that the job JOBS.WIN.COND creates a file on the computer on which the agent WIN01 runs. The file transfer should transfer this file from this computer (WIN01) to a different one (WIN02). The file transfer does not start if the source file already exists.

If the target file exists, the file transfer aborts. As a result, the target file is renamed and the file transfer is repeated. This procedure ensures that no files are overwritten and that the stored data is kept.

By specifying verifications directly in the workflow, you can easily avoid particular errors and set the corresponding actions.

 


Automic Documentation - Tutorials - Automic Blog - Resources - Training & Services - Automic YouTube Channel - Download Center - Support

Copyright © 2016 Automic Software GmbH