IBM Datacap Taskmaster Capture Client Service is not processing batches

Problem(Abstract)

The Datacap Taskmaster Client Service has a started status, but is not processing any batches.

Resolving the problem

First, review the following logs for errors, warnings and other information around the incident time.

• Datacap Taskmaster Client Service logs
• Batch logs
• Windows Application and System Event logs

If the logs do not immediately show the root cause, ensure the following scenarios do not apply:

• Login ID and station ID used by the client service have insufficient permissions, including user/group Client(s) permissions, Taskmaster Sub (Client Service) permissions, and individual privileges to the job-task pairings for both user/group and station.
• The Datacap Taskmaster Client Service is connecting to the incorrect Taskmaster Server.
• There are multiple instances of process TMrt.exe on the client service machine. If more than one instance exists, stop the client service by terminating each instance of TMrt.exe, TMSub.exe, BPilot.exe and DCOProcessor.exe, and then start the service. Then monitor for recurrence and try to isolate the problem to specific batches or tasks; contact IBM Support for further assistance as necessary.

Why is an error received when IBM Datacap Taskmaster Client Service VScan accesses a remote directory?

Problem(Abstract)

IBM Datacap Taskmaster Client Service reports 'Folder ... does not exist' on the VScan rule action SetSourceDirectory(), where the directory path is a remote shared directory.

Symptom

• Remote shared directory is specified using UNC path such as \\server\share.
• Remote directory does exist.
• Taskmaster Client (thick client) works (without reporting the error).
• Taskmaster Client Service Logon User is set to a user having full permission to read/write to the remote directory.
• Remote share is a Unix-hosted file system.
• vscan_rrs.log reports Error: Folder '\\server\share' does not exist.

Cause

The Logon ID format is not accepted by the remote host.

Environment

Windows 2008

Resolving the problem

Change the Taskmaster Client Service Windows service Logon ID from a "User1@Domain" format to a "Domain\User1" format. For example, use the format FINANCE\jdoe instead of jdoe@FINANCE.local.

IBM Datacap Taskmaster Capture is allowing only one client connection at a time

Problem(Abstract)

Datacap Taskmaster client application is allowing only one connection at a time.

Cause

The UNC path of Taskmaster client application is missing in the Datacap.xml.

Resolving the problem

Putting the UNC path to the application in the Datacap.xml file will resolve the issue.

To add the UNC path to an app, the format is as follows:
<app name="appname" ref="\\servername\Datacap\appname"/>

Here is the content of the default datacap.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<datacap ver="8.0">
<app name="1040EZ" ref="1040EZ"></app>
<app name="Express" ref="Express"></app>
<app name="Flex" ref="Flex"></app>
<app name="Survey" ref="Survey"></app>
<app name="APT" ref="APT"></app>
<app name="MClaims" ref="MClaims"></app>
<app name="AppWizard" ref="DStudio\AppWizard"></app>
</datacap>

Here is the content of the default datacap.xml file with a UNC path for 1040EZ:
<?xml version="1.0" encoding="UTF-8"?>
<datacap ver="8.0">
<app name="1040EZ" ref="servername\1040EZ"/>
<app name="Express" ref="Express"></app>
<app name="Flex" ref="Flex"></app>
<app name="Survey" ref="Survey"></app>
<app name="APT" ref="APT"></app>
<app name="MClaims" ref="MClaims"></app>
<app name="AppWizard" ref="DStudio\AppWizard"></app>
</datacap>

Maximum connections reached with IBM Datacap Taskmaster Capture

Problem(Abstract)

Datacap Taskmaster client applications fail login to the Taskmaster Server service. Logging shows the following error:

Login failed. Taskmaster has reached the maximum allowed number [#] of stations

Symptom

Users are able to login to the application using same credentials but different station ID.

Cause

Certain rare events can leave an orphaned login within Taskmaster. If enough of these occur for a specific station, than any further logins from that station will fail, as no more connections are available. This requires that either the connections be reset or the maximum increased.

Resolving the problem

Reset the connections using Taskmaster Client (8.0.1 and earlier)

1. Make sure that no client applications are logged in from the station that will be reset.
2. Run Taskmaster Client. It can be run from any station including the one being reset.
3. Log in as admin or any other user with full rights.
4. Select Settings, Stations, and highlight the station to be reset.
5. Click Advanced, Reset.
6. Click Yes of the warning window.
7. Click OK, Apply, and Done to close the remaining windows.

Reset the connections using Taskmaster Web

1. Make sure that no client applications are logged in from the station that will be reset.
2. Run Taskmaster Web. It can be run from any station including the one being reset.
3. Log in as admin or any other user with full rights.
4. Select Administrator, Stations.
5. Select the station to be reset, then Clear Virtuals.

Increase the maximum connections using Taskmaster Client (8.0.1 and earlier)

1. Run Taskmaster Client. It can be run from any station including the one being reconfigured.
2. Log in as admin or any other user with full rights.
3. Select Settings, Stations, and highlight the station to be reconfigured.
4. Click Advanced.
5. Change Maximum number of virtual stations to 1000 or some other large value.
6. Click OK, Apply, and Done to close the remaining windows.

Increase the maximum connections using Taskmaster Web

1. Run Taskmaster Web. It can be run from any station including the one being reconfigured.
2. Log in as admin or any other user with full rights.
3. Select Administrator, Stations, and select the station to be reconfigured.
4. Change Max N to 1000 or some other large value.
5. Click save and exit the screen.

Why is FNP8_Upload failing when using IBM Datacap Taskmaster Capture?

Problem(Abstract)

In the export.log file, the following errors were listed:

15:04:43.931 (313) t:1278 p:5E24A68 Upload failed.
15:04:43.931 (0) t:1278 p:5E24A68 ERROR!!! N-2146233088
Error description = Error executing the batch operation

....

15:04:43.932 (0) t:1278 p:5E24A68 Error (385875969=hex:17000001). In CIMainAlgorithm::execute4DCO: Aborting: Action [FNP8_Upload] requested abort [api source:]

15:04:43.932 (0) t:1278 p:5E24A68 EXCEPTION: code="385875969" msg="Aborting: Action [FNP8_Upload] requested abort" loc="CIMainAlgorithm::execute4DCO" API=""

Cause

Upon further investigation, it was found that one of the property fields was a choice list. The export log showed that the property list was being set to "", which was not a valid selection according to the choice list definition on the customer's IBM P8 Content Engine (CE).

It was necessary to remove the blank field from the Datacap choice list and correct the spelling of all items in the Datacap choice list. The Datacap choice list and the CE choice list must be identical, since the CE is case sensitive when comparing choice list fields.

Diagnosing the problem

Review the export.log and find all of the document properties that are being set by the function FNP8_SetProperty. Determine which ones are choice lists and what the return value is from the operator input. Verify that the spelling is identical to the CE property definition. Be aware that the spelling is case sensitive.

Resolving the problem

After the Datacap choice list content's spelling was corrected to match the CE choice list, the export operated correctly.

Document Class not found exporting documents with IBM Datacap Taskmaster Capture

Problem(Abstract)

When committing documents to IBM FileNet P8 Content Engine, the export fails. The error in the Task log shows as:

15:21:39.984 (1000) t:E04 p:AC18C80 Upload failed.
15:21:39.984 (0) t:E04 p:AC18C80 ERROR!!! N-2146233088
Error description = An exception occurred while creating a folder: 'Class MyP8DocClass not found.'
Error Source = DC_P8_Server

Symptom

Viewing a list of the Document Classes shows that the class does exist.

Cause

The Symbolic Name, not the Display Name is used when exporting to P8 Content Engine from Datacap Taskmaster.

Resolving the problem

Change the parameter in the FNP8_SetDocClassId action to reference the Symbolic Name of the Document Class, not the Display Name.

Exported dates to IBM FileNet Content Engine are one day off in IBM Datacap Taskmaster Capture

Problem(Abstract)

Dates exported to IBM FileNet P8 Content Engine show yesterday's date when viewed by an IBM FileNet Content Engine client

Cause

IBM FileNet Content Engine stores all time stamps using UTC format. If a date is passed into IBM FileNet Content Engine with no time component then the time defaults to midnight UTC, which may indicate the prior date when converted back into local time.

Taskmaster does not convert or handle dates in GMT/UTC and thus any date values must be formatted by the application rules prior to export to IBM FileNet Content Engine

Resolving the problem

Modify the date/time value into proper GMT/UTC format of YYYY-MM-DDTHH:MM[:SS] and then add a time offset to account for the GMT time difference, e.g. YYYY-MM-DDTHH:MM:SS-HH:MM, prior to export to FileNet P8.

The action IsFieldDateWithReformat from the Validations library can be called with a parameter of "s" (no quotation marks) to format a local date/time value to UTC; a GMT offset can be appended to a UTC value with any standard action such as rrSet from the rrunner library.

Example 1:

Description	Field Value (Case A)	Field Value (Case B)
Data captured	05/31/2012 15:00	05/31/2012
IsFieldDateWithReformat(s)	2012-05-31T15:00:00	2012-05-31T00:00:00
rrSet(@F+-07:00,@F)	2012-05-31T15:00:00-07:00	2012-03-15T00:00:00-07:00

Here the initial field value is first transformed to UTC. The rrSet action is called to append the GMT offset "-07:00" to the field value.

Example 2:

Description	Field Value (Case A)	Field Value (Case B)
Data captured	05/31/2012 15:00	05/31/2012
IsFieldDateWithReformat(s)	2012-05-31T15:00:00	2012-05-31T00:00:00
rrSet(@F+@CHR(43)+07:00,@F)	2012-05-31T15:00:00+07:00	2012-03-15T00:00:00+07:00

Here the initial field value is first transformed to UTC. The rrSet action is called to append the GMT offset "+07:00" to the field value, @CHR is used to avoid conflict with the concatenation operator.

Note: IBM FileNet Content Engine may have a back end setting for Daylight Savings Time (DST), thus modifying the GMT offset to account for DST may not be necessary.