Emitting an event

You can emit an event from a rule agent. In the action part of a rule, you use the emit <an event> keyword to create an event that is sent out when the agent is triggered, if the conditions apply. The emitted event can then be processed by the agents that listen for this event type.

You specify the values of the new event instance that you want to create by using the where keyword. These values come from the attributes that are defined in the event type.

You do not need to specify the time stamp for the new event. The time stamp of the new event is set to the value of the parameter now.

Important: When an agent sends an event to itself, or when an agent creates a chain of events that ends up coming back to the same agent, the system can be compromised. Although Decision Server Insights has mechanisms that detect and prevent recursion beyond a predefined limit, it is not possible to detect all situations. For this reason, it is important to pay special attention to event flows that involve internal events.

Warning: If you emit an event in a rule that only has an if part and no when clause, this event is emitted every time that the rule is applied. You must make sure that the rule does not emit events unconditionally.

In the following example, when a bike station query event happens, a response event is emitted with the information from the bike station entity.

when a bike station query occurs
then
   print "BikeStation query rule received query for station [" + the name of 'the bike station' + "]";
   emit a new bike station query response where
      the available bike stands is the available bike stands of 'the bike station',
      the available bikes is the available bikes of 'the bike station',
      the last update is the last update of 'the bike station',
      the rider is the rider of this bike station query;

The following business rule is created in a rule agent that references an entity customer. When a customer event is received, a new coupon object is created for this customer entity, and a new event is sent out.

when a customer event occurs, called 'the event'
then
   add a new coupon where 
      the amount is 100, 
      the long description is the description of 'the event',
      the short description is "New coupon" to the coupons of 'the customer'; 
   emit a new coupon sent external where 
      the customer is 'the customer';

The following rule postpones the processing of the pizza order. If the status of the order is still "PRICED" after an hour and a half, it means that the pizza is not delivered yet. Then, the rule emits a free order event to compensate for the delay.

when a pizza order has occurred 1 hour 30 minutes ago
if
   the order status of ‘the order’ is PRICED
then
   emit a new free order where
   the amount is the price of 'the order',
   the customer is the customer of this pizza order,
   the order is 'the order',
   the message is "We apologize for the lateness of your order. It is on us!";

The following rule processes a pizza order. If the customer has the "GOLD" status, an event is created and emitted, so that the favorite supplement of the customer is added to the toppings of each pizza. This example shows how to emit an event that has a collection, represented here by the pizzas.

when a pizza event occurs
if
   the status of the customer of this pizza event is GOLD
then
   define 'bonus' as a new pizza bonus event ;
   for each pizza in the pizzas of the order of this pizza event :
   - add the favorite supplement of the customer of this pizza event to the toppings of this pizza
   - add this pizza to the pizzas of bonus ;
   emit bonus ;

Emitting an event to update a remote entity

When a remote entity needs to be updated, you can emit a notification event from one agent to another agent.

An agent can update only its bound entity. Remote entities that the agent references through relationships can be read, but not updated. The agent can detect that an update to a remote entity is required, and notify another agent by emitting an event.

The following rule listens for an abusive customer event and emits a new event to notify that the abusive customer must be added to a blacklist.

when an abusive customer occurs
then 
   emit a new add blacklist event where
      the customer is the customer of this abusive customer;

You cannot emit an event to update a remote entity that is initialized by this same event, because the event is emitted before the entity is initialized. The routing between the event and the entity is made before the entity is initialized, and it cannot resolve because the entity doesn't exist yet.

In the following example, the blacklist event has a customer id attribute. In the initialization statement, this attribute is used to initialize a customer entity from a blacklist event:

--- business model definitions ---
a customer is a business entity identified by an id.
a customer has a name.

an abusive customer is a business event.
an abusive customer has a customer id.

a blacklist event is a business event.
a blacklist event has a customer id.

--- initialization statement ---
a customer is initialized from a blacklist event , where this customer comes from the customer id of this blacklist event .

The blacklist event can then be emitted to update the customer id remote entity from the customer id of the abusive customer event. The customerentity of the blacklist event can then be initialized and updated from this customer id.

when an abusive customer occurs
then 
   emit a new add blacklist event where
      the customer id is the customer id of this abusive customer;