Tuesday, March 18, 2014

Oracle User Messaging Service: Implementing custom messaging channels

Oracle User Messaging Service or UMS enables two-way communication between applications and users. There is support for a variety of messaging channels like email, IM, SMS and voice. Another option is to deliver messages to a user’s work list.

With UMS messaging preferences users can define how and when they want to receive message notifications. They can define filter criteria to only receive messages they are interested in. Applications can send messages to a user respecting their preferences or send messages over a specific channel.

In addition to the default channels, organisations can define custom channels using the Messaging Extension Driver. Messages for such channels are then delivered to a web service listener endpoint. This web service implements the actual delivery of the notification for that specific channel.

In this blog I’ll show the steps needed to send messages through a custom channel: 1) Implementing the Message Notify Service interface 2) Configuring the Messaging Extension Driver 3) Adding the channel to your user's message channels 4) Sending messages

Implementing the Message Notify Service interface

To be able to use the web service in the Messaging Extension Driver of UMS it should implement the Messaging Notify Service WSDL. The content of this WSDL is listed in the Admin guide here.

To quickly implement the service Message Notify Service interface I created a SOA composite that puts the contents of the notification message in a file using the File Adapter as illustrated above.

Configuring the Message Extension Driver

By default an instance of the usermessagingdriver-extension application is deployed but not targeted to any servers. To enable the driver, use the Administration Console to target it to the servers where UMS is running.

To configure the driver navigate to the usermessagingserver home page in the Enterprise ManagerClick User Messaging Service > Driver PropertiesSelect and Edit the driver usermessagingdriver-extension.

Under Driver-Specific Configuration, add a new extension endpoint configuration group and specify the correct properties:
  • Group: CUSTOM
  • Endpoint URLhttp://localhost:8001/soa-infra/services/default/MessageNotifyService/MessageNotifyService
  • Protocol: CUSTOM
Click OK to save the configuration.

Adding the channel to your user's message channels

To be able to receive messages over the custom channel, it must be added to your user’s messaging channels using the UMS preferences UI.

Login at http://localhost:8001/sdpmessaging/userprefs-ui with your user credentials and create a new messaging channel with the following properties:
  • Name: My custom channel
  • Type: CUSTOM
  • Address: nico
  • Set a default channel: true
The address is your unique user address for the custom channel similar to your email address. By setting the default property the channel will also be used to deliver messages that were sent to you based on user preferences.

Notice the warning at the bottom of the popup. The Notification Service used by the BPEL User Notification activity and Human Workflow is based on UMS. Unfortunately this service only supports the default channels where the user's channel address like email or phone number is fixed to the information stored in the identity management system.

Sending messages

To send messages with support for all channels UMS we have to use UMS directly using one of the  multiple UMS APIs. These include an EJB API, a plain Java API and a Web Service API . In this example we will use the Web Service API as documented here.

In JDeveloper create a new Java project and add the following libraries:
  • Web Service Data Control
  • BC4J Security
  •  JAX-RPC Client
and add the following JAR files:
  • sdpmessagingclient.jar
  •  sdpmessagingcommon.jar
  •  Oracle.http_client_11.1.1.jar
  • Oracle.logging-utils_11.1.1.jar

Create a new instance of the messaging client using the following code snippet:

HashMap<String, Object> config = new HashMap<String, Object>();
config.put(ClientConstants.POLICIES, new String[]{});

MessagingClient mClient = new MessagingClient(config); 

And send a message to a user using the custom channel:
Message message = MessagingFactory.createTextMessage("You received a message");
message.setSubject("Message over custom channel");
mClient.send(message, null,null);

That's it! There should be a new instance of your Message Notify Service composite delivering the message to a file on your server.

To send a message to a user based on his preferences set the address as following:


Now not only the custom channel is used to deliver the message but also the other channels marked as default like the email channel for example.

Thursday, February 13, 2014

Experiencing Interaction '14

Interaction '14 logoLast week I visited Interaction ’14 which was held in Amsterdam. Interaction is the annual interaction design conference built around a global community. As User Experience Expert I attended several Computer Human Interaction conferences before, but never this one. And I must say it was a very inspirational experience.

Context influences perception
One of the key takeaways was that context influences perception. This was shown in the talk by Bernard Lahousse (Partner at Foodpairing.com). He stated that the perception of food changes by the context in which it is served. To prove this, he asked a volunteer on stage and let him rub a rough object and simultaneously taste a drink, a minute later this subject had to taste another drink while rubbing a soft stuffed animal. The subject stated that the 1st drink tasted sharp/bitter and the 2nd drink more creamy/sweet. In fact he drank the same drink twice. So a tactile context influences perception of food.
The same goes for a bottle of wine you take home with you after a great holiday in Greece, because it tasted so well in a Greek tavern after a day of sunshine in Mediterranean air. Drinking the wine at home on a drizzling Saturday evening is perceived totally different.

The message of this talk matches very well with the talk by By Thomas K├╝ber (Design lead at Groupon) and Christian Drehkopf (User Experience Evangelist and Mentor) in which they stated that we, as interaction designers, should not design for devices but “we should deliver experiences that create superb value for the users in their personal situation/context”.

Design motivation and curiosity
In order to inspire users to use the applications or products we design, we have to motivate users and make them curious. At Interaction ’14 there were 2 talks which gave some insight in how to do this.

There was Ellis Bartholomeus (Game- & Design consultant). She explained that motivation can be designed via play. To play you need a game (= the definition of the rules and goals) and a player (= the person interacting). To motivate the player to play the game, the player needs to feel safe and trust the game. The game should be hard to play, but not too hard. If the player barely completed the level, he will be curious about himself in the next level and be very loyal to play it again. A player will be motivated by a game if it contains wonderment, engagement, frustration, reward, surprise, irritation, freedom competence and joy.

Jan Willem Huisman (founder of IJsfontein Interactive Media) talked about how “curiosity and playfulness are deeply embedded in our mind and feed the urge for learning and exploring”. Users need structure, and must always feel in control.  By nature users also are curious and motivated and these characteristics should be fed by the applications/product they use. Curiosity is the urge to fill the information gap and curiosity can be designed among others by:
  • leaving room for experiments
  • telling what to expect and then hiding it
  • creating violation of expectations
  • creating a sequence with an unknown ending
  • introducing novelty
  • introducing information that is possessed by others.
  • creating collaborative curiosity
However, the user should always be in control. “If we take control of the user, we kill curiosity” says Huisman.

Onlyness & Design Loneliness
I attended two talks pleading that good user experience design always involves a team.
Tash Wong (independent product designer) talked about Onlyness by which she means the fact that “we all have our own perspective and own unique feminine or masculine point of view from which we design. We are social engineers that design for behavior and communication.” To be able to design products/applications for others we need empathy and look at things from different points of view. Tash Wong developed a method containing a set of 16 cards which is designed to help UX designers better articulate their perspectives and priorities. The cards can be used to communicate the direction for a project, figure out why we do, what we do, or generate new ideas and then ‘Think Bigger to Make Better’.

Then there was Christopher Noessel (Managing Director at Cooper) talking about Design Loneliness and ‘Pair Design, Why You Need It’. In Agile developing software development pair programming is common. In UX design working in pairs also leads to better results. What you need is a pair of 2 designers: a generator (who generates ideas and sketches) and a synthesizer (who analyses and connects). Co-working like this results in a better design, a more efficient way of working and a happier team. While co-working like this, 3 rules should be taken into account:
1. There can only be one marker in the room
2. Ideas should be visualized, not only talked about
3. Feedback is given (mainly by the synthesizer)
    - What’s good
    - Questions?
    - Suggestions for improvement 

At Vennster we already work like this and from experience I can tell that it works.

Last week I have been listening to many experts in the field of interaction design and I gained a lot of inspiration which I definitely can use in the projects I’m currently working on as a User Experience Consultant for Vennster and in the ones I will be working on in the future.
If you want to read more about the lectures given at Interaction ’14 just visit their site http://interaction14.ixda.org

Sunday, January 19, 2014

Tracking progress of your BPEL process using sensors

Often when you start using Oracle SOA Suite11g and BPEL you need a mechanism to help the end users keep track of the progress of the overall process instances. The EM shows this to administrators, but this is not suitable for end users.

What about the worklist application?

The SOA Suite offers the worklist application to handle tasks and to view progress using views and reports. It shows human tasks, crossing multiple process definitions. It does not show invocation of services or specific data changes in the process. The figure below shows three instances of one specific process definition. In this example relevant milestones are reached when the process starts, the first automated step is executed, the second human task is executed and when the process ends. In the worklist application you would be able to see what human tasks are open or executed by which user. With the worklist application you can't keep track of the first, second and last milestone, only of the third one because that is the only one associated with a human task. 

Sensors and sensor actions

The required functionality can be accomplished using sensors and sensor actions on relevant parts in the BPEL process. There are different types of sensors that can be used in SOA Suite 11g: activity sensors, variable sensors and fault sensors.

After you have configured the sensor in your BPEL process, you need to define one or more sensor actions. There are four types of actions: three sensor actions and one BAM sensor action:

  • Database to publish it to the BPEL dehydration store
  • JMS to publish it to a JMS topic or queue. If the JMS provider is not local, you can use the JMS adapter
  • Custom Java class to handle it in a different way. 
  • BAM Sensor actions to publish them to Oracle BAM.
You can chose to publish the sensor to AQ, so you can handle it both with Java clients and with PL/SQL because JMS queues in WebLogic can be implemented using AQ. 

Displaying the information with BAM or a custom application

There are two ways to show the progress to the end user: using BAM or building a custom application on top of the sensor data. You can easily decide to implement BAM later: you can either add BAM sensor actions to the BPEL sensor, or define a Enterprise Message Source in BAM. 

Option 2 (defining an Enterprise Message Source) has the advantage of not having to change the BPEL process (design time) when you decide to start using BAM rather than or on top of the custom application. 


Now that we have established how we want to implement the functionality, we can get started :) The following steps need to be taken:
  1. Define the relevant milestones you want to show to the user;
  2. Configure the sensors;  
  3. Configure the sensor actions;
  4. Create the database user and queues for AQ;
  5. Configure WebLogic Server and add JMS objects;
  6. Create PL/SQL code to read from the queue and store it in the table;
  7. Deploy the BPEL process;
In parallel you can build the GUI or configure BAM, depending on what you decided upon.