Introduction
The implementation of Remote Delivery is intended to involve the minimum of disruption to the current processing of the COPIAFACTS fax server, while maximizing the throughput and convenience. Changes have only been necessary in the main engine and in the command-file processor CF9CMDFILE, with support for the new queue types added in CF9MSMQ.
CF9CMDFILE is the handler for reading and writing (but not parsing or creating) all command-files for the main engine. It handles Unicode encoding issues and input/output for both files and streams, the latter being used for MSMQ messages.
The current implementation assumes that the ACTIVE_WORK and WORK_TYPES modes of operation are not in use.
Configuration changes in the Server Engine
The configuration folder variable value is saved in a global rd_folder variable for the node along with a global rd_status variable which takes the values RD_NONE, RD_ORIGINAL or RD_DELIVERY to indicate the node type.
The inbound and outbound queue names are saved in global variables rd_in_qname and rd_out_qname. There is a check that these queues must be defined if the node type has been set, and vice-versa. The queues are opened at start-up, and start-up fails if the queues cannot be opened. Currently the outbound queue is left open permanently during the lifetime of the engine.
Since the inbound queue is operated as an FS queue, only one such queue (fax, e-mail, sms) is permitted for a node. The inbound rd_in_qname is not made available for normal fax launch operations and is only used for original and delivery node FS files.
CF9MSMQ now supports these queue types.
Originating Node outbound processing
In the preparation of an outbound fax on an originating node, the detection of a matched action code (applied at launch, in the engine lookup, or as a variable value in ACTION_CODES) suppresses the write-back of the FS file to the TOSENDx folder with status3, just as for brief-process e-mail and SMS FS files. Next, at the point at which a 'KEEP_FAX' option is checked, the RD_ORIGINAL node type, combined with an action code in the specified range, causes a modified KEEP_FAX operation to be performed. This will create a single TIF file, named with the base name of the FS file, and placed in the rd_folder folder. The FAX_HEADER_RD variable overrides the header content (with default 'none') in the same way as FAX_HEADER_KF would for the single TIF. At the same time a filename is built for a backup FS file, to be saved later in the RDFSFILES folder. The transaction is then treated as a SUPPRESS_FAX operation with a successful outcome.
The only other change in the main engine affects writing FS files with a 'successful' outcome code. Failures resulting from launch issues such as do-not-send matches will have been processed in the normal way, as will failures to save the remote delivery TIF file. For the successful remote delivery files, the SENT FS file will have been built up in the engine by writing to CF9CMDFILE line-by-line as usual, but a new CF9CMDFILE operation WriteFSQ will be called instead of the normal file-write function. WriteFSQ performs two operations: it saves a backup copy of the file to the job RDSFSFILES and it also writes the FS content to the rd_out_queue. The normal writing of the FS file to SENT is suppressed.
Inbound Fax FSQ processing
The existing 'get-next-FSfile' processing has been modified, for both originating and delivery nodes, to handle fax in addition to e-mail and SMS FS files, and to work with a new line mode LM_OB_QUEUE. This has involved small changes in a number of places to allow for the new line mode.
Delivery Node inbound processing
In CF9CMDFILE, the processing of an FS-content inbound stream from an rd_in_queue message has been modified for a node identified as a delivery node. Before passing the command file to the main engine for processing, a backup memory copy is made, and in the original copy the $fax_user command is replaced with one which references the DefaultUser for the node, and all the $fax_filename commands and the $fax_cover command are replaced by a single command referencing the TIF file with the same basename as the FS file in the rd_folder for the delivery node. In addition the $fax_send date/time commands, the $fax_next date/time commands and the $fax_send line/channel commands are all removed as a precaution, though they should not be present in a file sent for remote delivery. The incoming action code is saved and the ACTION_CODES variable is removed.
The modified 'working' file is then made available to the main engine for normal parsing, and processing proceeds for delivery.
Delivery Node outbound processing
When the FS class is ready to be written back to the SENT, FAIL, or TOSENDx folder, the saved incoming FS content is retrieved instead, and updated from the 'working' content ready to be written. The update transfers the following items to the saved FS content:
•the $fax_status2 (outcome) value is replaced in the original FS
•the set of OC_... variables in the 'working' FS file are copied, replacing any already present.
•the variables DIALED_DIGITS, LAST_OUTCLASS, LAST_OUTCOME and LAST_FS_WRITE are also copied.
•fax result variables and BladeWare result variables are also copied.
•the final $attempt_record command in the 'working' file is added to the original FS content.
The updated version of the original content is then written as a message in the delivery node rd_out_queue. If CF9CMDFILE low-level trace is specified, a copy of the 'working' file content will be written FFTRACE for diagnostic purposes, before this content is discarded.
Originating Node inbound processing
The incoming rd_in_queue message is loaded as a fax queue message but is passed direct to the 'end fax' state which will, on an originating node, first check for a matching RDFSFILES message and delete it. The FS file is then processed as if the attempt had been made locally, with an NQ message written if specified, and the file is then saved in SENT, FAIL or TOSENDx in the normal way.
