Implementing the capture solution
This chapter explains how to implement the capture solution by using the solution example as outlined in Chapter 4, “Solution example” on page 123. To configure the system, you use the IBM Datacap Taskmaster Capture (Taskmaster) development tool Datacap Studio. You see how to design a capture workflow and create an application. The chapter also explains how to create actions, rules, and rule sets, how to configure document hierarchy and task profiles, and how to set up the verification panel.
This chapter includes the following sections:
Before you read this chapter, you must have already installed the Taskmaster software. If you have not installed it, follow the installation information in Chapter 13, “Installation, migration, and application reuse” on page 453.
6.1 Configuring the Datacap application
This section guides you through the creation of a Taskmaster application by using the solution example of the insurance company introduced in Chapter 4, “Solution example” on page 123. It shows you how to create the claim form-related portion of the application. By following the solution example, you can see many of the common functions that are used by the Datacap applications.
Creating the claim form portion of the application entails the following tasks:
1. Installing and configuring the scanner on the Datacap client.
2. Creating the required rule sets.
3. Adding the rule sets to the task profiles.
4. Adding the rule sets to the document hierarchy.
5. Creating the Verify user interface in Batch Pilot.
6.1.1 Creating a blank application
To create an application from scratch using Datacap Studio and Batch Pilot, complete these steps:
1. Launch Datacap Studio by selecting Start → Programs → Datacap → Datacap Studio.
2. Click Close when you are prompted for the application you want to open.
Datacap Studio opens with a blank view as shown in Figure 6-1.
Figure 6-1 Blank view of Datacap Studio
a. In the Service box, configure the service. We select Work offline.
b. In the Rulerunner general settings box, Specify the path to the global rule sets and actions location. This path usually points to a directory that is updated during product update on the project server. Do not store customized rule sets and actions here. We enter the c:datacapRRS path. Then we select Save older version of rules in archive(s).
Figure 6-2 RRS settings
4. Click the DCapp tab, and enter the path that holds the main application management files for the client (Figure 6-3). This path usually points to the file in the local Datacap directory. To improve administration, alternatively you can place it on a network drive. For this case study, we use the default value. We also select Save older versions of application in archive(s).
Figure 6-3 DCapp setting
5. Click the DStudio tab (Figure 6-4). Optionally, select the Transparency option, which defines the transparency of the pop-up windows within Datacap Studio. For this use case, we do not select the check box, which is the default.
Figure 6-4 DStudio transparency setting
6. In the Settings window, click OK.
7. Click the Application Wizard icon next to “Settings” at the top of the Datacap Studio window (Figure 6-5) to open the application wizard to start creating an application.
.
Figure 6-5 Clicking the Application Wizard icon
8. Select Create a new RRS application.
9. In the Datacap application wizard–Application Wizard window (Figure 6-6), complete these steps:
c. Enter the name of the new application. Users must enter this name in the client when they log on to an application.
d. Enter the Datacap Folder, which points to the executables of the clients. You can set an alternative path on your local machine if you do not follow the standard installation.
e. For the Destination field, which points to the project directory, enter a network path to make the project available to others. You can use Universal Naming Convention (UNC) notation for the server.
f. Optional: Select the option to create an application shortcut for either the current user only or for all users.
g. Click Next.
Figure 6-6 Specifying the application name and paths
10. In the Document Hierarchy, Fingerprints, and Add sample images windows, click Next to accept the default settings. The options are handled later.
11. Click Finish to start creating of the new application.
12. When the wizard is finished, review the summary information of the new application (Figure 6-7), and then click Close to close the wizard.
Figure 6-7 Application wizard, summary
The wizard creates the directories with the required files in it. The wizard also registers the new application in the Taskmaster environment. On a 32-bit Windows system, the wizard creates the shortcuts in the Windows Start menu.
Changing the Taskmaster Server location
Taskmaster Application Manager manages the configuration of applications. For our use case, we must correct the location of the Taskmaster Server.
To change the location of the Taskmaster Server, complete these steps:
1. Select Start → Programs → Datacap → Taskmaster Client → Taskmaster Application Manager.
2. In the left side of the Taskmaster Application Manager window (Figure 6-8), select the new application Auto_Claim.
Figure 6-8 Taskmaster Application Manager window
3. Click the Taskmaster tab, and change the server name and the address entry appropriately. You can enter several server addresses. If the first server is unreachable, the Taskmaster clients automatically try the next server.
4. Go back to the Datacap Studio application. Click the Connection wizard icon (the second button from the right side) in the upper right corner of the window (Figure 6-9) to start the connection wizard and connect to the new application.
Figure 6-9 Connection wizard
5. Select the new application Auto_Claim and click Next.
6. In the Taskmaster Login window (Figure 6-10), enter the user ID and the password for station 1. Then click Finish.
Figure 6-10 Logging in to the Connection wizard
6.1.2 Setting up the document, pages, and fields
After creating a new blank application, you must set up the document, add or update the associated pages to the document, and add the associated fields for each page.
For our use case, we name our document Auto_Claim. The document contains two pages, Claim_Pg and Claim_Attachment_Pg. The first page, Claim_Pg, also contains 25 fields.
To set up the document, pages, and fields, complete these steps:
1. Start the editing mode:
a. At the top of the window, click the Rulemanager tab.
b. On the Document hierarchy tab, click the Lock DCO for Editing icon. For information about the structure of the Document Hierarchy (DCO), see 5.2.1, “Document hierarchy” on page 142. Now you are ready to add or update content to the project.
2. Rename the document (Figure 6-11):
a. Click the Document DCO to select it.
b. After a pause, click the Document DCO a second time, and rename it to Claim_Doc.
Figure 6-11 Creating a DCO and renaming it
3. Repeat step 2 for the page, and then rename it to Claim_Pg.
4. Add another page to that document:
a. Go to the document, right-click it, and select Add Page.
b. Rename the second page as needed. For our use case, we name it Claim_Attachment_Pg as supplementary pages.
5. Add fields to your page (Figure 6-12):
a. Right-click the page (Claim_Pg in this example), and select Add multiple → Fields.
b. Enter the number of fields you want to add. In this example, we enter 25.
Figure 6-12 Adding multiple fields in Datacap Studio
6. Save and unlock the Document Hierarchy.
6.1.3 Setting up the physical scan device
|
Prerequisite: The scanner must be installed and configured with the Image and Scanner Interface Specification (ISIS) driver at the Windows level. For more information, see the documentation for the scanner.
|
To set up the IScan.bpp file, complete these steps:
1. In the DCO_ directory, look for the iScan.bpp file. If you cannot find this file, copy the kScan.bpp file as the iScan.bpp file.
2. Launch Batch Pilot by selecting Start → Programs → Datacap → Batch Pilot and click the Batch Pilot executable.
3. In Batch Pilot, select File → Open Project.
4. Navigate to your DCO directory by using the fully qualified path, and select the iScan.bpp file.
Figure 6-13 Batch Pilot, warning
6. In the Batch View window at the bottom of the Batch Pilot application, right-click the Form Path column of the SetupForm line and select Pick form (Figure 6-14).
Figure 6-14 Selecting Pick form in Batch Pilot
7. Open the C:DatacapBPilotISScanisscan.dcf file, which opens the corresponding form in the upper window.
8. Repeat steps 6 and 7 for the Auto_Claim entry the Form Path.
9. Select File → Save Project to save this project.
10. Select File → Exit to exit Batch Pilot.
11. If you are prompted to save the project, click Yes.
6.1.4 Creating a module in Taskmaster
|
Prerequisite: The scanner must be installed and configured with the ISIS driver at the Windows level. For more information, see the documentation for the scanner.
|
To create a module in Taskmaster, complete these steps:
1. Open the Taskmaster Client.
2. Open the Auto_Claim application.
3. Click the gold key icon in the middle of the upper icon bar (Figure 6-15) to open the Taskmaster Administrator.
Figure 6-15 Starting Taskmaster Administrator in the Taskmaster Thick Client
4. Click the Modules tab, and then click Add.
5. In the right frame, enter a value for the module ID and its description. Change the type to Batch creation, and change the program name to Batch Pilot. The parameters point to the .bpp file that you just created.
6.1.5 Creating a job within the Taskmaster Client
We want to create a job. The New Application wizard creates three basic jobs (Main, Web Main, and Fixup). Because our use case requires multiple jobs, we use these jobs as patterns to create our new jobs.
To create a job within the Taskmaster Client, complete these steps:
1. Click the Workflow tab.
2. In the left pane, select Main Job, and then click Copy.
3. In the Copy Jobs dialog box (Figure 6-16), enter a name for the new job. For our use case, we enter Claim Thick. Click OK.
Figure 6-16 Copy Jobs dialog box
A copy of the source job is created, except for the name that you assigned it.
4. Remove any unnecessary tasks from the job.
The New Application wizard places the VScan task by default. We need to remove it from our job:
a. Click the new job, Claim Thick, to open its subcategories.
b. Right-click the VScan task, and then select Remove to remove the VScan task.
5. Add necessary tasks for the existing job.
For our use case, we need to add a task that control the thick client physical scanner:
Figure 6-17 Adding a task
b. Enter a name for the new task. We enter iScan.
c. Enter a description for the new task.
6. Click the Module frame, and then select the iScan module from the list. By using the Ctrl and Arrow up keys, move this task to the top of the job. If you do not move up the task, the system displays an error message.
7. Click Apply.
|
Startbatch module: If a job contains the Startbatch module, the task that calls that module must be the first task in the job. You are limited to one Startbatch task for each job.
|
6.1.6 Setting up the iScan task
To set up the iScan task, complete these steps:
1. Click the Setup button in the right frame. The first time you click it, the system prompts an error message indicating an invalid procedure. Ignore this error message, and click OK and continue.
|
ISIS driver: The iScan task interacts with the ISIS driver. Actual controls might vary depending on the type of scanner you use.
|
2. Enter the path to the settings.ini file. This file stores the scanner settings for your particular scanner. Store this file in a location that is local to the scanner so that you can use the same iScan task for different ISIS scanners in your environment. This setup must be executed locally at every scanner in your environment.
3. Enter the path to the ImprinterScript file, and include the file name in the path. This file is used to interface with the imprint feature (if available) of the scanners so that you can control what is written on the paper by the scanner imprinter during the scan process.
For our use-case scenario, the scanner does not support the use of an endorser. Therefore, we leave this line blank.
4. Configure the StartBatch panel. In this optional panel, you enter additional information at scan time. With advanced development, you can enter a receive date, for example. The information that you enter in the StarBatch panel is available to the entire batch. For our use case, we do not use a StartBatch panel. Therefore, we delete the text from the StarBatch File: (with path) field (highlighted in Figure 6-18).
Figure 6-18 shows the Scan task setup that we entered for our scenario.
Figure 6-18 Setting up the Scan task
5. Select the appropriate scanner for your system:
a. Click Select Scanner. The iScan setup then scans your computer for the matching combination of the ISISI driver you have installed and the physical scanner that is connected (to your machine).
b. Select your specific scanner. For our case, we select Epson S80.
c. Enter additional information, depending on the scanner and the matching ISIS driver.
d. When you are finished setting up the scanner values, click Done to save all of the scanner settings that you selected in the .ini file that you specified earlier.
Figure 6-19 shows the result of the scanner setup for our use case. The settings are specific to the scanner that you select and the matching ISIS driver.
Figure 6-19 Configuring the scanner
For more information, see the document input section in Taskmaster Application Development Guide, SC19-3251.
Setting up the Scan icon
After you create the scan module, connect it to a task, and then set up the scanner behavior:
1. In the Taskmaster Administrator window, click the Shortcuts tab.
2. Click Add, which places the cursor to the input box for the Shortcut ID.
3. Enter in the name that you want for this shortcut. For our use case, we called this IScan. Enter a description for this short cut, and then
4. Click Apply to add the new shortcut you created to the Shortcuts list.
5. Define the settings for this shortcut. Select the shortcut in the left frame. Then in the right frame, select the Batch Selection Mode and the Permissions.
With the Batch Selection mode, you define, for the task, which batch to do next:
– The Auto mode automatically selects the next available batch. This batch is determined by using First In First Out (FIFO) technology. For a batch creation task, it automatically creates a batch.
– The Manual mode shows a list of all available batches, and the user selects which batch they want to run.
– The Manual for Hold mode only shows a list of all the batches that the current user has on hold. If that user has no batches on hold, the system reverts to the Auto mode.
When a user initially starts, the system prompts the user with the three choices. The user selects a choice. As long as the current session is active, that choice is always used.
We normally run the Scan task in Auto mode.
6.1.7 Setting up the PageID task
The PageID task uses Batch Pilot with a specific project file (a .bpp file). This file contains information such as the path to the DCO file, the path to the batches directory, a connection to a specific Task Profile entry, and several other values. The Task Profile connects the PageID task to a collection of specific rule sets to run, which is developed and maintained by Datacap Studio.
Setting up the PageID task profile
To set up the PageID task profile, complete these steps:
1. Open Datacap Studio.
2. Select the project.
3. Navigate to and click the Task Profile tab.
4. Move the PageID task in front of the ImageFix task.
On the Task Profile tab, tasks are listed in the order in which they run. The Application Wizard created ImageFix followed by the PageID tasks. Because we use barcodes for Page ID, we want to perform the PageID task before we do any image fix on the page. Therefore, we need to move the PageID task in front of the ImageFix task.
To move the task:
a. Lock the task profile for editing.
On the Task tab, click the blue padlock icon in the upper left corner to lock the Task Profiles for editing. The blue icon then changes to a golden locked padlock.
b. Expand the task profile.
c. Select the task that you want to reorder, and then rearrange the task.
Click the green arrow keys to move the rule set up or down to rearrange. For the use case, we move PageID before ImageFix (Figure 6-20).
Figure 6-20 Rearranging rule sets
d. Unlock the task profile for editing.
Click the gold padlock icon to unlock the task profiles. The task profile is now ready for operation.
Setting up the PageID rule set
The PageID rule set is used to automatically identify the pages that come in from the scanner. In our use case, for the claim application, we expect to receive two types of pages, Claim_Pg and Claim_Attachment_Pg. The claim page is identified by a barcode with a value of CLAIM-29A. If a page does not have this barcode value, it is defaulted to a page type of Claim_Attachment_Pg.
To set the rule set, we delete the existing function attached to the PageID rule set. The existing function is added when we create a new application. The PageID rule is attached to the page type “Other,” which is the default page type produced by the Scan task.
To make changes to the existing rule set, complete these steps:
1. Remove a function from an existing rule:
a. Select the rule set.
b. Click the Lock/Unlock Ruleset button.
|
Locked and unlocked items: DCOs and task profiles are locked and unlocked in this one step. Rule sets are locked and unlocked individually.
|
Figure 6-21 Remove function
2. Add a function to an existing rule. Right-click the rule set to which you want to add the function, and then select Add Function (Figure 6-22).
Figure 6-22 Adding a function
This step adds a function under the rule. The default name of the new function is “Function,” with sequential numbering such as “Function1.”
Although not necessary, consider renaming this function to a more descriptive name that indicates what it does. In our use case, we rename Function1 to Claim Id by Bar Code.
3. Repeat step 2 for each the following functions:
– Page after Claim Page
– Page after Claim Attachment Page
When you are done, you have three functions under the PageID rule:
– Claim Id by Bar code
– Page after Claim Page
– Page after Claim Attachment Page
4. Add an action to a function:
a. Click the function to which you want to add an action.
b. From the Actions Library, select the action that you want to add. For our use case, we select MatchBarcodeBP.
c. Click the Add to Function button.
5. Set the parameters for the action:
a. Under Function, click the MatchBarcodeBP action.
b. On the Properties tab, click Parameter, and then enter the value CLAIM-29A.
c. Press Enter to apply the parameter.
This action returns TRUE if the specified barcode value is found.
6. Add the SetDCOType("Claim_Pg") and Get2DCode() actions (Figure 6-23). In the lower center frame, you can choose to enter comments for the actions, functions, rules, and rule sets. You can add the comments to make your rule set more clear to other users.
Figure 6-23 Setting PageID based on a barcode with comments
|
Case sensitivity: When using the SetDCOType() action, remember that you are calling a case-sensitive object. Ensure that you use proper capitalization.
|
Setting up the ImageFix rule set
The ImageFix rule set is used to clean up the image. The purpose of cleaning the image is to get the best recognition results possible from the document.
In this use case, we switched the order of PageID and ImageFix in the task profile because, when the ImageFix rule set runs, depending on the settings, it can damage a barcode. The ImageFix rule set normally contains two rules, one attached to the batch level and one attached to the Page object. For our use case, we use these two existing rules and add an additional action to the Enhance Image rule. We also change the object to which the Enhance Image rule is attached.
ImageFix load settings
The ImageFix rule set is attached to the batch level. It loads preconcerted settings on how you want image processing to behave. It uses the LoadSettings() action with the “@APPPATH(imagefix)” parameter. This parameter indicates to the action to use the application path, which is the path where your DCO directory resides. The ImageFix rule set directs it to use the imagefix.ini file in that application path.
Enhance Image rule set
The Enhance Image rule set, by default, is attached to the “Other” page object. We want to disconnect this rule set from the “Other” page object and attach it to the “Claim_Pg” page.
Figure 6-24 shows the setup.
Figure 6-24 Attaching a rule to a DCO
To remove a rule from an object, complete these steps:
1. On the Document hierarchy tab, click the padlock icon to lock the DCO for editing.
2. Expand the “Other” page object to expose “Open”/(global).
3. Right-click ImageFix: Enhance Image, and select Delete.
To add the rule to a new object, complete these steps:
1. Click the Claim_Doc to expose the Page Object “Claim_Pg.”
2. Click the rule you want to add.
3. Click the Add to DCO button.
4. Under Document Hierarchy, click Save.
5. Click the padlock icon to unlock the DCO for editing, allowing it to be used.
|
Testing: Now test your application through the PageID task.
|
Figure 6-25 shows the test result of the pageID.xml file.
Figure 6-25 Test result of the Page ID file
6.1.8 Setting up the Rulerunner task
The Rulerunner task is an unattended task that runs after the Page ID task and before the Verify task. The purpose of this task is to perform background processes. What happens here varies from project to project, although normally it includes basic elements. The Rulerunner task normally runs on a system in the network room. It does not have a user logged in. Although it runs on a desktop computer, running it on a server is preferred because of the heavy traffic that goes through it. In the Datacap portion, this system performs the most work.
For our use case, we use the rrsRuleRunner module (Figure 6-26).
Figure 6-26 Setup of the rrsRulerunner module
This module calls the Rulerunner task profile (Figure 6-27).
Figure 6-27 Setup of the Rulerunner job
For our use case, the Rulerunner task profile performs the following rule sets:
•CreateDoc rule set
•Recognize rule set
•FindFingerprint rule set
The CreateDocs rule set
The CreateDocs rule set has two rules associated with it: Create Docs and Create Fields.
The Create Docs rule (Figure 6-28) contains one function. This function contains the CreateDocuments() action. This action creates the document structure. The action does not reorder the pages, but rather creates a document based on the page types.
Figure 6-28 Create Docs rule of the CreateDocs rule set
The Create Fields rule contains one function. This function contains the CreateFields() action. This rule is attached to every page in the Document Hierarchy that has data fields attached to it. This action builds child fields on every page to which it is attached and that has fields defined on it. These fields all have a position value of “0,0,0,0” and contain no data.
|
Tip: This rule set normally does not require any additional work. You attach the Create Fields rule to each page that you expect to capture data field values.
|
The Recognize rule set
The Recognize rule set is used to perform a full page Optical Character Recognition (OCR). If no CCO is created yet, this rule set also creates the CCO file for the page. The CCO file is then used by other actions to locate data and find fingerprints. Because our use case has several pages, some of which we extract information from and fingerprint, we let this rule set create our CCO file.
To set up this rule set, make the following changes to the Recognize Page rule:
1. Click the Recognize rule set, and then click the padlock icon to lock it for editing (Figure 6-29). By locking the rule set, other users are prevented from changing it while you have it locked.
Figure 6-29 Locking a rule set and then adding a rule
2. Select a proper function:
a. Double-click the Recognize Page rule to open it.
b. Double-click the Recognition: Page Function 1 function to open it.
3. Remove unwanted actions:
a. To remove the ReadZones() action, right-click it and then select Remove.
b. Do the same for the RecognizePageFieldsOCR_S() action.
4. Adding new actions.
To add the RecognizePageOCR_S() action to the function:
a. Click the function we want to add it to.
b. Click the action we want to add.
c. Click Add to function.
5. Click Save to save the rule set.
6. Click the down arrow next to the padlock icon, and then select Publish Ruleset (Figure 6-30) to save the changes to the Recognize.rul file in the rules subdirectory of the DCO directory. The previous version gets added to the Recognize.rul.bak file.
Figure 6-30 Saving and publishing the rule set
7. Click the down arrow next to the padlock icon, and then select Unlock ruleset.
8. Add a rule to the pages that need a full page OCR (Figure 6-31).
We must attach the completed rule to the proper object in the Document Hierarchy:
a. On the Rulesets tab, click the rule that you want to add.
b. On the Document hierarchy tab, click the padlock icon to lock the Document Hierarchy.
c. Expand the Document Hierarchy to select the object to which you want to add the rule. For our use case, we select Claim_Pg.
d. Click Add to DCO.
Figure 6-31 Applying a rule to DCO
If you receive the “Already exist” error message, expand the page object to ensure that the entry to the object is the “Ruleset: Rule” that you are trying to add. If there is a different pairing, look at combining the two rules.
For our use case, we initially received this error message because we were trying to add the “Ruleset: Rule” combination of “Recognize: Recognize Page,” and it already existed for that object.
|
Rule set entries per object: No more than one entry from a rule set can be attached to any given object.
|
The FindFingerprint rule set
With the Find Fingerprint rule set, we can compare the current runtime image with a list of known fingerprints. When it matches an existing fingerprint, it returns the value of the Template ID for the fingerprint to which it matches best. If it fails to match with any known fingerprint, depending on how the action is set up, it creates a fingerprint or does nothing.
The FindFingerprint rule set needs two rules to properly function, one rule with setup information and one rule to perform fingerprint matching. We use the FindFingerprint rule set to match the current runtime image with the ones we know of to find the best match.
Because this rule set does not exist, we must add a rule set first. Complete these steps:
1. Add a rule set:
a. In Datacap Studio, on the Rulesets tab, right-click the Auto_Claim, and select Add New Ruleset. You add a rule set to the bottom of the list. By default, it is called “Ruleset1.” (If the name Ruleset1 exists, the next incremental number is used.)
b. Rename the rule set to Find Fingerprint:
i. Click Ruleset1 to select it. Pause and then click it again to invoke the rename option.
ii. Enter Find Fingerprint for the name.
iii. Click the Rule1 rule, and rename it to Batch Level Fingerprint Settings.
2. Add the SetFingerprintDir() action to the “Batch Level Fingerprint Settings” rule:
a. Click Function1.
b. On the Actions Library tab, expand the Autodoc library.
c. Select the SetFingerprintDir() action.
d. Click the Add to function button to add this action to the function.
e. Enter "@APPPATH(fingerprint)" as the input parameter value for the action.
This parameter tells the system to look in the project folder at the project app file, and then find the entry for fingerprint and insert that value into this parameter. In our use case, we look in the \morpheuscDatacapAuto_Claim directory. In this directory, the system looks for the Auto_Claim.app file (the <project name>.app). This file includes an entry for the value for fingerprint, which is “fingerprint.” This action inserts the path variable “\morpheuscDatacapAuto_Claim
fingerprint,” which indicates to the system that this directory is where the fingerprints are kept.
fingerprint,” which indicates to the system that this directory is where the fingerprints are kept.
3. Add the SetProblemValue() action to the rule:
a. On the Rulesets tab, click the function level of the Batch Level Fingerprint Settings rule.
b. Under Actions Library, expand the AutoDoc library, and then click the SetProblemValue() action.
c. Click Add to function.
d. Set the input parameter to .75.
The SetProblemValue() action establishes the minimum acceptable value of a good match when comparing fingerprints. The higher you set this value, the more stringent the matching process is. For our use case, we set it to .75, which is a good starting point. Based on testing, you can adjust this number.
4. Add the SetFingerprintSearchArea() action to the rule, setting the input parameter to 0.5.
The fingerprints we match have CCO files that cover the entire page, and our runtime CCO covers the entire page. With the SetFingerprintSearchArea() action, you can focus on a particular portion of the image for the matching process.
For this use case scenario, we set this value to .5. Figure 6-32 shows the setup so far.
Figure 6-32 Fingerprint rule set
5. Add the Page Fingerprint Matching rule to the rule set:
a. Right-click the Find Fingerprint rule set, and select Add Rule to create a rule called Rule1.
b. Rename Rule1 to Claim Page Fingerprint Matching.
c. Under the rule, click Function1.
d. Under the Actions Library, expand AutoDoc, and then click FindFingerprint.
e. Click Add to function.
The FindFingerprint() action is now added to the function. The FindFingerprint() action uses the values that we set at the batch level and compares those values with the current runtime CCO. It looks at all of the CCO files and then selects the one with which it matches best.
If the action fails to match with any existing fingerprint, the FindFingerprint() action has one input parameter associated with it that tells the system what to do. The input parameter can be set to “True” or “False.” If the parameter is set to “True,” when the system fails to find a match, the system reports the closest match and uses the current CCO to create a fingerprint. The new template ID is assigned to the current page.
If the parameter is set to “False” and the system fails to find a match, the system reports the closest match but does not assign a template ID to the current page.
For our use case, we set the FindFingerprint(“True”) action for initial Fingerprint creation.
|
Tip: When initially developing a project, you can set the parameter for the FindFingerprint() action to “True” so that the system can learn and create new fingerprints. Later, when you are done with the development and you are now dealing with the structured form, you can set the parameter to “False” for the FindFingerprint() action.
|
Adding rules to the proper objects
Now that the rules are fully developed, associate the rules to the proper object in the Document Hierarchy. Although a rule can be associated to any object, we want to ensure that they are connected properly. We have two rules to attach, one to the batch level and one to the page level.
To add the rules to the proper objects, follow these steps:
1. Add the “Batch Level Fingerprint Settings” rule to the Auto_Claim batch object:
a. Click the padlock icon for the Document Hierarchy to lock it for editing.
b. Click the Auto_Claim batch object.
c. Click the Batch Level Fingerprint Settings rule.
d. Click Add to DCO.
e. Click the Sync Views Left button.
You now see an entry under the batch object called Find Fingerprint: Batch Level Fingerprint Settings as shown in Figure 6-33. This rule runs once for each batch, and it loads the batch-level fingerprint settings into memory.
We can load the fingerprint settings at any level down, including the page level. However, we must load the setting at the batch level to ensure that it is done only once for each batch and it reduces the loading time.
Figure 6-33 Applying rules to the DCO
2. Add the Claim Page Fingerprint Matching rule to the Claim_Pg object. Repeat the same step for Batch Level Fingerprint Settings rule, but add the rule under the Claim_Pg object this time.
3. On the Document Hierarchy page, click the Save changes icon to save the Document Hierarchy.
The saved changes are reflected in the <project>.xml file. In our use case, this file is the Auto_Claim.xml file, which is in the DCO directory.
4. Click the Unlock DCO for Editing icon to unlock the Document Hierarchy.
Adding a rule set to the Task Profile for Rulerunner
After creating the Find Fingerprint rule set and setting up the associated rules, add this new rule set to the Task Profile for Rulerunner:
1. Click the Task Profile tab.
2. Unlock the task profile.
3. Click Rulerunner Task.
4. On the Rulesets tab, click the Find Fingerprint rule set.
5. Click the Add ruleset to profile button, which adds the Find Fingerprint rule set to the bottom of the list for that task profile.
6. Click the green up and down arrows to place the rules in the order in which you want to run them. For our use case, we move the Find Fingerprint rule set immediately after the Recognize rule set.
7. Click the Save icon to save the task profile.
Removing unwanted rule sets
From this same location, we can also remove any unwanted rule sets. In our use case, we are not using the Document Integrity rule set. Therefore, we can remove it.
To remove a rule set, complete these steps:
1. On the Task profile tab, select the Document Integrity rule set to remove it.
2. Click the Remove icon.
3. Click the Save icon to save the task profile.
4. Click the padlock icon to unlock the task profile. This action saves the changes to the Administrator database and releases it for use.
The Document Integrity rule set is removed from the execution sequence. However, it is still listed under the rule set, and its rules are still connected to the object in the Document Hierarchy. Because the rule set is never called in the Task Profile, it never runs.
Figure 6-34 shows how the Task Profile looks now.
Figure 6-34 Task profile setup after adding the Find Fingerprint rule set
At this point, test the system. We have already scanned test batches to ensure the scanner works. If we move the scanned pages through the PageID and Rulerunner tasks, we must create a fingerprint in Datacap studio when we finish.
When adding new fingerprints, close Datacap Studio so that you can see the changes.
|
Important: Before closing Datacap Studio, verify that all rule sets have been saved and published, which is evident by the blue globe icon. Make sure that the Document Hierarchy and the Task Profiles are all unlocked.
|
6.1.9 Testing the progress
To test the application so far, complete these steps:
1. Scan in a new batch, and then let it run through both the Page ID and Rulerunner tasks.
2. Reopen Datacap Studio, and then select the Auto_Claim project.
3. In Datacap Studio, click the Zones tab. Click the Fingerprints tab, click <New> to expand it (Figure 6-35). You now see an entry with [Claim_Pg].
This entry has a sequential number to the left of it that is assigned to each new fingerprint that the system creates. In our use case, the number is 558.
Figure 6-35 Adding a fingerprint
6.2 Zones and fingerprints
So far in our project creation, we set up rules to identify the pages and perform clean up on the images. We placed the pages into a document structure. We performed a full-page OCR. We ran the images through a fingerprint matching process and created a fingerprint.
Now we are ready to set the zones on the newly created fingerprint. Zones must be defined and located before validation on the content can be performed.
In Datacap Studio, on the Zones tab, click the newly created fingerprint, which is 558[Claim_Pg] in this example (Figure 6-36).
Figure 6-36 Newly created Claim_Pg fingerprint
In the right pane, you now see the image for the fingerprint that was just created. Looking at the image, you see that many of the vertical lines are gone. The reason why you no longer see these lines is because we arranged the PageID to come before the Image Enhancement rule set.
If you look in the batches directory, you see the TM000001.tif and TM000001.tio files. No .tio file exists for nonclaim sheet images because we only attached the Image Enhancement rule to the Claim_Pg page type. The .tio file is before the image enhancement version, complete with all lines and other image noise.
6.2.1 Setting up the zones
To set up zones, complete these steps:
1. On the Fingerprints tab, click the fingerprint for doing the setup.
2. On the Document hierarchy tab, lock the document hierarchy for editing.
Figure 6-37 Claim_Pg zones setup window
6.2.2 Setting up optical mark fields
An optical mark (Optical Mark Recognition (OMR)) field has two levels. The first level is the coordinates for the entire field and is attached to the parent field. The second level is the coordinates at each box.
For our case study, in the Claim form, the claimant selects the Injury check box, indicating whether an injury was involved in the accident. Then the claimant signs the form. We want to set, as OMR fields, the Yes and No check boxes of the Injury field and the signature.
To set up the OMR fields for the fields, complete these steps:
1. Select the Injury field.
2. On the Properties tab, right-click the lower Properties tab. Right-click Show tabs, and then select the tabs to display or hide (for the tabs that you are not using; Figure 6-38).
Figure 6-38 Selecting the OMR properties in Datacap Studio
|
Licensed options: Some choices on the Properties tab can be activated only through the purchase of additional licensing.
|
3. Set the OMR properties:
a. Click the OMR tab. The Properties view changes to reflect your choice.
b. Click the box next to the length, and then enter the number of check boxes that are available on the form. In the use case, because there are two boxes, we set the length to 2.
As soon as you set the length and tab out of the box, on the Document hierarchy tab for the Injury field, two new field boxes are displayed as the children fields to the field. These new fields are automatically named Injury_OMR1 and Injury_OMR2 (Figure 6-39). Do not rename these fields. The names are established by the system.
Figure 6-39 Assigning two OMR fields to the Injury field
4. Set the coordinates for the new OMR fields.
These coordinates are going to be associated with the view while in the Verify task. To set the coordinates, complete these steps:
a. On the Document hierarchy tab, click the Injury field.
b. Click the image on the right.
c. In the upper left corner of what you want to show, while holding the left mouse button, drag down and to the right to set the lower right coordinate. When you finish, you see a dashed red box around the yes and no check boxes for the Injury question (Figure 6-40).
Figure 6-40 Setting up the zone around the Yes and No check boxes for the Injury field
d. On the Document hierarchy tab, click the first of the child boxes, Injury_OMR1.
e. On the image, draw another box that encapsulates the first check box value (Figure 6-41).
Figure 6-41 Setting up the zone around the Yes check box for the Injury_OMR1 field
5. Repeat steps 1 on page 221–4 on page 222 for the InsuredSignature field. This time set the length to 1, because we are only looking to see if something is in the signature zone. Notice that, in this use case, in the first level box, we include the word signature, but in the second box, we exclude that word to avoid false hits. The word signature gives the verify operator a frame of reference for determining whether there is a signature there.
6.2.3 Setting up an ICR field
When you want Datacap to capture handwritten words or numbers, you set the fields as Intelligent Character Recognition (ICR) on the form. For the claim form, the claimant signs the form and writes the date when the claimant signs the form. The signature field is treated as OMR field. The date field, however, is processed as an ICR field.
To set up an ICR field for the SignedDate field, complete these steps:
1. On the Document hierarchy tab, click the SignedDate field.
2. On the image, draw a box from the upper left corner to the lower right corner, covering the entire area where the signed date will be written.
3. Click the ICR/C tab, and then set up the ICR/C Recognition Setup properties:
a. For the Recognition Type field, select ICR Field.
b. For the Remove Spaces field, select Yes.
Figure 6-42 shows the setup.
Figure 6-42 Setting up Recognition setup
4. On the ICR/C tab, set up the ICR/C Zonal and Full Page Recognition properties:
a. For the Character Set field, select 0-9.
b. For the Classifiers field, leave it blank.
c. For the Country field, set to the specific country you want to use. For our case, we selected USA.
d. For the Length field, enter the number of characters you expect to find in that zone. For our use case, we set this field to 4.
e. For the Pattern field, enter a regular expression for the value you expect to find in the field. For our case study, we leave it blank.
Figure 6-43 shows the setup.
Figure 6-43 Setting up the Zonal and Full Page Recognition
5. Save the Document Hierarchy, and then unlock it.
6.2.4 Removing the Clean rule set
The Clean rule set is created by the system by default. Because we do not use it, we delete it from our project.
To remove the Clean rule set, complete these steps:
1. Go to the Task Profiles tab.
2. Lock the Task profiles for editing.
3. Expand the Rulerunner task, and then select the Clean rule set.
Figure 6-44 Removing the Claim rule set
5. Click the Save icon to save the changes.
6. Click the padlock icon to unlock the task profile.
6.2.5 Creating a rule set to read fields
We defined the zones on the page. Currently, they cannot be used because the system is not aware of them. Now, we must create a rule set that locates the previously defined zones and reads their contents from the captured form. We also need to assign the rule set to the DCO and Rulerunner task.
For our use case, in the claim form, we look for whether the document has a signature and date and whether the Yes or No checkbox was selected for Injury or if the field was left blank. As stated earlier, the Signature and the Injury fields are OMR fields. The date of the signature, the SignedDate field, is an ICR field. Therefore, in the new rule set, we must read both OMR fields and ICR field.
To create the rule set to read the claim form fields, complete these steps:
1. Go to the Rulesets tab.
2. Right-click the Auto_Claim rule set, and then select Add ruleset.
3. Rename the new Ruleset1 rule set to Locate and the Rule1 rule to Claim_Pg Rule. You can also rename the Function1 function. For our case study, we keep the same name for the function.
4. From the Actions library tab, add the ReadZones() action to the Function1 function. Figure 6-45 shows the current setup.
Figure 6-45 Adding the Locate rule set to the Auto_Claim rule set
5. Lock the Document Hierarchy for editing.
6. Select the Claim_Pg page, and then click the Add to DCO button.
7. Click the left sync view icon to verify that the correct rule has been applied to the right DCO.
8. Add a Read OMR Fields rule that reads OMR fields in the rule set (Figure 6-46 on page 228), and then apply the rule to the OMR fields in the DCO:
a. Select the Locate rule set, and then right-click Add rule.
b. Rename the new rule to ReadOMR Fields.
c. Select Function1 under the ReadOMR Fields rule.
d. From the action library, add RecogOMRThreshold() to Function1.
e. Set the parameters for RecogOMRThreshold() to ("1","0.5").
f. Apply the rule to the Injury and InsuredSignature fields in the DCO.
Figure 6-46 Read OMR Fields rule setup
To properly set the OMR value, see 9.2.7, “OMR field configuration” on page 298.
9. Add a Read ICR Fields rule that reads the ICR field in the rule set (Figure 6-47), and then apply the rule to the ICR field in the DCO:
a. For Rule name, enter Read ICR Fields.
b. For Function name, enter Function1.
c. For Action name, enter RecognizedFieldICR_C() (from the icr_c action library).
d. For Field applied to in DCO, enter SignedDate.
Figure 6-47 Read ICR Fields rule setup
10. Select the Locate rule set, and then save the changes.
11. Add the Locate rule set to the Rulerunner task profile. Move the rule set just after the Find Fingerprint rule set.
12. Save your changes.
Figure 6-48 shows the Locate rule set now.
Figure 6-48 Locate rule set setup
6.2.6 Creating a rule set to validate fields
We bundle the validation of the content of the form in one rule set and name it “Validate.” This rule set connects to a DB2 database and performs a database lookup with the claim number (read from the barcode) as the key. The rule set then populates the fields on the claim page with the values from the database lookup. The additional content is then available on the form during the Verify step. At the end, the rule set checks whether the Injury, Signature, and SignedDate fields are completed and whether the SignedDate is in the correct format.
To create this rule set, complete these steps:
1. Select the Validate rule set, and then lock it for editing.
2. Verify that the application wizard added the Validate Page rule to the page object.
3. Add a validation rule for each field:
a. Right-click the Validate rule set, and select Add Rule.
b. Rename the new rule to Field populated from Database.
c. Add the IsThisFieldFilled() action to the function in this rule.
d. Add this rule to every field object. These fields are populated by the database lookup. These fields are different from the Injury, InsuredSignature, and SignedDate fields.
e. Add another rule to ValidatePage, and then name it OMR Field Marked.
f. Add the ISMaxOMRChecked() and ISMinOMRChecked() actions to the function.
g. Apply this rule to the Injury and InsuredSignature fields.
h. Add another rule to ValidatePage, and then name it SignedDate Field.
i. Add the AllowOnlyChars() action to the rule with a parameter of 1234567890 to that rule.
j. Add the IsFieldLengthMin() action with a parameter 6.
k. Add the IsFieldLengthMax() action with the parameter 6.
l. Apply this rule to the SignedDate field.
Figure 6-49 shows the final Validate rule set.
Figure 6-49 Validating the rule set
6.2.7 Validating captured field values against the database
The claim form has two fields that you can validate against the database, the form type field and the claim ID field. The form type field comes from the first barcode on the form. The claim ID field comes from the second barcode on the form.
The claim ID (the Incident_Number) is in the form of CL-#######, for example CL-2389534. In the database, the field value does not have the CL-. Therefore, to validate the claim ID against the database, we must strip away the characters and get the integer claim number, 2389534. Because the claim ID is created in the system when the accident is reported, there must always be a claim record matching with the claim ID.
With the claim record, we can get claim and policy information from the database, such as the policy expiration date. If the claim ID exists in the database, the validation goes through. We then populate fields from database to Datacap. If the claim ID does not exist in the database or is missing, we want to highlight the field in red color and mark it for operators to manually verify the field for the claim form.
Creating a validation rule for the Incident_Number
To create a validation rule for Incident_Number, complete these steps:
1. On the Rulesets tab, select Auto_Validate, and then click the Lock for editing icon.
2. Expand Auto_Claim → Validate → Validate Page → Validate: Page Function 1. Instead of a hard-coded user ID and password in OpenConnection(), enter APPVAR(Lookupdb:cs) for the parameter string to look up the database connection information (Figure 6-50).
Figure 6-50 Validating the incident number: Validate Page Function 1
3. Add a rule for Lookup Incident Number as shown in Figure 6-51:
Figure 6-51 Adding a Lookup Incident Number rule
a. Add the rule, and then rename it to Lookup Incident Number.
b. Add an rrSet() action from the action library, and then set its properties as follows:
• For varSource, enter @P.GetBarCode0.
• For varTarget, enter @F.
This action reads what is scanned in the BarCode0 field, which is the claim number, and places the number in the current field, @F.
c. Add the AllowOnlyChars() action from the action library and set its parameter as 0987654321.
This action reads the claim number from the current field @F, removing all characters, except characters 0–9. As mentioned earlier, in the claim form, the claim number has the format of CL-########, for example CL-2389534. In the AUTOCLAIM database table, it is in digits, such as 2389534, without the “CL-” character.
d. Add the SmartSQL() action from the action library, and then set its parameter as follows:
• Set the first parameter:
Select * from DB2ADMIN.AUTOCLAIM C, DB2ADMIN.AUTOPOLICY P WHERE C.CLAIM_NUMBER=+@F+ AND C.POLICY_NUMBER=P.POLICY_NUMBER
• Second parameter to YES.
This action runs the smart SQL as set in the first parameter. It passes in the CLAIM_NUMBER (stored in @F) from the previous action. Then it gets the claim record from the AUTOCLAIM table and the associated policy record from the AUTOPOLICY table.
The second parameter specifies whether you want the result set to return. In this case, we want to get the result set back for our case study to demonstrate that you can do that. In an actual production system, if you need the information back, set it YES, but we advise that you return only the field that you need.
The result set returns rows as [...] [...] [...] .... The base index for the result set is from 1. To obtain the first field, you reference it as 1. To obtain the second field, you reference it as 2.
e. Add actions to get fields from the result set, and then set them to the fields on the scanned page by using the following actions:
• PopulateWithResult("#,<true/false>")
• rrSet("@F","@P/<field name>")
The first action gets the nth field from the result set. If the field does not exist, exit the function. The second action sets the current @F field to the field of the page specified in <field name>.
For our example, we get and set the following fields:
• PopulateWithResult("5,False")
• rrSet("@F","@P/PolicyEffectiveDate")
• PopulateWithResult("6,False")
• rrSet("@F","@P/PolicyExpiryDate")
• PopulateWithResult("1,False")
• rrSet("@F","@P/...")
|
Getting the fields: You can tell what fields will return from the result set based on your database table schema. Alternatively, you can look at the log file to see what row set is returned from Datacap for testing and verification purposes. To see the log file, go to the machine that executed the batch scan. Go to the specific scanned batch directory, and then look for XML file under yyyy######.XML, where ###### specifies the batch scan that was done.
|
f. When all the fields are populated, add the rrSet() action to reset the current field back to the original field that was read by using rrSet():
rrSet("@P.GetBarCode0","@F")
4. Attach the Lookup Incident Number rule to the field IncidentNumber in the scanned page:
a. From the Document hierarchy tab, expand Auto_Claim → Auto_Claim → Claim_Doc → Claim_Pg → IncidentNumber → Open → (global).
b. Right-click Validate (...was Field Populate ...) (Figure 6-52), and then select Delete to delete the default rule set.
Figure 6-52 Attaching Lookup Incident Number to the page definition
You must delete the default validation rule set before you add the newly created rule set here. Otherwise, you receive an Already exists error message (Figure 6-53).
Figure 6-53 Error message when adding a second validation rule to the same DCO
c. Apply the newly created Lookup Incident Number rule set to the DCO. From the Rulesets tab, click the vertical Add to DCO button on the left border of the Rulesets frame (Figure 6-54).
Figure 6-54 Adding the Lookup Incident Number rule set to the IncidentNumber field
5. Save all your changes:
a. On the Rulesets tab, click the Save the change icon to save the rule set that you created.
b. Click the down arrow icon, and then click PublishRuleSet.
c. On the Document hierarchy tab, click Save Changes.
d. Click the Unlock DCO for Editing icon.
6.2.8 Setting up routing
The Routing rule set decides the path of an image through the system. The rule set checks whether the confidence of the recognition is high enough to process the image automatically or whether an image must be routed for manual verification. In addition, it creates a separate image of the signature.
To set up the Routing rule set, complete these steps:
1. Go to the Task profiles tab, and then select Rulerunner → Routing.
2. On the Rulesets tab, expand Auto_Claim → Routing → Routing:Rule1.
3. Attach the routing rule to the claim page DCO in the Document Hierarchy frame with the following functions (Figure 6-55):
– Function 1: ChkDCOStatus(“1”)
– Function 2: ChkConfidence(“8,1”)
Figure 6-55 Check confidence for rule routing
The first action, ChkDCOStatus(“1”), checks whether the DCO status is 1. We configure the system later, so that when the DCO status is 1, it means the rule set failed during the validation. When the validation fails, the image is not processed automatically.
The second function, ChkConfidence(“8,1”), checks whether each character that has undergone OCR has a confidence weight of 8 or higher. For each character the scanner scans in, Datacap assigned a confidence number of 0–9 to it, with 9 being the highest. Therefore, 9 equates to 100%, and 8 means 90% confidence weight. If one of the characters that Datacap reads has a confidence weight lower than the specified number here, the system fails, and the document is not routed to other places. The operator must then do manual verification. The second parameter in the second function specifies whether to continue. For a value of 1, if any confidence weight of less than 8 for the character appears, stop the routing operation.
6.2.9 Testing scan validation and routing
Test the validation that is set up by scan in a document, and check the result by looking at the XML log file:
1. Launch the Taskmaster Client, and then log on to the Auto_Claim application, if you have not already done so.
2. Click the appropriate scan shortcut, such as the iScan icon to scan a new batch.
3. Click the Rulerunner icon to run the batch through Rulerunner (Figure 6-56). The data file has been created.
Figure 6-56 Running Rulerunner in the Taskmaster Client
4. Go to the batch directory of your application on your Taskmaster Server. In this use case, we go to the \morpheuscdatacapauto_claimatches directory.
5. Open the current batch directory, for example 20110174.015, and then search for the tm000001.xml file (Figure 6-57)
Figure 6-57 Field data in the data file
An F in the first column indicates information about the field that follows it. The field name is given in the colored line. Information is displayed depending on the properties of the field. In this example (as shown in Figure 6-57), the SignedDate has a text value of 062511. Each character (in the SignedDate value) has a confidence of 9. This valued means that the confidence of each character is 100%.
Depending on the type of the image you scanned in, you might see different results. Be sure to test an image with low confidence so that you see the routing stops.
6.2.10 Setting up the verification panel
You create the verification panel for the operator to work with. Batch Pilot creates a form and populates it with the fields in the page. With Batch Pilot, you can change the look and feel of the panel. For example, for the OMR fields, we want to display a meaningful word rather than a 0 or 1.
To set up the verification panel:
1. Select Start → Programs → Datacap → Batch Pilot → Batch Pilot to start Batch Pilot.
2. From the menu, select Open Project, and then navigate to the dco_Auto_Claim directory in your project directory to open the rrs_verify.bpp file.
3. In the lower frame, expand Auto_Claim → Claim_Doc → Claim_Pg.
4. In the column to the right, right-click Claim_Pg and select Auto Form (Figure 6-58 on page 239). This form reads the fields from this page and shows the snippets, which are a small extraction of the image, field label, and the data box. This form has just been created by Batch Pilot.
Figure 6-58 Creating an AutoForm for Claim_Pg
5. To begin configuring the form, select File → Save Form (Figure 6-59). Save this form in the dco_Auto_ClaimVerify directory of the project as Claim_Pg.dcf.
Figure 6-59 Saving the new form
6. Go back to second column from the left, and go to the lower frame. Right-click Claim_Pg, and select Pick form (Figure 6-60). Navigate to the just saved form.
Figure 6-60 Picking the new form
7. Open this Claim_Pg.dcf form.
8. Save the project to make this form part of the project.
Now we must set up the Verify job in the Taskmaster Client.
6.2.11 Setting up the Verify job
To set up the Verify job, complete these steps:
1. Launch the Taskmaster Client, and then click the golden key icon to open the Taskmaster Administrator window.
2. In the Taskmaster Administrator window, click the Workflow tab.
3. Select the Claim Thick job, and select the Verify task. Then in the right frame, click the Setup button (Figure 6-61). Batch Pilot opens.
Figure 6-61 Opening the Verify task
Figure 6-62 Selecting Task Settings
5. In the Settings for Verify task window (Figure 6-63), complete these steps:
a. Click the Filters tab.
b. For the Level field, select PAGE.
c. For the Property field, select STATUS.
d. For the Type field, select Claim_Pg.
e. For the Problem value, enter 1.
|
Confidence level for page type: We want to present a page of type Claim_Pg to the operator, only if the confidence is below a defined level. In this case, the Status was set to 1 by the validation rule.
|
f. Click Add.
g. Click OK to save the changes.
Figure 6-63 Task settings, add problem value
6. In the Taskmaster Administrator window, click Done to publish the changes.
We can test the verification panel in the Taskmaster Client now. However, first, we want to translate the boolean values of the OMR fields to more values that are easier to use. To achieve this goal, we create a dictionary within Datacap Studio.
Creating a dictionary for value translation
To create the dictionary for value translation, complete these steps:
1. Go back to Datacap Studio.
2. Navigate to Rulemanager → Document hierarchy.
3. Lock the DCO for editing, which changes the Dictionaries button in the icon row of the Document hierarchy tab from gray to black (Figure 6-64).
Figure 6-64 DCO: Manage dictionaries
4. Click Dictionaries.
5. In the window that opens and shows the available dictionaries, click the Edit Dictionary icon on the far left side. Hover over this icon, and then select Add dictionary (Figure 6-65).
Figure 6-65 Adding a dictionary
6. Give the new dictionary the name YesNo, which is done the same way as you change the name of a function.
7. Right-click the new dictionary, and then select Add word.
8. Rename <new word> to Yes and “value” to Y.
9. Add another word and value pair, where you rename <new word> to No and “value” to N (Figure 6-66).
Figure 6-66 Adding the word and value pairs
10. Save the DCO. Do not unlock it yet.
11. With the DCO still locked, right-click the Injury field, and select Manage variables (Figure 6-67).
Figure 6-67 Managing field-level variables
12. In the Injury pane (Figure 6-68), in the upper left corner, select New. Then enter the var field level variable name of DICT. Keep in mind that this name is case sensitive.
Figure 6-68 Attaching a dictionary to a field
13. Name this variable Yes/No. Then click Done.
14. Save your changes, and then unlock the DCO.
15. Go back to the verify window.
Now, a dictionary has been created and attached to the Injury field. From now on, a field of value 0 is translated to No, and a value of 1 is translated to Yes. Users on the verification panel no longer see the technical return value of the OMR function. They see a returned value that is closer to what is displayed on the image.
6.2.12 Setting up the export to the repository
We decide to export the multipage TIF files into the repository. This way, an image closest to the original is stored in the repository for further processing and archiving.
During the process, the original image, which was created by the scanner, has been renamed to <filename>.tio. The processed images are split into single paged images and named <filename>.tif. We must prepare the files for export to the FileNet repository. We want to export one file for each document to the repository. The file must have the .tif extension for it to display in the client of the repository.
To create the Image Swap rule set, complete these steps:
1. Add the RenameFile() action to the function Function1 in the rule.
2. Rename the Claim_Pg.tif file in the Image Swap rule set twice. The first call changes the extension from a .tif file to a .tip file. The second call changes the extensions from a .tio file to a .tif file.
3. Attach this rule to the Claim_Pg DCO.
4. Create the Make Multipage tif rule.
5. Add the TifMerge_SetFileName() action to the function Function1 in that rule, which sets the filename to <DocID>.tif.
6. Add the TifMerge_MergeImages() action to the function Function1 in that rule. With the All parameter, this action merges all images into the multipage image. In our use case, it adds the snippet of the signature and it has been saved earlier.
7. Attach this rule to the Close event of the Claim_Doc DCO.
Overwriting the OMR field values with the values
in the dictionary
in the dictionary
Before exporting to the FileNet P8 system, we want the OMR field values from the dictionary rather than a 0 or 1. To overwrite the field values with the values in the dictionary, complete these steps:
1. Create the Signature Field DICT rule. The default Function1 function is created. Add the rrSet() action to set the InsuredSignature field.
2. Create the Injury Field DICT rule. The default Function1 function is created. Add the rrSet() action to set the Injury field.
Figure 6-69 shows the current setup.
Figure 6-69 Overwriting the field values with the values in the dictionary
Now we can create the rule set to export the document to FileNet.
Exporting the document to the FileNet P8 system
To create the Export out to FN rule set, complete these steps:
1. Add the FN Setup values rule to that rule set.
In the FN Setup values rule, the following actions are located to connect and log in to the FileNet repository. There is no data transfer yet.
– FNP8_SetURL() to set the URL to the repository
– FNP8_SetTargetObjectID() to set the object ID in the FileNet repository
– FNP8_SetTargetClassID() to set the class ID in the FileNet repository
– FNP8_Login() to log on to FileNet (This action logs on to FileNet.)
2. Assign the rules to the open event of the batch.
In our case, these actions are general actions for the whole batch. Therefore, the FN Setup values rule set is assigned to the batch (Figure 6-70).
Figure 6-70 FN Setup values rule set assigned to DCO
3. Create the Doc Level Export to FN rule for the Export out to FN rule set. It contains the following actions:
– FNP8_SetDocClassId() to set the document class ID in the FileNet repository
– FNP8_CreateFolder() to create a folder within the FileNet repository
– FNP8_SetProperty() to set a property in the FileNet repository (called once for each property to be set)
– FNP8_SetDocTitle() to set the document title in the FileNet repository
– FNP8_Upload() to upload the image to the FileNet repository
4. Assign the rule to the open event of the document (Figure 6-71).
Figure 6-71 Export out to FN rule assigned to DCO
After a successful upload, the P8_Uploaded.xml file is created in the batch directory.
|
P8_Uploaded.xml file: If you debug this functionality, be sure to delete the P8_Uploaded.xml file before each run. The existence of this file prohibits another successful export.
|
6.3 Task profiles overview
We have created an application that serves our use case. Figure 6-72 provides an overview of the Taskmaster task profiles.
Figure 6-72 Task profiles overview
|
Task profiles sequence: The sequence of the tasks on the Task profiles tab is important. The tasks are run from top to bottom and are run on each DCO to which they are assigned.
The order of the rule sets in the Rulesets tab does not affect the execution order. However, as a good practice, sort them in a meaningful order.
|
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.