WebSpool

Overview

WebSpool ensures that files are transferred to the client in the correct form.

Data is handled consistently, regardless of the connection type.
Data can be customized before being sent.
Externally-sourced documents are handled the same way as host data.
The efficient architecture of the software guarantees good performance and high productivity.

Architecture

All files pass through a series of processing steps, from receiving or importing files to displaying or processing files at the client, and each file always results in a defined document status. The statuses are represented by directories. Each document in a specific directory thus has a define status. An administrator can therefore easily and intuitively get an overview of the document delivery status. The processes involved only handles a small amount of the data to be processed, which leads to good performance. Additionally, access to the physical directories is minimized by cache mechanisms.

Each document basically passes through the following stages:

Reception of the file by the host (mainframe, UNIX) or by an external source (receive).
Optional transformation into a form that is usable for the client and preparation for transfer to the client (in).
Notification of the client (notified).
Delivery to the client (out).
Archiving files for further use (archive).

The directory system for WebSpool is structured as follows:

spool
     /receive
     /in
     /notified
     /out
     /archive

The location of the basic "spool" directory can be configured and is usually in the basic directory for user configuration.

During processing, every document must be clearly and uniquely assigned to a user. For this reason, a consistent naming scheme is used that takes these requirements into consideration. When transferring a file to WebSpool, these attributes are added to the original file name and an internal name is created.

Configuring WebSpool

WebSpool is configured so that no changes are needed for most installations.
All configuration parameters have the Spool prefix and are specified in the file ajax.ini.

The application server assigns a file type to the MIME type when the file is requested. To configure this assignment, refer to the documentation for your application server.

Importing files

The forwarding of mainframe documents or print data to the client is done completely automatically and requires only a few typical configurations. For a UNIX connection, specific options (depending on the infrastructure and the specified tasks) can be considered. The most suitable solution must be determined for each case.

Except with mainframes, importing files generally takes place using the HTTP POST command in the form of multipart/form-data (see RFC 2388, 2387, 2046, 1867, 1521).

The following information must be transmitted for this:

Content-Disposition: form-data; name="User"
with user name as the content of the section. It describes the recipient.
Content-Disposition: form-data; name="File"; filename="filename"
with file content as the content as the section. In WebSpool, "filename" is used without a specified path.

This data must be sent to spool/spoolin.jsp. The example spool/upload.jsp illustrates the procedure.
For UNIX integration, for example, the program logwebimport (component of LogWeb installation) can be used.

Example: logwebimport -u demo -f test.txt -config logwebimport.ini or logwebimport -u demo -f test.txt

In the case of the latter, logwebimport searches for its configuration parameters in the LogWeb server.ini. An essential parameter is ImportDestination.

Example:

ImportDestination= http://127.0.0.1:8080/ajax/spool/spoolin.jsp

With this simple import interface, each external source should be capable of transferring data to WebSpool.

Transforming data

For special tasks, data can be modified on its way to the client. The possibilities range from simple renaming (which results in a new MIME type) to replacing text for language-specific variations, from broadcasting a document to many users, to generating PDF files on the fly.

The required transformation or filter functionality is implemented as a Java class. Rules establish which filters are applied to which document. The rules can apply to both file names and file contents.

Example: Filling a PDF form with host data in the form of an XFDF file (see Adobe XFDF 2.0 Specification).

The host does not produce print data or generate the complete document, but delivers only the content of fields, which can be derived from a database, for example. WebSpool fills a PDF form with this data, and delivers a PDF document to the client.

The host application determines which form to use. This information is also transmitted in the XFDF data flow. The forms are stored on the server for the Web application. In this example, the forms are found in the directory "PDFTemplates".

The file filter.xml determines which filters to apply under which conditions. The file contains the following parameters, among others:

If the file name ends with .lwf and
the file contains the text <xfdf xmlns = http://ns.adobe.com/xfdf/. (Note the specific features of XML files here, particularly the coding for the characters '"', '<', '>')
Apply the filters "XFDF Merge" to the input file
and then the filter "rename".

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE spool-filter SYSTEM "spool-filter_1_0.dtd">
<spool-filter version="1.0">
   <description> Spool filter for LogAjax</description>
   <doc-class name="XFDF Merge PDF">
      <condition>
         <and>
1.          <filename regexp=".*\.lwf"/>
2.          <contains regexp=".*\x3Cxfdf\s+xmlns\s*=\s*\x22http://ns.adobe.com/xfdf/\x22"/>
         </and>
       </condition>
       <filter-chain>
3.        <filter name="XFDF Merger" class="de.logics.logwebAppV3.spool.in.filter.PDFFormFiller">
             <param name="TemplateDir" value="PDFTemplates"/>
          </filter>
4.        <filter name="rename" class="de.logics.logwebAppV3.spool.in.filter.Rename">
             <param name="extension" value="pdf"/>
          </filter>
      </filter-chain>
   </doc-class>
</spool-filter>

If no errors occur during processing, the generated file is prepared for transfer to the client. If there is an error, the client gets a detailed message.

You can find a short guide to implementing a filter in the developer documentation. A description of the corresponding Java interface is available on request.