VET Improve escalation related error information for support teams

The current escalation system does not give administrators visibility of the number of errors that are encountered when an escalation runs. The lack of visibility means that administrators can create escalations without realising that they are failing for large numbers of the records that are expected to be processed.
If the numbers were recorded then automatic checks could be implemented e.g. to send a notification if an escalation hit a significant number of problems

This RFE proposes extending the escalation application to provide more information about the results of the escalation.
There are several potential levels of information that could be provided.
I am happy to create other RFEs if development decide to implement the functionality in parts.

Level 1
-------
Record the number of rows that were returned by the initial query – This would remove the need for support staff to go through the logs to identify if the escalation processed any records
Record the number of errors that were raised for the run. These would be fatal errors that prevented the record being processed.
Record the percentage of records that were successfully processed – Having this as a value means that it is easy to read

Level 2
-------
Create a KPI to show the top 10 escalations sorted by the percentage of failed records – this would allow system administrators to see which escalations they need to focus on
Customers could build this themselves but then everyone would have to go to the effort.

Include the crontask CID in the escalation history so support staff can quickly search for the related log entries.

Use an escalation specific prefix in the CID. Currently it is a CRON so it is referenced as CRON-. Replacing CRON with ESC would make it easier for support staff to instantly identify if the log message related to an escalation.

Level 3
-------
Create a CLOB/Long description field on the escalation and store the error messages for the records that failed.
Store the BMX code that was generated for analysis purposes. The last BMX code, or a list of the BMX codes for child exceptions, could be stored.
This would allow system administrators to assess how often a particular problem, e.g. invalid email address, was occurring and prioritise the most frequent ones that are causing log rollover.

This would allow system adminstrators to check for errors even if the logs have rolled over. It could also be used to check if the same records have failed in previous runs.

Build a BIRT report to show the details for the escalations so the administrators can act on it.
Include a seprate table that counts the number of records by BMX number.