/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;}
As an implementer of Documaker products, I am often asked
some variant of the question, “How can I
improve my processing performance?” Most often the answer is an in-depth
discussion about Documaker versions, resources libraries, processing models,
and hardware. Frequently there are innumerable tangential discussions that invariably
follow the initial discussion. In this article, I will discuss some models for performance tuning and scaling Documaker implementations. Any discussion on performance needs to begin with a
definition of processing methods, which describe the systems by which documents
are received and published by Documaker. The three types of processing methods are
Batch, On-demand/real-time, and Interactive.
There are similarities between each of the methods, and in fact there is even
some overlap between some of the methods. A closer look at the processing methods
will help demystify these approaches to document automation – so let’s get started, shall we?
Batch Processing
The Batch
processing method should be familiar to anyone who has been involved in
document publishing in the last 20+ years; this is by far the oldest method of
document production. Batch processing follows the event-driven or periodic
models for transactional processing. Broadly speaking, the event-driven model
uses business transactions to determine when a document should be published. An
example of this would be a new customer event, which results in a welcome
letter being sent to the customer. The periodic model describes processing that
occurs at specific time periods or cycles. An example of this would be a
billing statement that is mailed every 30 days.
Regardless of the transaction model in use, the batch
processing method starts with an input file
that contains one or more transactions. This file may be created over a time
period, in which transactions accumulate in the input file, or the file may be
created at a specific point in time in which applicable transactions are dumped
into the input file. Documaker processing can be started by a timer, e.g. a cron job on UNIX systems or Scheduled
Task on Windows systems or job
scheduler on mainframe systems, or by a job, e.g. a mainframe job, or Windows/UNIX shell script.
When Documaker processing is started, the input file is
read, documents are triggered, data is mapped to variable fields, transactions
are assigned to recipients and batches, and print files are generated. There
may be other downstream systems which begin after Documaker processing has
concluded, such as preprocessing for finishing systems, address manipulation,
file movement and staging for printing, and more – these other jobs are
external to the Documaker system but take part in the overall process.
Real-Time
The On-Demand/Real-time
(hereafter called real-time) model
is very similar in terms of what happens with Documaker processing; in fact the
actual processing flow is the same. The key differences between real-time and
batch processing are:
- the manner in which Documaker processing is executed;
- the
business transaction that precipitates Documaker processing; and, - the handling
of output files generated by Documaker.
Real-time processing generally follows the event-driven
model for transactional processing – a defined business event occurs which
results in the need for a document to be generated at the time of the event. An
input file is generated which typically contains a single transaction; that
input file is fed to Documaker either via a web service call or a request
placed into a message queue. In this configuration, there are
additional software components that are necessary to round out the
infrastructure required for real-time processing. For web service-based
requests, a web service application server (e.g. WebLogic or WebSphere) is
needed. For message queue-based requests, a message queue server (e.g. WebLogic
JMS, WebSphere MQ, or MSMQ is required. In both cases, Docupresentment is used
to broker the requests and facilitate the real-time execution of Documaker –
often called Documaker Server.