28 Configuring Oracle User Messaging Service

28.4.1.3.1 Driver Application Archive (ear)

$oracle_home/communications/applications/sdpmessagingdriver-extension.ear

28.4.1.3.2 Common Properties

These are common driver properties that are indicative of the capabilities of this driver for use by the engine when routing outbound messages. Some properties are set by the driver developer and do not normally require modification, while others can be modified by the administrator to change the routing behavior. Some properties (such as sendingqueuesinfo) are for advanced use and only require modification for advanced deployment topologies. For a complete description of these properties and available values see the JavaDoc for driverconfigpropertynames.

28.4.1.3.3 Custom Properties

This driver supports multiple configuration groups called extension endpoint groups. An extension endpoint group holds the configuration for a remote endpoint at which to deliver extension notifications. Each endpoint must have a distinct combination of protocol and mapped domain. The properties of the extension endpoint group are listed in Table 28-3:

28.4.1.3.4 Extension Driver Security

If the remote extension endpoint is secured using WS-Security, then additional configuration of the extension driver is required. There are two typical WS-Security configurations that are supported. The extension driver can either use SAML tokens or username tokens.

1. To use SAML tokens, the Security Policies configuration property should contain value oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy, and the Keystore Alias configuration property should contain a valid alias for keystore entries that will be accepted by the remote extension endpoint.

2. To use username tokens, the Security Policies configuration property should contain value oracle/wss11_username_token_with_message_protection_client_policy, and the Credential Store Key configuration property should contain a valid alias for a credential store entry that will be accepted by the remote extension endpoint.

For more details about using WS-Security policies, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

28.4.1.3.5 Client API Messageinfo Support

Table 28-4 describes whether the protocol or driver implementation honors the following message delivery related properties that are specified through the client API.

28.4.1.3.6 Usage Instructions

Perform the following steps to use the extension driver:

1. Implement and deploy a Web Service listener endpoint based on the MessagingNotifyService WSDL (umsnotify.wsdl):

   <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                     xmlns:tns="http://xmlns.oracle.com/ucs/messaging/extension"
                     xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                     name="MessagingNotifyService"
                     targetNamespace="http://xmlns.oracle.com/ucs/messaging/extension">
    
       <wsdl:types>
    
       <xsd:schema targetNamespace="http://xmlns.oracle.com/ucs/messaging/extension">
         <xsd:element name="notification">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="messageId" type="xsd:string" minOccurs="0" maxOccurs="1">
                 <xsd:annotation>
                   <xsd:documentation>Unique message identifier from User Messaging Service.</xsd:documentation>
                 </xsd:annotation>
               </xsd:element>
               <xsd:element name="sender" type="xsd:string">
                 <xsd:annotation>
                   <xsd:documentation>The sender address.</xsd:documentation>
                 </xsd:annotation>
               </xsd:element>
               <xsd:element name="recipient" type="xsd:string">
                 <xsd:annotation>
                   <xsd:documentation>The recipient address (typically username).</xsd:documentation>
                 </xsd:annotation>
               </xsd:element>
               <xsd:element name="subject" type="xsd:string" minOccurs="0" maxOccurs="1">
                 <xsd:annotation>
                   <xsd:documentation>The subject of the message, if available.</xsd:documentation>
                 </xsd:annotation>
               </xsd:element>
               <xsd:element name="contentType" type="xsd:string" default="text/plain">
                 <xsd:annotation>
                   <xsd:documentation>The MIME type of the message. e.g. text/plain, text/html, text/xml.</xsd:documentation>
                 </xsd:annotation>
               </xsd:element>
               <xsd:element name="content" type="xsd:string">
                 <xsd:annotation>
                   <xsd:documentation>The main body of the message. Textual content only (no binary content).</xsd:documentation>
                 </xsd:annotation>
               </xsd:element>
               <xsd:element name="parameters" type="tns:parameter" minOccurs="0" maxOccurs="unbounded">
                 <xsd:annotation>
                   <xsd:documentation>Additional key-value pairs. This interface does not define any specific key-value pair meanings. Use of such parameters is defined on a private basis by particular implementations of this interface.</xsd:documentation>
                 </xsd:annotation>
               </xsd:element>
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
         <xsd:complexType name="parameter">
           <xsd:sequence>
             <xsd:element name="name" type="xsd:string">
               <xsd:annotation>
                 <xsd:documentation>Parameter name</xsd:documentation>
               </xsd:annotation>
             </xsd:element>
             <xsd:element name="value" type="xsd:string">
               <xsd:annotation>
                 <xsd:documentation>Parameter value</xsd:documentation>
               </xsd:annotation>
             </xsd:element>
           </xsd:sequence>
         </xsd:complexType>
         <xsd:element name="notificationResponse">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="messageId" type="xsd:string" minOccurs="0" maxOccurs="1">
                 <xsd:annotation>
                   <xsd:documentation>A message identifier returned in response to successfully accepting the message. If returned, the identifier should be unique. Note: A fault is raised if the message cannot be accepted.</xsd:documentation>
                 </xsd:annotation></xsd:element>
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
         <xsd:element name="notificationFault">
           <xsd:complexType>
             <xsd:sequence>
               <xsd:element name="code" type="xsd:string"/>
               <xsd:element name="message" type="xsd:string"/>
             </xsd:sequence>
           </xsd:complexType>
         </xsd:element>
       </xsd:schema>
     </wsdl:types>
     <wsdl:message name="notifyRequest">
       <wsdl:part element="tns:notification" name="parameters" />
     </wsdl:message>
     <wsdl:message name="notifyResponse">
       <wsdl:part element="tns:notificationResponse" name="parameters"/>
     </wsdl:message>
     <wsdl:message name="notifyException">
       <wsdl:part element="tns:notificationFault" name="parameters"/>
     </wsdl:message>
     <wsdl:portType name="Notify">
       <wsdl:operation name="invoke">
         <wsdl:input message="tns:notifyRequest"/>
         <wsdl:output message="tns:notifyResponse"/>
         <wsdl:fault message="tns:notifyException" name="NotifyException"/>
       </wsdl:operation>
     </wsdl:portType>
     <wsdl:binding name="NotifySOAPBinding" type="tns:Notify">
       <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
       <wsdl:operation name="invoke">
         <soap:operation
           soapAction="http://www.oracle.com/ucs/messaging/extension" />
         <wsdl:input>
           <soap:body use="literal" />
         </wsdl:input>
         <wsdl:output>
           <soap:body use="literal" />
         </wsdl:output>
         <wsdl:fault name="NotifyException">
           <soap:fault name="NotifyException" use="literal"/>
         </wsdl:fault>
       </wsdl:operation>
     </wsdl:binding>
    
     <wsdl:service name="NotifyService">
       <wsdl:port binding="tns:NotifySOAPBinding" name="Notify">
         <soap:address location="http://localhost:8001/NotifyService"/>
       </wsdl:port>
     </wsdl:service>
   </wsdl:definitions>
   

2. Configure the Extension Driver.

   1. Target the pre-deployed extension driver called usermessagingdriver-extension or a new deployment to the appropriate servers where UMS (usermessagingserver) is running and start the driver.

   2. In Enterprise Manager Fusion Middleware Control, navigate to the usermessagingserver Home Page. Click User Messaging Service > Driver Properties.

   3. Select and Edit the driver usermessagingdriver-extension or Create a new driver with the same name as your new driver deployment.

   4. Under Driver-Specific Configuration, add a new Extension Endpoint configuration group and specify the correct properties: EndpointURL is the URL to the web service listener endpoint created in Step 0 Protocol is the value of the new messaging channel for which you want to add notification support (for example: popup).

   5. Under Common Configuration, update Supported Protocols with a comma-separated list of protocols defined in each Extension Endpoint group.

   6. Click OK to save the configuration.

This completes the configuration and integration of a new messaging channel (protocol) in UMS using the Extension Driver.

To send notifications to this new channel (protocol), recipients must be specified for the URI delivery type using the URI addressing format URI:<scheme>:<scheme-specific-address-value>, where <scheme> is the protocol. The URI delivery type is optional. For example, if the extension driver was configured to support the protocol popup, an application can compose a message to popup:john.doe@example.com.

End users can also declare their messaging preferences by creating a new Messaging Channel for the new channel type in the Worklist/UMS Preferences UI. Note that user preferences are only applied when applications send user-based notifications (that is, to recipients of the form USER:username).

28.4.1.4.1 E-mail Driver Interoperability

This section details interoperability features of the e-mail driver.

The e-mail driver is compatible with these protocols: pop3, imap4, and SMTP.

E-mail driver features include:

• automatic connection retry

• smtp for message sending

• imap4 and pop3 for message receiving (using polling)

• scalable, highly available

• prevents message loss and avoids duplication

the gateway vendors and versions in Table 28-5 have been verified.

28.4.1.4.2 Common Properties

these are common driver properties that are indicative of the capabilities of this driver for use by the engine when routing outbound messages. some properties are set by the driver developer and do not normally require modification, while others can be modified by the administrator to change the routing behavior. some properties such as sendingqueuesinfo are for advanced use and only require modification for advanced deployment topologies. for a complete description of these properties and available values refer to the javadoc of driverconfigpropertynames.

28.4.1.5.1 SMPP Driver Interoperability

This section details interoperability features of the SMPP Driver.

The SMPP driver is compatible with these protocols: SMPP v3.4.

SMPP Driver features include:

• Automatic connection retry

• HTTP proxy for firewall traversal

• Authentication configuration

• Configurable chunk size

• Bulk Sending

• Encoding: UCS2, IA5, GSM_DEFAULT

• Priority Setting

• Configurable Window size

• Plain text content only

The Gateway Vendors in Table 28-9 have been verified.

28.4.1.5.2 Common Properties

These are common driver properties that are indicative of the capabilities of this driver for use by the engine when routing outbound messages. Some properties are set by the driver developer and do not normally require modification, while others can be modified by the administrator to change the routing behavior. Some properties such as SendingQueuesInfo are for advanced use and only require modification for advanced deployment topologies. For a complete description of these properties and available values refer to the javadoc of DriverConfigPropertyNames.

28.4.1.6.1 About XMPP

XMPP is an open, XML-based protocol for Instant Messaging and Presence. XMPP-based software is deployed on thousands of servers across the Internet and is used by millions of people worldwide. XMPP consists of a client/server architecture, which resembles the ubiquitous e-mail network. XMPP servers are completely decentralized, allowing anyone to set up their own server. Messaging is achieved as in the e-mail network, where recipients are addressed by an XMPP ID (or Jabber ID or JID) with the following form: [username]@domain[/resource]. Please refer to RFC 3920 for details on the addressing scheme.

In an XMPP network, users identified by their XMPP IDs as mentioned above (which typically consist of a username and the domain of the XMPP server to which the user connects). An end user of XMPP connects to an XMPP server using an XMPP client in order to send instant messages to other XMPP users. XMPP, however, is not the only protocol network available for instant messaging. XMPP has an extensible and modular architecture. It integrates with proprietary IM networks, enabling XMPP users to communicate with those on other networks.

In order to use the XMPP Driver in UMS, you must have access to a Jabber/XMPP server and an XMPP account for the UMS XMPP Driver instance to login as.

28.4.1.6.2 XMPP Driver Interoperability

This section details interoperability features of the XMPP Driver.

The XMPP driver is compatible with these protocols: XMPP (RFC 3920, 3921).

XMPP Driver features include:

• Automatic connection retry

• HTTP proxy for firewall traversal

• Plain text content only

In addition to Oracle Beehive, the Gateway Vendors and Versions in Table 28-9 have been verified.

28.4.1.6.3 Third-Party Software

The XMPP Driver uses or requires the following third-party software (you may optionally choose to install and configure your own XMPP server):

28.4.1.6.4 Driver Application Archive (EAR)

$ORACLE_HOME/communications/applications/sdpmessagingdriver-xmpp.ear

28.4.1.6.5 Common Properties

These are common driver properties that are indicative of the capabilities of this driver for use by the engine when routing outbound messages. Some properties are set by the driver developer and do not normally require modification, while others can be modified by the administrator to change the routing behavior. Some properties such as SendingQueuesInfo are for advanced use and only require modification for advanced deployment topologies. For a complete description of these properties and available values refer to the javadoc of DriverConfigPropertyNames.

28.4.1.7.1 VoiceXML Driver Interoperability

This section details interoperability features of the VoiceXML Driver.

The VoiceXML driver is compatible with these protocols: VoiceXML over HTTP (VoiceGenie gateway protocol).

VoiceXML Driver features include:

• VoiceXML content only

The Gateway Vendor and Version in Table 28-18 has been verified.

28.4.1.7.2 Common Properties

These are common driver properties that are indicative of the capabilities of this driver for use by the engine when routing outbound messages. Some properties are set by the driver developer and do not normally require modification, while others can be modified by the administrator to change the routing behavior. Some properties such as SendingQueuesInfo are for advanced use and only require modification for advanced deployment topologies. For a complete description of these properties and available values refer to the javadoc of DriverConfigPropertyNames.

28.4.1.8.1 Install the Worklist Driver on Oracle WebLogic Platform

To enable the messaging worklist feature, the WebLogic SOA domain must be extended using the extension template available at $ORACLE_HOME/common/templates/applications/oracle.ums.driver.worklist_template_11.1.1.jar. To extend a SOA domain using the Oracle Fusion Middleware Configuration Wizard:

1. Launch Oracle Fusion Middleware Configuration Wizard ($ORACLE_HOME/common/bin/config.sh or %ORACLE_HOME%\common\bin\config.cmd).

2. Select the Extend an existing WebLogic domain option.

3. Select the desired SOA domain directory.

4. Select the Extend my domain using an existing extension template option.

5. Click Browse, and navigate to $ORACLE_HOME/common/templates/applications

6. Select oracle.ums.driver.worklist_template_11.1.1.jar

7. Complete the remaining steps of the Oracle Fusion Middleware Configuration Wizard, and restart the SOA servers.

28.4.1.8.2 Install the Worklist Driver on IBM WebSphere Platform

To enable the messaging worklist feature, the WebSphere SOA cell must be extended using the extension template available at $ORACLE_HOME/common/templates/was/oracle.ums.driver.worklist_template_11.1.1.jar. To extend a SOA cell using the Oracle Fusion Middleware Configuration Wizard:

1. Set the environment variable CONFIG_JVM_ARGS with the value -DTemplateCatalog.enable.selectable.all=true. For example, in Linux bash shell: exportCONFIG_JVM_ARGS="-DTemplateCatalog.enable.selectable.all=true" At the Windows command prompt: set CONFIG_JVM_ARGS=-DTemplateCatalog.enable.selectable.all=true

2. Launch Oracle Fusion Middleware Configuration Wizard ($ORACLE_HOME/common/bin/was_config.sh or %ORACLE_HOME%\common\bin\was_config.cmd).

3. Click Select and Configure Existing Cell.

4. Select the desired SOA cell and click Next.

5. Select Oracle User Messaging Service Worklist Driver on the Add Products to Cell screen and click Next.

6. Complete the remaining steps of the Oracle Fusion Middleware Configuration Wizard with default selections, and restart the SOA cell.

28.4.1.8.3 Common Properties

The following common driver properties are indicative of the capabilities of this driver for use by the engine when routing outbound messages. Some properties are set by the driver developer and do not normally require modification, while others can be modified by the administrator to change the routing behavior. Some properties such as SendingQueuesInfo are for advanced use and only require modification for advanced deployment topologies. For a complete description of these properties and available values see the javadoc of DriverConfigPropertyNames.

28.4.1.8.4 Custom Properties

The following custom property is available:

28.4.1.8.5 Client API MessageInfo Support

This table shows if the protocol or driver implementation honor the following message delivery-related properties that are specified through the client API.

28.4.1.9.1 Common Properties

These are common driver properties that are indicative of the capabilities of this driver for use by the engine when routing outbound messages. Some properties are set by the driver developer and do not normally require modification, while others can be modified by the administrator to change the routing behavior. Some properties such as SendingQueuesInfo are for advanced use and only require modification for advanced deployment topologies. For a complete description of these properties and available values refer to the javadoc of DriverConfigPropertyNames.

http://<host>:<port>/sdpmessaging/parlayx/SendMessageService