Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

When “something” gets out of due, your managers loved to be informed about it; AND because you’re the low-code developer, it’s your job to do a proper “out-of-due” implementation; AND the last thing you need, is to have that manager at your desk asking why he was NOT informed, informed to early, or informed TOO late! That’s why we now do a proper analysis on the “Deadline” building block to clear up the technical details behind this BB principle.

Let get right into it…

We start with a Monday morning routine…

1. Wake-up…06.00 u. would be sufficient time to have your ME-time to build your presence, brand, and knowledge (before the grind of the day begins for your clients)
2. A quick (cold-shower) to boost your brain with dopamine to conquer the day…Do your own research on it!
3. Some caffeine to start the creativity mode in yourself
4. Boot up your VM and dive into your favorite workspace and project

Time to create our first case entity with two properties; One called case_name with corresponding label (type is ‘Text’); And a property called case_duration of type ‘Duration’ and also a logic label. Generate the other BBs, make it consistent against your naming convention, and do a first publication. No need to dive into runtime (for now).

The next step is to add the ‘Deadline’ BB to the ‘Case’ entity; I give it the name dl_overdue and the first implementation looks like this:

Let’s digest here for a moment…So, when a new case is created, this deadline will start running for 1 day; AND it will stop running when the name of the case equals STOP. Right!? But what will be the technique behind it…How, what, or who is watching this? Well, I did some monitoring on my Postgres DB and after a publication of the case, I see these 2 tables popping up:

1. o2aw_tipsgenericdeadlineinstance; Will probably get a new row when we create a new case and keeps track of the deadline itself; So, when it starts/stops and the state (active or not!?)
2. o2aw_tipsgenericdeadlineactioninstance; Will also get a new row on case creation, but will probably keep track of the trigger actions; So, when a BPM or send mail will be triggered as an alert (check out below when we’re further down into the well!)

Where are we waiting for? Go into runtime and create a new instance of the case and have a look in the database:

1
2
3
4
5

SELECT id, duedate, status, startdate, stopdate, stopcondition
FROM o2aw_tipsgenericdeadlineinstance
WHERE startdate > '2023-11-15 00:00:00'::TIMESTAMP
ORDER BY id DESC
LIMIT 10;

NICEEE…We’re in progress; I’m curious…Let’s have a view in the PIM (just because we can!):

There you have it! It’s an ordinary BPM instance watching out for our trigger…
Again, where are you waiting for; Update the case instance name to STOP!

Guess what will happen? Yes, the BPM instance gets a green “Complete” state, and the database gets an update as well:

GREAT! Time for a next level…

Adding a dynamic element

A simple task as we already have the ‘Duration’ property available on our ‘Case’ entity. So, back in design-time, open the ‘Deadline’ BB dl_overdue, and change the deadline option from ‘Static’ to ‘Dynamic’:

So, this means our deadline is now depending on a value selected in the duration property! Time for a publication and the creation of a new entity instance in runtime; For quickly checking out the outcome on the duration changes, I add the deadline due-date property to the ‘Create’ form. When you now change the duration, you can see the deadline due-date will change with it:

You see I also add the ‘Tracking’ BB with the creation date on the form for verification! A task to do on your own. 🤠
Watch also carefully in the screenshot that we pass midnight here!…I know…My day started at 06.00, but this was after a complicated day at the client (as always!?)
…
If you ever wondered what is saved at DB level for our case_duration property; It looks like this: P1M2DT3H5M for 1 month, 2 days, 3 hours, and 5 minutes. Read about this data-type here

Let’s level up…

Dynamic stop condition

Currently, we have a stop condition on the instance name with value STOP, but can we make it more interesting; more flexible? Well, how about a condition like this:

This is behind the advanced editor: item.Deadlines.dl_overdue_DueDate>date(2023,11,21,0,0,0)

So, when the due-date of my deadline is greater than a specified date (21/11/2023 0:00), the policy will stop (and the monitoring BPM instance completes!). How can we do this? Well, today (when I’m writing!) it’s 20/11/2024 17:00; So, when we set our case duration properties on 1 day, our policy is directly met! Well, trust me (I just tried), and indeed…The BPM instance is completed!

What else?…What about this:

Don’t ask why it’s fixed to only ‘days’!?
This is behind the advanced editor: (item.Deadlines.dl_overdue_DueDate>=today && item.Deadlines.dl_overdue_DueDate<=today + 1 days)

So, this is when our due-date is between 20/11/2024 00:00 (today; this early morning) and 21/11/2024 00:00 (tomorrow; early morning or the end of this day!). This will happen directly when we set our duration for about 5 min! Trust me again…The BPM is completed! And indeed…The BPM will never complete when you set your duration on 1 day! 😐

What else?…Time to do something advanced ourselves (what they can do, we can do as well):

item.Deadlines.dl_overdue_DueDate > now + 10 minutes

So, when the due-date (I make it a 1-day duration from now) is greater than 10 minutes from now it should stop (equals BPM completion!). Works flawless…directly! 😇

…

What if I set that duration now on 5 minutes (on a new created instance); Will the BPM wait for 5 minutes and complete after this? I tried it with 9 minutes and after 1 min.!? Well…TOOO bad; The BPM isn’t completed!? hmmmm…Is it my thinking-process here? I guess it is (aha!!); Off-course it will never stop as my due date will always be smaller…dûh! 😵

The BPM completes again when I update the duration to 1 day…Lucky I found it out within 1 day!

Right, but how to make a condition that will stop my deadline in the future? How about this:

now >= item.Deadlines.dl_overdue_DueDate

So, when I set my duration 1 min. from now; The monitor BPM will wait for 1 minute and completes? Correct? WRONG! Only, this time I’m not losing my mind as “Now” (at moment of writing) has value 20/11/2024 18:19, and the due-date is 20/11/2024 18:01. “Now” is definitely greater than the due-date!? Did we find a bug here? Does it have to do with the only-days possibility?

What about this ((today + 1 days) - 4 hours) >= item.Deadlines.dl_overdue_DueDate?? Well, already getting crazy here? So, that’s tonight ‘0:00’ minus 4 hours; That’s at ‘20:00’! So, when ‘20:00’ is greater than due-date (which I set with a duration of 5 min.), we are TRUE to get a completed BPM!? Right? Indeed…It’s completed!

Finally, will this ((today + 1 days) - 16 hours) >= item.Deadlines.dl_overdue_DueDate make sure the BPM completes tomorrow at ‘08:00’? It’s now ‘19:00’ Well, I leave this waiting task for you! Let’s do a bed on the outcome…Comment me! 🤔

Done with playing…Time to continue!

Playing with alerts

Alerts? Yes, those are the actions when the date has passed the deadline! For a solid assessment, I quickly change my deadline definition to something like this:

With this in place, we move to the next tab called ‘Alerts and escalations’ with an implementation like this:

I leave the email action out of scope (as I don’t have a mail server currently), but it works the same with a BPM. My bpm_dummy is just a one-activity BPM doing nothing (comment me if you don’t have a clue); This BPM starts when my case duration is passed AFTER the deadline (we could make it static as well, but that’s no fun!).
So, when the start policy triggers at 18:12 with a duration of 1 minute (which sets the due-date at 18.13), I expect my dummy BPM to get a start 1 minute (my duration!) after the due-date; That’s at 18.14! That is also what exactly happens after a quick run from runtime. ✅

Is my monitoring BPM finished after this alert? Well NOPE (in my case!) as my stop condition isn’t met! Only, if we would do something smart in our BPM…Like calling an update webservice for our case to set the case name to the value STOP; This way we make a closing circle ORRRRRR maybe you want to trigger a second alert when (for example) the duration gets an update to a new (bigger) value! WHAT? Yes, my friend…That’s the power of a dynamic deadline implementation!

Have a look in the database as well for that “fire” moment:

1
2
3
4
5

SELECT id, firetime, actiontype, actionobjectreference, escalationcondition,
       escalationduration, escalationstatus
FROM o2aw_tipsgenericdeadlineactioninstance
ORDER BY id DESC
LIMIT 10;

You see exactly my “fire” moment of my updated duration (from 1 minute to 8 minutes!). Did it fire? HELL YEAH it fired! 🤠

Well, I’ve seen enough what I wanted to see; Let’s do a Q/A!

Q/A time

Just some answers on questions during my exploration…

1. Can we restart/re-init a completed deadline BPM? Not a “completed” BPM, but we can trigger a new one! For this we simply change the start policy from ‘item created’ to a condition like item.Properties.case_name=="START". Fascinating here is to get note from the BPM instances; Each time the condition is met (on a save trigger) a new BPM instance is started as well! AND each time the stop condition is triggered a BPM instance is completed too. It’s a queue system!

2. Can we switch from static to dynamic when the condition is already met for the instance in runtime? Not from my experience; It looks like the old instances follow the old setting and new instances follow the new settings. Sounds logic to me as this mindset also applies to changes in the BPM or in the lifecycle for an entity!

3. What if the duration property is not required during creation of the entity? Well, the due-date for the deadline will also be empty until the duration property gets a value!

4. Can we fix dates in the database to complete endless waiting BPM instances? Well, not magically from what I tried, but how about updating the stop-date value in the database (AND just terminate the BPM instance from the PIM):

1
2
3

UPDATE o2aw_tipsgenericdeadlineinstance 
SET stopdate = '2023-11-22 17:49:00.000'::timestamp, status = 'Completed'
WHERE id = '983045';

This last trick is not a supported trick…Do your own research and always make sure your data is consistent! If you (by any chance) have another way; Let me (and others) know in the comments below…

That’s a proper out-of-due “DONE” where we learned about the ‘Deadline’ BB and its related ‘Duration’ property and corresponding escalation actions. We even saw what is happening in the database, so not one manager can ask/deny what happened as you can tell exactly what happened now! I love these kinds of deep dives and check what happens in the background…Always good for your learning skills and improving yourself. With AppWorks Tips you’re already at the correct path; Keep it locked and I see you in the next post, next week.

The outcome on our bed (read the blog!)? Well, the BPM is still running! 🤑

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