Read Data from File

This action reads content of the provided file name and saves it in a variable. Content of any file type, including binary data can be read.

Usually, Automation Builder module receives data for label printing using a trigger. E.g. if a file trigger is used, the content of trigger file is automatically read and can be parsed by filters. However, you might want to bypass filters to obtain some external data. Once you execute this action and have the data stored in a variable, you can use any of the available actions to use the data.

This action is useful:

  • If you must combine data received by the trigger with data stored in a file.

  • Warning

    If you load data from binary files (such as bitmap image or print file), make sure the variable to store the read content is defined as a binary variable.

  • When you want to exchange data between triggers. One triggers prepares data and saves it to file (using the Save Data to File action), the other trigger reads the data.

File group defines the file to read the content from.

  • File name: location of the file to be read within this action.

    Path and file name can be hard-coded, and the same file is going to be used every time. If only a file name without path is defined, the folder with Loftware Automation configuration file (.MISX) is used. You can use a relative reference to the file name, in which the folder with .MISX file is used as the root folder.

    Data source: enables variable file name. Select a variable that contains the path and/or file name or combine several variables that create the file name. For more information see section Using Compound Values in Loftware Automation User Guide.

    Note

    Use UNC syntax for network resources. For more information, see section Access to Network Shared Resources in Loftware Automation User Guide.

Content group sets file content related details.

  • Variable: variable that stores the file content. At least one variable (existing or newly created) should be defined.

  • Encoding: encoding type for the sent data. Auto defines the encoding automatically. If needed, select the preferred encoding type from the drop-down list.

    Note

    Encoding cannot be selected if the data is read from a binary variable. In this case, the variable contains the data as-is.

Retry on Failure group defines how the action execution should continue if the specified file becomes inaccessible.

Tip

Automation Builder module might become unable to access the file, because it is locked by another application. If an application still writes data to the selected file and keeps it locked in exclusive mode, no other application can open it at the same time, not even for reading. Other possible causes for action retries are: file doesn't exist (yet), folder does not exist (yet), or the service user doesn't have the privileges to access the file.

  • Retry attempts: defines the number of retry attempts for accessing the file. If the value is set to 0, no retries are made.

  • Retry interval: time interval between individual retries in milliseconds.

Action Execution and Error Handling

Each action can be set as a conditional action. Conditional actions only run when the defined conditions allow them to be run. To define these conditions, click Show execution and error handling options.

Execution options are:

  • Enabled: specifies if the action is enabled or disabled. Only enabled actions will execute. This functionality may be used while testing a form.
  • Condition: defines one-line programming expression that must provide a Boolean value (true or false). When the result of the expression is true, the action will execute. Condition offers a way to avoid executing actions every time.

Error handling options are:

  • Ignore failure: specifies whether an error should be ignored. If enabled, the execution of actions continues even if the current action fails.

    Note

    Nested actions that depend on the current action do not execute in case of a failure. The execution of actions continues with the next action on the same level as the current action. The error is logged but does not break the execution of the action.

  • Example

    At the end of printing, you might want to send the status update to an external application using the HTTP Request action. If the printing action fails, action processing stops. In order to execute the reporting even after the failed print action, the Print Label action must have the option Ignore failure enabled.

  • Save error to variable: allows you to select or create a variable to save the error to. The same cause of the error is also saved to internal variables ActionLastErrorId and ActionLastErrorDesc.