Differenze tra le versioni di "EEM - External Event Management"

Da itm wiki.
(Monitoring system configurations)
(Web Services syntax)
 
(20 versioni intermedie di 2 utenti non mostrate)
Riga 39: Riga 39:
  
 
|-
 
|-
|<u>Id</u> || ||     
+
|<u>Id</u> ||Channel identifier||     
 
   
 
   
 
|-
 
|-
| <u>Name</u> || ||  
+
| <u>Name</u> ||Channel name||  
 
   
 
   
 
|-
 
|-
| <u>Status</u> ||   ||  
+
| <u>Status</u> ||Can be Active or Inactive||If Inactive: EEM will not use it
 
   
 
   
 
|-
 
|-
| <u>Logging</u> || ||  
+
| <u>Logging</u> ||If active: more info will be logged in JBOSS log file||  
 
   
 
   
 
|-
 
|-
| <u>Host</u> || ||   
+
| <u>Protocol</u> ||Different protocols are available: POP3, POP3S, IMAP, IMAPS|| 
 +
 
 +
|-
 +
| <u>Host</u> ||URL or IP address of mail server||   
 
   
 
   
 
|-
 
|-
| <u>Port</u> || ||  
+
| <u>Port</u> ||Port of mail service||Usually: 143 for IMAP, 993 for IMAPS, 110 for POP3 and 995 for POP3S 
  
 
|-
 
|-
| <u>Authentication Required</u> || ||  
+
| <u>Authentication Required</u> ||Check it if mail server requires authentication||  
  
 
|-
 
|-
| <u>Username</u> || ||  
+
| <u>Username</u> ||Login to access mail server||  
  
 
|-
 
|-
| <u>Password</u> || ||  
+
| <u>Password</u> ||Password to access mail server||  
  
 
|-
 
|-
| <u>Email</u> || ||  
+
| <u>Email</u> ||email address||
 +
 
 +
|-
 +
| <u>Advanced Properties</u> ||Properties used by secure Protocols||
  
 
|}
 
|}
Riga 86: Riga 92:
  
 
|-
 
|-
|<u>Id</u> ||  ||     
+
|<u>Id</u> ||  The identifier of the ''[[Glossary|MSC]].''
 +
||    Automatically assigned by the system.
 
   
 
   
 
|-
 
|-
| <u>Name</u> ||  ||  
+
| <u>Name</u> ||  The name of the ''[[Glossary|MSC]].''
 +
|| Mandatory field.
 
   
 
   
 
|-
 
|-
Riga 95: Riga 103:
 
   
 
   
 
|-
 
|-
| <u>Status</u> ||  ||  
+
| <u>Status</u> ||  The status of the ''[[Glossary|MSC]].''
 +
|| If "Active", the MSC is processed.
 
   
 
   
 
|-
 
|-
| <u>Active Channels Available</u> ||  ||   
+
| <u>Active Channels Available</u> ||  If set, it means the MSC is available for ''[[Glossary|active channels]]'' (all).
 +
||  This also enables the following two depending parameters.
 
   
 
   
 
|-
 
|-
| <u>Email Identification Strategy</u> ||  ||  
+
| <u>Email Identification Strategy</u> ||  The strategy used to determine if the ''[[Glossary|MSC]]'' shall be applied to the mail.||
  
 
|-
 
|-
| <u>Email Identification Value</u> ||  
+
| <u>Email Identification Value</u> || The value which is searched in the mail when applying the identification strategy. If found, the ''[[Glossary|MSC]]'' is applied to the mail.||The match is done "in like". ie: <u>Email Identification Strategy</u> = "subject" and <u>Email Identification Value</u> = "gmail.com" means that all the mail incoming from domain "gmail.com" will be considered as valid for current ''[[Glossary|MSC]]''
  
 
|-
 
|-
| <u>Passive Channels Available</u> ||  ||  
+
| <u>Passive Channels Available</u> ||  If set, it means the MSC is available for ''[[Glossary|passive channel]]''
 +
|| This also enables the following depending parameter.
  
 
|-
 
|-
Riga 114: Riga 125:
 
|}
 
|}
  
The image below shown the Parameter tab used by the system to collect information present on a message.
+
''Parameters ''configuration is shown in the screen below.
  
 
[[File:EEM MSC parameter configuration v1.0.jpg|centre|thumb|500x500px|EEM MSC Parameter Configuration]]
 
[[File:EEM MSC parameter configuration v1.0.jpg|centre|thumb|500x500px|EEM MSC Parameter Configuration]]
  
The following parameters shall be provided:
+
The following details shall be provided for each parameter:
  
 
{| class="wikitable"
 
{| class="wikitable"
Riga 124: Riga 135:
  
 
|-
 
|-
|<u>Id</u> || ||     
+
|<u>Id</u> ||Parameter identifier||Automatically assigned by system    
 
   
 
   
 
|-
 
|-
| <u>Name</u> || ||  
+
| <u>Name</u> ||Parameter name||It will be matched with incoming Parameters: mail or web service calling shall contain all an only the parameters defined in ''[[Glossary|MSC]]''. If any parameter is missing or not matched --> no itmSUITE Message is forwarded to MB
 
   
 
   
 
|-
 
|-
| <u>Status</u> ||   ||  
+
| <u>Description</u> ||||  
 
   
 
   
 
|-
 
|-
| <u>Logging</u> || ||  
+
| <u>Aliases</u> ||Here can be defined one or more Aliases for current Parameter: all of them will be added in itmSUITE Message by ''[[Glossary|EEM]]''||  
 +
|}
 +
 
 +
<u>Name</u> is searched in the incoming message body for each parameter. The content following <u>Name</u> is assigned as value of the parameter.
 +
 
 +
An inbound message is acceptende only if the identification strategy is matched or the identification tag is found all the parameters are present into the body of message.
 +
 
 +
=== Examples ===
 +
 
 +
==== Open a Ticket from mail ====
 +
To achieve the aim of current example the following configurations shall be done:
 +
MB: an itmSUITE Message with type "Generate Emails" shall be scheduled in MBù
 +
 
 +
In Message Scheduler Management add a new Message
 +
Set "Message Publisher" as Message Bus Scheduler
 +
Set "Message Type" as Generate Emails
 +
Set a valid cron string (example: 0/10 * * * * ? will send a Message to EEM every 10 sec)
 +
 
 +
EEM: shall subscribes to "Generate Emails" message
 +
 +
In EEM, select menu item Message Bus and check "Generate Emails" option
 +
 
 +
An Active Channel shall be configured in EEM (see above)
 +
 
 +
In EEM, select menu item Active Channel and insert a valid mailbox
 +
 
 +
A MSC with type "Email Forward"
 
   
 
   
|-
+
In EEM, select menu item Message System Configuration and create a new MSC
| <u>Host</u> || || 
+
Select Type "Forwarding"
 +
Insert a matching value
 +
Active it
 +
 
 +
An Action shall be created and activated in PMSM on event "Incoming Mail"
 +
 
 +
In PMSM, go in Action Engine and create a new Action with Type "Incoming Mail"
 +
Add a Task with Type "Scripting Task"
 +
  Following code will create a new Ticket when an itmSUITE Message will arrive to PMSM from MB
 
   
 
   
|-
+
/**
| <u>Port</u> || ||
+
* @param event
 +
* @param incomeParameters
 +
*/
 +
function main(event, incomeParameters)
 +
{
 +
  var ticket = null;
 +
  ticket = createTicket(event);
 +
}
 +
/**
 +
* Create a ticket.
 +
* @param event
 +
* @return ticket
 +
*/
 +
function createTicket(event)
 +
{
 +
var ticketService = taskRuntime.getService("TicketService");
 +
var systemService = taskRuntime.getService("SystemService");
 +
var mail = taskRuntime.getService("UserMessageService").parseEemMessage(event.parameters.get
 +
('Message'));
 +
var ticket = new com.kv4.psm.core.domain.model.ticket.WFTicketModel();
 +
var SRCS = "SRCS path";
 +
ticket = ticketService.prepareNew(ticket, SRCS).getResult();
 +
if(ticket != null)
 +
{
 +
var arrivalTime = event.parameters.get('ArrivalTime');
 +
var processTime = event.parameters.get('ProcessTime');
 +
var oversized = event.parameters.get('Oversized');  
 +
var sender = event.parameters.get('mail.from');
 +
var subject = event.parameters.get('mail.subject');
 +
var cc = event.parameters.get('mail.cc');
 +
var reciever = event.parameters.get('mail.to');
 +
var body = mail.getBodyText();
 +
var contentType = mail.contentType;
 +
var descritpion = 'ArrivalTime: ' + arrivalTime + '\n ProcessTime: ' + processTime + '\n Oversized: '
 +
+ oversized + '\n Sender: ' + sender + '\n Subject: ' + subject + '\n CC: ' + cc + '\n Reciever: ' + 
 +
reciever + '\n Body: ' + body + '\n ContentType: ' + contentType;
 +
ticket.setDescription(descritpion);
 +
}
 +
//create a ticket
 +
ticket = ticketService.create(ticket).getResult();
 +
taskRuntime.addWarning("Ticket: " + ticket.id + " had been created");
 +
return ticket;
 +
}
 +
 
 +
===== MB: Schedule a "Generate Emails" message =====
 +
The important part of a scheduled message is the "Cron Expression". It define the interval time between messages generation.
 +
 
 +
Cron expression example: 0/10 * * * * ?
 +
 
 +
Is possible to found more example here:
 +
http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/crontrigger.html
 +
 
 +
===== PMSM Action =====
 +
The action "Incoming Mail" can be used to manage an itmSUITE Message generated by an incoming mail.
 +
 
 +
=== Web Services syntax ===
 +
The Passive Channel is exposed by EEM and described through wsdl at the following address:
 +
 
 +
http://[indirizzo]:[porta]/EEM/webservices/wsPassiveNotificationChannelService?
 +
wsdl=PassiveNotificationChannel.wsdl
 +
 
 +
In details:
 +
<?xml version="1.0" encoding="UTF-8" ?>  
 +
- <wsdl:definitions name="PassiveNotificationChannel"
 +
targetNamespace="http://api.service.domain.eem.kv4.com/"
 +
xmlns:ns1="http://api.service.domain.eem.kv4.com/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
 +
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 +
  - <wsdl:types>
 +
- <xs:schema elementFormDefault="unqualified" 
 +
targetNamespace="http://api.service.domain.eem.kv4.com/" version="1.0"
 +
xmlns:tns="http://api.service.domain.eem.kv4.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
 +
<xs:element name="Notify" type="tns:Notify" />
 +
<xs:element name="NotifyResponse" type="tns:NotifyResponse" />
 +
- <xs:complexType name="Notify">
 +
- <xs:sequence>
 +
<xs:element minOccurs="0" name="RequestIdentificationTag" type="xs:string" />
 +
<xs:element maxOccurs="unbounded" minOccurs="0" name="Parameters" type="tns:parameter" />
 +
</xs:sequence>
 +
</xs:complexType>
 +
- <xs:complexType name="parameter">
 +
- <xs:sequence>
 +
<xs:element minOccurs="0" name="name" type="xs:string" />
 +
<xs:element minOccurs="0" name="value" type="xs:string" />
 +
</xs:sequence>
 +
</xs:complexType>
 +
- <xs:complexType name="NotifyResponse">
 +
- <xs:sequence>
 +
<xs:element minOccurs="0" name="return" type="xs:string" />
 +
</xs:sequence>
 +
</xs:complexType>
 +
</xs:schema>
 +
</wsdl:types>
 +
- <wsdl:message name="NotifyResponse">
 +
<wsdl:part element="ns1:NotifyResponse" name="parameters" /> 
 +
</wsdl:message>
 +
- <wsdl:message name="Notify">
 +
<wsdl:part element="ns1:Notify" name="parameters" />
 +
</wsdl:message>
 +
- <wsdl:portType name="PassiveNotificationChannel">
 +
- <wsdl:operation name="Notify">
 +
<wsdl:input message="ns1:Notify" name="Notify" />
 +
<wsdl:output message="ns1:NotifyResponse" name="NotifyResponse" />
 +
</wsdl:operation>
 +
</wsdl:portType>
 +
</wsdl:definitions>
 +
 
 +
The request recieved by EEM shall contain a dictionary of parameters, each dictionary item shall be a pair name – value:
  
|-
+
<xs:complexType name="parameter">
| <u>Authentication Required</u> || ||
+
- <xs:sequence>
 +
<xs:element minOccurs="0" name="name" type="xs:string" /> -- Parameter Name
 +
<xs:element minOccurs="0" name="value" type="xs:string" /> -- Parameter Value
 +
  </xs:sequence>
  
|-
+
EEM will parse the incoming message by checking parameters name and identification tag (contained in XML node highlight below):
| <u>Username</u> ||  ||
 
  
|-
+
<xs:complexType name="Notify">
| <u>Password</u> || ||
+
<xs:sequence>
 +
<xs:element minOccurs="0" name="RequestIdentificationTag" type="xs:string" />  
 +
  <xs:element maxOccurs="unbounded" minOccurs="0" name="Parameters" type="tns:parameter" />
 +
</xs:sequence>
  
|-
+
If the message parsing will be evaluated as ok: the message will be forwarded (throught MB) to PMSM.
| <u>Email</u> || ||
+
The management of messages among Suite modules is asynchronous, so the meaning of EEM response (OK or KO) means:
 +
OK: EEM recieved a well formatted message
 +
KO: EEM recieved a not well formatted message
  
|}
+
Optionally:
 +
The Action Engine of PMSM will evaluate the Message paramters and will send, directly to external software Web Service, a response about Task executed.
 +
The response from PMSM requires a development (to introduce in PMSM the logic to interact with external Web Services ).
  
One message is validated if the Identification Strategy is respected and all the parameters are presents into the body of message
+
[[File:EEM passive channel.jpg|centre|thumb|500x500px|EEM Passive Channel schema]]

Versione attuale delle 17:14, 20 nov 2017

EEM - External Event Management is one of the complementary modules of itmSUITE®. The module is aimed to enable interactions between itmSUITE® and third party applications (interfaces). The supported direction of the data flow is from the external application to itmSUITE® (input). It is possible to define and implement outbound data flow and interfaces by using the action engine component of the itmSUITE®.

Introduction

The module can receive information (inbound messages) with two modes which may be activated at the same time:

Active channel

In this mode data acquisition is made by means of mails. EEM verifies at regular intervals the existence of mail messages in a configured mailbox and processes them when found.

Passive channel

In this mode, EEM makes available web services in order to acquire data.

EEM processing steps

EEM works on inbound messages received by means of the active or passive channel through a three steps process:

  1. EEM processes and validates the incoming message
  2. EEM passes processed messages to message bus which, in turn, dispatches them to the recipients (the modules configured to subscribe to the message)
  3. itmSUITE® recipient module performs the configured tasks for the received message by means of the action engine

The above mentioned three steps process is illustrated in the figure below.

EEM inbound schema


EEM configuration

The following paragraphs gives an overview of EEM configuration.

Active channel configuration

Using EEM menu Active Notification Channels it is possible to define an active channel which is mapped on an existing mailbox.

The image below shown the parameters needed to configure an active channel.

EEM Active channel

The following parameters shall be provided:

Field Meaning Comments
Id Channel identifier
Name Channel name
Status Can be Active or Inactive If Inactive: EEM will not use it
Logging If active: more info will be logged in JBOSS log file
Protocol Different protocols are available: POP3, POP3S, IMAP, IMAPS
Host URL or IP address of mail server
Port Port of mail service Usually: 143 for IMAP, 993 for IMAPS, 110 for POP3 and 995 for POP3S
Authentication Required Check it if mail server requires authentication
Username Login to access mail server
Password Password to access mail server
Email email address
Advanced Properties Properties used by secure Protocols

Passive channel configuration

There is no specific configuration for passive channels.

Monitoring system configurations

A monitoring system configuration tells EEM what to do in the very first step (processing and validating an inbound message).

For each monitoring system configuration there are two configuration screens, one for general settings and one for specific parameters. The General configuration is shown in the screen below.

EEM MSC General Configuration

The following parameters shall be provided:

Field Meaning Comments
Id The identifier of the MSC. Automatically assigned by the system.
Name The name of the MSC. Mandatory field.
Type
Status The status of the MSC. If "Active", the MSC is processed.
Active Channels Available If set, it means the MSC is available for active channels (all). This also enables the following two depending parameters.
Email Identification Strategy The strategy used to determine if the MSC shall be applied to the mail.
Email Identification Value The value which is searched in the mail when applying the identification strategy. If found, the MSC is applied to the mail. The match is done "in like". ie: Email Identification Strategy = "subject" and Email Identification Value = "gmail.com" means that all the mail incoming from domain "gmail.com" will be considered as valid for current MSC
Passive Channels Available If set, it means the MSC is available for passive channel This also enables the following depending parameter.
Request Identification Tag

Parameters configuration is shown in the screen below.

EEM MSC Parameter Configuration

The following details shall be provided for each parameter:

Field Meaning Comments
Id Parameter identifier Automatically assigned by system
Name Parameter name It will be matched with incoming Parameters: mail or web service calling shall contain all an only the parameters defined in MSC. If any parameter is missing or not matched --> no itmSUITE Message is forwarded to MB
Description
Aliases Here can be defined one or more Aliases for current Parameter: all of them will be added in itmSUITE Message by EEM

Name is searched in the incoming message body for each parameter. The content following Name is assigned as value of the parameter.

An inbound message is acceptende only if the identification strategy is matched or the identification tag is found all the parameters are present into the body of message.

Examples

Open a Ticket from mail

To achieve the aim of current example the following configurations shall be done: MB: an itmSUITE Message with type "Generate Emails" shall be scheduled in MBù

In Message Scheduler Management add a new Message
Set "Message Publisher" as Message Bus Scheduler
Set "Message Type" as Generate Emails
Set a valid cron string (example: 0/10 * * * * ? will send a Message to EEM every 10 sec)

EEM: shall subscribes to "Generate Emails" message

In EEM, select menu item Message Bus and check "Generate Emails" option

An Active Channel shall be configured in EEM (see above)

In EEM, select menu item Active Channel and insert a valid mailbox

A MSC with type "Email Forward"

In EEM, select menu item Message System Configuration and create a new MSC
Select Type "Forwarding"
Insert a matching value
Active it

An Action shall be created and activated in PMSM on event "Incoming Mail"

In PMSM, go in Action Engine and create a new Action with Type "Incoming Mail"
Add a Task with Type "Scripting Task"
Following code will create a new Ticket when an itmSUITE Message will arrive to PMSM from MB

/**
* @param event
* @param incomeParameters
*/
function main(event, incomeParameters)
{
 var ticket = null;
 ticket = createTicket(event); 
}
/**
* Create a ticket.
* @param event
* @return ticket
*/
function createTicket(event)
{
var ticketService = taskRuntime.getService("TicketService");
var systemService = taskRuntime.getService("SystemService");
var mail = taskRuntime.getService("UserMessageService").parseEemMessage(event.parameters.get
('Message'));
var ticket = new com.kv4.psm.core.domain.model.ticket.WFTicketModel();
var SRCS = "SRCS path";
ticket = ticketService.prepareNew(ticket, SRCS).getResult();
if(ticket != null)
{
var arrivalTime = event.parameters.get('ArrivalTime');
var processTime = event.parameters.get('ProcessTime');
var oversized = event.parameters.get('Oversized');	  
var sender = event.parameters.get('mail.from');
var subject = event.parameters.get('mail.subject');
var cc = event.parameters.get('mail.cc');
var reciever = event.parameters.get('mail.to');
var body = mail.getBodyText();
var contentType = mail.contentType;
var descritpion = 'ArrivalTime: ' + arrivalTime + '\n ProcessTime: ' + processTime + '\n Oversized: '
+ oversized + '\n Sender: ' + sender + '\n Subject: ' + subject + '\n CC: ' + cc + '\n Reciever: ' +  
reciever + '\n Body: ' + body + '\n ContentType: ' + contentType;
ticket.setDescription(descritpion);
}
//create a ticket
ticket = ticketService.create(ticket).getResult();
taskRuntime.addWarning("Ticket: " + ticket.id + " had been created");
return ticket;
}
MB: Schedule a "Generate Emails" message

The important part of a scheduled message is the "Cron Expression". It define the interval time between messages generation.

Cron expression example: 0/10 * * * * ?

Is possible to found more example here: http://www.quartz-scheduler.org/documentation/quartz-2.x/tutorials/crontrigger.html

PMSM Action

The action "Incoming Mail" can be used to manage an itmSUITE Message generated by an incoming mail.

Web Services syntax

The Passive Channel is exposed by EEM and described through wsdl at the following address:

http://[indirizzo]:[porta]/EEM/webservices/wsPassiveNotificationChannelService? 
wsdl=PassiveNotificationChannel.wsdl

In details:

<?xml version="1.0" encoding="UTF-8" ?> 
- <wsdl:definitions name="PassiveNotificationChannel" 
targetNamespace="http://api.service.domain.eem.kv4.com/" 
xmlns:ns1="http://api.service.domain.eem.kv4.com/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
- <wsdl:types>
- <xs:schema elementFormDefault="unqualified"  
targetNamespace="http://api.service.domain.eem.kv4.com/" version="1.0" 
xmlns:tns="http://api.service.domain.eem.kv4.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Notify" type="tns:Notify" /> 
<xs:element name="NotifyResponse" type="tns:NotifyResponse" /> 
- <xs:complexType name="Notify">
- <xs:sequence>
<xs:element minOccurs="0" name="RequestIdentificationTag" type="xs:string" /> 
<xs:element maxOccurs="unbounded" minOccurs="0" name="Parameters" type="tns:parameter" /> 
</xs:sequence>
</xs:complexType>
- <xs:complexType name="parameter">
- <xs:sequence>
<xs:element minOccurs="0" name="name" type="xs:string" /> 
<xs:element minOccurs="0" name="value" type="xs:string" /> 
</xs:sequence>
</xs:complexType>
- <xs:complexType name="NotifyResponse">
- <xs:sequence>
<xs:element minOccurs="0" name="return" type="xs:string" /> 
</xs:sequence>
</xs:complexType>
</xs:schema>
</wsdl:types>
- <wsdl:message name="NotifyResponse">
<wsdl:part element="ns1:NotifyResponse" name="parameters" />  
</wsdl:message>
- <wsdl:message name="Notify">
<wsdl:part element="ns1:Notify" name="parameters" /> 
</wsdl:message>
- <wsdl:portType name="PassiveNotificationChannel">
- <wsdl:operation name="Notify">
<wsdl:input message="ns1:Notify" name="Notify" /> 
<wsdl:output message="ns1:NotifyResponse" name="NotifyResponse" /> 
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>

The request recieved by EEM shall contain a dictionary of parameters, each dictionary item shall be a pair name – value:

<xs:complexType name="parameter">
- <xs:sequence>
<xs:element minOccurs="0" name="name" type="xs:string" /> -- Parameter Name
<xs:element minOccurs="0" name="value" type="xs:string" /> -- Parameter Value
</xs:sequence>

EEM will parse the incoming message by checking parameters name and identification tag (contained in XML node highlight below):

<xs:complexType name="Notify">
<xs:sequence>
<xs:element minOccurs="0" name="RequestIdentificationTag" type="xs:string" /> 
<xs:element maxOccurs="unbounded" minOccurs="0" name="Parameters" type="tns:parameter" /> 
</xs:sequence>

If the message parsing will be evaluated as ok: the message will be forwarded (throught MB) to PMSM. The management of messages among Suite modules is asynchronous, so the meaning of EEM response (OK or KO) means: OK: EEM recieved a well formatted message KO: EEM recieved a not well formatted message

Optionally: The Action Engine of PMSM will evaluate the Message paramters and will send, directly to external software Web Service, a response about Task executed. The response from PMSM requires a development (to introduce in PMSM the logic to interact with external Web Services ).

EEM Passive Channel schema