Many Infor SX users use UnForm for document production, and in many cases UnForm and SX are on different machines. SX is sometimes capable of submitting many hundreds of print jobs virtually simultaneously, and that can strain UnForm's ability to transfer all those files from the client (SX) to the server (UnForm).
With CirrusPrint 3, UnForm users now have a zero-cost way to improve both performance and reliability of these large batches, using the free 2-device version offered with version 3.
SX Printing
SX prints documents via a print script, which is configured in SX's sasp screen. The print script is given a printer name argument, and implicitly provides a file name argument to that script. The printer name argument is handled by the script to tell UnForm where to print the job. For example, if the print script configuration is "rxfprintuf.sh SacWhse", the script could launch an UnForm job using a uf100c command line with "-o windev:$1" and runtime substitution would provide UnForm with "windev:SacWhse" as the output device for the job. The script can provide the output device in a format that matches the system where the UnForm server runs, whether Windows or Linux.
The bottlenecks occur when the UnForm's uf100c client is required to submit hundreds of files across the network virtually simultaneously. That stresses the UnForm server, potentially to the point where connections are delayed or even can't be accepted due to resource constraints.
CirrusPrint Transport
Leveraging this scripting structure, CirrusPrint can be used as the transport mechanism that sends the print files from the SX machine to the UnForm machine, and runs the uf100c command on the UnForm server rather than the SX system. Doing enables submission via the file system rather than over the network, reducing the overhead. CirrusPrint 3 is able to transport of hundreds or even thousands of files quickly with less overhead.
CirrusPrint supports two features that are used for this process. One is path-based import sources, where directories can be monitored for new files, and those files sent to an output device. Two is command-based output devices, which can run a command line, such as uf100c, at the remote system.
CirrusPrint Server on SX, Client on UnForm
Install the CirrusPrint server on the SX system. Define a company and location, and then install the CirrusPrint client on the UnForm system and configure it to login as the location.
Output Device
Configure an output device in the location called 'unform' (or anything you want). This will be a command type of device, and the target field will be an UnForm command line that looks like this:
uf100c -i "{file}" -e "{errfile}" -o "windev:{srcid}" -f your-rule-file -asyncrpq c:/sdsi/uf100/server/rpq
Adjust this for your specific configuration, such as your rule file, or a different structure of -o option if you use share names or UnForm runs on Linux. The most unusual option is -asyncrpq path. Many users are familiar with -async, which causes jobs to be spooled rather than run immediately, which provides a way to pace out jobs without overtaxing the system. Normally those jobs are still submitted via a connection to the server, which involves some overhead. However, if the client and server are running on the same system, you can use the -asyncrpq option to instruct the client to submit the job through the file system, avoiding the connection overhead. Those jobs are processed the same way as the -async jobs, but are submitted directly to the server's rpq subfolder rather than indirectly through a network connection.
Input Sources
Configure a File type input source that monitors a folder whose last segment is the name of a printer. This simplifies the print script changes required. Make the input source id also be the name of the printer. This allows the -o argument in the output device to use the source id as the printer name. For example, the source id could be SacWhse and the input folder /files/to/unform/SacWhse.
Each input source can target one or more output devices. You'll configure one input source for each printer, each targeting the unform output device you configured. Now any file that shows up in /files/to/unform/SacWhse will be submitted as an UnForm job going to windev:SacWhse.
Script Changes
The last step hooks up the print script and the monitored folders. Since the $1 argument (%1 in Windows) contains the name of the printer and $2 the name of the print file, you simply rename the $2 argument to /files/to/unform/$1. The operating system will move the SX-provided print file to the monitored folder for the printer. Look in the script for where it runs the UnForm client, and replace that with a command to perform the rename, using these $1 and $2 built in arguments or the more intuitive script variables typically found in the SX-supplied print scripts.
An important consideration here is that this process must perform an atomic transfer, meaning the report file must arrive in the monitored folder in a complete state. CirrusPrint will ignore incomplete files of some types, but a plain text file like SX produces is not one of those types. A file copy won't be reliable because CirrusPrint may pick up a partial file. Instead, use a rename technique (mv on Linux, rename on Windows). If you want to make a copy of the report file, do so before this step so you can rename the file to the monitored folder rather than copy it.
Note also that this setup assumes server-side printing by UnForm, which is a requirement of async or asyncrpq submissions. In other words, the printers must be defined on the UnForm system.