0025511: Performance problems with 2 alertrule created by ModuleScript: Issue21640WrongMatchInvAccounting

Openbravo Issue Tracking System - Openbravo ERP

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0025511

Openbravo ERP

09. Financial management

public

2014-01-20 09:50

2014-05-27 17:19

Reporter

shuehner

Assigned To

AtulOpenbravo

Priority

normal

Severity

major

Reproducibility

have not tried

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

Target Version

3.0PR14Q2

Fixed in Version

Merge Request Status

Review Assigned To

dmiguelez

OBNetwork customer

Web browser

Modules

Core

Support ticket

Regression level

Regression date

Regression introduced in release

Regression introduced by commit

Triggers an Emergency Pack

Summary

0025511: Performance problems with 2 alertrule created by ModuleScript: Issue21640WrongMatchInvAccounting

Description

This Modulescript creates 2 sql-based Alertrules whose execution is in many cases really slow (up to 20-30 seconds).

Technically this modulescript is inserting 2 ad_alertrule with its sql and then immediately executes those sql's to insert the needed ad_alert entries directly.

But as the ad_alertrule do exist and contain the sql they will be executed forever over and over again during the normal background alert processing.

Based on the description of the issue the purpose of those alerts is to check for wrong data created by some old accounting bug and to advise the user if any is found.

This means that after the check has been ran it is not needed to be ran again over the same data.

Disabling the sql in the alertrule would achieve that, as then the check would only be ran once (first time the modulescript is ran).

However this would switch of the part of marking the alerts as done automatically after the user did do the re-posting of the affected documents.

That could be avoided by special casing this in the modulescript. Adding a check if there art any alerts creating by this alertrule and then re-checking only those documents forever again (until the ad_alerts are deleted or marked as solved).

Steps To Reproduce

Proposed Solution

The ad_alertrule table has a 'type' column which is normally set to 'D' (data-driven, aka sql-based) having the usual semantics.

However there is also a type 'E' (external) which does nothing as a rule but exists so that some custom code can do the ad_alert inserts.

Note: That this type 'E' in practice has never been used so needs to be tested first if it works fine.

Assuming it does:
- The ModuleScript should be changed to insert the ad_alertrule with type 'E'
- For that it needs to 'find' it rules based on name instead of sql as the alertrule will no longer contain the sql.
- Furthermore the existing ad_alertrule created by previous execution of this modulescript should be changed from type=D to type=E and have their sql removed.

Note: It is important to have the sql-column empty as the current AlertProcess.java code filters for that when processing alerts and is not using the type=D.

Note when the last part of the description should be implemented code for this needs to be added to the modulescript to:
- get alertrule by from name
- select ad_alert for this ad_alertrule_id having status not yet solved
- for those docuents only, recheck the consistency with the sql.

Additional Information