JEMH Audit History saves a copy of the email to disk, allowing further processing (as of JEMH 1.4.7!)
Audit History has collected a range of processing failures for a number of reasons:
An incorrectly formatted email may not be processable initially, but after serializing through audit history, is actually usable!
A configuration issue may have prevented processing the first time round
The outside chance that a bug in JEMH may have prevented correct processing!
Re-processing uses some (currently) hard-coded matching rules to determine what should be Reprocessed. A Reprocessed Audit History entry may or may not be marked 'Processed'. Currently the following Reprocessing options are available:
Marked as 'Processed' but no Created Issue or Commented Issue is present (possible result of a buggy regular expression, not noticeable pre 1.4.7)
Exception is present
The new Reprocessing panel in the JEMH Auditing screen looks like this:
The top form allows some rudimentary parameters to be set:
the Profile that should be used for the given email
the Reprocessing rule to be applied to locate emails
the MAX ID to be used (useful to limit the number processed in one go)
max attempts (not yet wired in)
Contents of the form must be saved before any related operations will work.
The lower half shows a status window. The three operation buttons are:
Test; will run the currently configured Processing Type, and indicate how many records matched, without actually doing anything
Export; will download a spreadsheet capable CSV text file containing pertinent information about the records involved
Run now; will execute processing with parameters from the form
Execution may take considerable time, picking a lower MAX ID initially will limit the period of loading
Every record processed will re-recreate a new Audit History record, including a copy of the related email. Watch disk consumption if processing large volumes of email.
If an email is processed due to rule matching, its audit history entry will be updated, indicating it is Reprocessed, and will refer to the new Audit Event ID that was the result of the reprocessing.
Here is an example Audit History view, showing a few exceptions and a contrived buggy outcome entry:
Noting the maxId involved, the Reprocessing form is updated to reflect (maxID of 150), and setting the rule type to withException (must be applied).
The matches to rules can be quickly checked:
Click the Check Matches button updates the information, showing the rule applied and matches found, note that 2 were found as shown above.
For sanity, the matches can be downloaded as CSV by clicking the Download list button:
Running the reanimation is just a click on the Run button:
The process will be started in the background and a progress bar will by dynamically updated in the background:
Refreshing the page will show the previous failed entries marked as Re-processed, and refer to the new ID of events for the post-processed entries:
Its also possible to manually trigger reprocessing, but this doesn't 'clean up' the original entry as the rules driven reprocessing do
When you have an active authorized http session, you can monitor what is going on through the browser:
http://server:8080/rest/jemh/1.0/api/auditing/reprocessing/status.json |
Result:
{"auditId":0,"percent":0,"processingStatus":"notRunning","recordsProcessed":0,"recordsToProcess":0} |
Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.
|