Tuesday, August 31, 2010

Together with another jBPM enthusiast, we submitted this session to the JFall 2010 call for papers:

AbstractSNS Bank is a leading provider of on-line internet banking products within the Dutch financial market. The last three years she has been converting her activities from a traditional branch offices to an on-line experience. This transition has involved extensive business process implementations to put both internal service processes, external service processes as well as product selling channels online.

An important part of their processes has always been connected to human tasks, as the financial world often requires human validation / intervention at crucial points in the various processes. To facilitate BPM human tasks SNS Bank has implemented various jBPM GUI solutions. These solutions have led to some important lessons when interacting with jBPM that we will present.

These lessons have led to the In2Flow application provides this session with a great example of how to interact in your jBPM processes using human tasks. This implementation will be discussed and includes SEAM, JBoss Cache, Rich Faces, JBoss WS and all of the best practices to modularize your human task development in future projects.

The lead developer of the In2Flow application will detail the architecture and cover the most important points that you need to be aware of to develop a scalable, flexible, extensible jBPM human task solution for your next jBPM project. This will include an overview of the management information and empirical data that is collected on the human tasks processed within In2Flow, based on four months in a production environment.

Monday, August 30, 2010

I would really like to attend this first every EMEA version of the JBoss Developers Conference (JUDCON 2010) in Berlin on 7-8 October. Therefore, I have thrown my best pitch at the Call for Papers and we will see what happens:

(Workflow and BPM track)

Title:
Get your BPM ducks in a row - preparing for migration to jBPM5Abstract:With the recent shift to unify the projects DroolsFlow and jBPM4.x into jBPM5, we are all wondering what the impact could be to our existing BPM projects. What is new in jBPM5? What does one need to be aware of? What does one need to prepare in advance for a move to this new platform? All these questions and more will be discussed in this session.

First, we will take a look at what has happened historically within jBPM to get us where we are now, with jBPM3.x and jBPM4.x versions. We will discuss DroolsFlow in relation to the path towards jBPM5. Next we will take a look at the Request for Comments (RFC) that was put into the community and resulting architecture for the future of BPM within JBoss Middleware. This leads to a closer look at the resulting jBPM5 road map and how this will relate to the JBoss Enterprise BPM products moving towards the future.

Finally we will provide a plan for positioning your existing Enterprise jBPM projects for the eventual move towards jBPM5. This will cover the architectural layers involved, a look at the tooling being created for this and steps you can take to ensure a smooth transition moving into your jBPM future.

Sunday, August 29, 2010

During boot of my Fedora 13 I only happened to notice these warnings when I hit the ESC key during boot to remove the graphical front (you can find them in the /var/log/boot.log):

Starting udev: udevd[525]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/48-UMTS.rules:1
udevd[525]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/48-UMTS.rules:1
udevd[525]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/48-UMTS.rules:2
udevd[525]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/48-UMTS.rules:2
udevd[525]: NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /etc/udev/rules.d/60-kqemu.rules:1
udevd[525]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/85-pcscd_egate.rules:3
udevd[525]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/85-pcscd_egate.rules:3
udevd[525]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/85-pcscd_egate.rules:5
udevd[525]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/99-huawei-e220.rules:2
udevd[525]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/99-novatel-ovation.rules:2
udevd[525]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/99-option-icon.rules:2

These are just warnings but if you want to clean them up just edit the offending files and replace the text as described (I used ATTRS{} and SUBSYSTEMS{} for all my changes) in the warning messages. It is not often that the solutions are provided right in the logs, eh! ;-)

Wednesday, August 25, 2010

Together with a fellow jBPM enthusiast, submitted the following paper to the JFall 2010 call for papers:

AbstractThe Schiphol Group has developed a product called Service Dropoff for a large Dutch airline which automates the baggage check-in process. By removing the middle man, you are able to check-in for your vacation trip without having to wait in the long lines we all find at airport check-in desks.

This session will start with the background story on how the Service Dropoff project came into being. This will shed light onto the very first automated baggage check-in system in the entire world and how this came to be.

We will then take a look at the Service Dropoff project as it was first developed and deployed in 2004. The results of this will be shown in the market via a video made at the time for marketing purposes which runs through actual traveller usage of the automated baggage check-in machine. This project provided many insights into the impact that various solution choices had and we will discuss these as they translate to a future wish list of improvements.

Next we will highlight the Service Dropoff version 2.0 project, which is currently going into production at Schiphol Airport. The projects goals will be outlined, along with a closer look at the technical details of the implementation. This will provide various insights into what was improved and why. The new Service Dropoff project addresses the best practices and issues we have encountered based on actual usage by travellers going through Schiphol Airport.

After this session, you will be ready for your first automated vacation where you can test drive our jBPM solution while checking in for your next flight!