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

Da itm wiki.
(→‎Inbound Comunication)
(→‎Web Services syntax)
 
(48 versioni intermedie di 3 utenti non mostrate)
Riga 1: Riga 1:
−
EEM - External Event Manager is one of the ''complementary'' ''modules'' of itmSUITE®. The ''module'' is intended to support the interaction with third parties applications. A set of pre-configured methods are supplied, in particular:
+
''[[Glossary|EEM]]'' - ''[[Glossary|External Event Management]]'' is one of the complementary ''[[Glossary|modules]]'' of itmSUITE®. The ''[[Glossary|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 ''[[Glossary|action engine]]'' component of the itmSUITE®.
  
−
The ''module'' can receive information (inbound message) and  send information (outbound). EEM can process inbound message in two ways:
+
=== Introduction ===
−
* ''[[Glossary|Active channel]]''
+
The ''module'' can receive information (inbound messages) with two modes which may be activated at the same time:
−
* ''[[Glossary|Passive channel]]''
+
* [[Glossary|''Active channel'']]
 +
* [[Glossary|''Passive channel'']]
  
 +
==== Active channel ====
 +
In this mode data acquisition is made by means of mails. [[Glossary|''EEM'']] verifies at regular intervals the existence of mail messages in a configured mailbox and processes them when found. ''<nowiki/>''
  
−
=== Active channel ===
+
==== Passive channel ====
 +
In this mode, ''[[Glossary|EEM]]'' makes available web services in order to acquire data.''<nowiki/>'' 
  
−
EEM verify at regular interval the existence of mail message in a configured mailbox
+
=== EEM processing steps ===
−
and process then.
+
''[[Glossary|EEM]]'' works on inbound messages received by means of the active or passive channel through a three steps process:
 +
# ''[[Glossary|EEM]]'' processes and validates the incoming message
 +
# ''[[Glossary|EEM]]'' passes processed messages to ''[[Glossary|message bus]]'' which, in turn, dispatches them to the recipients (the ''[[Glossary|modules]]'' configured to subscribe to the message)
 +
# itmSUITE® recipient ''[[Glossary|module]]'' performs the configured tasks for the received message by means of the ''[[Glossary|action engine]]''
  
−
EEM forward the received data towards itmSUITE® module sending them to MB (Message
+
The above mentioned three steps process is illustrated in the figure below.
−
Bus) that works as Dispatcher
 
  
−
MB manage the message queue and dispatch towards the subscriber (other 'modules'' of
+
[[File:EEM inbound schema v1.0.JPG|centre|thumb|500x500px|EEM inbound schema]]
−
itmSUITE® as SM/PM, CMS or EEM)''
 
  
−
 itmSUITE®module received the message and based on the rule configured in Action Engine
 
−
execute tasks (eg.: Ticket creation, ticket updating , sending notification, ect.)
 
  
−
Outbound notification are managed directly the itmSUITE® modules eg. PM/SM
+
=== EEM configuration ===
  
 +
The following paragraphs gives an overview of ''[[Glossary|EEM]]'' configuration.
 +
==== Active channel configuration ====
 +
Using ''[[Glossary|EEM]]'' menu '''''Active Notification Channels''''' it is possible to define an ''[[Glossary|active channe]]''l which is mapped on an existing mailbox.
  
−
=== Passive channel ===
+
The image below shown the parameters needed to configure an ''[[Glossary|active channel]]''.
  
−
EEM has a set of Web Services that third parties software can call.  
+
[[File:EEM active channel configuration schema v1.0.jpg|centre|thumb|500x500px|EEM Active channel]]
  
−
EEM forward the received data towards itmSUITE® module sending them to MB (Message
+
The following parameters shall be provided:
−
Bus) that works as Dispatcher
 
  
−
MB
+
{| class="wikitable"
−
manage the message queue and dispatch toward the subscriber (other 'modules'' of
+
! Field !! Meaning !! Comments
−
itmSUITE® as SM/PM, CMS or EEM)''
 
  
−
itmSUITE®
+
|-
−
module received the message and based on the rule configured in Action Engine
+
|<u>Id</u> ||Channel identifier||   
−
execute tasks (eg.: Ticket creation, ticket updating , sending notification,
+
−
ect.)
+
|-
 +
| <u>Name</u> ||Channel name||
 +
 +
|-
 +
| <u>Status</u> ||Can be Active or Inactive||If Inactive: EEM will not use it
 +
 +
|-
 +
| <u>Logging</u> ||If active: more info will be logged in JBOSS log file||
 +
 +
|-
 +
| <u>Protocol</u> ||Different protocols are available: POP3, POP3S, IMAP, IMAPS|| 
  
−
Outbound notification are managed directly the itmSUITE® modules eg.
+
|-
−
PM/SM
+
| <u>Host</u> ||URL or IP address of mail server|| 
 +
 +
|-
 +
| <u>Port</u> ||Port of mail service||Usually: 143 for IMAP, 993 for IMAPS, 110 for POP3 and 995 for POP3S 
  
−
=== Inbound EEM schema ===
+
|-
 +
| <u>Authentication Required</u> ||Check it if mail server requires authentication||
  
−
* EEM process and validate all the incoming message
+
|-
−
* MB dispatch the message to a subscriber
+
| <u>Username</u> ||Login to access mail server||  
−
* itmSUITE® module through ''[[Glossary|Action Engine]]'' execute the required task
 
  
−
[[File:EEM inbound schema v1.0.JPG|centre|thumb|500x500px|EEM inbound schema]]
+
|-
 +
| <u>Password</u> ||Password to access mail server||
 +
 
 +
|-
 +
| <u>Email</u> ||email address||
 +
 
 +
|-
 +
| <u>Advanced Properties</u> ||Properties used by secure Protocols||
  
 +
|}
  
−
=== Inbound Comunication ===
+
==== Passive channel configuration ====
 +
There is no specific configuration for ''[[Glossary|passive channels]]''.
  
−
As mention above, this communication can be managed through:
+
==== Monitoring system configurations ====
−
* Active channel
+
A ''[[Glossary|monitoring system configuration]]''  tells ''[[Glossary|EEM]]'' what to do in the very first step (processing and validating an inbound message).
−
* Passive channel
 
  
−
The paragraph below shown the main step necessary to configure them.
+
For each monitoring system configuration there are two configuration screens, one for general settings and one for specific parameters. The ''<u>General</u>'' configuration is shown in the screen below.
  
−
==== Active channel ====
+
[[File:EEM MSC general configuration v1.0.jpg|centre|thumb|500x500px|EEM MSC General Configuration]]
  
−
The activity to perform to correctly set up this configuration are:
+
The following parameters shall be provided:
−
* Define one or more Active configuration channel
 
−
* Implement a validation rule via MSC (Monitoring System Configuration)
 
  
−
Using EEM Menu Active Notification Channels is possible to define the parameter necessary to access, one or more, mailbox.
+
{| class="wikitable"
 +
! Field !! Meaning !! Comments
  
−
The image below shown the parameter to insert to configure a mailbox
+
|-
 +
|<u>Id</u> ||  The identifier of the ''[[Glossary|MSC]].''
 +
||    Automatically assigned by the system.
 +
 +
|-
 +
| <u>Name</u> ||  The name of the ''[[Glossary|MSC]].''
 +
|| Mandatory field.
 +
 +
|-
 +
| <u>Type</u> ||  ||
 +
 +
|-
 +
| <u>Status</u> ||  The status of the ''[[Glossary|MSC]].''
 +
|| If "Active", the MSC is processed.
 +
 +
|-
 +
| <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> ||  The strategy used to determine if the ''[[Glossary|MSC]]'' shall be applied to the mail.||
  
−
[[File:EEM active channel configuration schema v1.0.jpg|centre|thumb|500x500px|EEM Active channel]]
+
|-
 +
| <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]]''
  
−
An MSC (Monitoring System Configuration) is composed by General and Parameter informations.
+
|-
 +
| <u>Passive Channels Available</u> ||  If set, it means the MSC is available for ''[[Glossary|passive channel]]''
 +
|| This also enables the following depending parameter.
  
−
The image below shown the General tab used by the system to validate the incoming data
+
|-
 +
| <u>Request Identification Tag</u> ||  ||
  
−
[[File:EEM MSC general configuration v1.0.jpg|centre|thumb|500x500px|EEM MSC General Configuration]]
+
|}
  
−
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]]
  
−
One message is validated if the Identification Strategy is respected and all the parameters are presents into the body of message
+
The following details shall be provided for each parameter:
 +
 
 +
{| class="wikitable"
 +
! Field !! Meaning !! Comments
 +
 
 +
|-
 +
|<u>Id</u> ||Parameter identifier||Automatically assigned by system   
 +
 +
|-
 +
| <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>Description</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)
  
−
==== Passive channel ====
+
EEM: shall subscribes to "Generate Emails" message
−
When itmSUITE® is called from third parites system is necessary to define the validation rule using the MSC (monitoring sytem configuration) session.
+
 +
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):
  
−
In this case, a client call is accepted if the Request Identification tag and the expected Parameters are properly passed into the SOAP message.
+
<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>
  
−
The image below shown a MSC (monitoring sytem configuration) configuration session.
+
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
  
−
[[File:EEM passive configuration v1.0.jpg|centre|thumb|500x500px|EEM Passive Configuraiton]]
+
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 ).
  
−
=== Outbound Comunication ===
+
[[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
Estratto da "http://wiki.itmsuite.eu/index.php?title=EEM_-_External_Event_Management&oldid=3385"