Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
Ohw man, did I found an interesting principle to share with you all! It’s all about the nicest “Return” action button which can be a pain in the @$@!#$ for the long run if incorrect implemented. Yes, I sometimes see configurations passing by that should not see the light, but I just want to show you what the correct way should be. We can low-code a lot, but building it with the wrong mindset and not overseeing the future consequence is (in my opinion), a bad habit; As a technical consultant it’s your duty to protect the customer for making wrong decisions and bring live a steady and clean environment which “smells” nice and fresh…Even after running in production for a couple of years!
Let get right into it…
That’s a “great talk” introduction, but what on earth am I talking about? Well, maybe you also tried to build a “navigation” type of button on your action bar. It doesn’t need to do anything; just navigate to another location in your solution. We can do this via a ‘Rule’ BB of type ‘Action’, but it has limitations as you’re still “in-context” of your entity instance.
I see navigation more as an “out-of-context” thing, but we will face the hard truth this is only possible from a ‘Homepage’ type of document. Let this homepage be exactly what we do not want, and we have a gray-area to cover when it comes to navigation from an entity instance…I stop mumbling now! 🤐 Start the action…
Let’s create yourself an entity Case with just a case_name property and all default BBs applied; Specially for you, I even make it nice and shiny applying my naming conventions:
Now, add the ‘History’ BB with a corresponding history log configuration (I name this log hl_case); All out of the box, but gives some insides later. Next is to add a new ‘Rule’ BB of type ‘Action’; Give it a name a_return with label Return…Implementation like this:
So, no condition (which is fine), setting a property by itself (because we need to do something!?), and move to the homepage (to have that return). Will it work? For sure, but can you imagine what is wrong with this?
…
Before we try out our button, I first make sure my audit tracker is enabled. For this I follow my own post. If you want to be quick, do these 2 steps:
- Start the ‘Auditing’ service container from the ‘System’ / ‘Shared’ space in the ‘System Resource Manager’ artifact
- Enable the entity entries in the ‘Audit Configuration’ artifact; ‘Entity’, ‘Entity Data Audit’, and ‘Entity Instance’
…
This is the time to do a publication, create an instance in runtime, and move up and down with the ‘Return’ action.
Why is this action rule implementation a bad principle? Well, it pollutes your audit/history trail information with nonsense; You don’t see it now, but eventually it will hit the brink wall…Trust me!
This is my view on the history for my instance (which seems to be OK…Also, not expected by me!):
This is my view on the audit trail (the ‘Audit Viewer’ artifact) for that same instance in my own organization (which I did expect!):
The correct implementation
With the previous implementation in the back of our minds it’s now time to implement another solution; Or better, the correct solution! But…Is there a correct implementation? Well, let’s see! We start with the implementation of a so-called “do-nothing” BPM. It’s a Business Process Model type of document with just a start-construct, one activity (with no message mappings), and an end-construct. Like this (with execution mode ‘short-lived’):
Have also a look in de ‘Monitoring’ tab for this BPM where I uncheck any monitor possibility (otherwise we’ll pollute our PIM with nonsense). Save the BPM with name bpm_do_nothing under the bpms folder of your project and do a first publication. You can do a quick manual run from the context menu and double-check the PIM on non-existing entries!
If you’re a smart person (and you are!), you already produced the idea to also enable the BPM flags (‘BPM’ and ‘BPM Configuration’) for the audit configuration in the ‘System’ space; Well, I did, and trust me…The BPM instances are not logged here! The only entry I can find is the publication of my BPM into runtime; That triggers an ‘Add’ event, but that’s fine.
So, now what? Well, what about updating our action rule like this:
WHAT?…Yes, low-code can be this easy! Do the publication, and try it out in runtime!
Does it work…Ohw yeah! It works…How about the PIM after some ‘Return’ hits? Well, empty! The audit viewer? Well, no ‘Update’ entries are found any more and also no ‘Start BPM’ entries (in case you wondered!); So, that’s it; A clean solution for your own action button.
Nicely “DONE”…That’s how you implement a non-data-polluted navigation type of action ‘Rule’; Again, with the power of BPM! Where would we be without it? I know, it’s a different world comparing with our entity modelling principles, but it’s still the correct place when you want to do more advanced implementations. Lucky for you! You are already in the correct place learning all the good habits which you can bring to your own projects and solutions. Let me know what you think in the comments, and I see you in another great AppWorks Tips post!
Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?
