Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Also, a happy new 2022-year! In this year we just continue our grind on our beloved AppWorks platform as my backlog is far from being empty. It looks like the product contains endless possibilities to write great posts about where we all gain knowledge from based on my own weekly experiences / struggles!

This week again a nice use-case from the ‘Analyst guy (or gal)’ 😉:

1
2
3
4
5
6
7
8
9

Dear AppWorks low-code expert (that's you!),

We have a new business requirements thought out for you.
When we 'view' our precious entity instance in runtime, 
we would like to trigger a back-end system for some reason.
Would it be possible for you to build this onload form rule?

Kind regards,
{Your-best-friend-in-hard-times}

Hmmmm….The question from my side was: What does it need to call in the back-end?.
The reaction was: Just a ReST end-point…simple!…right?
Me and I: Sure…Let’s see what we can come up with…We’ll keep in touch!

Let get right into it…

…with this interesting use-case where I thought to start pretty straight forward. Just add a ‘Rule’ BB to an entity (I use a ‘prototype’ entity with a ‘name’ field) with an ‘onload’ event. Well, that’s not an available option, but we do have the ‘onPropertyChange’ event, and the low-code guide tells me this thing about it:

Exactly what we want…A trigger event ‘onFirstLoad’! On this first load we would like to start a BPM, and once we’re in BPM-land we’re flexible enough to call some back-end webservice…correct?

So, something like this…Which calls a ‘dummy’ BPM, and we should be fine:

The BPM looks like this for now:

Note: I made sure the BPM runs in ‘Short live’ mode as it might need to interact with our form, and we just call webservices!

Once it’s all in place we do a publication and do our first test. Just with the ‘Developer’ role, so we don’t face security issues for now. Monitor the PIM artifact to see some results.

How is it on your side? On my side there is silence!? Nothing happens in the PIM! Is my rule even triggered?

…
!!UPDATE UPDATE; read all about it!!

After gaining more knowledge in my own project we learned our lesson. We were playing with the same principle and when using a property in the condition, like item.Tracking.LastModifiedDate > 0, the BPM was triggering directly! So, the condition must have a property applied (as quoted behind that small information-icon in the screenshot above…#RTFM).
You can ask the question on what happens when we update our current entity with an ‘Update’ service call in the dummy_bpm? Well, it eventually aborts when the maximum value on the property is reached. Updating it with the same name? Good one, but this will trigger the BPM only once! How about a second rule resetting the property value back to the default (with that same condition)? Yes…That’s an endless loop!!
…

Let’s do one step back and just show an information message to see if our rule triggers:

Publish and try again…hmmm…works like a charm! The rule “onInit” is born.

Let’s set a property:

The test? Runs smoothly too; although my field get grayed out for some reason!? This is not an issue for now as we need to start that BPM!

What else? Like the ‘Hide’ option?

After a test, it’s working as expected…OK…retry the BPM option again (as it’s early in the morning!)

Hmmmm…Nothing!?

We have a deployed BPM…right?

It is!? It’s getting stranger by the minute. Is it our ‘true’ condition on the rule which is in our way? Let’s do an update like this:

Finally, after a publication, I see some started BPMs in the PIM, but these only start once I update my ‘p_name’ property with a value ‘trigger’…Play a bit with it, so you see the trigger moments for yourself. You might also notice you really need to remove the focus of the form to make the real trigger happen, but that’s an ‘advanced option on the rule configuration:

Still…This is not really an ‘onFormInit’ rule, we rather like the ‘true’ condition from our first tests…Time for a trick to fix this once and for all.

The trick

How does the trick work? Well, we need 3 extra components!

1. A ‘helper / internal’ property
2. A second rule
3. An ‘Update’ webservice on the entity

The second rule will do a ‘setProperty’ on a ‘helper’ property which sets our ‘trigger’ flag to true. Our current rule will ‘listen’ to this flag-update and will then start our BPM. To close the circle we call the ‘Update’ webservice from our BPM to ‘Unflag’ our property back to false.

Let’s see this in practice…

The ‘helper/internal’ property

Dive back into our ‘prototype’ entity and let’s add the ‘internal’ property. I name it ‘int_p_bpm_is_triggered’ of type ‘Boolean’ (‘int’ is for ‘Internal’). After the property creation, I remove the ‘none’ value from the list which leaves me with just TRUE|FALSE options. The default value will be FALSE.

The second rule

Time for our second rule. It’s again an event with a nice name like ‘on_prop_change_set_bpm_trigger’, and it all looks like this:

The ‘Update’ webservice

For this we just add the ‘Web service’ BB to our entity, and we make sure to select the ‘Update’ operation from all the available CRUD operations. Like this:

The final updates

Now back to our original rule which will get an update in the condition. We saw our triggered BPM when we update a property, so now we just need to check our ‘trigger’ property as a condition.

Let’s do a first publication of the entity, but don’t test it yet as we still need to do 2 things! That’s the ‘Update’ webservice call in our BPM (to reset our trigger property) and creating a service container which can handle our “Update” webservice calls.

The BPM update

Back into the created ‘dummy_bpm’ where we can right-click our one and only ‘Activity’. Hover to the ‘Insert’ menu option and hit the ‘Web Service Operation’. In the operations overview, you should be able to select ‘Updateprototype’ as our operation. Once selected we go to the ‘Message Map’ of our BPM and make an update like this:

The service container creation

We’ve done this creation several times on this blogsite already…So, in short steps:

• Open the ‘System Resource Manager’ artifact
• Create a new service group of type ‘Application Server Connector’
• Give the group a nice name like ‘app_server_service_group’ and select your exposed interface of our just exposed entity ‘Web service’ BB
• Give the service container a nice name like ‘app_server_service’
  • Make it start up automatically
  • Make sure to mark ‘Assign OS Process’ and select your instance

The final test

Make sure to publish everything and open up the PIM for your valuable monitoring on any running BPM.

An (optional) thing to do is adding the ‘trigger’ Boolean property onto the ‘Create’ form of the entity…This way you see it being updated on the fly! 🙃

Let do a first create of the ‘Prototype’ entity, but don’t hit the ‘Create’ button yet! Check the PIM…

…

Niceeeeeee…That’s our first ‘onInit’ green flag! ✅

Now, create it for real and open the thing again! Check the PIM…

…

Hooray…Again an ‘onInit’ green flag! ✅

Close it and reopen it again! Check the PIM…

…

I’ll be damned…Again! ✅

It’s getting boring…How about an update on my ‘p_name’ property value when viewing!? Will it trigger? I hope not as it will break my ‘onInit’ feature. A quick test satisfied my feeling…Lucky me, but is it logic? Rethinking it all over, it is more logic my ‘on_prop_change_set_bpm_trigger’ (with the only ‘true’ condition) would be triggered again. Maybe that’s also the case, but as we saw already in the beginning of this post, we don’t have a triggered BPM! So, we’re fine with this solution.

That’s a “DONE” for me; where we learned about an interesting workaround to introduce an ‘onInit’ feature (to trigger a BPM) on a form. Nothing more, and nothing less. Have a great week-end and stay tuned for the next post on another AppWorks Tips topic…cheers.

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”?