Chatting or instant messaging is a valuable for of communication, somewhere between email (very asynchronous) and telephone/Skype/VoiP/HangOut (synchronous) and quite similar to SMS. Unfortunately, there is has been an explosion in the number of IM protocols and services, many of which cannot talk to each other. Whatsapp is perhaps the most popular chat-like service, but it lives on its own. Google Talk (now assimilated into GMail and Google Hangouts) started as a relatively open service (based on the XMPP standard for IM), but is now largely proprietary. AOL, MSN, ICQ, Facebook, Skype, Twitter – many different largely closed networks within in which users can interact in char-style. But unfortunately hardly across which. Not like emails for example that float freely between domains, servers and vendor technologies.
Having said all that, XMPP is still supported by many tools and servers – and it is still used by large numbers of users. Not just for chatting, but for other types of push-style interaction. See this Slideshare presentation for a nice intro into XMPP. Note that it mentions some attempts to create gateways to connect the worlds of XMPP, Skype, AOL/AIM, IRC.
The goal of this article is not to commiserate over XMPP. It is to show you how SOA Suite can be configured to participate in XMPP based conversations – for now only as a sender of messages (we will discuss inbound integration with XMPP in a later article). In SOA Suite 12c, the functionality that was already available from the UMS (User Messaging Service) and the UMS Adapter in SOA Suite 11g has been continued and a little bit extended. I will show you what it looks like and how to make it to work.
Steps:
- Get access to two IM accounts on an XMPP server: one to send the chat message from (the account you will set up in the XMPP driver) and one to send the test message to; you probably also need a chat client to see the chat message arriving
- Ensure that the UMS Adapter and the associated applications and libraries are deployed to the managed server that is running the SOA Suite run time (and are up and running)
- Create the configuration for the XMPP Driver (on the SOA Suite managed server)
- Enable the Human Workflow engine’s notification service to support the IM channel
- Send a test message from the SOA Suite to a destination IM address
Note: you may have to restart the WebLogic managed server somewhere along the line (I did, after making some of the configuration changes)
Get access to two IM accounts on an XMPP server
There are many services offered on the internet where you can easily create free XMPP chat accounts. I have made use of two of these – https://duck.co/ and http://www.einfachjabber.de but you can of course create your own. At DuckDuckGo I created an account called saibotcustomer ( @dukgo.com) – this account is used for the fictitious airport Saibot Airport in Lexville that is central in the case for the Oracle SOA Suite 12c Handbook that I am in the middle of writing). At einfachjabber.de I created an account called saibot.airport (@einfachjabber.de). This second account will represent the information desk of the imaginary airport. This account will be the one used to configure the XMPP driver in the SOA Suite run time environment.
There are also many clients that will help you interact with XMPP servers and with your chat contacts. I have used the open source Pidgin client for this example: http://pidgin.im/. This client can connect with many other chat (IM) services in addition to XMPP, although that is not relevant for me in this case.
In Pidgin, you can manage multiple XMPP (and other protocol) accounts – and interact through each of them.
I have added both accounts relevant to this article in Pidgin:
For the account on the einfachjabber.de server, the account configuration is shown next:
I have checked whether the two accounts can actually send messages to each other. First they added one another as authorized buddies:
Here we have account SaibotCustomer@dukgo.com add saibot.airport@einfachjabber.de as his new best buddy – using the local alias Saibot Airport Administration.
The account saibot.airport@einfachjabber.de has to accept this buddy request, or customer has to accept the reverse request from the Saibot Airport (to add the customer as Travelling Customer to his buddy group called Customers):
Pidgin presents this dialog to the customer:
For example: as saibotcustomer(@dukgo.com), we can now start a new conversation with our new best buddy:
Ask for help:
The Saibot Airport administrators receive that message, and respond instantaneously:
Their response goes to the customer
and we have now established that the two accounts are working, Pidgin is doing a fine job of connecting to both and they can talk to each other. The question now is: can the SOA Suite also talk to the customer, on behalf of the Saibot Airport staff?
Ensure that the UMS Adapter and the associated applications and libraries are deployed and running
After creating a fresh installation with the Oracle Installer – configuring separate managed servers for SOA Suite (soa_server1) and Service Bus (osb_server1) next to the AdminServer – I discovered when I fired up my WebLogic domain that the libraries and applications required for doing the XMPP conversations were installed, but not yet deployed to the soa_server1 target.
In short, when you go into the WLS Console and open the Deployments overview, you have to check these two libraries
and these enterprise applications
and make sure that they are all deployed, targeted to the managed server with the SOA Suite run time (in my case soa_server1) and have status Active:
Note: I ran into some errors. The usermessagingdriver-xmpp application would not start. It ended up from New in state Prepared. On closer inspection, the soa_server1.out log file contained this message:
<Aug 5, 2014 3:41:57 PM CEST> <Warning> <oracle.sdpinternal.messaging.driver.xmpp.XMPPResourceAdapter> <SDP-26200> <An exception was caught. oracle.sdp.messaging.driver.DriverException: XMPPDriver could not initialize.
at oracle.sdpinternal.messaging.driver.xmpp.XMPPResourceAdapter.createDriver(XMPPResourceAdapter.java:600)
This problem occurred when the configuration for the XMPP driver was invalid and did not allow the driver to correctly startup. In this specific case I tried to configure the XMPP driver for Google’s chat service – something that I do not believe is possible at this point in time. Or at least, I have given up on it.
At another moment, I saw this message:
<Aug 5, 2014 2:40:40 PM CEST> <Warning> <oracle.sdpinternal.messaging.driver.xmpp.XMPPResourceAdapter> <SDP-26249> <No configuration was found for this XMPP Driver deployment: usermessagingdriver-xmpp. Driver disabled until a configuration is created.>
It was present in the log file before I had created the XMPP Driver configuration (see the next section) (and after I had deleted that configuration).
When I tried to send an IM message, I also noticed this error:
<Aug 5, 2014 2:43:34 PM CEST> <Warning> <oracle.sdpinternal.messaging.DriverLocatorImpl> <SDP-25087> <No matching driver found for delivery type = IM.>
which was the result of the previous message: no (valid) configuration was found and there the XMPP driver was not available at all. The remedy clearly was to add a valid configuration.
Create the configuration for the XMPP Driver (on the SOA Suite managed server)
Open the EM FMW Control. Click on the node User Messaging Service | usermessagingdriver-xmpp (soa_server1). Note: soa_server1 is the name of the managed server; in your environment this managed server may have a different name.
In the right side of the page, open the dropdown menu and select XMPP properties:
The properties page opens. The important fields to set are:
- IM Server Host – set to the domain of the XMPP Server on which the account is located that is used for sending messages; in my example that is einfachjabber.de
- IM Server Port – this is 5222 by default (for almost all XMPP servers)
- IM Server Username – the account name (with or without domain) for the XMPP server account that is used to send messages from (and receive messages into); in my case that would be saibot.airport or saibot.airport@einfachjabber.de
- IM Server Password – the password for the account configured under IM Server Username.
Note: I am not sure whether the sender address has to be specified as well. I have set it to IM:saibot.airport@einfachjabber.de and it works – but if it is necessary or even relevant, I am not sure.
After pressing OK, the XMPP driver configuration is created, as is shown in this screenshot:
Enable the Human Workflow engine’s notification service to support the IM channel
We still have to configure the workflow notification properties. Once again, with the soa-infra node selected, open the dropdown menu and select SOA Administration | Workflow Properties:
In the page that appears next, set the Notification Mode to All . Press Apply to make the change last.
Confirm the changed properties once again:
At this point, you may need to restart the managed server – to me it seemed necessary, but maybe first try the next section without a resort and keep it in mind when you run into an error mentioning the Notification Mode.
Send a test message from the SOA Suite to a destination IM address
Select the node SOA | soa-infra. Open the dropdown menu and select Service Engines | Human Workflow.
Open the tab Notification Management.
Click on Send Test Notification.
In the popup that opens next, set the Channel to IM. Type the destination XMPP account (in my example saibotcustomer@dukgo.com) in the Send To field. Note: this should not be the account configured in the XMPP Driver configuration, because that is the account from which the message is sent. The subject is not relevant for instant messaging. The content however is. Press the Send button.
The UMS is invoked using the XMPP Driver configuration and if all was set up correctly, the chat message is now being sent:
In our chat client (Pidgin in my case) the test message should arrive shortly:
This proves that our configuration is correct.
The Notification Management tab contains an overview of the Outgoing Notifications that have been sent. Here we see an entry for the test message that was sent through the IM channel.
Further steps
Now that we know that our UMS service is capable of sending chat messages, we can leverage this in SOA composites that use the (outbound) UMS Adapter, configured for the IM channel. Simple SOA composites (or complex ones for that matter) can easily send out chat messages to human partners (or anyone with an XMPP account).
Resources
FMW 12.1.3 documentation on configuring the UMS Adapter: http://docs.oracle.com/middleware/1213/adapters/develop-soa-adapters/ums_adapter.htm#CHDCHJJC
