Hi,
I am working on IBM Datacap RV2 reports. The Report Background Summary doesn't work correctly with my SQL database. The query that comes by default in the .rdlc file is
SELECT TOP 5000 COUNT(ts_BatchID) AS Batches, ts_JobName, ts_TaskName, ts_Status, ts_Station, SUM(ts_PagesInBatch) AS Pages, SUM(ts_DocsInBatch)
AS Documents, SUM(ts_ElapsedSec) AS Elapsed FROM taskstats WHERE ts_Status <> 'pending' GROUP BY ts_JobName, ts_TaskName, ts_Status, ts_Station
I broke the above SQL query into parts and realized that the column 'ts_DocsInBatch' is causing a problem. I have had erroneous values shown in that column. in my SQL database
Please check the screenshot attached herewith. The erroneous values are for ONLY those batches which NOT in pending status. So if I were to comment out the 'Where' clause, the SQL query fails .since the "SUM of (ts_DocsInBatch)" goes beyond the definition of 'Integral values'.
Is there any way we could get to the root cause of How the 'ts_DocsInBatch' column gets populated when a batch is being executed ?? Can I avoid the erroneous values from creeping into the database,?
Also I have checked all the other tables and columns in the Engine database this problem of wrong data values has not been seen anywhere else!
Let me know if other details are required.
Thank You.
Answer by Hrishikesh Gilda (151) | Dec 03, 2014 at 08:57 AM
Hi W.Darwish,
This is the response from the IBM team. I just tested this once. It worked fine. You may give a try.
Let me know if this doesn't work.
Our developer has provided a test module to address the erroneous number in RV2 report issue, please download the fix from ecurep FTP:
ftp://ftp.ecurep.ibm.com/fromibm/pmr/15467,756,000/RR_testModules_PMR15467.zip
Instructions on applying rulerunner.exe 8.1.0.94 and rrprocessor.exe 8.1.0.28 on TM 8.1 FP 2 system during a maintenance window:
1.Stop taskmaster applications, RuleRunner services and taskmaster services.
2.Make a copy of rulerunner.exe and rrprocessor.exe found in \Datacap\Taskmaster folder to a temp folder. (Do not rename or remove these modules from this folder)
3.Extract rulerunner.exe and rrprocessor.exe into \Datacap\Taskmaster folder.
4.Restart taskmaster services and taskmaster applications and RuleRunner Services.
Answer by Hrishikesh Gilda (151) | Oct 31, 2014 at 09:46 AM
Hi,
I figured out that when I execute a batch, the erroneous values I have mentioned above, creep into the database at the Profiler Step of custom application. IS there some way I can sort out this issue....
To describe further the Profiler step - recognition step; recognises documents i.e. whether a trailing page or an important form.... documents that are scanned
Let me know if any other details are needed. A screenshot of the Engine database is attached herewith.
Thank You.
Answer by MoizQ (2966) | Oct 31, 2014 at 09:11 PM
The client running rules is responsible for formatting the insert statement applicable to the statistics table during batch completion.
The standard is to count the number of document level nodes in the output page file -- this may be a shallow search, not accounting for nested elements depending on implementation. (I don't know off-hand.)
Assuming this supersedes everything else, and the fault lies there, accessing the PilotCtrl object and manually modifying the doc count property wouldn't make a difference, though you can explore it to confirm/deny.
What client ran the background task? Rulerunner? This may be a defect with that client, I suggest opening a PMR to start investigation and remediation; supplying a ready-to-replicate app would expedite the process significantly.
Answer by Hrishikesh Gilda (151) | Nov 03, 2014 at 10:20 AM
Hi MoizQ,
Thanks again for your response. The Profiler (Recognition step) was executed as an automated step from Rulerunner. This may be a defect with that client - did not understand what kind of a defect would it be with Rulerunner!
I am not accessing the PilotCtrl object (or I am probably not aware about this if Datacap does it in the background).
A PMR is already open on the issue, but it hasn't been of much help since the only possibility of an error, he says, is with my Custom application. And this is not under the scope of a PMR, it seems.
Hope to get some resolution either from the community here or the PMR.
Let me know if you need any other details. Thank You.
Answer by MoizQ (2966) | Nov 03, 2014 at 04:30 PM
Customization in general is not in scope of support, however using a non-foundation application by itself does not mean you are ineligible to receive assistance. There are additional factors determining that.
Are you doing something that could incur odd behavior? For example, are you doing manual updates to the taskstats -- posthumously or otherwise, modifying the PilotCtrl's properties, or something else that may be relevant? If so, it's incumbent upon you to prove those factors are unrelated (e.g. by removing customizations one by one).
In your case it doesn't seem like you are. It's always possible you are overlooking something, but support must work with you to help identify whether that (configuration problem) is the case or whether it is a product integrity problem. Most likely it's completely unrelated to your application, but an investigation should proceed.
You can help by removing any custom actions, etc., if feasible within a standalone / lower environment to help evaluate this. You can also provide your application to support to reproduce the problem. All in all, I think they should not defer this specific issue unless it's extremely clear that it's configuration related despite it being a non-foundation application.
Determining whether an issue is due to custom application development can be tricky, so there is room for error. I do not believe your PMR should be deflected. Follow up with the engineer assigned to your case and point to this forum thread for back up. If you continue to have trouble, you can ask for the duty manager to help clear up the misunderstanding.
Answer by Hrishikesh Gilda (151) | Nov 04, 2014 at 11:31 AM
Hi MoizQ,
Thanks for your response.
You are right. I am not modifying the PilotCtrl properties.
I will follow-up with the PMR and also investigate stuff from my end.
Answer by NSK55 (981) | Nov 06, 2014 at 08:51 PM
I suggest looking carefully at the task XML file (e.g. Profiler.xml) that is created after your Rulerunner task finishes, and compare it with other task XML files to see if the document structure looks OK. Are there in fact any documents (<D> nodes) or just pages? Furthermore, If you enable logging on the Taskmaster Server you should be able to see the query which updates the taskstats table just after the Rulerunner task runs. Presumably it will show that very strange large integer value. If you then enable maximal Rulerunner task logging you may be able to see the Pilot object represented as XML, alternatively the Rulerunner Service log may also show some info about the number of documents after the task runs.
Answer by Hrishikesh Gilda (151) | Nov 10, 2014 at 11:11 AM
Hi N SK55,
Thanks a lot for your response. A few results that we could delve into are here:
1. In the first screenshot - 97- Compare.... you can see that there is NO 'D' node in the PageID.xml file (PageID is the page Identification step) - So what exactly is the significance of this ?
2. I have attached the formatted log files - BEFORE the Profiler step and AFTER the Profiler step... The word files are attached herewith. What I observed is - the SQL query writes ts_DocsInBatch = '0' for all the 5 times it is run under PageId step. A similar SQL query writes ts_DocsInBatch = '2008074848' after the PROFILER step is executed.
A simple Ctrl+F of 'DocsInBatch' will lead you to all the spots I have highlighted.
3. The issue is the same across different Jobs and different documents - irrespective of whether the documents have been zoned earlier or not; and whether there are multiple documents or single.
b) It is the SAME erroneous number that gets logged into the Database table of taskstats - column DocsInBatch.
c) This same erroneous number is NOT seen in the Profiler_rrs.xml file anywhere; instead in all the "DocsInBatch" tags, I can only find 'ZERO'!
Let me know How I can resolve this. Thank You.
T
Answer by NSK55 (981) | Nov 10, 2014 at 02:51 PM
1. The significance of no <D> nodes before profiler is that the separation of pages into documents takes place in your Profiler task.
2. You seem to have identified a defect in Rulerunner, since it sends incorrect statistics to Taskmaster Server after the Profiler task. (unless there are actually 2 billion <D> (document) nodes in profiler.xml which seems unlikely).
3. You should utilize the support process to get resolution via the PMR that you opened. If you are not getting satisfactory or timely responses contact the support desk and ask to speak to a supervisor. Escalate the issue with your IBM sales / account representative. I am not aware of prior reports of this issue so there might be some unusual issue with your Datacap software installation.
Answer by Hrishikesh Gilda (151) | Nov 11, 2014 at 05:19 AM
Hi N SK55,
Thanks a lot for your inputs on the issue.
Ans 1) Ok. I got it now.
Ans 2) No. I could find just one 'D' node is most of my other Profiler.xml files too.... or two maximum.
Ans 3) Sure. I will continue pursuing the PMR thing.... and also keep you posted over here, if i find something useful.
Thanks again!