Intrexx-Pattern: Workflow-Routing

Intrexx-Pattern is a series of articles, where I want to show you some patterns I often use while developing Intrexx applications. In this article I want to show you how I implement workflow-routing with Intrexx.

What is Workflow-Routing?

Workflow-Routing means knowing exactly where a click on a button in the front-end, ends up in the back-end.

The workflows are very technical, for example you can listen on update-events for records of a specific datagroup. However, it is rather complicated to determine where the event originated. There is an easy way to find out exactly on which button the user clicked and control which parts of your workflows should be executed.

Where to start?

First of all, if there are different buttons for updating a single record, you want to give each button some kind of identifier. If you activated the expert-options for the application-designer of your portal-manager, you can see an expert-tab in the properties dialog of each button. This expert-tab allows you to add request-parameters  by simply adding an item with a name starting with “rq_”. To separate my own request-parameters from the ones Intrexx uses itself, I always use “rq_custom_” instead. For workflow-routing I always use the parameter rq_custom_action and fill it with the value of what the button is supposed to do. This could be something like “actSaveDraft” or “actCompleteStepOne”.

 

 

 

How to route a workflow?

Now after every button has this “rq_custom_action”-attribute filled  with a meaningful value, you can switch to the process-module.

To listen on changes of your datagroup, add a datagroup-event-handler and configure it to listen on every kinds of events for this datagroup. The event-handler is then followed by a Groovy script-condition element. This element allows me add some groovy code to the workflow and additionally to that define several individual exits for this condition. After I finished the Groovy condition, I can add additional controls and will then be asked for the “Connection ID” which is no more than the exit I defined in my script before.

 

Martin Weber on EmailMartin Weber on Facebook
Martin Weber
Consultant at United Planet
Since April 2014 I'm working in the Consulting Services department at United Planet in Freiburg, Germany. My tasks there include holding Intrexx seminars, develop and customize customer-applications and in general find solutions for all kinds of problems using Intrexx. Also I forward bugs and feature-requests to our development department in order to further develop Intrexx.
Additionally to that I'm very active in United Planet's community forum and answer a lot of questions asked by customers or partners of United Planet.

Leave a Comment