The Word Merge feature in Job Administration allows a service-bureau customer to submit a job consisting of a Word document and its data source, exactly as for a normal Word merge to print, and have the resulting personalized documents faxed or e-mailed by Job Administration.  The Word Merge option therefore makes it very easy for clients to prepare jobs for faxing or e-mailing.  Although the name is similar, Word Merge does not use FFMERGE, and no special text is needed in the document, other than the merge fields.

There are four pre-requisites for operating Job Administration Word Merge:

The Word Document and its data source must be specified as the $job_document and $listfile, with the data source in a supported list format.  The list must have a header specifying the field name for each column. One of the list columns must of course specify the destination fax or e-mail address.  WordMerge implies the OmitListHeader keyword, so the latter need not be specified for WordMerge jobs.

The $convert_types command in FAXFACTS.CFG must specify that DOC conversion can be performed.

FFEXTERN should be running, on any node(s) in the system which can access the CopiaFacts common data area. It should have a preprocess for queue 0 defined in the usual way with all the necessary document types checked, and with Word installed to perform the conversions and merge.

The job instance must have the $job_options keyword WordMerge specified.  You should only specify this option on for jobs which will involve a Word merge.

The operation of the Word Merge feature is as follows:

Prior to launch, Job Admin runs the REMOVEDS program, which has two functions: (A) it deletes the data source from the document, and saves a copy as a plain document. (B) it makes a list of the named mergefields in the document.  The launch will fail if any named document field is not present in the header row of the list.  REMOVEDS requires Word 2003 or later to be installed on the machine on which the job is launched.  If the Word Document has no MERGEFIELDs, and if no ADDRESSBLOCK or GREETINGLINE fields are present (the content of these is not checked against the field list) then it will not be involved in the merge, and will be pre-converted if the PreConvert option is present

Unlike a normal 'PreConvert' launch where a single pre-conversion is done on the master document, the job is launched with every item sent to the PREPROC folder for conversion.  In addition, each FS file contains not only BCF1, BCF2, etc. (with the contents of the individual list row), but also BCH1, BCH2, etc. with the names of the fields from the list column header row.

The special WordMerge option of the document converter process (in FFEXTERN/CVSINGLE) writes a small temporary data file before starting the document conversion: this contains two rows, the header row and the individual data for this item. It also attaches this file as the temporary data source for the document. This causes Word to run a single-item merge and personalize a single output document.

Depending on the broadcast type, the resulting output TIF file is then faxed in the normal way, or e-mailed either as a TIF or as a PDF.

Running Word automation for every item in a job can sometimes take as long as actually faxing the output.  If you offer this service to bureau customers who send very large jobs, you may have to set up several machines or virtual machines running Document Converter to keep up with your faxing and e-mailing machines.

Handling Extra Blank Pages inserted by Word

Sometimes Microsoft Word will inexplicably add a blank page at the end of each merged document during a merge.  A Google search will reveal many suggestions for manually tweaking the master document, with mixed success, to avoid this; but it is hard to incorporate this into a production workflow.  Earlier releases used Word automation to attempt to detect a blank final page, but this was subject to false positives, which could affect the formatting of merge fields in other parts of the document.  The WMnostrip job option was used to suppress the check.

The Word automation check is now no longer done before the page is rendered to TIF.  Instead each multi-page TIF files created in a WordMerge is opened after creation, and if the last page is all white, it is deleted.  You can still use WMnostrip to suppress this new check, but this should only be needed in a high-volume merge with long and pre-checked documents, when the small extra time needed to open and check each document might be noticeable.

Bulk WordMerge

The Bulk WordMerge feature is an optional enhanced version of WordMerge for high-volume applications.  It requires a Document Converter node or nodes which are configured as Bulk WordMerge nodes (in CFHWL).  Bulk WordMerge jobs are provisioned and set up in exactly the same way as normal WordMerge jobs, with the addition of a non-empty job variable named USE_WMDC to initiate the use of a special Document Converter node.  An MSMQ queue is also required, with the queue name specified on a $preproc_wmdcqname configuration command.

Each WordMerge job is processed through a single Document Converter node, and if you have multiple Document Converter nodes configured for Bulk WordMerge, a job will be processed on whichever node picks up the MSMQ message generated at the end of the launch.

The job launcher creates FS files in a subfolder under PREPROC named with the job name, and creates a tab-separated-value job list file comprising all the lists specified for the job.  The Document Converter node then runs CVSINGLE to process the complete merge, both creating the necessary personalized TIF, PDF or DOC files and updating each FS file with the generated filenames.  As each FS file is processed, it is moved out of the special PREPROC subfolder and into the TOSEND queue as usual.  Suspending a job stops the merge, which can then be restarted, after the job has been resumed, by means of Job Action 30 or by using the JOBADMIN right-click menu for the job.

The principal benefits of Bulk WordMerge are:

The merge typically runs up to 20 times faster than a normal WordMerge.  For example over 3 pages per second instead of a page every six seconds.

Each Word merge-master document is only loaded once, by one node, for the merge.

Job documents other than Word can be included in the same job and will be preprocessed (by a normal FFEXTERN node) if necessary before the merge is done.

Multiple Word documents can be merged in a single job, using the same Data Source.

In an FEB1 job, only the documents needed for a specific destination are created from the merge.

Current WordMerge users can use the same procedures to create and launch jobs, with only one variable needed to select the method.