Differenze tra le versioni di "EEM - External Event Management"
(→Web Services syntax) |
|||
(57 versioni intermedie di 3 utenti non mostrate) | |||
Riga 1: | Riga 1: | ||
− | EEM - External Event | + | ''[[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 | + | === Introduction === |
− | * Active channel | + | The ''module'' can receive information (inbound messages) with two modes which may be activated at the same time: |
− | * 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/>'' | ||
− | EEM | + | ==== Passive channel ==== |
− | + | In this mode, ''[[Glossary|EEM]]'' makes available web services in order to acquire data.''<nowiki/>'' | |
+ | === EEM processing steps === | ||
+ | ''[[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]]'' | ||
− | === ''[[Glossary|Passive channel]]'' configuration === | + | The above mentioned three steps process is illustrated in the figure below. |
+ | |||
+ | [[File:EEM inbound schema v1.0.JPG|centre|thumb|500x500px|EEM inbound schema]] | ||
+ | |||
+ | |||
+ | === 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. | ||
+ | |||
+ | The image below shown the parameters needed to configure an ''[[Glossary|active channel]]''. | ||
+ | |||
+ | [[File:EEM active channel configuration schema v1.0.jpg|centre|thumb|500x500px|EEM Active channel]] | ||
+ | |||
+ | The following parameters shall be provided: | ||
+ | |||
+ | {| class="wikitable" | ||
+ | ! Field !! Meaning !! Comments | ||
+ | |||
+ | |- | ||
+ | |<u>Id</u> ||Channel identifier|| | ||
+ | |||
+ | |- | ||
+ | | <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|| | ||
+ | |||
+ | |- | ||
+ | | <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 | ||
+ | |||
+ | |- | ||
+ | | <u>Authentication Required</u> ||Check it if mail server requires authentication|| | ||
+ | |||
+ | |- | ||
+ | | <u>Username</u> ||Login to access mail server|| | ||
+ | |||
+ | |- | ||
+ | | <u>Password</u> ||Password to access mail server|| | ||
+ | |||
+ | |- | ||
+ | | <u>Email</u> ||email address|| | ||
+ | |||
+ | |- | ||
+ | | <u>Advanced Properties</u> ||Properties used by secure Protocols|| | ||
+ | |||
+ | |} | ||
+ | |||
+ | ==== Passive channel configuration ==== | ||
+ | There is no specific configuration for ''[[Glossary|passive channels]]''. | ||
+ | |||
+ | ==== Monitoring system configurations ==== | ||
+ | A ''[[Glossary|monitoring system configuration]]'' tells ''[[Glossary|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 ''<u>General</u>'' configuration is shown in the screen below. | ||
+ | |||
+ | [[File:EEM MSC general configuration v1.0.jpg|centre|thumb|500x500px|EEM MSC General Configuration]] | ||
+ | |||
+ | The following parameters shall be provided: | ||
+ | |||
+ | {| class="wikitable" | ||
+ | ! Field !! Meaning !! Comments | ||
+ | |||
+ | |- | ||
+ | |<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.|| | ||
+ | |||
+ | |- | ||
+ | | <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> || If set, it means the MSC is available for ''[[Glossary|passive channel]]'' | ||
+ | || This also enables the following depending parameter. | ||
+ | |||
+ | |- | ||
+ | | <u>Request Identification Tag</u> || || | ||
+ | |||
+ | |} | ||
+ | |||
+ | ''Parameters ''configuration is shown in the screen below. | ||
+ | |||
+ | [[File:EEM MSC parameter configuration v1.0.jpg|centre|thumb|500x500px|EEM MSC Parameter Configuration]] | ||
+ | |||
+ | 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) | ||
+ | |||
+ | 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 ). | ||
+ | |||
+ | [[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 ).