/ Development  

Warning; The easiness of debugging a BPM with sub-BPMs

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

I have some spare time, and, in those moments, I like to try the strangest things…Just because we can! This time on BPMs; More specific sub-BPMs in debug mode, a parent BPM calling itself as sub-BPM, and a sub-BPM calling the parent BPM again (as circularity)! 😱

Notes upfront:

  • For these exercises it’s important to have the basic monitoring level on the BPM enabled called “Process status”. There is no need to have it enabled on activity level.
  • It doesn’t matter if you use short-lived or long-lived execution modes (for this post!).

Time to blow up the VM…

Let get right into it…

Spin up the VM and login to your favorite spot of the platform; The ‘Workspace Documents’ artifact with corresponding workspace and project. I jump into my already available ‘bpms’ folder where I create a first BPM; Easy like this:

debug_001

Save it as bpm_parent. Now write click the BPM activity construct “Independent Sub-Process” and insert a new BPM; In the popup you can create a new BPM like this:

debug_002

Save it as bpm_child and insert a new BPM here as well; The last one is as simple as this:

debug_003

Save this one as bpm_dummy. This is my end-result:

debug_004

Now run the bpm_parent and check the PIM artifact:

debug_005

So far, so good!

Debugging

Let’s do a debug session and see how it is responding to sub-processes and how it will be possible to jump through them. Right-click the bpm_parent to start your debug session:

debug_006

A new panel is starting we give the BPM a starting sign:

debug_007

You’ll see this instance also from a PIM perspective with status “Debug”.
…In case you wondered!? 🤔

Hit the same button to move to the next step/activity…AND continue until you see the sub-BPM triggering in a new window! NICEEEE…I wasn’t aware this works out of the box; I saw it different at other low-code systems; That’s why I took the time to try it out here!

Now, move on and continue the clicking and experience the third sub-BPM jumping into! GREAT! We can even continue the stepping and the panels are closing again as well, until we’re back into our parent instance:

debug_008

Don’t forget to also finish it off on the RED stop button!

…

Did anybody raise the question: What on earth is the action “Run Interactively”? It’s really simple, you just have more control over what needs to happen with tasks, sub-BPM, and case models (if ever used!?). You can directly switch from “mode” during your debugging session!

debug_009

FYI: I have never ever used this feature!

…

What if we remove the “Wait until Sub Process is Finished” checkmark?

debug_010

It doesn’t matter…The debugger still jumps through the hoops. For the BPM behavior it’s indeed something different, but that’s not the scope of this post!

For me that’s sufficient details…Give me a comment if you would like to see other things!?

Calling the parent (itself) as sub-BPM

WHAT…Can we do this? Sure, we can; We can even deploy it:

debug_011

How about running it? What will happen? Only one way to find out! 🙈 🙉 🙊 YOLO!

debug_012

Well, my laptop starts to be a “heater” instead of a “worker”! 🤣

Can we stop it? Yes, simply stop the BPM service container in ‘/system’; AND clean the BPM instances mess in the database! Your administrator will thank you for it…

1
2
3
UPDATE process_instance
SET    status = 'COMPLETE'
WHERE  status IN ( 'WAITING', 'QUEUED' );

Great experiment…Next one!

Create a “failing” circularity

This is a simple one; When I make sure the bpm_dummy calls the bpm_parent again, I get an expected error during publication:

1
2
3
4
5
Circular dependency in build for objects 
    BPM: bpms/bpm_dummy >> Sub-process: bpms/bpm_dummy/Independent Sub-Process >> 
    BPM: bpms/bpm_parent >> 
    BPM: bpms/bpm_child >> Sub-process: bpms/bpm_child/Independent Sub-Process >> 
    BPM: bpms/bpm_dummy

Strange that it’s detected here, but not in the previous recursiveness (or recursively!?) section!?

I give it a “DONE” for this week’s post. We learned more about BPM debugging and even tried interesting circular calls. Always watch what you’re doing, make sure your BPMs do one thing and that they do it at their best (incl. the worse-case scenarios), colorize your activities for recognition, use a naming convention…AND don’t forget to comment the intention of the BPM; Your fellow developer will love you for it in a later moment in time. Have a great weekend, till next week, 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”?