To set up alerts you must create an alert group. When end-users save a query as an alert, they must select an alert group for their alert. To avoid spam issues, real-time alerts cannot be sent directly through email as for scheduled alerts. Real-time alerts can only be sent to a web service that will handle processing and publishing.
This section describes the limitations and performance considerations you should be aware of when defining a real-time alert.
Limitations
The following constraints must be considered when defining a real-time alert:
• It takes only transformed UQL into account:
It means that refinements (i.e. facets) are not managed. An alert is published when a new document matches the query regardless of other refinements. You may use prefix handlers instead to restrict the query.
• Some UQL operators are not supported:
◦ Geo operators: distance, within.
◦ Separators: #sentence, #paragraph, #page
◦ Attributes: #uid, #around
◦ Other operators: INNERJOIN, FUZZYAND, SPLIT, XOR, BUTNOT
◦ Queries with both proximity and boolean operators. For example, (cat OR cats) NEAR (dog OR dogs)
• It is triggered at the end of the analysis pipeline, before semantic processing and mapping.
It means that the following objects are not managed:
◦ Metas stored in a dynamic field or renamed during mapping.
◦ Filters based on virtual expressions.
◦ Conditions set on entities built during the semantic processing (for example, named entities or related terms).
◦ Categories (for example, Top/Language/fr).
A workaround is to set a meta with the value of the meta you need to retrieve, directly in the analysis pipeline and before the Real-time alerting processor.
Performance considerations
When task queues are not used, real-time alerting increases the amount of analysis required on incoming documents. The first round of analysis checks whether an incoming document matches any real-time alerts, and then all documents must go through the normal analysis pipeline.
Queries with proximity operators (for example, NEAR, NEXT) have a more significant impact than queries with boolean operators (for example, AND, OR, NOT). As an example, 10 million rules using AND with 1 to 5 words need 1 GB RAM. Raw text processing speed reaches 2.5MB/s on a single core. Note that, as the number of rules increases, processing speed is gradually impacted.
Create a real-time alert group
An alert group allows to gather alerts sharing the same parameters.
A real-time alert group is defined by:
• a document processor (only if you are not using task queues).
• a security source. To save a query as an alert in the Mashup Builder, the end-user must be logged in.
• the web service address(es) or the custom publisher to publish the alert to.
Enable real-time alerting (only if you are not using task queues)
1. In the Administration Console, add a RealTimeAlerting document processor to the analysis pipeline.
The Alert groups field allows you to specify the alert group to which the real-time alerting applies. If no alert group is specified, it will apply to all real-time alert groups.
Create a real-time alert group
1. In the Business Console, go to Notification > Alerting.
2. On the Alert Group List, click Add.
3. In the Add Alert Group dialog box,
a. Enter a Name.
b. For Type, select Real time.
4. Select Use as default if you want this alert to be the default choice displayed to the user when clicking Save query as alert in the Mashup UI.
5. Enter a description.
6. For Security source, enter the security source name, for example, mysecurity.
◦ This is only required for saving alerts using the Mashup Builder alerting widgets. If building your own, or building a custom application, a security source is optional.
You must now specify how to publish the alert, either as a web service or using a custom publisher.
Publish real-time alerts
You can publish real-time alerts as a web service or using custom publishers.
Publish the alert to a web service
1. Still in the same alert group details, click Add Alert Publisher.
a. Enter a descriptive Name.
b. Select Push to Web service.
2. In Address, specify the URL for the web service.
3. Click Go Live.
Publish the alert using custom publishers
You can publish alerts using custom publishers for both real-time and scheduled alerting. For more information, see "Custom real-time publisher" in theExalead CloudView Programmer's Guide.
1. Still in the same alert group details, click Add Alert Publisher.
a. Enter a descriptive Name.
b. Select Custom.
2. In Class id, select your custom publisher.
3. Click Go Live.
Test real-time alerts
If you are using the RealTimeAlerting document processor and the task queue mode is not used, you can send a test document to the analysis pipeline to trigger the alert.
For more information, see "Testing your Analysis Pipeline Behavior" in the Exalead CloudView Configuration Guide.
Example - Web service and PHP scripts
Below is an example of web service in PHP. It allows to listen to POST requests in JSON format and save results to disk in a directory (here alerts_json/alert)