Product Overview

This topic discusses RDM fundamentals and how to implement the application, and provides an example of how to use it.

Introduction

RDM is an advanced application based on the Cypress architecture that creates a fully automated report processing and distribution environment. It enables you to create and deliver reports and subreports throughout your Cypress-controlled environment.

RDM processes report files to deliver customized content to any enterprise or Web destination, along with other subreport processing features. When you create report definitions, you can use RDM to instruct Cypress on splitting and indexing data contained in output data files. You also can specify how Cypress should deliver the new documents to the appropriate devices and recipients. Cypress’s RDM eliminates the laborious and error-prone task of manually separating and delivering reports.

Specifically, RDM can perform these functions:

Processing application output files composed of individual pages, containing multiple reports
Creating individual subreports with customized content for each user
Indexing all or select pages within the original report and/or subsequent subreports for future search and retrieval
Archiving all original report files and/or resulting subreports in the DocuVault
Addressing the subreport to a Cypress-defined device or recipient, whether explicitly defined by you or dynamically determined by Cypress
Routing each subreport to the appropriate destination

This is the Distribution Manager window:

For more information, see Distribution Manager Window.

Once RDM is set up, report creation and distribution are fully automated and easy to maintain. Also, RDM uses Windows domain security settings to simplify security management. For more information, see the ASG-Cypress System Administrator’s topic.

Advanced and Automated Features

RDM offers advanced and automated tools that enable you to control report processing functions in new and highly efficient ways. This topic provides a brief overview of RDM’s functions and features.

Address Book

The Cypress Address Book is a centralized repository of recipients and their associated information, such as work locations, output devices, electronic Inboxes, and custom selection attributes. The Address Book enables Cypress to automatically deliver documents and subreports to the appropriate destination based on information about a recipient. For more information, see Sending a Subreport to a Specific Device and the ASG-Cypress Address Book Administrator’s topic.

Bundling

The bundling capabilities of Cypress enable pages from multiple report files to be aggregated into subreports, then released to a specific recipient or device according to criteria that you define.

This productivity feature enables users to receive knowledge packages that contain all the information necessary for a specific task or activity, and provides knowledge workers with a predictable and convenient method for accessing their reports. For more information, see Using the Bundling Feature.

Data Mining

The data mining capabilities of Cypress enable you to create customized subreports that can then be delivered as Excel- or text-formatted files to any appropriate enterprise or Web destination.

Using the Cypress data-mining module, you can change the structure and presentation of report file data, summarize report data, and perform other types of data manipulations. For more information, see Installing and Using the Data Mining Module.

Supported File Formats

The only prerequisites for files processed by RDM is that they be composed of individual pages of information (not records of data). Concerning file formats, RDM can process any file that Cypress can process.

Supported Platforms and Operating Systems

There are no restrictions on which platforms or operating systems that RDM can process, as long as the report file is in one of the supported formats as described above and can be delivered to Cypress using one of these scenarios:

•

Submitted from supported Windows platforms

•

Submitted via the Cypress LPD In option (for platforms that support LPD)

•

Submitted via the FT In option (for platforms that support network file transfer)

•

Submitted via the DDI option (for jobs submitted from SAP, Oracle, Baan, J. D. Edwards, etc.)

•

Submitted via TCP In

RDM Object Types

This topic contains guidelines for Cypress object naming conventions. ASG strongly recommends that you use naming conventions that match existing application naming standards whenever possible. This approach minimizes transition times and improves cross-system communication.

For example, if a data field is named SSN on one system to represent a customer’s social security number, then the Cypress index name should be SSN to represent the same information.

This table lists Cypress Distribution Manager object types and naming convention guidelines:

Object Type	Naming Guidelines	Example
Report Group	Dictated by the corresponding RDM processor name.	SAP RDM
Report	The Report ID that the report application administrator uses.	INV001
Subreport	The report or document name.	Monthly Inventory Summary
Region	Defined in Output Manager but used bythe Distribution Manager. Typically a descriptive name is used to identify the region. Many customers find it helpful to prepend the characters rgn to indicate a region object type.	rgnInvoiceNumber
Variable	Information that will be dynamically be populated on a page-by-page basis. Spaces are not allowed. Many customers find it helpful to prepend the characters var to indicate a variable object type.	var_auto_role
Document	The generated document name is the subreport object name or subreport description. Other informational items can be appended or prepended to the Document Name (such as the report date) if it will help end users in identifying what they are about to view.	Quarterly Tax Report for Department 55

Using the Cypress ODBC Driver

ODBC is a standard database access application programming interface (API) that allows an application to access data in diverse database management systems (DBMSs) through a single interface. Accordingly, the Cypress ODBC Driver provides an interface between Cypress and other applications, allowing common access to the data stored in a DocuVault. It currently supports read-only access to statistical information gathered by the Document Access Tracking module, as well as data on recipients, devices, security roles, report distribution definitions, and other common objects found in the DocuVault.

Processing Reports

You use RDM structures to create your report distribution environment. This topic describes the fundamental terms and concepts related to RDM structures. A thorough understanding of these structures is required before you can implement RDM successfully.

This table briefly describes each structure:

Structure	Brief Description
RDM processor	Logical output device that passes jobs to RDM.
Report group	Group that contains related report and subreport definitions.
Report definition	Definition that contains related subreport definitions.
Subreport definition	Definition that controls subreport creation and delivery.
Bundle	Group of files which includes pages from multiple report files that are to be released to the same defined destination.

This figure illustrates how a job flows through the RDM application. Each number in the figure corresponds to a discussion in this topic.

RDM structures allow you to create an automated report distribution environment. All RDM structures are stored in the Cypress DocuVault.

1 Passing Jobs to RDM

An RDM Processor is a Cypress-controlled logical device that accepts report files from users and delivers them to RDM for processing. An RDM processor cannot have any other device subordinate to it. You create RDM Processors in the Administration Tools module and users can access them in the same way they access printers and hold queues. Any job that a user submits to an RDM Processor is processed by RDM, which begins the process by identifying its associated report group. For more information, see Creating and Configuring RDM Processors .

An RDM Processor name has this structure:

where:

<group name> is the name of the associated report group

<literal> is any alphanumeric string.

Parallel Processing

Cypress promotes maximum device throughput for fast and reliable content delivery by processing multiple jobs in parallel. While parallel processing provides significant performance benefits, jobs are not necessarily queued in the order they were received by Cypress: some jobs will complete processing and be queued faster than others. Most customers prefer parallel processing because of its performance benefits.

An exact match must exist between the RDM Processor <group name> and the report group name to enable parallel processing.

If you need to ensure that jobs are queued in the order in which they were received by Cypress, see the ASG-Cypress Document Capture Administrator’s topic for information on the DDI queue class attribute (QC). This attribute ensures that documents are queued to devices based on the order they are received, regardless of when a document completes processing. This feature provides a predictable job order for both printed output and the job queue within the Enterprise Output Manager module.

2 Selecting Report Groups

The report group is the top-level structure within RDM. The purpose of the report group is to categorize report definitions by related applications. For example, you could create report groups named Sales Reports, Admin Reports, or Shipping Reports, each of which contain report definitions for applications pertaining to sales, administration, and shipping. For more information, see Creating Report Group Definitions.

3 Applying Report Definitions

A report definition is the second level structure within RDM. The purpose of a report definition is to organize subreport definitions that are to be applied to the report file being processed by RDM. Typically, users create a report definition named for every unique report application to be processed. For example, within the Sales Reports report group, you could create report definitions for Performance, Orders, Quotes, and Commissions. For more information, see Creating a Report Definition.

Default Report Definition

A default report definition is a special report definition that catches report files that fail to be processed by RDM. ASG recommends that you create a default report definition for every report group in your RDM environment. For more information, see Creating a Default Report Definition.

4 Creating and Delivering Subreport Definitions

A subreport definition is the third level structure within RDM. Subreport definitions are contained within report definitions and are the key structures used to control subreport creation and delivery. Subreport definitions provide a number of configuration options for creating and delivering reports.

Subreport definitions provide a number of configuration options for creating and delivering reports. Many of these options require the use of RDM criteria to determine how the control is to be applied to the report file.

With the exception of the identify criteria, all criteria are entered within a subreport definition. For more information, see Defining Subreports and Sending a Subreport to a Specific Recipient.

5 Distributing and Customizing Subreports

Cypress can distribute subreports to individuals and devices. You can explicitly specify by name the individual recipient or output device that is to receive the subreport. In addition, Cypress provides these automated delivery options: Auto Recipient, Auto Device, and Multi Auto Device. For more information, see Distributing Subreports to Devices and Distributing Subreports to Recipients.

The Cypress bundling and data mining capabilities are extensions of the distribution functionality. These capabilities enable you to customize subreports and specify how you want them to be delivered. For more information see Using the Bundling Feature and Installing and Using the Data Mining Module.

Distributing Reports

This topic discusses characteristics of application report files, the report files submitted to RDM for report distribution. Consider this information when planning your report distribution strategy. RDM controls subreport creation and delivery based on information within the application report file (see Creating Subreports and Distributing Subreports to Recipients). It is critical that you understand the structure and content of the report file in order to develop a successful report distribution strategy.

Typically, a report file is a large file already formatted into individual pages. RDM processes the file to produce individual, customized subreports and deliver each subreport to the appropriate destination.

RDM creates and delivers subreports based on data within the report file and its associated job ticket. Using RDM criteria, you define the actions to be taken when RDM encounters specific data or events within a report file.

You should always use end-user requirements to determine the specific report file data or characteristics that can be used to develop a report distribution strategy. For example:

•

What do your users want in terms of subreports?

•

Do they want all information related to their department or only summary pages?

•

Do they want only those pages that contain their name in the title?

•

Do they want to receive reports at their office printer, or electronically in their Inbox Viewer or Web browser?

Once you have gathered the user requirements, review specific report file data and characteristics to determine which ones would be most effective in controlling subreport creation and delivery.

ASG recommends that you ask yourself the questions listed below when developing your report distribution strategy. Although this is a very short list, you will find these questions to be sufficient for many of your report distribution applications. Ask yourself these questions:

Do the individual reports within the file all have identical page counts or do they have different page counts?

If all reports have identical page counts, you can create new subreports every n pages, where n is the page count of each report. This would be the ideal case as it requires very little effort to implement. If the reports are of varying page counts, you will need to create subreports based on specific data within the report.

Is each department’s data grouped together?

If department data is grouped together, you might be able to create subreports when the department number changes. If each department’s data is scattered throughout the file, you will need a more complex strategy to add individual pages to each subreport based on data unique to each department.

Is the report file composed of only sales performance reports or are other types of reports included?

Many applications are programmed to generate more than one type of report. For example, an application might write both sales performance and sales commissions reports in a single file. If you are submitting a file to RDM that contains multiple report types, you can specify only the portion of the file that RDM is to process.

What information appears at consistent locations from page to page, yet changes periodically throughout the file?

If you are creating subreports based on the occurrence of specific data, you need to define regions in which key data appears consistently throughout the file.

Does the report file contain information that can be used to control processing, but is not visible on a page?

There are two key sources of information associated with a job, but not printed on a page:

–

Job ticket name. Associated with a report file, the job ticket name is often a rich source of data. Depending on the method used to submit the job to Cypress (e.g., LPD In, FT In, or DDI), you might have available the host name, user name, job name, file name, title, description, and other pieces of information. Job ticket information is typically used to control report and subreport definition selection, but you also can use it for indexing, addressing, etc. You use the Variable tab of a subreport definition to generate meaningful job creator and job ticket names (see Naming a Job Ticket Dynamically).

–

Variable (var) InLine command text. You can use this command to add (but not print) information to a page to control RDM processing. For example, you might want to embed text that is extracted for indexing or to control device selection.

Does the report file use banner pages or blank pages to separate reports?

Knowing which type of page is used to separate individual reports within a report file is very important. For example, you might decide either to break reports upon the occurrence of a blank page or extract information off the banner page to control device or recipient selection. Even though banner pages and blank pages can be used to control processing, you will most likely want to discard them from the resulting subreport. If archiving, you will not want to waste space on these pages. If banner sheets are required, you might prefer to set the banner option within RDM so that banners are generated with each subreport, but not archived.

What indexing terms appear consistently across multiple report applications?

When indexing, use search keys that apply to a wide range of report applications whenever possible. For example, avoid the mistake of creating two different index keys for the same information (e.g., date and today’s date). Promoting common search keys improves the results obtained by your end users.

Are new users or reports routinely added to a report file?

When devising your approach, ASG encourages you to consider how the report file might change over time. If the file might change over time, use automated functions that control processing based on region text and variable data. Unless there is a major change to the structure of a report file, it is quite likely that minor report file modifications will not affect your RDM definitions.

Refreshing the RDM Application

If you are working in RDM while another user makes changes to it, you will not see that user’s changes automatically unless you exit the application and restart. If you are unaware of another user’s modifications, you can accidentally overwrite them. To avoid causing conflicts with another user’s changes, refresh RDM’s DocuVault data periodically if you keep the application open for a significant length of time.

RDM’s main tree view, located in the upper left frame of the application window, contains the names of all defined report groups, reports, and subreports.

To refresh RDM’s main tree view

Select View } Refresh.

Right-click the name of a report group, report, or subreport in the tree view, and select Refresh from the context menu.

Press the F5 key.

RDM also includes three secondary tree views (i.e., Device, Recipient, and Region) that are accessible by a tabbed dialog in the lower left frame of the application window.

To refresh RDM’s device, region, or recipient tree view

Right-click the name of a device, region, or recipient, then select Refresh from the context menu.

Using RDM - Sales Performance Report Example

This topic introduces a practical example of how you can use RDM. It uses a monthly Sales Performance report application that is routinely distributed to sales managers, the Vice President of Sales, and the President of CompanyABC. The Sales Performance report example is referenced in other sections of this topic to illustrate implementation strategies and how to create regions.

What Each User Has Now

Each sales manager at CompanyABC receives a printed version of the entire Sales Performance report, which is much more information than they need.

The Vice President and President receive a printed report containing only the summary pages (i.e., the last page of each department’s data), but it is hand collated and often in error.

Also, because only source application data files are backed up, it is virtually impossible (or highly inconvenient and costly) to search for or reprint previously generated reports.

What Each User Wants

Each sales manager wants only the information pertinent to their department, and the Vice President and President want an accurate compilation of the summary pages from each department.

Also, all users want the ability to search, retrieve, and print any previously generated report.

Where Users Want Their Reports

As critical business decisions are made based on this information, each user would like the information delivered to a personally controlled destination as soon as it is available.

Using RDM, you can easily and automatically create subreports, customize subreport content, index and archive the report file and/or subreport, and deliver subreports to each of your users’ point of need, whether it is a printer, e-mail address, fax, Inbox, or other destination. Documents delivered to Inboxes can be viewed within the Inbox Viewer (either within the Cypress client user interface or a Web browser using Cypress.Web).