Differenze tra le versioni di "EEM - External Event Management"
(→Web Services syntax) |
(→Web Services syntax) |
||
(4 versioni intermedie di uno stesso utente non sono mostrate) | |||
Riga 111: | Riga 111: | ||
|- | |- | ||
− | | <u>Email Identification Strategy</u> || The strategy used to determine if the ''[[Glossary|MSC]]'' shall be applied to the mail. | + | | <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> || The value which is searched in the mail when applying the identification strategy. If found, the ''[[Glossary|MSC]]'' is applied to the mail. | + | | <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]]'' |
|- | |- | ||
Riga 242: | Riga 241: | ||
=== Web Services syntax === | === Web Services syntax === | ||
The Passive Channel is exposed by EEM and described through wsdl at the following address: | The Passive Channel is exposed by EEM and described through wsdl at the following address: | ||
− | http://[indirizzo]:[porta]/EEM/webservices/wsPassiveNotificationChannelService?wsdl=PassiveNotificationChannel.wsdl | + | |
+ | http://[indirizzo]:[porta]/EEM/webservices/wsPassiveNotificationChannelService? | ||
+ | wsdl=PassiveNotificationChannel.wsdl | ||
In details: | In details: | ||
Riga 288: | Riga 289: | ||
</wsdl:portType> | </wsdl:portType> | ||
</wsdl:definitions> | </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 ). | ||
+ | |||
+ | [[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:
- EEM processes and validates the incoming message
- EEM passes processed messages to message bus which, in turn, dispatches them to the recipients (the modules configured to subscribe to the message)
- 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 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.
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 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.
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.
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 ).