This chapter describes the architecture and deployment models of IBM Production Imaging Edition with an emphasis on IBM Datacap Taskmaster Capture (Taskmaster).

This chapter includes the following sections:

The Production Imaging Edition offering consists of Taskmaster, FileNet Content Manager (including the business process management (BPM) tools), FileNet Workplace XT, and Daeja ViewONE Pro. Figure 2-1 illustrates these components and their interactions at a high level. From top to bottom, you see the client layer, the application logic and presentation layer, and the data layer. The Taskmaster components are highlighted in green, and the components delivered with the FileNet Content Manager platform are highlighted in yellow.

For details about the main components, see 2.2, “Components of the Taskmaster system” on page 37, and 2.3, “Components of FileNet Content Manager” on page 41. For an overall view of the architecture, see 2.4, “Overall system architecture” on page 45.

The Taskmaster system includes the following components:

Figure 2-2 shows a detailed view of Taskmaster system architecture.

This section highlights each component in the Taskmaster system.

The Taskmaster Server is the heart of the Taskmaster system. It manages and serves batches to workstations and users. It also orchestrates the tasks according to the workflow of the Taskmaster application. It provides user authentication and access control, assigns batch IDs, controls batch queuing, and controls access to the Taskmaster databases.

All communications between the Taskmaster Server and its clients, or the other core Taskmaster Server components, use the Datacap Taskmaster socket protocol. For communicating with the databases, it uses Microsoft Object Linking and Embedding for Database (OLE DB). It also uses the Common Internet File System (CIFS) interface to mount the file share that is required to access batches. Taskmaster Server also uses Active Directory Service Interfaces (ADSI) or LDAP to communicate with the Directory Service for user authentication.

For its operation, a Taskmaster application relies on the following relational databases that are hosted in a production system in Microsoft SQL Server or Oracle:

Each application has its own set of self-contained databases. Also, in many cases, Taskmaster applications need access to other databases to perform lookups or export data to line of business (LOB) systems and databases.

In Taskmaster sample and add-on applications, Microsoft Access database is also used for portability reasons but must not be used in production.

A file server hosts image files, extracted data and control files, and files that are required for running various applications such as the fingerprint files and document hierarchy definition files. The file server must be shared across all the components that need to process the batches.

The Taskmaster thick client is used to launch user-attended tasks, user and functional security administration, and application configuration. In addition to communicating with the Taskmaster Server, the client requires access to the file server for processing batches (such as viewing a page). It also needs direct access to the fingerprint database and possibly to the lookup databases.

Datacap Studio is used to configure the Taskmaster applications, by defining and assembling the document hierarchies, recognition zones and fields, rules, and actions. It requires access to the file server and the Taskmaster databases.

Taskmaster Web interfaces with the Taskmaster Server to serve web pages and documents to web users and to upload documents that are scanned or imported remotely. It is configured as a virtual directory (or site) in Internet Information Services (IIS) for Windows Server. It handles all communications with the back-end services through the Taskmaster Server.

The Taskmaster Web client runs inside an Internet browser. The ActiveX components are required for scanning and uploading scanned pages to the server and for data entry or verification.

The Rulerunner service runs all tasks that do not require operator intervention, such as image cleaning, conversion, recognition, classification, and export to FileNet Content Manager and databases. It interfaces with FileNet Content Engine through the Web Services application programming interface (API).

RV2 is a web application that is used to display Taskmaster reports on system activities such as batch status, station activity, or problem batches.

NENU is used to automate system health and housekeeping tasks. Such tasks include batch monitoring, status notification, and automatic deletion of completed batches. Tasks are scheduled by using the Microsoft Windows Scheduler.

Typically, connection to a business application or database is through Open Database Connectivity (ODBC). For example, a customer, vendor, or purchase information can be queried against a database and used for image process verification purposes. In addition, information that is extracted from an image can be exported to business applications and databases.

An LDAP or Active Directory service is also often part the configuration for Taskmaster users to authenticate.

FileNet Content Manager bundled with Production Imaging Edition consists of the following components:

Figure 2-3 shows a detailed view of the FileNet Content Manager architecture.

This section highlights each component of FileNet Content Manager.

The Content Engine runs in a Java 2 Platform, Enterprise Edition (J2EE), application server. It interfaces with the object stores in Microsoft SQL Server, Oracle, or IBM DB2® to store the document metadata. It also interfaces with File Storage Areas or Fixed Storage Areas to store document content files. In addition, it interfaces with the LDAP server for the administration of users.

The FileNet Enterprise Manager is used for the administration and configuration of FileNet Content Manager. It runs as a thick client application that connects to the Content Engine by using its COM API.

The Process Engine runs the workflows that route image documents that are stored in the Content Engine to users. It typically runs on its own machine and connects to a Microsoft SQL Server, Oracle, or DB2 database to store runtime workflow data and queue states.

The Case Analyzer interfaces with the Process Engine to accumulate statistical information about workflows in an Online Analytical Processing (OLAP) cube in Microsoft SQL Server.

The Process Simulator interfaces with the Process Analyzer database to use historical data. Alternatively, it interfaces with the workflow definitions in the Content Engine to run simulations.

The BPM Tools consist of the Process Designer, Process Tracker, Process Administrator, and the Simulation Console and Designer. They are all Java-based applications that run on the Application Engine of FileNet Content Manager as a thin client.

Daeja ViewONE Pro is used by FileNet Content Manager users who run FileNet Workplace XT in Microsoft Internet Explorer to display, annotate, and redact documents. Daeja ViewONE Pro also offers additional servlets in addition to the standard version for performing redaction and streaming. These additional servlets require extra licensing.

Figure 2-4 shows a diagram of the Daeja ViewONE redaction and streaming architecture.

Figure 2-5 shows the overall system architecture of Production Imaging Edition.

For more information about FileNet Content Manager, FileNet P8 Platform in general, or FileNet Business Process Manager (BPM), see the following IBM Redbooks publications:

Production Imaging Edition combines the deployment capabilities of FileNet Content Manager and Taskmaster to provide flexible deployment models. These models include centralized deployment, distributed deployment, and web deployment.

Centralized deployment is where all the production imaging operations, including capture and content management, are done in one location. This type of deployment is used typically when operations need to be concentrated in one place, such as in a traditional mailroom scenario. This approach is best suited when incoming image volumes are high and when economies of scale can be derived from pooling resources and specializing operators to specific tasks, similar to an assembly line.

For example, in a mailroom, high-end production scanners can be used to handle the bulk of the scanning volumes of an organization. Paper documents are collected and shipped to the central location where they are scanned, processed, and exported to FileNet Content Manager. After the documents are ingested in FileNet Content Manager, users get their work items and documents over the wide area network (WAN) or over the local area network (LAN) if they are at the central site.

Figure 2-6 shows an example of a centralized deployment.

A distributed deployment configuration is ideal for organizations with geographically dispersed user populations and resources and where key system resources can be located closest to users. A distributed deployment can be thought of as a variant of the central deployment model. In a distributed deployment, a large population of users and sizable capture operations justify installing system resources in regional offices.

For example, in a regional office, you might want to install an Application Engine and a Content Engine with content caching, an instance of Taskmaster, and a departmental scanner.

Figure 2-7 shows an example of distributed deployment.

After the documents are ingested into FileNet Content Manager, users in the regional office can connect to the local Application Engine. In turn, the Application Engine transparently communicates with the remote Process Engine (at the central site) to get their work items. With the local Content Engine cache, the users can get the images that have been scanned locally and released by Taskmaster to the local Content Engine instance. The images stay in cache for local consumption while they are written to the file storage areas at the central site. This setup provides the best performance for local users because images do not need to be transferred over the WAN.

Also, because the object stores that hold the document metadata remain at the central site, enable “request forwarding” on the central Content Engine. Enabling request forwarding can improve performance by forwarding queries to the central Content Engine for execution against the object stores and by sending back only the result sets.

For more information about the deployment options of the FileNet P8 platform, see IBM FileNet P8 Platform and Architecture, SG24-7667.

Flexibility can be added to the previous two deployment scenarios with Taskmaster Web. Taskmaster Web provides close to the same functionality that is available in its thick client, including scanning, importing, indexing, and verifying documents, in addition to administering the Taskmaster system. Essentially, all user-attended functions of the typical Taskmaster process can be performed through a browser.

For example, by adding Taskmaster Web to the deployment scenarios described earlier, you can perform the following tasks:

This chapter described the system architecture of Production Imaging Edition and its components. It also highlighted the various deployment options.

Chapter 3, “Production imaging functionality” on page 51, focuses on the capabilities, user interfaces, and internal processes of Taskmaster.