Performance and Feedback Options

Parallel Processing

Loftware Automation supports parallel processing for both – inbound and outbound processing. This ensures maximum efficiency on any system with installed software. Loftware Automation executes multiple tasks simultaneously, while still preserving the order in which the triggers have been added. Throughput of label job processing depends greatly on the hardware in use.

Inbound Parallel Processing

You can run many triggers on the same machine. They all simultaneously respond to changes in the monitored events. Each trigger remembers the data of unprocessed events on the queue list. This list buffers incoming data in case none of the print processes is available at the moment. As soon as one of the print processes becomes available, the first job is taken from queue using FIFO (First In, First Out) principle. This ensures the correct order of inbound data processing. However, it does not ensure the FIFO principle for printing. See the next section below.

	Note
	Parallel processing means more than just running multiple triggers at once. Each trigger can also allow concurrent connections. TCP/IP, HTTP, and Web Service triggers all accept concurrent connections from many clients. Also, file trigger can be configured to monitor a set of files in a folder. This is configurable by file mask.

Outbound Parallel Processing

Usually, the result of a trigger is label printing process. For this process, you are using data received by the trigger to print it on labels. Loftware Automation service runs the printing processes (aka "print engines") in parallel in the background. Modern processors have two or more independent central processing units called cores. Multiple cores can run multiple instructions at the same time, increasing the overall speed of processing. In case of Loftware Automation, multiple cores increase print job processing, and ultimately label printing performance.

By default, each Loftware Automation instance runs each printing process as a separate thread on every available core. The more powerful CPU you have, the more throughput is available. This maximizes the usage of the available CPU power. The software installs with reasonable defaults defining that every available core accommodates a single thread for print processing. Under normal circumstances, there is no need to make any changes on the defaults. If the configuration setup requires a change, see section Changing Multi-threaded Printing Defaults.

If there are multiple printing processes available, the data from the first event can be printed by one printing process, while the data from the second event could be printed by a different printing process simultaneously, if the second printing process is available at that time. If the second event did not provide a significant amount data, the printing process might provide the data for the printer faster than the first printing process, breaking the order. In such case, data from the second event could print before the data from the first event. To ensure FIFO principle also for printing, see section Synchronous Print Mode.

Caching Files

To improve the time-to-first label and performance in general, Loftware Automation supports file caching. When loading the labels, images and database data from network shares, you might experience delays while printing the labels. Loftware Automation must fetch all required files before the printing process can begin.

There are two levels of caching that complement each other.

Memory cache: Memory cache stores the already used files. The labels that have been used at least once are loaded in the memory cache. When a trigger requests a printout of the same label, the label is immediately available for printing process. Memory cache is enabled by default. Its contents are cleared after you remove or reload a configuration. The label file is checked for changes for each Open Label action. If there is a newer label available, it loads automatically, replacing the old version in the cache.

	Note
	After a label is not in use for 8 hours, it is offloaded from the memory cache.

Persistent cache: Persistent cache stores data to disk – its role is to provide medium term storage for files. Caching is managed per file object. After a file is being requested from the network share, the service first verifies if the file is already present in cache, and uses it. If a file is not in the cache, it is fetched from network share and cached for future use. The cache service continuously updates cache contents with new versions of files. You can configure the time intervals for version checking in Options menu.

Prolonging the Time Period for Label Offloading

After a label is used for the first time, it is loaded in the memory cache. The label becomes available for instant printing the next time it is required. Memory cache housekeeping process removes all labels that haven't been in use for 8 hours or more.

To prolong the time interval in which labels are offloaded from memory cache, do the following:

Navigate to the Loftware Automation System folder.

%PROGRAMDATA%\Loftware\Loftware
Make a backup copy of the file product.config.
Open product.config in a text editor. The file has XML structure.
Add the element Common/FileUpdater/PurgeAge.

This parameter defines the number of seconds that define the time frame for keeping labels in memory cache. Loftware Automation keeps track of the time when each label was used for printing for the last time. When that time frame reaches the defined threshold, the labels are unloaded from memory.

	Note
	Default value: 28800 (8 hours). Maximum value is 2147483647.

The product.config file should have the following contents:

<?xml version="1.0" encoding="utf-8"?><configuration>    <Common>        <FileUpdater>            <PurgeAge>28800</PurgeAge>        </FileUpdater>    </Common>...
</configuration>

After you save the file, Loftware Automation Service automatically applies the setting.

Enabling Persistent Cache

To enable and configure persistent cache, open the Option, select Loftware Automation and enable Cache remote files.

Refresh cache files: Defines the time interval in minutes in which the files in the cache will be synchronized with the files in the original folder. This is the time interval that you allow the system to use the old version of the file.
Remove cache files when older than: Defines the time interval in days for removing all files in cache that haven't been accessed for the specified time duration.

Loftware Automation uses the following local folder to cache remote files:

%PROGRAMDATA%\Loftware\Loftware\FileCache

	Note
	File caching supports label and picture file formats. After you enable file caching, restart Automation service to make the changes take effect.

Forcing Reload of the Cache Content

Loftware Automation automatically refreshes cache content upon the defined time interval. Default value is 5 minutes.

To manually force cache reloading, do the following:

Open Automation Manager.
Locate the configuration that contains the trigger for which you want to force-reload labels.
Right-click the configuration.
Select Reload Configuration.

Error Handling

If an error occurs while executing an action, Loftware Automation stops executing all actions in the trigger. If there are actions defined after the current action that reports an error, these actions are not executed.

For example, actions are defined as shown in the screenshot below. If Set Printer action fails due to invalid name or inaccessible printer, the actions Print Label and HTTP Request are not executed. Action processing stops at Set Printer, Automation Manager shows the trigger in error state and the trigger status feedback (if enabled) reports "wrong printer specified / printer not accessible".

However, in this particular case you don't want to use synchronous feedback which is sent automatically if enabled in the trigger that supports synchronous feedback. Status feedback must be provided asynchronously using the HTTP Request action after the print job is created (or not). After the print process completes, update an application with its status. To achieve this, send the application an HTTP formatted message.

In this case, the HTTP Request action must be executed regardless of success of all the actions in the list above it. Enable the Ignore failure option for all actions that are placed above the HTTP Request action. The option is available under Execution and error handling options of an action.

If a particular action fails, Loftware Automation starts executing the next action on the higher level of hierarchy.

Example 93. Example

If the Set Printer action on level 1.1 fails, the execution does not continue with Print Label action on level 1.2 because it will likely fail as well. It continues with the HTTP Request action on level 2, because it is the next action in the higher-level hierarchy.

The same logic can be implemented for looping actions, such as Use Data Filter, Loop and For Each Record. With these actions, you iterate through all members on the list. If processing of one member fails from whatever reason, by default Loftware Automation stops processing all other members and reports an error. If you enable Ignore failure option, the processing of the failed member stops, but Loftware Automation continues with the next member. At the end, the error is reported anyway.

Synchronous Print Mode

Asynchronous Print Mode

The default operation mode of Loftware Automation is asynchronous mode. Asynchronous mode is a form of printing, during which a trigger sends data for printing and closes connection with the print subsystem. The trigger does not wait for the result of the printing process and does not receive any feedback. Immediately after the data is sent, the trigger is ready to accept a new incoming data stream.

Asynchronous mode boosts trigger performance and increases the number of triggers that can be processed in a time frame. Each printing process has buffer in front – this is where the trigger feeds the print requests in. The buffer accommodates for trigger spikes and makes sure no data is lost.

If an error occurs during processing, it still gets logged in Automation Manager (and Loftware Control Center, if you use it), but the trigger by itself is not aware of it. When running Automation in asynchronous print mode, you cannot define conditional actions that would execute, if the trigger execution is in error.

Synchronous Print Mode

In comparison to asynchronous mode, synchronous mode doesn't break connection when the printing process begins. In this mode, the trigger sends data for printing and keeps the connection to the print subsystem established for as long as it is busy executing actions. When the printing process is complete (successfully or with an error), the trigger receives feedback about the status.

You can use this information inside the actions that are defined in the same trigger and decide to execute another action in case an error occurs. You can also send print job status back to the data-issuing application. For more information, see section Print Job Status Feedback.

Example 94. Example

You can report printing status to the ERP application that provided the data.

Enabling the Synchronous Print Mode

Print mode is definable per-trigger. To enable synchronous mode in a trigger, do the following:

Open the properties of the trigger.
Go to Settings tab.
Select Other.
In section Feedback from the Print Engine, enable option Supervised printing.

Note

Use synchronous printing mode when you want to receive status feedback within the trigger or print your labels in the FIFO method. FIFO method means that labels are printed in the same order as receives trigger events. When a trigger runs in synchronous printing mode, it communicates with a single printing process only.

By default, multi-core processing can't ensure the printing order. By changing multi-threaded printing defaults and limiting concurrent requests, you can ensure the FIFO method:

Open file product.config in text editor.

The file is located here:

%PROGRAMDATA%\Loftware\Loftware\product.config

Set the values for elements MaxConcurrentPrintProcesses and MaxConcurrentSessionPrintProcesses to 1.

<configuration>    <IntegrationService>        <MaxConcurrentPrintProcesses>1</MaxConcurrentPrintProcesses>        <MaxConcurrentSessionPrintProcesses>1</MaxConcurrentSessionPrintProcesses>    </IntegrationService></configuration>

Save the file. automatically updates the service with the new number of print threads.
Open Builder and go to your trigger properties.
Go to the Execution tab.
In section Concurrent Requests set Number of concurrent action executions to 1.

Print Job Status Feedback

The application that provides data for label printing into Loftware Automation might expect to receive information about print job statuses. Feedback can be as simple as "All OK" in case of a successful print job generation, or detailed error description in case of an issue. Due to performance reasons, Loftware Automation disables feedback possibility by default. This ensures high-throughput printing as trigger doesn't care about the print process execution. The errors are logged to log database, but the trigger does not handle them.

You can also use this method to send feedback about other data the trigger collects. This can be status of network printers, number of jobs in the printer spooler, list of labels in a folder, list of variables in the specified label file, and many more.

	Note
	To enable feedback support from print engine, enable synchronous print mode. For more information, see section Synchronous Print Mode.

Enable print job status feedback using one of the two available methods.

Trigger provides feedback about print job status (Synchronous feedback)

Some triggers have built-in feedback possibility. If synchronous print mode is enabled, the trigger is internally aware of the job status. The client can send the data into trigger, keep the connection open and wait for the feedback. To use this feedback method, select and use a trigger type that supports providing feedback.

If an error happens with any of the actions, the internal variable ActionLastErrorDesc contains the detailed error message. You can send its value as-is or customize it.

For more information, see details about the respective trigger types.

Web Service Trigger: This trigger type supports feedback by design. The WSDL (Web Service Description Language) document describes details about the Web Service interface and instructs how to enable feedback. You can use the default reply that returns error description in case the print action failed. Or, you can customize the response and send back content of any variable. The variable itself can contain any data, including label preview or label print job (binary data).
HTTP Server Trigger: This trigger type supports feedback by design. Loftware Automation uses standard HTTP response codes to indicate print job status. You can customize the HTTP response and send back content of any variable. The variable itself can contain any data, including label preview or label print job (binary data).
TCP/IP Server Trigger: This trigger supports feedback, but not automatically. To make it deliver feedback, configure the data-providing client not to break the connection once the data is sent. After the print process completes, the next action on the list (Send Data to TCP/IP Port) might have the setting Reply to sender enabled. Provide feedback over the established still-open connection.

Action provides feedback about print job status (Asynchronous feedback)

In case of triggers that do not natively support feedback or in case you want to send feedback messages during the trigger processing, define an action that sends feedback to a selected destination. In this case, the data-providing application can close the connection as soon as the trigger data is delivered.

Example 95. Example

You used the TCP/IP trigger to capture the data. The client dropped connection immediately after the data was sent, so we cannot reply over the same connection. In such cases, you can use another channel to send feedback. You can configure any of the outbound-connectivity actions, such as Execute SQL Statement, Open Document/Program, HTTP Request, Send Data to TCP/IP Port, and others. You would place such action under the Print Label action.

If you want to send feedback only for specific status, such as "error occurred", you can use the following methods.

Using condition on action: Print job status is exposed in two internal variables (ActionLastErrorID and ActionLastErrorDesc). The first one contains error ID or contains value 0 in case of no reported errors. The second one contains a detailed error message. Use values of these variables in conditions on actions that you want to execute in case of errors. For example, you would use the action HTTP Request after printing. The action would send feedback in if an error occurred. To enable such feedback, do the following:

Open trigger properties.
In ribbon group Variable, click the Internal Variables button and enable variable ActionLastErrorID.
Go to Actions tab.
Add the action Send Data to HTTP.
Inside the action's properties expand Show execution and error handling options.
For Condition, enter the following. The action with this condition executes only if an error occurs and ActionLastErrorID contains the error ID (any value greater than 0). By default, the conditions runs using VBScript syntax.

ActionLastErrorID > 0

You also have to enable the Ignore failure option on each action you expect to fail. This instructs Automation not to stop executing actions entirely, but to continue with the next action on the same hierarchical level.

	Note
	For more information, see section Error Handling.

Using action Try: Action Try eliminates the need for coding conditions. The action gives you two placeholders. Placeholder Do contains actions that you want to run. If any error occurs when running them, the execution breaks, and actions in the On error placeholder are executed. You would use outbound-connectivity actions in this placeholder to provide a print job status feedback. For more information, see section Try.

Excluding printers from automated printing

In certain cases, your printing environment requires you to exclude some of your printers from the automated printing process. Possible reasons why you should exclude printers from the automated printing are your company printing policy or the limitations of you license.

By default, Automation prevents automated printing using file printers, such as Microsoft Shared Fax Driver, Microsoft Print To PDF, Microsoft XPS Document Writer, and similar. These file printers require the users to manually select the location for their "printouts". The request for manual user intervention causes the print engine to stop, reporting an error.

To prevent the Automation from using specific printers in the running configurations:

	Note
	When specifying the excluded printers from the automated printing in the `product.config` file, you must also explicitly list your file printers.

Open file product.config in text editor.

The file is located here:

%PROGRAMDATA%\Loftware\Loftware\product.config
Create a backup copy of the product.config file.

Automation uses two parameters to check which printer model and printer port should be excluded from automated printing. Add these parameters to your product.config file.

/IntegrationService/DisabledPrinterDrivers and type the printer models you want to exclude from automated printing.

/IntegrationService/DisabledPrinterPorts and type the ports you want to exclude from automated printing.

<configuration>    <IntegrationService>        <DisabledPrinterDrivers>NiceLabel Graphics Driver,NicePrinter1200dpi</DisabledPrinterDrivers>    
        <DisabledPrinterPorts>LPT1,LPT2</DisabledPrinterPorts>    </IntegrationService></configuration>

Once you define the printer models and printer ports in the product.config file, you can still run your Automation configurations, but your updated settings prevent printing on the listed printers. Automation reports an error if the these printers are part of the running configurations.

	Note
	Automated printing does not stop if the excluded printers are used in the Redirect Printing to File action.

Using Store/Recall Printing Mode

Store and Recall printing mode optimizes the printing process. It enhances printer response by reducing the amount of data that needs to be sent during repetitive printing tasks.

With store and recall mode activated, Loftware Automation does not need to resend the complete label data for each printout. Instead, the labels (templates) are stored in the printer memory. Fixed objects are stored as such, while placeholders are defined for the variable objects. Loftware Automation only sends data for variable label objects and the recall commands. The printer applies received data in the placeholders on the stored label and prints the label by recalling it from the memory. Typically, a few bytes of data are sent to the printer, compared to a few kilobytes as would be the case during normal printing.

The action consists of two processes:

Store label: During this process, the application creates a description of the label template formatted in the selected printer's command language. When done, the application sends the created command file to the printer memory and stores it. You can store a label from label designer or from Loftware Automation using the Store label to printer action.

	Note
	The label must have the store and recall printing mode defined in its properties before you can store it to printer.

Recall (print) label: A label stored in the printer memory is printed out immediately. Using the recall process, Loftware Automation creates another command file to instruct the printer which label from its memory should be printed. The actual amount of data sent to the printer depends on the current situation. For fixed labels without any variable contents, the recall command file only contains the recall label command. For variable labels that contain variable fields, the command file includes the values for these variables and the recall label command.

To recall a label from Loftware Automation just use one of the usual printing actions. When executed, the action analyzes the label and enables the appropriate printing mode: normal print or recall print, as defined in the label.

	Warning
	Before activating this mode, make sure the appropriate printer driver is selected for the label printer. Not all label printers have the ability to use the store and recall printing mode. The printer driver for which the label was created in the label designer must also be installed on the machine where Loftware Automation is running.

High-availability (Failover) Cluster

Loftware Automation supports Microsoft high-availability (fail-over) cluster. A fail-over cluster is a group of independent computers that work together to increase the availability of label printing through Loftware Automation. The clustered servers (called nodes) are connected by physical cables and by software. If one or more of the clustered nodes fail, other nodes begin to provide service (a process known as fail-over). In addition, the clustered roles are proactively monitored to verify that they are working properly. If they are not working, they are restarted or moved to another node. The clients providing data connect to the IP address that belongs to the entire cluster, and not to the individual node IP addresses.

To enable Loftware Automation to perform in a high-availability cluster, do the following:

Set up Microsoft Failover Clustering feature on your Windows Servers.
Install Loftware Automation on each node.
Enable fail-over cluster support in Loftware Automation properties on each node.

Do the following:
1. Open File > Options > Automation.
2. Under Cluster Support group, enable Failover Cluster Support.
3. Browse for the folder, located outside of both nodes, but still accessible with full access privileges to Loftware Automation software. Important system files that both nodes need will be copied to this folder.
Configure the cluster to start Loftware Automation on the second node in case the master node is down.

See the detailed description about configuring Automation failover cluster in our KB article.

Load-balancing Cluster

Loftware Automation supports Microsoft load-balancing cluster. Load-balancing cluster is a group of independent computers that work together to increase the availability and scalability of label printing through Loftware Automation. The clustered servers (called nodes) are connected by physical cables and by software. The incoming requests for label printing are distributed among all nodes in a cluster. The clients providing data connect to the IP address belonging to the cluster, and not to individual node IP addresses.

	Note
	You can use TCP/IP-based triggers with load-balancing cluster. These triggers are TCP/IP Server Trigger, HTTP Server Trigger, Web Service Trigger, and Cloud Trigger.

To enable Loftware Automation for load-balancing, do the following:

Set up Microsoft Load-balancing Clustering feature in your Windows Servers.
Install Loftware Automation on each node.
Load the same configuration files in Automation Manager on each node.