Screenflows with BPM and ADF 12c

BPM 12c came with a slew of features that were scrapped when Oracle truly integrated the acquired BEA’s BPM implementation. One of those features is “screenflows”. I guess some of you, if not all of you have ever come across the situation where you needed to retrieve some information from a user using a human task, then do some logic and immediately provide the same user with a new screen for processing this data without having to go back to the tasklist.

In 11g there was no (out-of-the-box) way to do so, other than using the human workflow api or simply doing a service call from the existing task flow and not really going back to the process. Well now you can! And we are going to demonstrate it in this post. Now this feature is easily configured. We first need to make sure the server is configured correctly. Because this feature uses JMS messaging to function we need to a new topic as well as a new connection factory.

In WLS console in BpmModule create a new topic:


Name: UIBrokerTopic
JNDI Name: jms/bpm/UIBrokerTopic
Type: Topic (or Distributed unified Topic if clustered)

Create a new connection factory:


Name: UIBrokerTopicConnectionFactory
JNDI Name: jms/bpm/UIBrokerTopicConnectionFactory
Type: Connection factory Last step in configuration is the enablement of the process broker in the Enterprise Manager.

Therefore navigate to the following MBean:

mbeans> BPMNConfig > DisableProcessBroker and set it to “false“.

Restart your managed servers.

So now we can actually develop a BPM process with a number of sequential user interactions. In between these user interactions we can do some logic to define which user interaction needs to be displayed next. What we want to happen when running this process and testing it using the EM and BPM Workspace is to see the various task screens popup automatically after we have finished the current task, without having to return to the task list.


All the configuration to make this work is done in the ADF Taskflow. Specifically in the hwtaskflow.xml file. I presume that we have created these task flows either manually or by using the wizard. We need to declare whether we want the task flow to wait for a new screen to popup or not. We can do this by adding the “ScreenFlowMode” element to the task flow definition and setting it to “true”. It does not matter which user interaction will come up next, as long as it is for the same user it will be shown to the user.

However it seems that at least for now you  need to mark the last user interaction in the flow with “ScreenFlowMode= false” to make sure you return to the task list immediately after finishing this task. Otherwise the human task engine will make you wait for 10 to 12 seconds before returning to the tasklist. This wait time seems to be the timeout for the screenflow mode. This can be a positive as well as a negative. It means when your server is overloaded and processing takes too long, you will be returned to the tasklist. The positive here is that you can always pick up where you left off.

There is still lots of stuff I do not know about screenflow mode. This is both technical and functional. When to use ScreenFlowMode or when to simply combine multiple screens in an ADF taskflow. Also the exact technical details of how ScreenFlowMode works I do not know just yet… I will update this post over time when I find out more.

Lets go back to the screens. After deploying the BPM process as well as the 3 ADF taskflows we can test if the screenflow works. Start a test case and open the worklist. When you finish a task it immediately jumps to the next without going back to the tasklist. Hooray!


After clicking an outcome, we immediately get to see the summary screen:


So thats it for today, feel free to comment!


So I now have some extra information about the inner workings of this feature. As it turns out the topic is used to notify the human workflow engine of the next screen in the flow. So when the BPM Process engine encounters a new User Interaction it will post a message on the topic which is then supposedly the trigger for the Human Workflow Eninge to display the accompanying taskflow.

Now there are a couple of pro’s and con’s to the screenflow engine as it is right now. (Release 12.1.3)


– A screenflow is not confined to the contents of a single BPM process / instance. It can continue into subflows or other proces instances, as long as it is for the same user of course and there is no marked end. (using ScreenFlowMode = false)

– You can always pick up where you left when you closed the browser since they actually are individual tasks. (and transactions)

– A screenflow works with any BPM process and needs no design time specific configuration. Only the ADF Taskflow needs this configuration (ADF Taskflows should be separated from the process anyway)


– There is no configurable timeout for the screenflow. It is now set for 10 seconds. From a UI designers perspective this is more than enough, since I really dont want any user to wait for more than 10 seconds before the screen pops up. Update: A patch has been released for this con. (20361155) It allows you to set the timeout in the preferences pane of the worklist application.

– Design-time declaration of which user interaction is the last one in the screenflow. I can foresee situations where it is not clear which wil be the last user interaction in the flow because of business logic. Also the declaration of which interaction is the last one in the flow is done in the ADF View layer which seems weird because you are actually putting a bit of business logic there as well.

– It’s a quite hidden feature,  I have a feeling this will improve over time.

In my opinion it would be great if we could add the possibility to mark a dynamic screenflow start and end in BPM so the view layer could remain nicely ignorant of business logic. Also I have a feeling this feature will become easier to configure and use in future releases…



  1. What about Guided Activities? they were introduced with PS5, and provided “screen flow” capabilities.That implementation used iFrames and was polling of the bpm instance for next the Human Task, and that it is why your cursor was always “busy”. I can see how JMS topic can improve user experience, but there still is a “wait” time, probably because of the asynchronous nature of the process, so we are still “guessing” when and if there is a next Human Activity.


    1. Hi, good point, I personally never used the Guided Activities but guess the effect is still the same. You control you business logic and the sequencing of human tasks from BPM. However the user experience is always lacking a bit when you are doing intensive operations in between consecutive screens. Also there will be no decent error handling when the timeout is reached. And in the case of screen flows there is not a truly loose coupling because you need to specify the end of the flow in the ADF task flow thus putting some business logic in the view layer.

      I do however prefer the topic opposed to the polling mechanism because it is much more lightweight especially if you consider scaling.


Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen. logo

Je reageert onder je account. Log uit / Bijwerken )


Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s