The Email Engine and Designer is a module of the Solution Builder designed for handling e-mail notifications to specified recipients considering their preferred languages and cultures. The emails sent to the Recipients are automatically generated based on dynamic data according to the rules defined in the Email Descriptor.
By means of the Email Designer, the System allows you to design the Email Descriptor, a definition of the Email template, which incorporates a static localizable text with dynamic data impacted by input parameters. There are plenty of ways of how the email sending can be triggered, such as the Send Email action for via Compliance Rules, the Send Email Workflow Activity, using the "Send Email" UI action, or by simply using the Email Service API to trigger an email from code. All these options add a record to the Queue.
The Email Engine's purpose is identical to that of the outdated Alerting Engine. Our aim is to replace the latter with the former in upcoming releases.
The application background process is responsible for the reliable processing requests for sending emails. Applications modules use various options of adding requests for sending emails to the application Queue, from which they, one by one, are pulled by the Email Engine, which guarantees the reliable processing, as regardless of any misbehavior (e.g. Server restart), the requests are persisted in the Queue, and the Email Engine keeps the processing right after the reactivation. The main purpose of the Engine is to calculate all the necessary information required for email sending, such as Recipients (To, CC), Sender information, Subject, Body, Signature, etc, and communicate with the mail server to send an email.
The Email Engine is taking care of sending emails to recipients in their preferable language, correctly formatted according to the recipient culture, with dates in local time. For the cases when the related Email Descriptors define that emails should be sent in recipients' preferable cultures, the Email Engine analyzes the detected recipients' preferences and automatically regenerates the email Subject and Body to consider the recipients' preferable language, culture (for formatting dates, currencies, etc) and time zone (to display dates in an email in recipient local time). If the Email Descriptor defines that the recipient preferences should be neglected or the recipient is not a User (defined by the email address which is unknown by the System), the Email Engine uses the System default settings for generating emails.
Email Sender and Signature
In a request to send an email, it is possible to set the Sender details, either a User or plain email address. If no Sender information is defined, the Email Engine takes the default Sender from the Settings. The email signature is not required, but just like the Sender could be implicitly defined in the Send Request; otherwise, it will be automatically detected first from the defined Sender (each user of the System can setup a personal Signature in the User Profile), or from the related Email Descriptor.
Starting from version 10.0.2 the Email Engine executes on trusted Matrix42 Workers. It allows easy scale-out the System by adding additional Worker to the cluster for scenarios when a huge amount of mails needs to generated and sent.
Email Engine logs can be found in the logs file for the Matrix42 Worker where the engine is running
In Solution Builder Administration settings, there is a section for configuring the Email Engine.
|Enabled||Activates or deactivates all the Email Notifications. When deactivated, the System ignores all incoming requests for sending Emails.|
|SMTP Server||Defines the server address with open SMTP port, which is used for sending emails. E.g. smtp.gmail.com.|
|Default Sender||Email address of a default Email Sender. Used by the Email Engine when the Sender is not implicitly defined in the Send operation.|
Specifies the way Email Engine processes the Emails sending and logging:
Send Email, the System only sends emails to recipients and does not log them.
Send Email and Store it in Database, the System sends emails and saves them in the database. All the emails can be further reviewed and managed in the "Services & Processes > E-mails > E-mail" section. The Emails stay in the database for the specified number of days, and then are cleaned up.
Write Emails to specified Folder, the Email Engine does not send emails to recipients but rather saves them as files in a specified Folder.
|E-mail Folder||The folder which the Email Engine uses to store E-mails when the "Write Emails to specified Folder" mode is activated.|
|Use SMTP Authentication||Signals to the Email Engine that the SMTP Authentication should be used.|
|Credentials||The Email Engine supports two ways of authentication on the Email Server:
Integrated Security, the Email Engine uses the Windows identity of a Service Account (the Windows user the Solution Builder IIS Application Pool is running on) for authentication on the Email Server.
Username-Password, the System uses the specified Account and Password for authentication.
|Use SSL||Signals to the System that the secured SSL protocol should be used for communication with the Email Sever.|
|Use Network Credentials|
|Recipients In Single Email||Specifies the maximum amount of Recipients in one single Email. If the amount of recipients exceeds the defined value, the Email Engine sends multiple emails, each of them has the defined (or less) amount of recipients.
Some Email Servers significantly reduce the performance when the email has a huge amount of recipients. This setting allows you to counteract such a problem.
|Clean-up Emails after (Days)||Defines the amount of Days the emails are stored in a database. This setting makes sense only when the "Send Email and store in Database" mode is activated.|
|Attempts to Send||The amount of attempts the Email Engine uses for successful sending of the email. If the email was not sent, the System saves it to the database with the Failed status. When the connection to the email server is recovered, the Email could be sent manually using the "Resend" action.|
Enabled, activates or deactivates all the Email Notifications. When deactivated, the System ignores all the incoming requests for sending Emails.
SMTP Server, defines the server name (or IP) with an open SMTP port which is used for sending emails.
The Solution Builder provides multiple ways of how the email sending can be triggered by the System.
The most popular way to send Emails in Service Management is using Compliance Rules, which allows you to define the list of actions the System needs to fulfill when some configured event occurs in the System. The Compliance Rule engine calculates automatically all the necessary information for sending an email, such as the related Email Descriptor and parameters values, Recipients, and calls the Email Engine for sending an email.
Use the Send Email UUX Workflow Activity for sending emails from a Workflow.
Send E-mail Action
The Send E-mail UUX action available for the Email Descriptor object, which can be used for manual triggering of an email notification. The action wizard asks you to specify manually the Sender, Recipients of the email, Signature for the Email (could be either implicitly set or taken indirectly from the Sender User Profile) and also provide values for the selected Email Descriptor parameters. On submitting the action, the System immediately generates an email based on the selected E-mail descriptor with specified input parameter values and sends it to the listed recipients.
The sending Email from the Application server can be activated by calling a REST service.
See more details about the execution contract in the Web Services management area, in Administration.
Here are some interesting things about...