ERROR:Unable to select image in Batch Pilot Properties Window using IBM Datacap Taskmaster Capture

Unable to select image in Batch Pilot Properties Window using IBM Datacap Taskmaster Capture

When we attempting to specify an image, by using the Picture property in the Property window for a Batch Pilot control, the selection reverts back to none.

This is due to The Picture property is no longer supported in Batch Pilot and code must be used to add an image to a form.

To set a picture to an image control:

1. Run Batch Pilot.


2. Open the project and bring up the Verify DCF or whichever form the image will be added to.


3. Double click anywhere in an empty area of the form.


4. In the first drop down select Pilot and in the second drop down select FormRun.


5. After the Dim section put a line as follows, where Image1 is the name of the control.
   Image1.Picture = LoadPicture("C:\Datacap\APT\Graphics\fprintnew.bmp")

How to locate fields across multiple pages in IBM Datacap Taskmaster Capture

How to locate fields across multiple pages in IBM Datacap Taskmaster Capture

To set up  Datacap Taskmaster application, so that it can locate a field, such as Invoice Total, that may be on any of several pages in a document We have to observe to observe the fallowing things.

In The APT application, shipped with Datacap Taskmaster provides an example of how to locate a field across several pages using the following components:

• The Locate Ruleset, Document Level Rule, Multi Page Function contains the following, which allow multiple pages in a document to be treated as a single page for some actions:
  
  
  
  • IsMultipageDocument()
  
  
  • MergeCCOs_ByType("Main_Page",Trailing_Page")
  
  
  
  


• The Locate Ruleset, Invoice_Total Rule, LastKeyWord First function uses the following action:
  
  
  
  • FindLastKeyList("TotalDue")
  
  
  
  

The FindLastKeyList action uses the key list TotalDue to locate the field, but any of the other actions in the Locate action library could have been used instead. The APT application has additional features that expand on this capability, but the basic functionality can be created with the above actions.

 

How to load TIO instead of TIF images with IBM Datacap Taskmaster Capture Batch Pilot Verify

How to load TIO instead of TIF images with IBM Datacap Taskmaster Capture Batch Pilot Verify

To change to using TIO images:

1. Run Batch Pilot and open the Verify form.


2. Double click on a blank section to access the code section.


3. Bring up the Pilot_FormRun event.


4. Locate the following commands: ImageCtrl.FileName=pObj.Variable("IMAGEFILE")
   Set ImageLink.PilotObject = Pilot
   Set ImageLink.ImageControl = ImageCtrl


5. For the next command add:
   If btnTIFFToggle.Caption <> UCase(Right(ImageCtrl.FileName,3)) Then Call TIFTIO()


6. Bring up the Pilot_OnActiveObjectChange event.


7. Locate the following commands:
   If ImageCtrl.fileName <> pObj.Variable("IMAGEFILE") And then
   ImageCtrl.FileName = pObj.Variable("IMAGEFILE")
   End if


8. Add the same command added in step 5.


9. Save the form.

Unable to convert PDF files into TIFF via eDoc suite

When we try to convert PDF files into TIFF via eDoc suite.The following error occurs: "This name format is not supported in current naming convention.". This is Due to The eDoc Conversion actions (convert.rrx), including PDF to TIFF, rely on the filename to be in a standard format in order to generate child page filenames. So when a PDF file contains 20 pages, it needs to be able to extract it to 20 TIFF files. eDoc actions use a simple scheme to name the individual page images. The file name must adhere to this standard in order to have a successful convert.

To Resolve this Problem

Change the PDF file names as needed to be compatible with eDoc Conversion actions.

How to customize Web Verify screens in IBM Datacap Taskmaster Capture

 Customize Web Verify screens in IBM Datacap Taskmaster Capture

The Web Verify task in Taskmaster 7 and above combines most features of previous Verify and Index tasks.

The layout of the displayed information by default is generated automatically, based on the file \Datacap\tmweb.NET\Task\prelayout.asp.  It is possible to modify this file to change the Verify display in minor ways.  It is also possible to customize the Verify screen layout extensively using the following procedure.  This is called a “static” layout as opposed to the default automatic layout.

Steps to Customize Web Verify screens

1. Edit an existing thick client Verify form (.dcf) or create a new one using some combination of Application Wizard, Batch Pilot Autoform, and manual editing in Batch Pilot designer.  Create a new subroutine Sub ProcessFrame(pParentFrame, sOut) by typing on a line right after Declarations, but do not fill in any code.


2. Start another copy of Batch Pilot and open the form \Datacap\tmweb.NET\Task\verify.dcf.


3. Copy and paste the scripting (body) of ProcessFrame from verify.dcf to the new form.  Copy and paste the body of the UserForm_Click from verify.dcf to the beginning of Sub FormDriver_OnInitialize.


4. Close the second Batch Pilot that has verify.dcf open.


5. Select Form/Run Script.  Even if an error message appears, this should create the file c:\ layout7.txt.


6. Open the file \Datacap\tmweb.NET\Task\1040ez.ascx in a text editor.  Copy the first four lines to the clipboard.  Close the file.


7. Open the file c:\layout7.txt in a text editor.  Paste the contents of the clipboard above the first line in this file.  Save the result as \Datacap\tmweb.NET\Task\MyForm.ascx (or use a filename more appropriate than MyForm.ascx that identifies the type of page or the application).  The file extension must be ascx.


8. Edit the .ascx file further in a text editor if desired.


9. Edit the Verify task project file (.bpp) in a text editor.  Typically this file is in the application’s process folder.


10. Find the [iCap] section.  Set Static=1, Types=1, Type0=<MyPageType>, and Src0=MyForm.ascx


11. If the application has more than one type of page to be verified or indexed, Types would be set to the number of page types, and Type1, Type2, … and Src1, Src2, … would need to be added, depending on the number of page types.  Each page type would need its own layout (.ascx) file.  Auto-generated layout cannot be mixed with static layout.

Migrating a legacy IBM Datacap Taskmaster Capture application

Datacap Taskmaster applications typically reference a number of files using either drive-letter or UNC based paths. They access several databases using either system DSN's or ODBC Provider specifications. Finally, they typically access the Taskmaster Server via an IP address or machine name. This document identifies where these file paths, database, and server specifications are stored and how to change them when the application must be moved.

The three main shared folders used by Datacap Taskmaster applications:

Datacap Taskmaster software is typically installed on a shared network drive, although it can also be installed locally on each station. In a network installation, the software folder is usually named \Datacap.

Application-specific files usually reside in a folder inside the Datacap folder. By convention the Application Process folder (and sub-folders) contains all application-specific files such as Access databases (*.mdb), Batch Pilot projects (*.bpp), custom forms and scripts (*.dcf. *.dcs, *.rra), etc.
Batches of documents, containing images and data, are usually stored in a shared folder on the network. Sometimes the Batch folder is within the Application folder, but typically it is separate.

Where file paths, database identifiers, and server IP addresses are stored:

• The Windows registry contains paths to the Datacap folder for registered software components, and may also contain non-critical paths such as recently used files, etc.


• Desktop, Start Menu, and Windows Scheduler shortcuts to Taskmaster Client, Rule Manager, AutoDelete, ENU, etc. frequently contain paths to the software, configuration settings (.ini) files, and either DSN's or ODBC Provider strings to databases. Services may also contain paths (e.g. to TMSub, the Taskmaster Client Service).


• The Taskmaster Admin database contains paths in dco table, dco_setup field and taskmod table, md_params field (Document Hierarchy file and task-specific setup parameters, respectively).


• The Taskmaster Engine database contains paths in the tmbatch table, pb_batchdir field (Batch Directory).


• Taskmaster Rules databases may contain paths in the action table, ac_Params field (Action parameters); paths are also stored in the Template table, tp_CCOPath and tp_ImagePath fields (fingerprint files and associated CCO's).


• Report Viewer databases contain paths in the Reports table, Crystal and DB fields (report file locations and databases).


• Batch Pilot and Taskmaster Web project files (*.bpp and *.icp) contain paths to forms, scripts, and possibly other files.


• Taskmaster Web configuration file Apps.ini contains the IP address of Taskmaster Server, as well as the DSN or ODBC connection string for the Admin and Engine databases for each Taskmaster Web application.


• Rule Manager settings files (e.g. ruleman.ini) contain paths to the Document Hierarchy (setup dco), Batch Folder, Actions Folder, Rule Runner software, and Fingerprint Folder.


• AutoDelete’s settings file (e.g. tmbatdel.ini)

Changing paths to the application and/or software:
When changing drive letters, UNC paths, or switching between drive letters and UNC, the following procedures are recommended. These actions should be performed when the Datacap Taskmaster system is shut down – Taskmaster Clients, Web Clients, Web Server, and Taskmaster Server should all be logged out or stopped. The entire Application folder, the Admin and Engine databases should be fully backed up before making these changes.

Changing the shared folder where Datacap Taskmaster software is located:

1. After installing the software in the new location, run the register install from all client stations.


2. Make an inventory of Datacap Taskmaster application shortcuts on client desktops, Start menus, and Windows Scheduler. Each one containing a path needs to be updated. (The install\clfolder.ini can be modified to install new or updated shortcuts automatically when the register install is performed)


3. If the application folder is located in the shared Datacap folder, follow the steps below for changing the shared Application folder.


4. If Taskmaster Server or Client is installed as a Service, select the Service, choose properties, and update the Path to Executable.


5. Report Viewer databases typically need to be updated – open the Reports table in the rptview.mdb database, and update paths in the Crystal and DB tables.


6. Batch Pilot projects (*.bpp) for standard tasks contain paths to the shared Datacap folder. Edit all *.bpp and *.icp files in the Application folder using a text editor. Change all paths as required.

Changing the shared folder where Batches are stored:

1. Identify the Batch Creation tasks in the workflows (typically scan, vscan, or fax input tasks).


2. For each Batch Creation task, go into Task Setup and change the Batch Directory. For Batch Pilot tasks select File/Task Settings and update the setting titled Create Batch Dir under.


3. If in process batches were moved, edit the Engine Database table tmbatch and make replacements to the value in field pb_batchdir for all affected batches.


4. If any application-custom tasks or actions contain the path to the batch folder, they should be modified. Application-custom action parameters can be scanned in the Rules database.

Changing the shared Application and Application Process folders:

1. Make an inventory of Datacap Taskmaster application shortcuts on client desktops, Start menus, and Windows Scheduler. Each one containing a path needs to be updated. (The install\clfolder.ini can be modified to install new or updated shortcuts automatically when the register install is performed)


2. Most Batch Pilot and Taskmaster Web projects (*.bpp and *.icp) contain paths to the Application and/or Process folder. Edit all *.bpp and *.icp files in the Application folder using a text editor. Change all paths as required.


3. Workflow Document Hierarchy files (XML files, also called setup DCO) need to be reset in Taskmaster Administrator for each workflow, and also reselected in each Batch Pilot Task Project that the application uses.


4. Some tasks refer to settings files in the Process folder. Go through the settings for each task, checking each option in each tab for paths, and update as needed.


5. If the Admin or Engine databases are MS-Access *.mdb files, the DSN will need to be updated in Taskmaster Server.


6. If the Rules or Lookup databases are MS-Access *.mdb files, update the DSN's on each server and client that runs rules or performs lookups.


7. If the application uses Rules:
   
   
   
   1. Edit ruleman.ini (or whatever rules setting file is specified in the Rule Manager shortcut) and change paths as needed.
   
   
   2. Edit the Taskmaster Rules database table action, and change any paths in the ac_Params field as needed.
   
   
   3. In the Taskmaster Rules database table Template, change paths as needed in fields tp_CCOPath and tp_ImagePath.
   
   
   
   


8. If the application uses FormSpecs, edit them in a text editor and search for references to the Process folder. Update the paths as required.

Changing Databases:
Using DSNs – inventory the chosen DSN names and then use ODBC manager to:
1. Update the Datacap Taskmaster application Admin and Engine DSN's on Taskmaster Server.
2. If the application uses lookups, update the Lookup DSN on all client stations that require it. If TMWeb is used, this includes the Taskmaster Server station.
3. If the application uses Rules, update the Rules DSN on all client stations that require it. If TMWeb is used, this includes the Taskmaster Server station.

Smart Parameter Actions for IBM Datacap Taskmaster Capture

In Datacap Certain actions can accept “Smart Parameters” to set or retrieve the value of an object in the Document Hierarchy – typically a Variable or a Field value.  Values can be compared with or set from other Document Hierarchy values, text strings (“constants”), or other special values as described below.  Only actions that specifically accept Smart Parameters understand and work with them.
Smart Parameters follow a special syntax. Words starting with an at sign (@) are special variables or expressions as described below.  Words that begin with two periods (..) or backslash (\) are navigation expressions as described below.  Words separated by a plus sign (+) are concatenated together.  Words that don’t start with (@ or ..\) are treated as string value constants.  For example: Batch+@BATCHID evaluates as “Batch” followed by the current Batch ID; @F.DICT is the value of the DICT Variable of the current Field, etc.
The main actions in rrunner.rrx that accept Smart Parameters are:

• rr_Get(from): assigns a value to the “calling” object of the Document Hierarchy.


• rr_Set(from, to): copies data from one place to another.


• rr_Compare(from, to): compares the values specified by two Smart Parameters.


• rr_Compare_Not(from, to): compares the values specified by Smart Parameters.


• rr_Copy(from, to); Copies values from one field node to another, including zones & character confidence.


• rr_Append(from,to): Appends the value to the target.


• rr_Prepend(from,to): Prepends the value to the target.

Many other actions accept Smart Parameters. Consult the action help and other documentation for details.

Smart Parameters Concepts and Terminology
The information and tables below show how Smart Parameter actions might be used.
A rule containing a Smart Parameter action is “bound” to an object of the Document Hierarchy. Important! - In Smart Parameter terminology, this is the calling object.

• By default, a Smart Parameter returns a value to the Text property of the calling object.


• An action that retrieves the value of a TaskID and adds it to the “text” variable of the Document Hierarchy’s Batch object might look like this: rr_Get(@TASKID)…as long as the rule is bound to the Batch object.


• In contrast, for an action to assign the string “ThisTask” to the Task_ID variable of the Batch object, the following action would do the trick: rr_Set(ThisTask,@B.Task_ID)


• An action to set a page’s variable METRIC to “100,100” would be:
  rr_Set(100+@CHR(44)+100,@P.METRIC)


• To compare two values, use the rr_Compare action: rr_Compare(@TASKID,@B.Task_ID)

Individual Smart Parameters
A Smart Parameter action returns String values when using any of the following ParameterString arguments:

@BATCHID	Returns the processing ID of the current batch.	rr_Get(@BATCHID) This assigns the Batch ID of the batch being processed, to the calling object.	6.5, 7.1, 7.5, 7.6, 8.0
@ID	Returns the processing ID of the bound object of the Document Hierarchy…the “calling” object.” For example, if the rule is bound to a Document object, this Smart Parameter retrieves the current document’s value.	rr_Set(@ID,@B.Doc_ID) During processing, this example assigns the ID value of the bound object – presumably a Document object – to the Batch object’s Doc_ID variable.  If the Batch object does not have a Doc_ID variable this action will create it.	6.5, 7.1, 7.5, 7.6, 8.0
@STATUS	Returns the value of a calling object’s STATUS value. Important! STATUS is both a setup property and a runtime variable. As a property, it indicates an object’s nature: -1 specifies an “Anchor Field” or hidden field. During processing, a change in Status may designate a problem (“1” = Problem, “0” = OK).	rr_Compare(@STATUS, @B.STATUS) If a rule with this action is bound to the Page object of the source page – Invoice_Page, for example – this very helpful example will compare each page’s processing status to the Batch object’s setup Status. If the values are different, the action will return False, and a follow-up action will probably halt processing (for details, see Page 11).	6.5, 7.1, 7.5, 7.6, 8.0
@TYPE	Indicates an object’s role and specifies its level on the Document Hierarchy: Batch, Document, Page or Field. This is a setup property with values that rarely change.	rr_Get(@TYPE+@ID)	6.5, 7.1, 7.5, 7.6, 8.0
@DATE (format)	Returns the current system Date value. Important! This is the current Date, unless another action has assigned a Date value to a different variable, and an rr_Set action is placing that value in this location (Page 11). The parameter can include a format specification (see the examples).	rr_Set(@DATE(),@P.Date) This action assigns the current Date to the Date variable of Page associated with the calling object. rr_Get(@DATE(mm.dd.yyyy) This action formats the date to resemble “12.31.2006” and assigns it to the calling object. The default format is MM/DD/YYYY.	6.5, 7.1, 7.5, 7.6, 8.0
@TIME(format)	Returns the current system Time value. Important! This is the current Time unless another action has assigned the Time to a different variable, and an rr_Set action is placing that value in this location (Page 11). The parameter can include a format specification (see the examples).	rr_Set(@TIME(),@P.Time) This action assigns the current Time to the Time variable of the Page associated with the calling object. rr_Get(@TIME(HH:MM) This action formats the Time value to resemble 12:33 and assigns to the calling object.  The default format is HH:MM:SS.	6.5, 7.1, 7.5, 7.6, 8.0
@VALUE	Returns the text value of the bound object…usually a Field object in a source page.	rr_Set(@VALUE,..\<FieldName>.Text) If bound to a field, copies the value of that field to the Text property of another field named <FieldName> on the same page.	6.5, 7.1, 7.5, 7.6, 8.0
@CHR(ASCII value)	Returns a character that is a member of the ASCII character set. The advantage of this Smart Parameter is that it allows a character to be accessed and placed that would not otherwise be available – a comma, for example. See the examples for the action’s format.	rr_Get(..\Vendor_Name+@CHR(44)+ ..\Invoice_No) In this case, the rr_Get action constructs a value with three components:  the vendor’s name, a comma, and an Invoice Number.	6.5, 7.1, 7.5, 7.6, 8.0
@JOBID	Returns the value of the current Job ID. Important! The Job ID originates in the Job ID field of the Taskmaster Administrator’s Workflow tab. The Job Name (below) is in the Description field.	rr_Get(@JOBID) If a rule is bound with this action to the Batch object, the rule will update the Batch-level Text variable with the Job ID. rr_Set(@JOBID+@JOBNAME) This action assigns the Job ID and the Job Name (below) to the calling object	6.5, 7.1, 7.5, 7.6, 8.0
@JOBNAME	Returns the value of the current Job Name. The Job Name originates in the Description field of the Taskmaster Administrator’s Workflow tab.	rr_Get(@JOBNAME) Sets the current Job Name – its description - to the Text property of the calling object.	7.1, 7.5, 7.6, 8.0
@OPERATOR	Returns the ID of the operator who is running the current task and places this value in the calling object’s Text property – or in a variable of another object designated by the rr_Set action. An Operator ID originates in the User ID field of the Taskmaster Administrator’s Users tab. The value of a specific Operator ID is established when the operator signs on and launches the current Job/Task Combination.	rr_Get(@OPERATOR) This action retrieves the ID of the operator responsible for the current task, and places the value in the Text property of the calling object. rr_Get(@BATCHID+@OPERATOR) This very simple Smart Parameter action could be used to connect an operator to a batch, and assign their ID values to a calling object’s Text property.	6.5, 7.1, 7.5, 7.6, 8.0
@STATION	Returns the ID of the workstation which running the current task and places this value in the calling object’s Text property – or in a variable of another object designated by the rr_Set action. A Station ID originates in the Station ID field of the Taskmaster Administrator’s Users tab.	rr_Get(@STATION) Station ID along with Operator ID provides useful information about the batch.	6.5, 7.1, 7.5, 7.6, 8.0
@TASKID	Returns the value of the current Task ID. The Task ID originates in the Task ID field of the Taskmaster Administrator’s Workflow tab; the Task Name (below) is in the Description field.	rr_Get(@TASKID) If a rule is bound with this action to the Batch object, the rule will update the object’s Text variable with the Task ID whenever a task runs. rr_Set(@JOBID+@TASKID) This action assigns the Job ID and the Task ID to the calling object’s Text property.)	6.5, 7.1, 7.5, 7.6, 8.0
@TASKNAME	Returns the value of the current task name.  (see the example.) The Task Name originates in the Description field of the Taskmaster Administrator’s Workflow tab.	rr_Get(@TASKNAME) Assigns the current Task Name – its description -  to the Text property of the calling object – unless the action indicates a different location (see the examples.)	6.5, 7.1, 7.5, 7.6, 8.0
@EMPTY	Represents an empty string	rr_Set(@EMPTY) This action assigns the calling objects Text property to an empty string, does not affect any other calling object values.	7.1, 7.5, 7.6, 8.0
@VAR(variable name)	Returns the value of the calling objects variable variablename. This is the same as using @F.variablename	rr_Get(@VAR(ID)) This action retrieves the unique Taskmaster "ID" of the calling object, and sets the calling object Text value to this ID.	7.5, 7.6, 8.0
@DCO(property name)	Returns the value of the calling object’s DCO property as specified in the property name argument. 8.0 Supported Properties: ID, TYPE, STATUS, BATCHDIR, BATCHPRIORITY, IMAGENAME, TEXT, CONFIDENCESTRING, XML.	rr_Get(@DCO(ImageName)) This action sets the calling object's Text value to the DCO ImageName property of the calling object.	7.5, 7.6, 8.0
@PILOT(property name)	Returns the value of the PILOT object property specified in the property name argument. 8.0 Supported Properties: BATCHID, BATCHDIR, OPERATOR, STATION, CHILDRENQUANTITY, PRIORITY, CAPTION, PROJECTPATH, PAGESINBATCH, DOCSINBATCH, EXPECTEDPAGES, EXPECTEDDOCS, ADJUSTEDPAGES, ADJUSTEDDOCS, JOBNAME, TASKNAME, FORMPATH, DCOFILE, JOBID, TASKID.	rr_Get(@PILOT(ProjectPath)) This action sets the calling objects Text property to the value of the Pilot.Projectpath property.	7.5, 7.6, 8.0
@STRING(string value)	Returns a string of the argument passed.	rr_Get(@STRING(..\HI+2)) This action sets the calling objects Text property to  “..\+2”	7.5, 7.6, 8.0
@PATH(key)	Returns the full path to a file that is defined in the configuration file “paths.ini” located in the application project folder.  For example, in the 1040EZ sample application, if c:\…\1040ez\process\paths.ini contains: [Paths] ExportDir=..\Export Then @PATH(ExportDir) would return c:\…\1040ez\Export	rr_Get(@PATH(Images)) This action assigns/sets the calling objects Text property to the value returned from the key ‘Images’ in the calling application files ‘Paths.ini’. The value of the entry is treated as a relative path., such that a paths.ini entry of ‘..\Images’ would result in a file path with the images directory being a sibling folder of the folder containing the paths.ini file and SetupDCO.xml.	7.5, 7.5SP1, 7.6, 8.0, 8.0
@APPVAR(key)	Returns the value defined in the configuration file “paths.ini” located in the application project folder.  For example, in the 1040EZ sample application, if c:\…\1040ez\process\paths.ini contains: [Variables] LookupDSN=.PROVIDER=XYZ Then @APPVAR(LookupDSN) would assign PROVIDER=XYZ to the calling object's value. 8.0+: @AppVar smart parameter changed to look in the App Service for the current application for the passed argument/variable. If it cannot connect to the App Service or if it cannot find the requested variable, it logs that fact and then looks in the [Variables] section of current applications paths.ini in the process (or dco_appname) folder.	rr_Get(@APPVAR(LookupDSN))	7.5, 7.5SP1, 7.6, , 8.0
@APPPATH(key)	Returns a full path value from the Application service.		8.0
@DICT_VALUE(smart parameter path)	Returns the DCO dictionary VALUE of  the OMR field specified in the parameter, which is a smart parameter path.	rr_Set(@DICT_VALUE(..\SEX)) This action sets the calling objects Text property to the Dictionary VALUE of the OMR field ‘SEX’ which is a sibling field to the calling object.	7.1, 7.5, 7.6, 8.0
@DICT_WORD(smart parameter path)	Returns the DCO dictionary WORD of the OMR field specified in the parameter, which is a smart parameter path.	rr_Get(@DICT_WORD(..\SEX)) This action sets the calling objects Text property to the Dictionary WORD of the OMR field ‘SEX’ which is a sibling field to the calling object.	7.1, 7.5, 7.6, 8.0
@DICT_WINDEX(csv string)	The argument is a csv string of the dictionary word to match. Returns a zero filled string where matched indexes are represented by the '1' character.		8.0
@DICT_VINDEX(csv string)	The argument is a csv string of the dictionary value to match. Returns a zero filled string where matched indexes are represented by the '1' character.		8.0
@PROJECTDIR	Returns the directory path to the PILOT application settings file.	rr_Get(@PROJECTDIR+\+myfile.ini) This action sets the calling object's Text property with a path to a file named myfile.ini located in the same directory as the current task’s settings file (bpp).	7.5, 7.6, 8.0
@PROCESSDIR	Returns path to the process folder.  Process folder is defined as the directory containing the task’s setup dco.		8.0

Smart Parameter Navigation Syntax
An action with a Smart Parameter typically delivers a value directly to the calling object…to the object of the Document Hierarchy to which the action’s rule is bound. However, an action’s syntax can be modified so that the rule locates values in variables of objects at various levels of the Document Hierarchy and, if appropriate, assigns the values to the variables of objects at different levels.
The following syntax parameters can be used to help Smart Parameter actions access and deliver data to and from objects of the Document Hierarchy, from level to level.
The descriptions in the table below use a simplified structure. In addition, the descriptions assume that values are returned to the calling object.
Batch: Invoice

   Document: Document

Page: Main_Page

Field:  Vendor_Name
Field:  Invoice_No

Navigation	Description
<object>.	The period (“.”) introduces a variable name – @D.Doc_ID, for example. rr_Get(@D.Doc_ID) retrieves the Document object’s Doc_ID variable value and assigns it to the calling object’s Text property. rr_Set(13,@P.b_tp) sets the Page variable named b_tp to the value 13.  For a Bar Code field, this sets the bar code symbology to Code 39.
@B, @D, @P, @F	References the parent Batch, Document, Page and Field of the calling object.  For example: @P.Type refers to the Type Variable of the current page.
..\	Designates a parent and child object, and returns the value of the child as long as it is one or more levels below the calling parent. For example, if the calling object is Document, the rr_Get action can return the value of the Invoice_No field because Invoice_No is a child of the Main_Page object. rr_Get(\Main_Page\Invoice_No) In the example below, the calling object might be the Invoice batch object which would have the Text property of the Invoice_No field returned. rr_Get(\MyDoc\Main_Page\Invoice_No)  Vendor_Name and Invoice_No are both siblings at lower levels. This action would copy the value of Vendor_Name to sibling Invoice_No.  Note that this process only copies the value and does not copy field confidence or captured zone info to Invoice_No. rr­_Set(..\Vendor_Name,..\Invoice_No) The following action would return the text value of the object PagesPerDoc, which is a child of the calling object. rr_Get(\PagesPerDoc)
+ (Concatenation)	Returns the concatenation of Smart Parameter values (one appended to the other) Here, the action appends Job ID and Task ID together and puts the resulting value in Batch variable JTInfo. rr_Set(@JOBID+@TASKID,@B.JTInfo)

 
Smart Parameter Actions
The following tables describe the rrunner.rrx Smart Parameter actions.

rr_Get

Actions Library	rrunner.rrx
Description	Uses the inserted Smart Parameter as a parameter to locate the value of an object variable, and assigns it to the Text property of the calling object.
Parameters	String Smart Parameter that identifies the target object and its variable.
Level	All levels.
Returns	False if the calling object and the target object are identical – or if the action cannot locate the target object. Otherwise, True.
Example	rr_Get(@D.Tot_Pages) This action locates the value in the Tot_Pages variable of the parent document, and assigns it to the Text property of the calling object.

rr_Set

Actions Library	rrunner.rrx
Description	Uses the two Smart Parameters elements - The value of the variable for the first object is assigned to a variable of the second object.
Parameters	A comma-separated String consisting of two Smart Parameters. Parameter 1 - A reference to the variable of an object that will be the value’s source. Parameter 2 - The identity of a target object, i.e. the variable or field where the value will be placed. For both elements, the action defaults to the Text property of the calling object.
Level	All levels.
Returns	False if the calling object and the target object are identical – or if the action cannot locate the target object. Otherwise, True.
Example	rr_Set(@D.Tot_Pages,@B.Tot_Pages) This variation on the example for the rr_Get action locates the value in the parent document’s Tot_Pages variable and assigns it to the Tot_Pages variable of the Batch object.

rr_Compare

Actions Library	rrunner.rrx
Description	Uses the inserted Smart Parameters as the parameter to locate and compare the values of two objects' variables. If the values do not match, the action returns False.
Parameters	A comma-separated String consisting of two Smart Parameters. Parameter 1 - A reference to the variable of an object that is the first value’s source. Parameter 2 - A reference to the variable of an object that is the second value’s source.
Level	All levels.
Returns	False if the calling object and the target object are identical – or if values do not match. Otherwise, True.
Example	rr_Compare(@D.Tot_Pages,@B.Tot_Pages) This variation on the examples for the previous action shows how a value is solicited from a comparable variable of two objects – the parent batch and document. The two values are then compared: the action returns False if the values are not the same.

rr_Compare_Not

Actions Library	rrunner.rrx
Description	Uses the inserted Smart Parameters as the parameter to locate and compare the values of two objects’ variables. If the values do not match, the action returns True.
Parameters	A comma-separated String consisting of two Smart Parameters. Parameter 1 - A reference to the variable of an object that is the first value’s source. Parameter 2 - A reference to the variable of an object that is the second value’s source.
Level	All levels.
Returns	True if the calling object and the target object are identical – or if values do not match. Otherwise, False.
Example	rr_Compare_Not(@D.Tot_Pages,@B.Tot_Pages) This variation on the examples for the previous action shows how a value is solicited from a comparable variable of two objects – the parent batch and document. The two values are then compared: the action returns True if the values are not the same.

rr_Copy

Actions Library	rrunner.rrx
Description	Copies values from one field node to another, including zones & character confidence.
Parameters	A comma-separated String consisting of two Smart Parameters. Parameter 1 - A reference to the field object that is the first value’s source. Parameter 2 - A reference to the field object that is the second value’s source.
Level	All levels.
Returns	True if the calling object and the source and target objects exist, otherwise False.
Example	rr_Copy(@P\SubTotal,@P\Total)

rr_Append

Actions Library	rrunner.rrx
Description	Uses the two Smart Parameters elements - The value of the variable for the first object is appended to a variable of the second object.
Parameters	A comma-separated String consisting of two Smart Parameters. Parameter 1 - A reference to the variable of an object that will be the value’s source. Parameter 2 - The identity of a target object, i.e. the variable or field where the value will be appended. For both elements, the action defaults to the Text property of the calling object.
Level	All levels.
Returns	False if the calling object and the target object are identical – or if the action cannot locate the target object. Otherwise, True.
Example	rr_Append(@D.Tot_Pages,@B.Tot_Pages) This variation on the example for the rr_Get action locates the value in the parent document’s Tot_Pages variable and appends it to the Tot_Pages variable of the Batch object.

rr_Prepend

Actions Library	rrunner.rrx
Description	Uses two Smart Parameters elements – The value of the variable for the first object is prepended to the value of the variable for the second object.
Parameters	A comma-separated String consisting of two Smart Parameters. Parameter 1 - A reference to the variable of an object that will be the value’s source. Parameter 2 - The identity of a target object, i.e. the variable or field where the value will be appended. For both elements, the action defaults to the Text property of the calling object.
Level	All levels.
Returns	False if the calling object and the target object are identical – or if the action cannot locate the target object. Otherwise, True.
Example	rr_Set(@D.Tot_Pages,@B.Tot_Pages) This variation on the example for the rr_Get action locates the value in the parent document’s Tot_Pages variable and prepends it to the Tot_Pages variable of the Batch object.

How to configure the batch number format for IBM Datacap Taskmaster Capture

When Taskmaster Client runs a batch creation task, such as a scan task, it first requests a new batch number from the Taskmaster Server. Taskmaster Server generates a new number via a component called batchn32.dll. A library of files comes with the Taskmaster install that can be used to overwrite the default batchn32.dll to change the batch numbering scheme. These files are named batnewXX.dll where XX is a number from 01 to 15 and represent the different formats available.

Procedure

1. Stop Taskmaster Server.


2. Copy the desired BATNEWxx.DLL from the \Datacap\dcshared\batchnew folder to \Datacap\dcshared\BATCHN32.DLL, changing the name to overwrite the existing file.


3. Using the appropriate database tool, edit the Taskmaster engine database, enginfo table.


4. Clear the db_LastBatch, db_lastQueue and db_LastDate fields. This is not necessary for all changes, but if you cannot create a batch after making the change, be sure to do this step.


5. Restart Taskmaster Server.

Available Formats

• BATNEW01.DLL

This is the default dll for Taskmaster.
----------------------------------------
This dll implements the following batch numbering scheme:
YYYYIDDD.LLL where:
YYYY - a last two digits from the year (0001 - 2128)
I - database ID (see note below)
DDD - Julian date (number from 1 to 365)
LLL - 001 - 999 then A00 - Z99 then AA0 - ZZ9 and after that AAA - ZZZ
Note: The database ID is from the db_id field of the enginfo table in the Taskmaster engine database. Since this is a text field in the database, be careful to have a single numeric digit at the beginning.
Examples:
"1Engine" will give index 1
"2Engine" will give index 2
"Engine1" will give index 0 since it cannot be converted to a digit.

• BATNEW02.DLL

This dll implements the following batch numbering scheme:
YYYYMMDD.LLL where:
YYYY - a last two digits from the year (0001 - 1997)
MM - month (1 - 12)
DD - day (number from 1 to 31)
LLL - 001 - 999 then A00 - Z99 then AA0 - ZZ9 and after that AAA - ZZZ

• BATNEW03.DLL

This dll implements the following batch numbering scheme:
YDDDINNN where:
Y - last digit from the year
DDD - Julian date (number from 1 to 365)
I - database ID (This is the first digit from the db_id field of the enginfo table in the Taskmaster engine database)
NNN - batch number for day (1 - 999)
Note: The database ID is from the db_id field of the enginfo table in the Taskmaster engine database. Since this is a text field in the database, be careful to have a single numeric digit at the beginning.
Examples
"1Engine" will give index 1
"2Engine" will give index 2
"Engine1" will give index 0 since it cannot be converted to a digit.

• BATNEW04.DLL

This dll implements the following batch numbering scheme:
NNNNMMDD where:
NNNN - order number for batch from 1001 - 9999
MM - month (1 - 12)
DD - day (1 - 31)

• BATNEW05.DLL

This dll gives a dialog for manually entering a new batch ID.

• BATNEW06.DLL

This dll implements the following batch numbering scheme:
MMDDLL where:
MM - month (1 - 12)
DD - day (number from 1 to 31)
LL - letter starting from A up to Z
sequence is AA , AB ... AZ, BA, .. BZ, etc.

• BATNEW07.DLL

This dll implements the following batch numbering scheme:
uYYMMDDL.NNN where:
u -- just the letter 'u'
YY - last two digits from the year (00 - 99)
MM - month (1 - 12)
DD - day (number from 1 to 31)
L - letter starting from a up to z
NNN - batch number for day (1 - 999)

• BATNEW08.DLL

This dll implements the following batch numbering scheme:
cYYMMDDL.NNN where:
c -- just the letter 'c'
YY - last two digits from the year (00 - 99)
MM - month (1 - 12)
DD - day (number from 1 to 31)
L - letter starting from a up to z
NNN - batch number for day (1 - 999)

• BATNEW09.DLL

This dll implements the following batch numbering scheme:
YYMMDD.NNN where:
YY - last two digits from the year (00 - 99)
MM - month (1 - 12)
DD - day (number from 1 to 31)
NNN - batch number for day (1 - 999)

• BATNEW10.DLL

This dll implements the following batch numbering scheme:
YYMMDDL.NNN where:
YY - last two digits from the year (00 - 99)
MM - month (1 - 12)
DD - day (number from 1 to 31)
L - letter starting from A up to Z
NNN - batch number for day (1 - 999)

• BATNEW11.DLL

This dll implements the following batch numbering scheme:
YYMMDDNN.NNN where:
YY - last two digits from the year (00 - 99)
MM - month (1 - 12)
DD - day (number from 1 to 31)
NN.NNN - batch number for day (1 - 99999)

• BATNEW12.DLL

This dll gives a dialog for manual entering of a new batch ID (8 characters) after which it appends '.DDD' where DDD is the Julian day of the year.

• BATNEW13.DLL

This dll implements the following batch numbering scheme:
MYYMMDDL.NNN where:
M - millennium
YY - last two digits from the year (00 - 99)
MM - month (1 - 12)
DD - day (number from 1 to 31)
L - letter starting from A up to Z
NNN - batch number for day (1 - 999)

• BATNEW14.DLL

This dll implements the following batch numbering scheme:
YYJJJNN.NNN where:
YY - last two digits from the year (00 - 99)
JJJ - Julian day of the year
NN.NNN - batch number for day (1 - 99999)

• BATNEW15.DLL

This dll implements the following batch numbering scheme:
YDDDNNNN where:
Y - last digit from the year
DDD - Julian date (number from 1 to 365)
NNNN - batch number for day (1 - 9999)

How to enable the Image View panel in IBM Datacap Taskmaster Capture Client

How to enable the Image View panel in IBM Datacap Task?

Some Times The Image View panel is not visible as a pop-up or in-line Batch Pilot view in Taskmaster Client, even when Image View is enabled.

This is due to The Batch Pilot window may have been placed off screen, thus not visible in Taskmaster Client even when the View menu option Image View (Ctrl + Alt + I) is toggled on.

How to Resolve the problem?

Close Taskmaster Client and in Registry Editor (regedit), remove the following key and its subkeys:

• HKEY_CURRENT_USER\SOFTWARE\Datacap\Batch Pilot\<task's BPP>

Note: If not logged into Windows with the affected user's credentials, the corresponding registry values through the HKEY_USERS branch will need to be deleted.

A task's BPP name is application dependent: To determine the task name:

1. Go to Settings -> Workflow -> <Job>, <Task> and note the Module name.


2. In Settings -> Modules, <Module>, note the file path and name specified in Parameters.
   Ex: if C:\Datacap\MyApp\dco_MyApp\verify.bpp, then the registry key to delete on the client machine is HKEY_CURRENT_USER\SOFTWARE\Datacap\Batch Pilot\verify.bpp.

How can Datacap Task master Capture Rulemanager and RRA based tasks load RRX files?

To make the Rulemanager and RRA based tasks load RRX files we have to do the fallowing modifications.

In the task project .bpp file (for Rulemanager, file ruleman.ini), include the entry:
[Scripts]
RRAXSL=c:\datacap\rrs\rra2rrx\buildrra.rls

IBM Datacap Taskmaster Capture application paths /connectionstringsChecklist

IBM Datacap Taskmaster Capture application paths/connection strings

This is an unofficial checklist of where application paths and connection strings may be stored in IBM Datacap Taskmaster 8.0.0 and later. Because of the highly customizable nature of Taskmaster, specific installations may differ.

System registry (client machine)

• HKEY_LOCAL_MACHINE\SOFTWARE\Datacap\Application\Location\'TopPath'
  The TopPath registry key does not exist by default
  Note: Datacap is under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node on an x64 OS.


• HKEY_LOCAL_MACHINE\SOFTWARE\Datacap\RRS\locations\'RRS'

If Taskmaster is fully installed on client:

1. Run Datacap Studio and close the application prompt.


2. Click the Settings button in upper-right corner.


3. The paths can be edited with:
   
   
   
   • RRS -> Rulerunner general settings ('RRS')
   
   
   • DCApp -> Main application management file ('TopPath')
   
   
   
   

Windows DSNs
Setup or configure DSNs in Data Sources to point to correct databases. Use %windir%\SysWOW64\odbcad32.exe on an x64 OS to view Data Sources.

Admin Database

• The DCO table's dco_setup values include a path to the setup hierarchy for each workflow, located in the xml file for the application, located at C:\Datacap\(application)\dc_(application).xml


• The Taskmod table's md_params column includes paths to BPPs which ideally are modified through Taskmaster Client in Settings -> Modules.


• Batch creation tasks like VScan will have a batch directory path in Settings | Workflow | <Task> | Setup | File, Task Settings.
  This is in the tasks table under ts_options and generally should not be modified directly in the database

Engine Database

• Batch directory paths in the tmbatch table's pb_batchdir column.


• If using a new engine database, the enginfo table's db_index value must match that in the admin database under adminfo table.


• The db_index is used in queue table under qu_admDB.

Fingerprint Database

• Connection to the fingerprint database is configurable in Taskmaster Application Manager, Fingerprint Database. Alternatively, the Fingerprint database connection can also be modified in the Zones tab of Datacap Studio by clicking the gear shaped icon below Fingerprint.


• The Template table will have paths to the CCO's and TIFF files in tp_CCOPath and tp_ImagePath

DotEdit, DotScan & Taskmaster Web
No paths or connection strings, but both have INI files that can specify some settings specific to either client. Some notes:

• INI files for DotEdit
  
  
  
  • \Datacap\DotEdit\apps.ini
  
  
  • \Datacap\DotEdit\DotEdit.ini
  
  
  
  


• INI files for DotScan
  
  
  
  • \Datacap\DotScan\apps.ini
  
  
  • \Datacap\DotScan\DotScan.ini
  
  
  
  


• INI file for Taskmaster Web
  
  
  
  • \Datacap\tmweb.net\apps.ini
  
  
  
  


• The DateTimeSeparator, which defaults to pound symbol (#), is changed to an apostrophe (') for SQL and Oracle admin/engine databases.


• Login to an application does not require that the application in question be listed in apps.ini.


• Taskmaster 7.x applications after upgrade & conversion may contain connection strings in apps.ini,

Taskmaster Application's APP File
The Taskmaster Application Service can be queried for specific settings stored in the application's .APP (APP) file. All of these settings should be changed/configured using the Taskmaster Application Manager.

Taskmaster Application's Processing Files
All paths in BPP, ICP and INI files in the \Datacap\<app>\dco_<workflow> folder can be modified. Some notes:

• The admin database's DCO table's dco_setup values must be identical to DCOSetup in the BPP if BPP uses the full non-relative path to the XML,


• Settings.ini may contain connection strings to fingerprint or other databases for custom actions.


• Where possible, the application service should be used instead.

Taskmaster 7.x applications after upgrade & conversion may contain a FingerprintConn variable in the setup hierarchy (e.g. APT.xml). The application should be updated to remove the variable from the XML and use the application service to query values instead. This also applies to Paths.ini, used by Smart Parameter @PATH(...) in certain actions. Application service is preferred instead.

Taskmaster Application's Rules
Rules are stored in \Datacap\<app>\dco_<workflow>\rules under various rule (RUL) files. Hard-coded paths and/or connection strings in the application rules can be configured through:

• Datacap Studio by going through the various rulesets, or by searching for specific actions like OpenConnection.


• Performing a search and replace against the *.RUL files.

Taskmaster 7.x applications after upgrade & conversion may need to be updated to take advantage of the application service wherever applicable.

How to configure Web Client to automatically import all files with IBM Datacap Taskmaster Capture?

When running Taskmaster Web Client from Datacap Taskmaster, If we want to have all the documents in a folder imported during the Scan task, rather than having to select each one individually.We have to  configure Web Client .

On the Scan page itself, set the following options:

• Check Multiple Files.


• Set Expected pages

How to configure IBM Datacap Taskmaster Capture to export index data and files to Content Manager On Demand (CMOD)?

CMOD has a component called ARSLOAD, which can input a flat index file that contains index data and locations of files that are to be uploaded with the index data. This file format specification can be found here.

A typical last stage of batch processing is the Export step, or task. The Export library actions can create flat files for consumption by external processes. This generic library will create flat text files of virtually any format. The generic nature of the library allows creation of index files that can be fed into many different systems. In this case, the Export library can be used to create output index files in a format required by CMOD ARSLOAD.

CMOD ARSLOAD File Format Review
To provide some context, here is a brief review of the required index file format for CMOD by looking at an example.

Index	Description
COMMENT:Your Comment Here	Multiple comment lines may be placed anywhere
CODEPAGE:819	The code page for the index file, 819 is Latin1
GROUP_FIELD_NAME:My FName	Custom field name
GROUP_FIELD_VALUE:My Value	Custom value
GROUP_FILENAME:C:\MyFile\Stuff.doc	File to upload
GROUP_LENGTH:0	Set 0 to grab whole file
GROUP_OFFSET:0	Starts at beginning of file

Note: Repeat GROUP_FIELD_NAME through GROUP_LENGTH for every file to upload.

Configuring Rules for CMOD ARSLOAD in Datacap Studio
The file is required to have a CODEPAGE specification and will occur once at the beginning of the file. The actions that will run once per batch have a ruleset that is attached in the open call at the batch level for the task. This is attached to the Datacap Object, DCO, in Datacap Studio.

Depending on how the application is created, the GROUP fields need to be executed for each document or each page. There will be a set of actions in a different rule that operate on the document or page level to perform the looping action to create the entries for each file to upload.

Lastly, the batch is closed at the end of the task. The close actions will be attached in the close of the batch in the DCO.

Below is an example set of Datacap Studio rules for an application that will create the output file for CMOD. Taskmaster application creation is very flexible, so the application may need alterations to the actions to fit needs.

The ExportFileHeader ruleset is attached at the batch level of the DCO hierarchy. The ruleset actions name the export file based on the batch ID, producing a uniquely named export file each time the application is run. It also places some comments and the required CODEPAGE line into the beginning of the export file. The export directory and filename can be customized along with desired comments in the file by changing the action parameters or adding additional actions to write more comments.

Here the ExportFileHeader ruleset is attached to the open event at the batch level in the DCO:


The ExportTheDocuments ruleset is attached at the page level for this application, specifically for the page type Other. An application can have multiple page types that it works with and the ruleset can be attached to only the types that are desired for export. For example, the application may have 4 types of pages, but only 2 types should be exported, so the rules would be attached to those two types:

In this example, the actions in the ExportTheDocuments ruleset are executed for each page. The application will want to have custom values for the field name and field values. They can be hard coded, as shown in the field name example, or values can be obtained at runtime using smart parameters, as is done in the field values example.

In virtually all cases, offset and length values of zero will be wanted, since this will cause the entire file to be uploaded. More comments may always be added to the export file in this ruleset. It is also possible to add actions to perform additional tests. For example, if only wanting to export pages that contained particular data, actions can be used to control what is placed into the file.

The CloseExportFile ruleset is attached at the batch level in the close event of the DCO hierarchy:

In this example, the ruleset has only one action, which closes the file. It is, of course, possible to add additional actions to this ruleset. For example, if wanting additional comments or data at the end of the file, actions could be added here to include the desired information.

Example Output File
Using the sample rules for this application, here is the resulting file:

COMMENT: Sample Output
CODEPAGE:819
GROUP_FIELD_NAME:TEST
GROUP_FIELD_VALUE:05.05.2011
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:c:\datacap\convert\batches\20110125.0111000000.jpg
GROUP_FIELD_NAME:TEST
GROUP_FIELD_VALUE:05.05.2011
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:C:\Datacap\Convert\batches\20110125.0111010000.tif
GROUP_FIELD_NAME:TEST
GROUP_FIELD_VALUE:05.05.2011
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:c:\datacap\convert\batches\20110125.0112000000.pdf
GROUP_FIELD_NAME:TEST
GROUP_FIELD_VALUE:05.05.2011
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:C:\Datacap\Convert\batches\20110125.0112010000.tif
GROUP_FIELD_NAME:TEST
GROUP_FIELD_VALUE:05.05.2011
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:C:\Datacap\Convert\batches\20110125.0112020000.tif
GROUP_FIELD_NAME:TEST
GROUP_FIELD_VALUE:05.05.2011
GROUP_OFFSET:0
GROUP_LENGTH:0
GROUP_FILENAME:C:\Datacap\Convert\batches\20110125.0112030000.tif

Application Specific Needs
This information should provide a start on developing application specific export rules for CMOD ARSLOAD. The rules and actions are highly flexible. Actions can be added to place more information into the file or to perform additional rules processing to control what data goes into the export file.

Many Taskmaster actions accept Smart Parameters. They are very flexible and allow dynamically changing the output data at runtime. The values can come from predefined settings or from runtime variables created specifically for the application.

Once the output file is created, the file can be fed into CMOD ARSLOAD, where it will read the file, and upload the specified files and index information.