Enhancing OutSystems BPT processes with “Behaviours”
In the following article I’ll try to explain how you can improve your BPT processes by using a “Behaviours” pattern. If you have attended an OutSystems BPT boot camp before you may already know it. If you haven’t you probably don’t have a clue what a “Behaviour” is.
Business Process Technology (BPT) is OutSystems approach to business processes design. It’s inspired by Business Process Model and Notation (BPMN).
If you already have some knowledge of the OutSystems platform but never implemented a BPT process before I suggest you take the Master Class on Modelling BPT available for free in the OutSystems Learning page.
The “Behaviours” pattern is about:
- Adding more control at UI level on your process;
- Ensuring your users don’t do changes at the wrong stage of a process;
- Designing you application around the process and not the other way around.
Securing BPT processes
As you know by now, all the Human Activies, by default, in a process can be done:
- By all end-users, if no configuration is done in the Human Activity properties (User property);
- By a specific user (when configured in the User property);
- By a specific group(s) of users with certain roles (pick the roles that have grants to carry out the Human Activity in the roles property).
Adding an extra layer of security/awareness to your applications
Take the following process designed to “Select Candidates” for a job.
After the “ScreenCandidate” activity (validate if Name and Position are filled) you must validate the candidate’s CV.
If the candidate hasn’t one you can request it.
Now you want to make sure the button is only visible if the current process activity is “ValidateCV”.
TIP: This way you guarantee nothing can be done without an activity!
Enter Behaviours
- Create a static entity called “BEHAVIOUR” where you will define all your process/application behaviours.
2. Create an entity called “ACTIVITY_BEHAVIOUR” that maps together your Activities, Behaviours and Users. They are your entity attributes.
3. Add logic to create the “BEHAVIOUR”. Your action receives an ActivityId, an UserId and a BehaviourId.
So now we have tables and logic to support the Behaviours.
Instantiating the Behaviours
In the “On Open” callback of the “ValidateCV” activity create your Behaviour.
You may ask why “On Open” and not “On Ready” callback?
TIP: Only “On Open” knows Session.UserId!
TIP: If the Behaviour is user agnostic you can use the “On Ready” callback and set UserId = NullIdentifier().
Validating Behaviours
Back to our screen… To enforce the button is only visible at the right time to the right user you check if the behaviour exists for the current user.
Once again, also guaranteeing the right activity exists!
The Behaviour_Check action validates if a certain behaviour exists.
Final remarks
If you decide that a Behaviour doesn’t apply to a certain activity, you make the change in your process and not in screen preparations. Much better no!?
Now, all you have to do is add more behaviours that support your business process.
With this simple example I hope you have understood the concept of “Behaviours”. I’m sure you’ll apply it to all your future processes 😃
This way they will be bullet proof.
Special thanks to Justin James and Miguel Seabra Melo, my fellow MVP colleagues, for giving me some input on the article.
Dedicated to CJPG 💪 Stay strong!
