Introduction

Cypress document capture offers the benefits of page-level indexing, archival, and retrieval. To facilitate these capabilities, Cypress provides several tools that allow you to submit print jobs to your DocuVault:

  • The Cypress capture driver is the universal print driver that captures and sends all Windows documents to the Cypress DocuVault.
  • Direct Document Input (DDI) uses a sender program installed on the host platform. It is designed to support the needs of SAP, Oracle, Baan, and other popular business applications by allowing much more information to be submitted with the print job than LPD In allows. This utility also provides status and feedback to selected applications and offers a variety of time-saving features.
  • FT In accepts, formats, captures, and stores any file sent to the Cypress server’s FT In directory via network file transfer.
  • LPD In accepts, formats, captures, and stores SYSOUT or ASCII documents received via the LPD protocol.
  • TCP In accepts, formats, captures, and stores files sent to Cypress devices via a TCP/IP connection.
  • The Windows capture driver is a Cypress-specific driver that you can use to submit jobs to Cypress from Windows applications. You can submit your jobs to Cypress from virtually any platform using lpd (LPD In), Direct Document Input (DDI), or network file transfer (FT In). You can also send a print data stream directly to Cypress using TCP In.

You can capture documents, which are then added to your DocuVault, through these non-Cypress sources:

AS400/1Series systems
BARR systems
Kofax Ascent
PeopleSoft SQR
SAP via DDI
SAP BusinessObjects
UNIX systems
UNIX Oracle systems
VPS print queue on IBM mainframe systems
Xerox LCDS/Metacode

How Cypress Handles Source Files

Cypress allows you to manage not only documents for distribution in the Cypress DDOC format, but also source files, or documents that have been stored in their original formats. The FT In component allows you to submit documents to Cypress via network file transfer and store them in their original format, in the Cypress DDOC format, or both. When you open a source file in Cypress, you can view the document in its native application rather than a Cypress DocuSpace.

Inbound e-mails from your Microsoft Exchange Server(s) do not require FT In. They are automatically captured and sent directly to Cypress for processing.

If you want to use Cypress features such as full-text indexing with your original source files, you can convert many source files to the Cypress DDOC format using Native File Conversion. See Using the Native File Conversion Utility for more information.

Data generated or maintained by ERP, CRM, and other enterprise-class business applications is typically extracted and written as an individual document or report. Depending on the application, the report can be generated by the application itself or by a reporting tool such as PS/nVision, Crystal, SQR, etc. Often, these reports are generated in an application-specific format such as Excel, Word, or other commonly used application formats to ensure that reports can be widely distributed and viewed.

Your business application or reporting facility writes the source document files to a specific directory that is monitored by Cypress. Any files that are placed in this directory will be processed by Cypress via FT In per your requirements.

If a Report Distribution Manager (RDM) processor is configured to monitor the directory, the files will be processed by RDM. Specifically, RDM can process source files for addressing (recipient selection) and indexing requirements, then deliver them to the Inboxes of all appropriate recipients. The subreport definition is used for routing and indexing only; the content of a source document file cannot be broken down into smaller subreports.

Once a document has been delivered to the user's Inbox, the user clicks the document title within an Inbox Viewer and follows the prompts to launch the document in its original authoring application.

As documents are acquired by Cypress, they are indexed in several system indexes. In addition, you can index and archive documents automatically (using an RDM subreport or a CPF program) or manually (using controls available in the Cypress DocuSpace).

Incoming e-mails can possibly create two types of source files: the e-mail record and the attachment document record (if there is an attachment to the e-mail). Each e-mail record includes references to any associated attachments, which have the document system type of e-mail attachment.

Once archived, source document files can be retrieved when you are querying a DocuVault using either the Knowledge Builder user interface or Cypress.Web. You can view any source document by selecting the document title from within the list of query results and then clicking the Launch Application button.

The device monitoring the watched directory substantially dictates how the source files are to be processed by Cypress:

If your goal is to distribute files to recipients, you will need to configure an RDM processor to watch the directory, and create Report and Subreport Definitions to control addressing and indexing, as required. See the ASG-Cypress Report Distribution Manager Administrator’s topic for more information.
If your goal is to archive source files without distributing them, you will most likely want to configure a hold queue to watch the directory. See Capturing Source Files for more information.

If you want to use source files, ASG recommends that you follow some or all of these suggestions to make the process as smooth and error-free as possible:

Understand the Cypress indexing model. Consult the Knowledge Base if you are not yet familiar with the Cypress indexes and the creation of data indexes.
Understand the Cypress report distribution model. Source files are distributed using RDM and it will be necessary for you to create a variety of RDM objects, enter RDM criteria, and perform other tasks that require familiarity with RDM.
Identify a robust naming convention. You can extract information from the name of the source file that you can use when you index and route the document from RDM. To ensure that your RDM subreport definition works as expected, make sure that the naming convention used for your source files enables you to achieve your objectives.

For example, you may need to create file names containing information that uniquely identifies the file (to aid in retrieval) or a recipient (to aid in automatic distribution). Most reporting applications, such as PS/nVision, offer replacement parameters that enable file names to be dynamically constructed based on information in the file. You will most likely need to employ such a scheme to achieve the desired results.

In addition, make sure that the structure of the file name enables you to use RDM criteria to extract unique data that can be used for recipient identification and automated indexing. Become familiar with RDM criteria to ensure that the naming convention you develop will be successful.

Files supported by Native File Conversion can use document content for RDM purposes and are not restricted to the same file-naming convention limit, allowing for more intuitive distribution.

Formats for Job Submission Options

Many different job submission options—DDI, FT In, LPD In, and TCP In—available in Cypress play a part in how you may want to invoke formats. The figure below illustrates how formats may be invoked using the different job submission options.

Documents that enter Cypress via the Windows capture driver do not use formats.

If you define two different formats for the same document, Cypress will evaluate how each format was specified to determine which should be used. The methods in the table above are listed in order from the highest priority to the lowest. For example, a format specified by an InLine command will always take precedence over any other format for a particular document. Similarly, a format determined by Auto Format will be used in place of a format defined in a device definition, and a format defined in a device definition will take priority over the default format definition.