ERP 2.50:Functional Documentation/Alerts -1
Alerts are the way Openbravo ERP informs users about virtually any event that happens in the system and the administrator has defined a rule to show it.
The workflow for alerts is as follows:
- Administrator creates alert rules, which include a SQL clause defining the event that is going to be monitored and the recipients for the alerts.
- A background process is permanently checking if the conditions defined in each of the active alert rules return any line, in this case a new alert instance will be created for each of the returned lines.
- When a user logs in the application there is another process that constantly checks whether there are alert instances whose recipient is the current user and shows them to the user.
It is planned to increase alerts functionality with the Intrusive Alerts project.
Alert rules are the alert definitions, each alert instance is generated by an alert rule.
The main information an alert rule contains is:
The background process will execute this SQL clause, for each row it returns a new alert instance will be created with the obtained values.
I.e. if we want to know which partners have reached a credit limit, we will have to create a SQL that returns a row for each of these partners.
This SQL clause must return the following fields (that will fit the fields in the alert instance table):
- referencekey_id: Is the identifier of the record that triggered the alert. I.e. in the previous example, the referencekey_id would be the partner_id. It is not possible to have more than one active instance with the same referencekey for the same alert rule. This field enables navigable alert instances, because it should be the primary key of the record we want to navigate to in the defined tab (see below).
- record_id: This is a human readable record identifier. I.e. in the previous example this record identifier could be the partner name.
- description: A description for the alert instance,
- isActive: Only active instances will be taken into account, so usually it should be 'Y'.
- ad_role_id, ad_user_id, m_warehouse_id: Role, user and warehouse fields can be used at Filter Clause.
- ad_org_id, ad_client_id , created, createdBy, updated, updatedBy: These fields are used for audit purposes.
This clause is a where clause that will be applied to the already existing alert instances, in case the clause is not met the alerts will not be shown.
The purpose of this clause is to have the capability of taking into account session variables in order to know if an alert instance is going to be shown or not. For example, using filters you can display an alert only if the user has logged in to a specific warehouse (i.e. the warehouse inserted in the m_warehouse_id field in the alert instance).
Alert recipients define who will be able to see alert instances.
Recipients are defined as roles and users; the role attribute is mandatory while user is optional. If a user is specified, any user accessing the application with the role will see the alert instances of the alert rule; otherwise, the alert instance is displayed only to the specified user logging in with the specified role.
In addition, it is possible to check whether a mail will be sent to the recipients every time an alert instance is generated.
This section allows you to specify the tab to use as navigation target for the alert instance. The navigation will use the referencekey field as primary key of the record to navigate to.
For example, if your alert rule returns business partners exceeding a credit limit, you can specify here the Business Partner tab so that the recipients of the alert can navigate directly to the Business Partner window where the business partner triggering the rule is automatically retrieved.
A background process is executed permanently to check alert rules; it creates new alert instances whenever the SQL clause defined in the rule returns at least one record.
This process works as follows:
- For each active alert rule, the SQL clause is executed.
- For each row returned by the query, a new alert instance is created in case there is not any active alert instance for this rule with the same reference key value. If any of the rule recipients is checked to receive e-mail, a new mail is sent with all the new alert instances.
- Finally, all the alert active instances for this alert rule having a reference key that no longer appears in the returned rows will be set as inactive.
Alert instances are the actual alerts. They are what final users will be able to see and manage. They are created by the background process and are dependent of an alert rule.
There is a visualization process that checks if any of the existing active and non fixed alert instances has as recipient the user/role that has made login and meets the filter clause. All the instances with these conditions are counted and displayed to the user.
- As alerts use background process and it writes a log file in the tomcat main directory (tomcat/webapps/yourContext/WEB-INF/ by default) tomcat user must have write permission in this directory, otherwise no new alert instances will be created.