Differences

This shows you the differences between two versions of the page.

--- docs:2000_concepts:0900_prod_feats:0500_email_handling [2022/08/25 00:00] – ↷ Page moved from 2000_concepts:0900_prod_feats:0500_email_handling to docs:2000_concepts:0900_prod_feats:0500_email_handling administrator
+++ docs:2000_concepts:0900_prod_feats:0500_email_handling [2025/06/12 02:33] (current) – Rename to AwareIM aware_support3
@@ Line 2: / Line 2: @@
 ====== E-mail Handling ======
-Many applications need to work with e-mails: e-mails often need to be automatically sent under the appropriate circumstances (for example, to remind customers that their insurance policy is about to expire) and certain actions need to be automatically performed upon receiving e-mails (for example, automatically register a support request from a customer). The following section describes how this can be done in //**Aware IM**//.
+Many applications need to work with e-mails: e-mails often need to be automatically sent under the appropriate circumstances (for example, to remind customers that their insurance policy is about to expire) and certain actions need to be automatically performed upon receiving e-mails (for example, automatically register a support request from a customer). The following section describes how this can be done in //**AwareIM**//.
 ===== Outgoing Email =====
-Sending outgoing e-mails is a part of a communication between //**Aware IM**// and an external party, such as an individual or an organization. Communication between //**Aware IM**// and external parties is described in the [[2000_concepts:0900_prod_feats:0300_comm_with_other_systems:0000_start|Communication with Other Systems]] section. An outgoing e-mail represents a notification sent by an //**Aware IM**// –based application to an external party. The external party must be represented by an intelligent business object and must have a communication channel of the “e-mail” type defined. E-mail can be sent from business rules using the ''[[3100_actions:0130_send|SEND]]'' action of the Rule Language.
+Sending outgoing e-mails is a part of a communication between //**AwareIM**// and an external party, such as an individual or an organization. Communication between //**AwareIM**// and external parties is described in the [[docs:2000_concepts:0900_prod_feats:0300_comm_with_other_systems|Communication with Other Systems]] section. An outgoing e-mail represents a notification sent by an //**AwareIM**// –based application to an external party. The external party must be represented by an intelligent business object and must have a communication channel of the “e-mail” type defined. E-mail can be sent from business rules using the ''[[a_f:a:send|SEND]]'' action of the Rule Language.
 There are, therefore, 3 steps involved in the configuration of an application that needs to send e-mails:
@@ Line 14: / Line 14: @@
   - Define a notification representing a particular e-mail.
   - Define a business rule that will use the SEND action to send the e-mail under the appropriate circumstances.
-Step 1 is described in the [[2500_config_apps:0500_add_edit_objects:0600_intelligent_bo:0000_start|Defining Intelligent Business Objects]] section. Once the channel has been defined //**Aware IM**// automatically adds the special attribute called EmailAddress to the definition of the intelligent business object. The value of this attribute is used by //**Aware IM**// to determine the e-mail address of the e-mail recipient when the e-mail is sent. The value of this attribute can be set on the form of the business object by the user or by rules.
+Step 1 is described in the [[docs:2500_config_apps:0500_add_edit_objects:0600_intelligent_bo|Defining Intelligent Business Objects]] section. Once the channel has been defined //**AwareIM**// automatically adds the special attribute called EmailAddress to the definition of the intelligent business object. The value of this attribute is used by //**AwareIM**// to determine the e-mail address of the e-mail recipient when the e-mail is sent. The value of this attribute can be set on the form of the business object by the user or by rules.
-Step 2 is described in the [[2500_config_apps:1200_add_edit_notifications|Adding/Editing Notifications]] and [[2500_config_apps:2300_emails:0200_outgoing_email|Sending Outgoing E-mail]] sections. When configuring a notification representing the e-mail it is important to define the Subject and Message attributes, the values of which will be used by //**Aware IM**// to specify the subject and body of the outgoing e-mail respectively. Also if the email has attachments the notification has to define attributes of the Document type – one attribute per attachment. The documents stored as values of these attributes will be used as e-mail attachments (see also [[2000_concepts:0900_prod_feats:0200_working_with_docs_reports:0100_doc_man|Document Management]]).
+Step 2 is described in the [[docs:2500_config_apps:1200_add_edit_notifications|Adding/Editing Notifications]] and [[docs:2500_config_apps:2600_emails:0200_outgoing_email|Sending Outgoing E-mail]] sections. When configuring a notification representing the e-mail it is important to define the Subject and Message attributes, the values of which will be used by //**AwareIM**// to specify the subject and body of the outgoing e-mail respectively. Also if the email has attachments the notification has to define attributes of the Document type – one attribute per attachment. The documents stored as values of these attributes will be used as e-mail attachments (see also [[docs:2000_concepts:0900_prod_feats:0200_working_with_docs_reports:0100_doc_man|Document Management]]).
-Step 3 is described in the [[3100_actions:0130_send|SEND]] action section of the Rule Language Reference. One point to note here is that it is not necessary to create the notification representing the email explicitly using the [[3100_actions:0060_create|CREATE]] action – //**Aware IM**// will automatically create and initialize the notification before it is sent if it has not been created explicitly. Initialization expressions of the notification may use tag elements referring to the current Context (see [[2000_concepts:0900_prod_feats:0200_working_with_docs_reports:0200_doc_gen|Document Generation]]). For example, one could define the ''ExpiryEmail'' notification with the Message attribute initialized to the following text:
+Step 3 is described in the [[a_f:a:send|SEND]] action section of the Rule Language Reference. One point to note here is that it is not necessary to create the notification representing the email explicitly using the [[a_f:a:create|CREATE]] action – //**AwareIM**// will automatically create and initialize the notification before it is sent if it has not been created explicitly. Initialization expressions of the notification may use tag elements referring to the current Context (see [[docs:2000_concepts:0900_prod_feats:0200_working_with_docs_reports:0200_doc_gen|Document Generation]]). For example, one could define the ''ExpiryEmail'' notification with the Message attribute initialized to the following text:
-<code aim>"Dear <<Customer.Name>>, your policy is about to expire". </code>
+<code aim>"Dear <<Customer.Name>>, your policy is about to expire".  </code>
 Then one could define the following rules:
 <code aim>FIND Customer WHERE Customer.Policy.ExpiryDate=CURRENT_DATE
-SEND ExpiryEmail TO Customer</code>
+ SEND ExpiryEmail TO Customer </code>
 This is equivalent to the following:
 <code aim>FIND Customer WHERE Customer.Policy.ExpiryDate=CURRENT_DATE
-CREATE ExpiryEmail WITH
+ CREATE ExpiryEmail WITH
-    ExpiryEmail.Message='Dear <<Customer.Name>>,
+    ExpiryEmail.Message='Dear <<Customer.Name>>, your policy is about to expire'
-        your policy is about to expire'
+ SEND ExpiryEmail TO Customer </code>
-SEND ExpiryEmail TO Customer</code>
 ===== Incoming Email =====
@@ Line 39: / Line 38: @@
 Just like outgoing e-mails incoming e-mails are represented by a notification. Unlike outgoing e-mails there is only one notification that represents an incoming e-mail. Its name is IncomingEmail. The name and attributes of this notification cannot be changed.
-Conceptually this notification is received by a business space, so to define this notification the configurator must indicate that the business space will be receiving incoming e-mails. This process is described in detail in the [[2500_config_apps:2300_emails:0100_incoming_emails|Setting Options for Incoming E-mail Handling]] section. Basically the configurator has to provide the name of the email server and the details of the e-mail account. After this //**Aware IM**// will automatically add the definition of the IncomingEmail notification to the business space.
+Conceptually this notification is received by a business space, so to define this notification the configurator must indicate that the business space will be receiving incoming e-mails. This process is described in detail in the [[docs:2500_config_apps:2600_emails:0100_incoming_emails|Setting Options for Incoming E-mail Handling]] section. Basically the configurator has to provide the name of the email server and the details of the e-mail account. After this //**AwareIM**// will automatically add the definition of the IncomingEmail notification to the business space.
-Once the IncomingEmail notification has been added to the list of notifications it is up to the configurator to define business rules that will be triggered once the e-mail is received (see [[2000_concepts:0800_data_processing:0000_start|Data Processing]]). The rules may check the attribute values of the IncomingEmail notification and perform the appropriate actions. The attributes of the notification contain the date when the e-mail was sent, who it was sent from, the subject and the body of the e-mail etc. There are also three attributes of the Document type representing the e-mail attachments. The first two attachments (if present) are contained in the first two attachment attributes. If e-mail has more than two attachments all other attachments are zipped up and stored in the third attachment attribute.
+Once the IncomingEmail notification has been added to the list of notifications it is up to the configurator to define business rules that will be triggered once the e-mail is received (see [[docs:2000_concepts:0800_data_processing|Data Processing]]). The rules may check the attribute values of the IncomingEmail notification and perform the appropriate actions. The attributes of the notification contain the date when the e-mail was sent, who it was sent from, the subject and the body of the e-mail etc. There are also three attributes of the Document type representing the e-mail attachments. The first two attachments (if present) are contained in the first two attachment attributes. If e-mail has more than two attachments all other attachments are zipped up and stored in the third attachment attribute.
 Example of a rule attached to the IncomingEmail notification:
-<code aim>If IncomingEmail.Subject = 'Support Request' Then
+<code aim>IF IncomingEmail.Subject = 'Support Request' THEN
-CREATE SupportRequest WITH
+ CREATE SupportRequest WITH
-    SupportRequest.Contents = IncomingEmail.Message</code>
+   SupportRequest.Contents = IncomingEmail.Message </code>
 This rule creates the business object ''SupportRequest'' initialized to the body of the received e-mail.
-The ''[[3100_actions:0300_set|SET]]'' action of the //**Aware IM**// Rule Language can be useful for analysing the received e-mail provided that the body of the e-mail is in a format required by the SET action.
+The ''[[a_f:a:set|SET]]'' action of the //**AwareIM**// Rule Language can be useful for analysing the received e-mail provided that the body of the e-mail is in a format required by the SET action.