DELIVER

Syntax

deliver "send to"|{expr},"docid"|{expr} [,combine yes|true|1 |{expr}]  [,args "list"|{expr}] [,tag "value"|{expr}, ...] [,async 0|1|{expr} [,ufnotify "address"|{addr$} [,ufnotifycc "address"|{addr$}] [,ufnotifyon "err | rty | ok" | {list$} ]]

Description

The deliver command generates subjobs whenever the document ID and output format changes, producing files as needed based on the list of "send to" values, and then sending them via email, fax, or custom configured methods.  Custom configuration provides facilities to deliver the generated documents to disk, program or script, web servers, cloud services, and more.  The output format is determined by the deliver.ini file, and if the recipient is an email, fax, or other destination.  Multiple destinations can be provided in a comma-separated list and each will get their own copy of the document.  If the combine option is on (yes, true, or 1 turn it on), then all documents for  a given destination are combined into a single transaction.  Note that not all fax systems offer support for multiple documents in a single  transaction (i.e. msfax).  The document ID is used as the basis for the file name to be sent, which can be useful when emailing to provide meaningful attachment file names.

The args option specifies command line options passed to the subjob.  The deliver.ini configuration can also add more options.  Other tag names are used to substitute values in the delivery gateway's configuration lines in deliver.ini.  More details are provided in that file, and in the Deliver Configuration chapter.

If the async option is specified, it overrides an async setting in deliver.ini for this particular job.  If turned on, the delivery is queued rather than delivered as part of the current job.  Queued files are stored as encrypted objects in the deliver directory and processed independently of the job that generates them.  When a queued file encounters an error, it is retried until successful, based on some deliver.ini configuration settings.

Any number of tags can be specified, using user-defined tag names.  When the delivery is executed, the deliver.ini configuration is scanned and occurrences of %tagname are substituted with the provided value.  Note that tag values cannot contain linefeed characters ($0A$) due to the method of parsing deliver.ini tag definitions.  Use "\n" sequences instead in message bodies, for example, where a linefeed character may be necessary.

Multiple delivery commands can be used.  This may be desired if different arguments, such as cover pages or -prm parameters, are desired to distinguish email from fax jobs for formatting.  If this is the case, the document ID should also vary, since only a unique ID and output type cause a new subjob to be executed.

When the subjob is executing, both uf.subjob and uf.deljob are true (1).

CSV formatted logs are maintained in the ./deliver directory (or other  configured directory named in logdir= in deliver.ini.  The logs are named yyyymmdd.csv and record date/time, to, file, success, response and error  messages, and optionally the tags.

Note that code blocks can also use the deliver() function, managing the file to be delivered with jobstore/jobexec functions or other techniques.

Notification Options

You can specify a notification address, along with an optional notification cc, and a selection of when to send notification, by using the following reserved tags (added in 9.0.24):

•ufnotify sets a notification address, which is required to enable notification

•ufnotifycc sets an optional notification cc address, where an additional copy of the notification is sent

•ufnotifyon is a space-separated list of status values for which notification is sent.  This defaults to "err".  You can set it to "err rty" to notify on both errors and pending retries, or "err rty ok" to send notifications in all cases.

A notification is sent immediately after the delivery attempt.  If there is an error sending the notification, the error is logged to the server's log file.  No additional notifications are attempted.  The notification relies on server and from address settings defined in the prog/mailcall.ini file, not the deliver.ini file.

SMTP Logging

If you specify a logfile option, a detailed log of the mail server communication is written to the specified file.  This name should be unique to avoid errors if two jobs require the same log file name at the same time.  The filename can include tags to assist in uniqueness.  Note the directory where log files are to be placed must exist and be accessible to the UnForm server.  The tags are:

•@d for the date in YYYYMMDD format

•@t for the time in HHMMSS (24-hour clock) format

•@p for the process ID of the UnForm task generating the file

•@j for the UnForm job number, a sequential counter

•@k for a millisecond value, generally appended to a %t tag

Examples

Email with an html message body from the variable htmlbody$, using the async option to spool the email submission:

deliver {sendto$},{"E"+invno$}, subject "Please review and pay your invoice", note {htmlbody$}, bodymime "text/html", async 1

Fax with cover tags:

deliver {faxnum$},{"Invoice "+invno$},name {contact$},subject {"Invoice "+invno$},

 note "Your invoice is attached.\n\nThank you for your business.", logfile "/tmp/smtplogs/@d-@t.@k-@p.log"

Deliver a file to a disk location:

deliver "store.pdfdoc",{"Inv"+invno$}, store_path="/docs/invoices", subdir {dte(0:"YYYY-MM")}