26 Configuring Oracle User Messaging Service

26.4.1.3.1 Driver Application Archive (EAR)

The EAR file is $oracle_home/communications/applications/sdpmessagingdriver-extension.ear.

26.4.1.3.2 Common Properties

These are common driver properties that are indicative of the capabilities of this driver for use by the messaging 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. See Table 26-2. For a complete description of these properties and available values, see the JavaDoc for driverconfigpropertynames.

26.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 26-3:

26.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.

To use extension driver security:

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 is 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 is 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.

26.4.1.3.5 Client API Messageinfo Support

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

26.4.1.3.6 Usage Instructions

Perform the following steps to use the extension driver:

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 predeployed 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.

   3. Click User Messaging Service > Driver Properties.

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

   5. 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 1. Protocol is the value of the new messaging channel for which you want to add notification support (for example, popup).

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

   7. 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).

26.4.1.4.1 Email Driver Interoperability

This section details interoperability features of the email driver.

The email driver is compatible with these protocols: POP3, IMAP4, and SMTP.

Email driver features include:

• Automatic connection retry

• SMTP for message sending

• IMAP4 and POP3 for message receiving (using polling)

• scalable, highly available

• Message loss prevention and duplication avoidance

The gateway vendors and versions in Table 26-5 have been verified.

26.4.1.4.2 Common Properties

Table 26-6 lists common driver properties that are indicative of the capabilities of this driver for use by the messaging 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.

26.4.1.5.1 SMPP Driver Interoperability

This section details interoperability features of the SMPP Driver.

The SMPP driver is compatible with this protocol: 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 26-9 have been verified.

26.4.1.5.2 Common Properties

Table 26-10 lists common driver properties that are indicative of the capabilities of this driver for use by the messaging 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.

26.4.1.6.1 Introduction to XMPP

XMPP is an open, XML-based protocol for IM 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 email network. XMPP servers are completely decentralized, allowing anyone to set up their own server. Messaging is achieved as in the email network, where recipients are addressed by an XMPP ID (or Jabber ID or JID) with the following form: [username]@domain[/resource]. See 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 to send instant messages to other XMPP users. XMPP, however, is not the only protocol network available for IM. XMPP has an extensible and modular architecture. It integrates with proprietary IM networks, enabling XMPP users to communicate with those on other networks.

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 with which to log in.

26.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

The gateway vendors and versions in Table 26-13 have been verified.

26.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):

26.4.1.6.4 Driver Application Archive (EAR)

The EAR file is $ORACLE_HOME/communications/applications/sdpmessagingdriver-xmpp.ear.

26.4.1.6.5 Common Properties

Table 26-15 lists common driver properties that are indicative of the capabilities of this driver for use by the messaging 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.

26.4.1.7.1 VoiceXML Driver Interoperability

This section details interoperability features of the VoiceXML Driver.

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

The VoiceXML driver features include:

• VoiceXML content only

The gateway vendor and version in Table 26-18 has been verified.

26.4.1.7.2 Common Properties

Table 26-19 lists common driver properties that are indicative of the capabilities of this driver for use by the messaging 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.

26.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.

26.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.

26.4.1.8.3 Common Properties

The common driver properties shown in Table 26-22 are indicative of the capabilities of this driver for use by the messaging 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.

26.4.1.8.4 Custom Properties

The custom property shown in Table 26-23 is available.

26.4.1.8.5 Client API MessageInfo Support

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

26.4.1.9.1 Common Properties

Table 26-25 shows common driver properties that are indicative of the capabilities of this driver for use by the messaging 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.

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