Content Management and Capture

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Julian,

Did you checked the rulerunner logs after enabling flush buffer and detailed logging?

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Shaun,

thanks for encouraging me to further investigate the PDFFREDocumentToImage() issue. I figured out, that for some reason Interop.FREngine.dll could not be found by the Convert library. As a temporary workaround i copied it in the rules folder and that fixed that issue.

Manual stepping now shows me that the application crashes at several, not particularly reasonable points including SetNamePattern("2"). When the studio crashes i at least get a meaningfull entry in the windows event logs:

Application: DStudio.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 739ED9C2 (738F0000) with exit code 80131506.

The exit code indicates an ExecutionEngineException. I have been guaranteed (and i asked multiple times) that all kinds of anti virus measures are disabled for the time being, which would be the main suspect for this.

Given that the issue is 100% reproducible and only affects 2 out of 4 applications all using basically the same patterns (including naming patterns), i am reluctant to suspect something like physical or virtualized RAM or something like that either. Anyone ever experienced something like this or any ideas how to analyse this further?

As always many thanks and regards,
Julian

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Julian,

Are all 4 applications running in the same environment?

If 2 of them are running in a different environment, I suspect that either the installation in the environment that has the issue has become corrupt or that there are some components missing. If all 4 of them are running in the same environment, there could be subtle differences between them which surface the issue for 2 but not for all 4.

I've seen this type of issue previously, particularly where the Email and Electronic Documents Connector hadn't been installed:

https://www.ibm.com/support/pages/convertrrx-missing-custom-install-ibm-datacap-taskmaster-capture

(brought to mind by the fact that you copied the Interop.FREngine.dll to the rules folder and that resolved the PDFFREDocumentToImage issue).

I've also had issues trying to repair Datacap 9.1.9 or add missing features when fix packs have been installed :(

In a couple of cases, I've ended up having to uninstall Datacap completely and reinstall it, selecting and installing the missing components prior to running the Fix Pack installation.

Does that help?

Kind regards,

Shaun

Hi Shaun,

thanks for encouraging me to further investigate the PDFFREDocumentToImage() issue. I figured out, that for some reason Interop.FREngine.dll could not be found by the Convert library. As a temporary workaround i copied it in the rules folder and that fixed that issue.

Manual stepping now shows me that the application crashes at several, not particularly reasonable points including SetNamePattern("2"). When the studio crashes i at least get a meaningfull entry in the windows event logs:

Application: DStudio.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 739ED9C2 (738F0000) with exit code 80131506.

The exit code indicates an ExecutionEngineException. I have been guaranteed (and i asked multiple times) that all kinds of anti virus measures are disabled for the time being, which would be the main suspect for this.

Given that the issue is 100% reproducible and only affects 2 out of 4 applications all using basically the same patterns (including naming patterns), i am reluctant to suspect something like physical or virtualized RAM or something like that either. Anyone ever experienced something like this or any ideas how to analyse this further?

As always many thanks and regards,
Julian

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Shaun,

thanks again for your replies and solidarity :)

Same environment and we actually figured out the subtle difference between the applications. It is the usage of DocumentAnalytics-Actions from the Insight Edition that causes the batch to abort. I have further been able to get the sporadic problems i had with DStudio and now get the same crash after full processing of the task in both DStudio and RulerRunner:

Application: DStudio.exe (or RRProcessor.exe)
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
at DocumentAnalytics.TextAnalysis.Cleanup()
at DocumentAnalytics.Actions.Finalize()

Given that DocumentAnalytics shows up in current iFix Patch notes, i would assume there are systems out there, that successfully run DocumentAnalytics under 9.1.9. Maybe someone here knows of some settings i missed?

Best Regards,
Julian

Hi Julian,

Are all 4 applications running in the same environment?

If 2 of them are running in a different environment, I suspect that either the installation in the environment that has the issue has become corrupt or that there are some components missing. If all 4 of them are running in the same environment, there could be subtle differences between them which surface the issue for 2 but not for all 4.

I've seen this type of issue previously, particularly where the Email and Electronic Documents Connector hadn't been installed:

https://www.ibm.com/support/pages/convertrrx-missing-custom-install-ibm-datacap-taskmaster-capture

(brought to mind by the fact that you copied the Interop.FREngine.dll to the rules folder and that resolved the PDFFREDocumentToImage issue).

I've also had issues trying to repair Datacap 9.1.9 or add missing features when fix packs have been installed :(

In a couple of cases, I've ended up having to uninstall Datacap completely and reinstall it, selecting and installing the missing components prior to running the Fix Pack installation.

Does that help?

Kind regards,

Shaun

Hi Shaun,

thanks for encouraging me to further investigate the PDFFREDocumentToImage() issue. I figured out, that for some reason Interop.FREngine.dll could not be found by the Convert library. As a temporary workaround i copied it in the rules folder and that fixed that issue.

Manual stepping now shows me that the application crashes at several, not particularly reasonable points including SetNamePattern("2"). When the studio crashes i at least get a meaningfull entry in the windows event logs:

Application: DStudio.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 739ED9C2 (738F0000) with exit code 80131506.

The exit code indicates an ExecutionEngineException. I have been guaranteed (and i asked multiple times) that all kinds of anti virus measures are disabled for the time being, which would be the main suspect for this.

Given that the issue is 100% reproducible and only affects 2 out of 4 applications all using basically the same patterns (including naming patterns), i am reluctant to suspect something like physical or virtualized RAM or something like that either. Anyone ever experienced something like this or any ideas how to analyse this further?

As always many thanks and regards,
Julian

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Julian,

I haven't used the DocumentAnalytics actions in DC 9.1.9 yet.

Are you able to share a screenshot of the ruleset that causes the crash? Or say which action(s) cause it?

I've noticed this entry in the Release Notes for iFix004 and I wonder whether this is the issue you're facing:

Hi Shaun,

thanks again for your replies and solidarity :)

Same environment and we actually figured out the subtle difference between the applications. It is the usage of DocumentAnalytics-Actions from the Insight Edition that causes the batch to abort. I have further been able to get the sporadic problems i had with DStudio and now get the same crash after full processing of the task in both DStudio and RulerRunner:

Application: DStudio.exe (or RRProcessor.exe)
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
at DocumentAnalytics.TextAnalysis.Cleanup()
at DocumentAnalytics.Actions.Finalize()

Given that DocumentAnalytics shows up in current iFix Patch notes, i would assume there are systems out there, that successfully run DocumentAnalytics under 9.1.9. Maybe someone here knows of some settings i missed?

Best Regards,
Julian

Hi Julian,

Are all 4 applications running in the same environment?

If 2 of them are running in a different environment, I suspect that either the installation in the environment that has the issue has become corrupt or that there are some components missing. If all 4 of them are running in the same environment, there could be subtle differences between them which surface the issue for 2 but not for all 4.

I've seen this type of issue previously, particularly where the Email and Electronic Documents Connector hadn't been installed:

https://www.ibm.com/support/pages/convertrrx-missing-custom-install-ibm-datacap-taskmaster-capture

(brought to mind by the fact that you copied the Interop.FREngine.dll to the rules folder and that resolved the PDFFREDocumentToImage issue).

I've also had issues trying to repair Datacap 9.1.9 or add missing features when fix packs have been installed :(

In a couple of cases, I've ended up having to uninstall Datacap completely and reinstall it, selecting and installing the missing components prior to running the Fix Pack installation.

Does that help?

Kind regards,

Shaun

Hi Shaun,

thanks for encouraging me to further investigate the PDFFREDocumentToImage() issue. I figured out, that for some reason Interop.FREngine.dll could not be found by the Convert library. As a temporary workaround i copied it in the rules folder and that fixed that issue.

Manual stepping now shows me that the application crashes at several, not particularly reasonable points including SetNamePattern("2"). When the studio crashes i at least get a meaningfull entry in the windows event logs:

Application: DStudio.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 739ED9C2 (738F0000) with exit code 80131506.

The exit code indicates an ExecutionEngineException. I have been guaranteed (and i asked multiple times) that all kinds of anti virus measures are disabled for the time being, which would be the main suspect for this.

Given that the issue is 100% reproducible and only affects 2 out of 4 applications all using basically the same patterns (including naming patterns), i am reluctant to suspect something like physical or virtualized RAM or something like that either. Anyone ever experienced something like this or any ideas how to analyse this further?

As always many thanks and regards,
Julian

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Shaun,

the two Actions in question are CopyAllBlocks() and AnalyzeLayout(). I am still a little unsure if above error message is symptomatic or causal to our problems (dotnet not being able to clean up after crash or not being able to clean up causes the crash).

I have not found strong candidates in the iFix04 patch notes, but the module has been touched in some way. So yeah - iFix04 would be next in line to try out.

Maybe I should experiment, if other Actions of that module have similar impact and if other tasks can be affected in the same way first. Either way, i will have a look :)

Many thanks an best regards,

Julian

Hi Julian,

I haven't used the DocumentAnalytics actions in DC 9.1.9 yet.

Are you able to share a screenshot of the ruleset that causes the crash? Or say which action(s) cause it?

I've noticed this entry in the Release Notes for iFix004 and I wonder whether this is the issue you're facing:

Hi Shaun,

thanks again for your replies and solidarity :)

Same environment and we actually figured out the subtle difference between the applications. It is the usage of DocumentAnalytics-Actions from the Insight Edition that causes the batch to abort. I have further been able to get the sporadic problems i had with DStudio and now get the same crash after full processing of the task in both DStudio and RulerRunner:

Application: DStudio.exe (or RRProcessor.exe)
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
at DocumentAnalytics.TextAnalysis.Cleanup()
at DocumentAnalytics.Actions.Finalize()

Given that DocumentAnalytics shows up in current iFix Patch notes, i would assume there are systems out there, that successfully run DocumentAnalytics under 9.1.9. Maybe someone here knows of some settings i missed?

Best Regards,
Julian

Hi Julian,

Are all 4 applications running in the same environment?

If 2 of them are running in a different environment, I suspect that either the installation in the environment that has the issue has become corrupt or that there are some components missing. If all 4 of them are running in the same environment, there could be subtle differences between them which surface the issue for 2 but not for all 4.

I've seen this type of issue previously, particularly where the Email and Electronic Documents Connector hadn't been installed:

https://www.ibm.com/support/pages/convertrrx-missing-custom-install-ibm-datacap-taskmaster-capture

(brought to mind by the fact that you copied the Interop.FREngine.dll to the rules folder and that resolved the PDFFREDocumentToImage issue).

I've also had issues trying to repair Datacap 9.1.9 or add missing features when fix packs have been installed :(

In a couple of cases, I've ended up having to uninstall Datacap completely and reinstall it, selecting and installing the missing components prior to running the Fix Pack installation.

Does that help?

Kind regards,

Shaun

Hi Shaun,

thanks for encouraging me to further investigate the PDFFREDocumentToImage() issue. I figured out, that for some reason Interop.FREngine.dll could not be found by the Convert library. As a temporary workaround i copied it in the rules folder and that fixed that issue.

Manual stepping now shows me that the application crashes at several, not particularly reasonable points including SetNamePattern("2"). When the studio crashes i at least get a meaningfull entry in the windows event logs:

Application: DStudio.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 739ED9C2 (738F0000) with exit code 80131506.

The exit code indicates an ExecutionEngineException. I have been guaranteed (and i asked multiple times) that all kinds of anti virus measures are disabled for the time being, which would be the main suspect for this.

Given that the issue is 100% reproducible and only affects 2 out of 4 applications all using basically the same patterns (including naming patterns), i am reluctant to suspect something like physical or virtualized RAM or something like that either. Anyone ever experienced something like this or any ideas how to analyse this further?

As always many thanks and regards,
Julian

Hi Julian

Thanks for sharing the XML and log files. The PDFConversion.xml file doesn't display, but the other files provide a good overview of the process. You should be able to run this in Datacap Studio, unless there's a Branch operation (see my screenshot from TravelDocs). Branching and splitting of batches was never implemented in Studio. 

I've worked on a couple of projects recently using DC9.1.9 iFix03 which leverage PDFFREDocumentToImage() and have been able to execute this in Studio with no issues.

My thinking is that if you're able to run the PDFConversion task profile in the Studio Test tab and it aborts, you should be able to see exactly which action causes the failure.

Kind regards,

Shaun

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

Your pdf coversion rrs log was cut short and didn't see the error.  I can see profile is the longest.

You are calling the release engine which is good. Try having just one thread and reprocess just this  task.  See if it complete.

If Rule runner is saturated try configuring the restart after batch execution to help rulerunner memory. 

https://www.ibm.com/docs/en/datacap/9.1.9?topic=service-configuring-rulerunner-restart-after-batch-execution

Total Profile Rule     esec:'18.10156'

------------------------------
Blue Devil

Original Message:
Sent: Thu September 28, 2023 04:33 AM
From: Julian Fiegenbaum
Subject: Datacap RuleRunner aborts after successful Task

Hi Shaun,

thanks for your comments! I uploaded the runtime-xml, the rulesets and the complete log. The step is really mostly the start of the process, where a pdf is split into tifs and recognized.

It is reproducible every time. I'm not quite sure what to make of the DocsInBatch - the PDFConversion.xml correctly shows a properly built structure. Doesn't the runtime-xml get updated after the task is fully processed (at least in this case the task is fully processed, but still the old page file is referenced)? In that case the 0 documents (not yet created) and 1 page (other) makes sense as we are at the start of the job.

I can not process the task in DatacapStudio as PDFFREDocumentToImage (and the corresponding release) is used and as far as i know (seen multiple client systems) this leads to an error in DatacapStudio.

Many thanks and regards,

Julian

------------------------------
Julian Fiegenbaum | ISR Information Products AG | Consultant | Germany

Original Message:
Sent: Wed September 27, 2023 06:09 AM
From: Shaun McDowall
Subject: Datacap RuleRunner aborts after successful Task

Hi Julian,

Without seeing the application and corresponding runtime XML it's difficult to visualise the possible cause of the abort.

The log seems to suggest that no actions are being executed but perhaps that is due to the log level that has been set?

I did notice this:

<P n="DocsInBatch">0</P>

Which suggests that there are no documents in the batch and I wonder if that is the cause of the abort?

Are you able to share the PDFConversion.xml?

Is this reproducible (i.e. does it occur every time you execute this batch via Rulerunner)? If it's intermittent, it will be more difficult to troubleshoot.

If it is reproducible, does the same batch abort when you run it in Datacap Studio?

Many thanks,

Shaun

------------------------------
Shaun McDowall

Original Message:
Sent: Tue September 26, 2023 09:52 AM
From: Julian Fiegenbaum
Subject: Datacap RuleRunner aborts after successful Task

Hi Varun,

for some reason i was not aware of this functionality in the RRS log. I activated it and now the log gets fully written, which is great - thank you :) I'll edit the original post to reflect that change in information.

Sadly still no error/exception to be found :(

------------------------------
Julian Fiegenbaum | ISR Information Products AG | Consultant | Germany

Original Message:
Sent: Tue September 26, 2023 09:03 AM
From: Varun Gupta
Subject: Datacap RuleRunner aborts after successful Task

Hi Julian,

Did you tried to use the Flush buffer option for RRS logs to flush out the logs?

------------------------------
Varun Gupta

Original Message:
Sent: Tue September 26, 2023 05:21 AM
From: Julian Fiegenbaum
Subject: Datacap RuleRunner aborts after successful Task

Hello community,

we currently have a problem with aborting Batches after migrating from Datacap 9.1.6 to 9.1.9 iFix 03. After successfully finishing a task, the batch status gets set to 'aborted' instead of 'finished'. This reliably happens in two out of our four applications at specific tasks. The only commonality shared by these tasks i can see is the usage of Abby OCR, but that is used in the other applications as well, which work just fine.

The last action of the last rule of the last ruleset gets executed.Then the batch is aborted. Task status and pageFile.xml are not updated and the last buffered content for the rrs-log is not written to disk. So if there was an error message, it does get lost.

There are no error/exception to be found in rrs batch-logs, RuleRunner thread logs or RuleRunner service logs. It is not IO28998 - the 64bit dlls are not used, which can be affirmed in the logs.

Have you ever had something like this? Or any ideas how to analyse further?

Many thanks and best regards,

Julian

------------------------------
Julian Fiegenbaum | ISR Information Products AG | Consultant | Germany
------------------------------