Page Comparison

...

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!

What Does It Do

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

Configuring

The new Reprocessing panel in the JEMH Auditing screen looks like this:Image Removed

...

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 applied saved before any related operations will work.

...

The lower half shows a status window. The three operation buttons are:

• Check Matches

  Test; will run the currently configured Processing Type, and indicate how many records matched, without actually doing anything

• Download list

  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

NOTE:

• 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.

Automated reprocessing

Here is an example Audit History view, showing a few exceptions and a contrived buggy outcome entry:Image Removed

...

Noting the maxId involved, the Reprocessing form is updated to reflect (maxID of 150), and setting the rule type to withException (must be applied).Image Removed

...

Checking rule matches

The matches to rules can be quickly checked:Image Removed

...

Click the Check Matches button updates the information, showing the rule applied and matches found, note that 2 were found as shown above.Image Removed

...

Download match list

For sanity, the matches can be downloaded as CSV by clicking the Download list button:Image Removed

...

Running the reanimation

Running the reanimation is just a click on the Run button:Image Removed

...

The process will be started in the background and a progress bar will by dynamically updated in the background:Image Removed

...

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:Image Removed

...

Manual Reprocessing

Its also possible to manually trigger reprocessing, but this doesn't 'clean up' the original entry as the rules driven reprocessing doImage Removed

...

Monitoring through REST

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

...