Examples of event rules for system functions

Introduction

The document describes examples of event rule configuration for event processing automations for the system. Details of the general event configuration are described in the 'howto' documentation in the documentation portal.

Email notification and assigning a person to a service event

  • Title: Assigned service event

  • Description: Sends an email for a newly assigned person.

  • Email title: A service event numbered #{{obj.eventNumber}} has been assigned

  • Email: You have been assigned a product service incident: {{obj.product.name}}

Rule type: change, object: service event, effector: notifications

Efector

Subject: service event number #{{obj.eventNumber}} has been assigned

Content: You have been assigned a product service incident: {{obj.product.name}}}

That will substitute the event number and product name in the templates. Comparison of UUID assigned before and now. Test positive only if the UUID has changed and if the assigned one is non-empty (comparison != supports both undefined and null.

Getting the email assigned and checking that it is not empty and that the "@" character occurs at character 2 or further (indexOf returns -1 if the character does not occur or the character index). This is not a fully correct validation, but it is a basic check. If the mail is OK, it is added to the mails array of the data object (which will later be rebuilt into an effector data object), and that’s where the script will stop. If it is not, an exception will be thrown (a message formatted using the built-in template mechanism) that the user with the given login does not have an email set, so the message cannot be sent.

check

(function(){
    var assignedUuid=_.get(ctx,"obj.assigned.uuid");
    var oldAssignedUuid=_.get(ctx,"oldObj.assigned.uuid");
    return (assignedUuid!=null) && (assignedUuid!=oldAssignedUuid);
})();

prepare

var assignedMail=_.get(ctx,"obj.assigned.employeeData.email");
if(
    (assignedMail!=null) &&
    (assignedMail.indexOf("@")>0)
) {
    data.mails.push(assignedMail);
}
else {
   logger.info("mail rejected: "+assignedMail);
   throw templating.render("User {{obj.assigned.login}} has no email address set!",ctx);
}

Customer notification of a service event

  • Title: Notify the customer of a service event

  • Description: Send an email to the client when the event status changes to resolved

  • Email title: service event number #{{obj.eventNumber}} has been resolved

  • Email message: the service event for product {{obj.product.name}} has been resolved.

  • Usage: Rule type: change, object: service event, effector: notifications

Effector

Subject: service event number #{{obj.eventNumber}} has been resolved

Message: the service event for product {{obj.product.name}} has been resolved.

Thanks to this, the event number and product name will be replaced in the template. The check rule verifies the public status of the event for the current and previous version of the object. A positive test occurs only if the current state is RESOLVED (the comparison != supports both undefined and null objects.)

The preparation rule retrieves the client’s email and checks whether it is not empty and whether the '@' character is present on the second or subsequent character (indexOf returns -1 if the character does not exist or returns the index on which the character occurs). That is not a full check, but it is sufficient for basic verification. If the email is OK, it is added to the list of emails to be sent and then the script will exit. If not, an exception will be thrown with the internal formatting of the message due to no email address defined for the client, so the message cannot be sent.

check

(function(){
  var currentState =_.get(ctx,"obj.state.publicState");
  var oldState = _.get(ctx,"oldObj.state.publicState");
  return (currentState == "RESOLVED") && (currentState != oldState);
})();

prepare

var customerMail=_.get(ctx,"obj.eventManager.customer.email");
if(
    (customerMail!=null) &&
    (customerMail.indexOf("@")>0)
) {
    data.mails.push(customerMail);
}
else {
    logger.info("mail rejected: " + customerMail);
    throw templating.render("Customer {{obj.eventManager.customer.name}} has no email address set!",ctx);
}

The connection of the device in the aggregator is not working

  • Title: Aggregator not working

  • Description: Checks the status of the connection to the aggregator

  • Email title: Aggregator "{{obj.name}}" is not working

  • Email message: Aggregator "{{obj.name}}" is not responding. Last communication date: {{lastCommunicationDate}}

  • Usage: Scheduler

You need to activate a task that periodically checks communication with the aggregators. The appropriate scheduler must be enabled.

Effector

Title: Aggregator "{{obj.name}}" is not working

Message: Aggregator "{{obj.name}}" is not responding. Last communication date: {{lastCommunicationDate}}

It is worth noting the lastCommunicationDate value, which by default is not present in the context, but is instead inserted into it by the check rule.

prepare

blank

check

(function() {
	if(ctx.detailedEventType != "aggregator_device_failure") {
		return false;
	}
We // check if there are objects of interest in the additional data
// for example, an energy meter with serial number 523-000034
if (additionalData) {
}
return true;
return false;
// Gets the date (as epoch ms) and converts to the string YYYY-MM-DD; HH:mm:ss
var lastComm = _.get(ctx, "obj.lastCommunicationDate");
var lastCommStr = "never";
if(lastComm) {
	var date = new Date(lastComm);
	lastCommStr = date.getFullYear(); //YYYY
	lastCommStr += "-";
	lastCommStr += ("00" + (date.getMonth()+1)).substr(-2,2); //MM
	lastCommStr += "-";
	lastCommStr += ("00" + date.getDate()).substr(-2,2); //DD
	lastCommStr +="; "
	lastCommStr += ("00" + date.getHours()).substr(-2,2); //HH
	lastCommStr +=":"
	lastCommStr += ("00" + date.getMinutes()).substr(-2,2); //mm
	lastCommStr +=":"
	lastCommStr += ("00" + date.getSeconds()).substr(-2,2); //ss
}
	ctx.lastCommunicationDate = lastCommStr
	return true
})()

Aggregator not working

  • Title: Aggregator not working

  • Description: Checks the status of the connection to the aggregator

  • Email title: Aggregator "{{obj.name}}" is not working

  • Email message: Aggregator "{{obj.name}}" is not responding. Last communication date: {{lastCommunicationDate}}

  • Using a scheduler: You need to activate a task that periodically checks communications with aggregators. The appropriate scheduler should be enabled.

Effector

Title: Aggregator "{{obj.name}}" is not working

Message: Aggregator "{{obj.name}}" is not responding. Last communication date: {{lastCommunicationDate}}

It is worth noting the lastCommunicationDate value, which by default is not present in the context, but is instead inserted into it by the check rule.

prepare

blank

check

(function() {
if(ctx.detailedEventType != "aggregator_failure") {
	return false;
}
// Gets the date (as epoch ms) and converts to the string YYYY-MM-DD; HH:mm:ss
	var lastComm = _.get(ctx, "obj.lastCommunicationDate");
	var lastCommStr = "never";
	if(lastComm) {
		var date = new Date(lastComm);
		lastCommStr = date.getFullYear(); //YYYY
		lastCommStr += "-";
		lastCommStr += ("00" + (date.getMonth()+1)).substr(-2,2); //MM
		lastCommStr += "-";
		lastCommStr += ("00" + date.getDate()).substr(-2,2); //DD
		lastCommStr +="; "
		lastCommStr += ("00" + date.getHours()).substr(-2,2); //HH
		lastCommStr +=":"
		lastCommStr += ("00" + date.getMinutes()).substr(-2,2); //mm
		lastCommStr +=":"
		lastCommStr += ("00" + date.getSeconds()).substr(-2,2); //ss
	}
ctx.lastCommunicationDate = lastCommStr
return true
})()

Create a complaint

  • Title: Creation of a complaint

  • Description: Sends an email to the person who created the orders associated with this complaint

  • Email title: Complaint with a number {{obj.number}} has been created

  • Email message: complaint with number {{obj.number}} has been created

  • Usage: Rule type: change, object: complaint, effector: notification

Effector

Subject: complaint with {{obj.number}} has been created

Message: Complaint with a number {{obj.number}} has been created

With this, the claim number will be replaced in the templates. The check rule processes and compares the current and previous claim state. Only a positive test will be when the claim state has changed and the current state is CREATED. The preparer rule takes the email from the person who created the related order (by delivery) and checks that it is not empty and the "@" character appears and the second or next character (indexOf returns -1 if the character is not present in the string). This is not a fully valid check, just a basic one. If the email is OK, it is added to the list of email addresses in the data object (which will be embedded in the effector object).

Then the script will exit. If not, an exception will be thrown (message formatted according to the internal template mechanism) with information which user login does not have a defined email address.

Available complaint states: CREATED, READY, SENT, IN_PROGRESS, VALID, INVALID, CLOSED;

check

function(){
  var currentState =_.get(ctx,"obj.complaintState");
  var oldState = _.get(ctx,"oldObj.complaintState");
return ((currentState == "CREATED") || currentState == "READY") &&  (currentState != oldState);
})();

prepare

var createdByMail =_.get(ctx, "obj.delivery.orderDocument.createdBy.employeeData.email");
if(
  (createdByMail != null) &&
  (createdByMail.indexOf("@")>0)
) {
  data.mails.push(createdByMail);
}
else {
  logger.info("mail rejected: " + createdByMail);
  throw templating.render("User  \"{{obj.delivery.orderDocument.createdBy.login}}\" does not have assigned  email address!",ctx);
}

Delivery status change

  • Title: Checked Delivery

  • Description: Sends an email to the person who created the orders associated with this delivery

  • Email title: delivery with a number {{obj.number}} has been checked on site

  • Email message: delivery with a number {{obj.number}} has been checked at the site

  • Usage: Rule: change, object: delivery, effector: notification

Effector

Subject: delivery with the number {{obj.number}} has been checked on site

Message: delivery with a number {{obj.number}} has been checked at the site

With this, the delivery number will be replaced in the templates. The check rule processes and compares the current and previous claim state. Only a positive test will be if the delivery status has changed and the current status is DELIVERED or REMARKS.

The preparer rule takes the email from the person who created the associated order (by delivery) and checks that it is not empty and the "@" character appears and the second or next character (indexOf returns -1 if the character is not present in the string). That is not a fully valid check, just a basic one. If the email is OK, it is added to the list of email addresses in the data object (which will be embedded in the effector object). The script will then terminate. If not, an exception will be thrown (a message formatted according to the internal templating mechanism) stating which user login does not have a defined email address.

Available delivery states: LOADING_ON_SITE, IN_TRANSIT, DELIVERED, REMARKS;

check

function(){
  var currentState =_.get(ctx,"obj.deliveryState");
  var oldState = _.get(ctx,"oldObj.deliveryState");
  return ((currentState == "DELIVERED") || (currentState == "REMARKS")) &&  (currentState != oldState);
})();

prepare

var createdByMail =_.get(ctx, "obj.orderDocument.createdBy.employeeData.email");
if(
  (createdByMail!=null) &&
  (createdByMail.indexOf("@")>0)
) {
  data.mails.push(createdByMail);
}
else {
  logger.info("mail rejected: "+createdByMail);
  throw templating.render("User \"{{obj.orderDocument.createdBy.login}}\" does  not have assigned email address!",ctx);
}

Order status change

  • Title: Order accepted

  • Description: Sends an email to the person who created the order if the order is accepted by the responsible person

  • Email title: Order number {{obj.number}} has been created

  • Email message: Order with a number {{obj.number}} has been created

  • Usage: Rule: change, object: order, effector: notification

Effector

Subject: Order with number {{obj.number}} has been created

Message: Order with a number {{obj.number}} has been created

With this, the order number will be replaced in the templates. The check rule processes and compares the current and previous claim state. Only a positive test will be when the order status has changed and the current status is ACCEPTED.

The preparer rule takes the email from the person who created the associated order (by delivery) and checks that it is not empty and the "@" character appears and the second or next character (indexOf returns -1 if the character is not present in the string). That is not a fully valid check, just a basic one. If the email is OK, it is added to the list of email addresses in the data object (which will be embedded in the effector object). The script will then terminate. If not, an exception will be thrown (a message formatted according to the internal templating mechanism) stating which user login does not have a defined email address.

Available order states: CREATED, READY, ACCEPTED, ORDERED, CONFIRMED, IN_TRANSIT, DELIVERED, CLOSED, REJECTED;

check

(function(){
  var currentState =_.get(ctx,"obj.orderState");
  var oldState = _.get(ctx,"oldObj.orderState");
  return (currentState == "ACCEPTED") && (currentState != oldState);
})();

prepare

var createdByMail =_.get(ctx, "obj.createdBy.employeeData.email");
if(
  (createdByMail!=null) &&
  (createdByMail.indexOf("@")>0)
) {
  data.mails.push(createdByMail);
}
else {
  logger.info("mail rejected: "+createdByMail);
  throw templating.render("User \"{{obj.createdBy.login}}\" does not have  assigned email address!",ctx);
}

Notification that a task/work order has been created and assigned to a person

In this case, we send an email to the person who is assigned to the event. We do not limit sending to specific tasks - all tasks are sent (see check rule).

Operation: CREATE

Subject: A new {{obj.name}} task has been created.

prepare

var   assignedMail=_.get(ctx,"obj.assignedUser.employeeData.email");

if(
    (assignedMail!=null) &&
    (assignedMail.indexOf("@")>0)
) {
    data.mails.push(assignedMail);
}
else {
   logger.info("mail rejected: "+assignedMail);
   throw templating.render("Użytkownik \"{{obj.assignedUser.login}}\" nie ma ustawionego adresu e-mail!",ctx);
}

check

(function(){
     return true;
 })();

Notification of assignment to a task/work order

In this case, we send the data to the assigned person. We do this when the record is updated. We do this only when the newly assigned person (here identified by UUID) is different from the person who was previously assigned (before saving changes to the record).

Operation: UPDATE

`Title/Content: You have been assigned to the task {{obj.name}}

check

(function(){
     var assignedUuid=_.get(ctx,"obj.assignedUser.uuid");
     var oldAssignedUuid=_.get(ctx,"oldObj.assignedUser.uuid");
     return (assignedUuid!=null) && (assignedUuid!=oldAssignedUuid);
 })();

prepare

if(
    (assignedMail!=null) &&
    (assignedMail.indexOf("@")>0)
) {
    data.mails.push(assignedMail);
}
else {
   logger.info("mail rejected: "+assignedMail);
   throw templating.render("Użytkownik \"{{obj.assignedUser.login}}\" nie ma ustawionego adresu e-mail!",ctx);
}

Notification that an ISO registry has been created and assigned to a person

New corrective action → to assigned (if different from submitter). The system will check new records - in this case, corrective actions and send an email to the person who is assigned. The system will NOT send an email if the reporting person is the same as the assigned person. See the check script to verify this person.

Object type: mod.AssetApi.model.special.energyenvironment.CorrectionAction

Operation: CREATE

Title: New Corrective Action with protocol number {{obj.protocolNumber}}

Email content: Protocol number {{obj.protocolNumber}}. Submitting login: {{obj.entryUser.login}}

check

(function(){
    var responsibleUserUuid=_.get(ctx,"obj.responsibleUser.uuid");
    var entryUserUuid=_.get(ctx,"obj.entryUser.uuid");
    return (responsibleUserUuid != null) && (entryUserUuid != null) && (responsibleUserUuid != entryUserUuid);
})();

prepare

if(
    (assignedMail!=null) &&
    (assignedMail.indexOf("@")>0)
) {
    data.mails.push(assignedMail);
}
else {
    logger.info("mail rejected: "+assignedMail);
    throw templating.render("Użytkownik \"{{obj.responsibleUser.login}}\" nie ma ustawionego adresu e-mail!",ctx);
}

Notification of ISO register reassignment

Corrective action update → to assigned (if it changes). The machine will send an email if the record is updated AND the assigned person has changed (see condition check).

Object type: mod.AssetApi.model.special.energyenvironment.CorrectionAction

`Operation: UPDATE (Update)

Email subject: You have been assigned a corrective action with protocol number {{obj.protocolNumber}}

Email: You have been assigned a corrective action. Protocol number {{obj.protocolNumber}}. Submitting login: {{obj.entryUser.login}}

check

(function(){
    var responsibleNewUserUuid=_.get(ctx,"obj.responsibleUser.uuid");
    var responsibleOldUserUuid=_.get(ctx,"oldObj.responsibleUser.uuid");
    return (responsibleNewUserUuid != null) && (responsibleOldUserUuid != null) && (responsibleNewUserUuid != responsibleOldUserUuid);
})();

prepare

if(
    (assignedMail!=null) &&
    (assignedMail.indexOf("@")>0)
) {
    data.mails.push(assignedMail);
}
else {
    logger.info("mail rejected: "+assignedMail);
    throw templating.render("Użytkownik \"{{obj.responsibleUser.login}}\" nie ma ustawionego adresu e-mail!",ctx);
}

Contents

This Howto is based on system version 1.22.0.0 (07.2023) and presents features that may not be available on your system. Ask AMAGE to provide this functionality.
Due to the ongoing development of the system, some screens or configuration files may look slightly different, but will still retain the full functionality described here. This does not affect the essential functions described in this document.