/ Development  

Unlock the full power of your entity lifecycle with this overlooked construct

Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

In May this year, I gave a workshop about Process Automation at a big IT provider in the Netherlands (Capgemini). A full-blown course with all the insights about OPA from fundamentals to die-hard BPM development (incl. xECM integration). A great eXperience with enthusiastic workshop members willing to follow the practical assignments!

During this type of workshop, you (as facilitator) get back to the roots of the platform where every failure happens at the members which you saw already 7 years ago. More important is the fact that the same YOU is also moving into unfamiliar terrain (although you think you saw it all) when your workshop members follow the assignment beyond what was asked. That’s clicking on things outside the normal (which is a good thing!) and asking questions about it (even better!). For me totally unprepared (and with no answer), but it makes me extra enthusiastic to go through it with the group. First for myself, but after my own quick R&D as sharable knowledge to the group.

So, get your details on an interesting construct in the ‘Lifecycle’ BB for an entity which I wasn’t aware of how to use it!? The construct’s name is “Document Received”:

doc_receive_001

It made me first think why/how/where on earth to use it!? It can trigger something in the lifecycle when you upload a document to your entity, but that also smells like business logic (‘onContentCreate’) for a ‘Rule’ BB on the related ‘Content/File’ BB? How is this different? Well, the ‘onContentCreate’ rule is for each content upload where this is a more single action to move further into the lifecycle.

Interesting thinking…We can continue writing down what we think it can solve, but let’s play with it and see what it can do for us…


Let’s get right into it…

Once your OPA VM is operational, you can quickly create a new basic ‘Case’ entity (with one case_name property) and a first lifecycle implementation like this:

doc_receive_002

The red arrow shows a “group” which is the “Default” folder for an applied ‘Content’ building block on the same ‘Case’ entity!

Be aware this only works for the ‘Content’ BB and NOT the ‘File’ BB on an entity!

Before you try this out in runtime, make sure to add the ‘Progress Bar’ panel (of type ‘Lifecycle’) to the default layout, a ‘Tasks’ panel for receiving tasks, AND the ‘Content’ panel to upload a document in the ‘Default’ folder. It’s all extra details to get insights in runtime what will happen:

doc_receive_003

Now do a publication and create yourself a new ‘Case’ instance in runtime and open it.

doc_receive_004

You see the lifecycle is in our first state “waiting” for something magic to happen…That magic something is the upload of a new document in our folder from the ‘Contents’ panel tab:

doc_receive_005

After the upload, you’ll see a new task in the ‘Tasks’ panel for completion:

doc_receive_006

Do the completion and see that the lifecycle state will complete too…NICEEEE! Mission accomplished! 😎


Looking beyond the construct

My inner self still asks me the question…Why? Why specifically this construct? We can also do this via a ‘Rule’ BB on the related ‘Contents’ entity…right?

Well, will a satisfy condition on the lifecycle transition work as first thought?

doc_receive_007

(item.Contents[]).size() = 2 (that’s one content file + the “default” folder itself)!

After publication, a new instance, waiting in ‘PreState’, and the upload of content does not do the trick! So, nice thinking but no; not working.

I did try (item.Contents[]).size() = 1 (no content + only the ‘default’ folder); This moves directly to the next state! Fascinating, but strange too!?

After a review of this post, I even did try (item.Contents[].File.FileName).size() = 2 and (item.Contents[].File.FileName).size() == 2; All responding the same and not moving an inch!?

How about this second thought? Create a ‘Rule’ BB on the related ‘Contents’ entity that triggers on event ‘An item is created’. This sets a Boolean property on the ‘Case’ entity which we can now check in a condition like this: item.Properties.case_has_content==true

Does it work? Well, not smoothly as you don’t have an option to link to the parent entity from a ‘Contents’ entity ‘Rule’ BB:

doc_receive_008

Hmmmmm…It’s getting interesting with each move we make! 🧐

I also notice (in a blink of my eye) sometimes the usage of one = and a double ==!? I tried both and nothing changed; both are valid conditions. Even item.Properties.case_has_content is a valid Boolean condition!

Ok, third thought! Can we make a ‘Rule’ BB on the ‘Case’ entity e_opc_set_has_content having a condition like this (item.Contents[].File.FileName).size() = 2, and setting the property to TRUE which we check in the lifecycle:

doc_receive_009

Notes:

  • opc = On Property Change!
  • (item.Contents[]).size() = 2 is not working for some strange reason!? It’s always giving TRUE!? #SUPPORT

After publication and a quick test, I conclude that it works nicely! Even with the double equal-sign: (item.Contents[].File.FileName).size() == 2

After all this R&D stuff, I have a strange feeling on a consistent implementation for the conditionals from above. Sometimes with ==, sometimes it’s valid, but gives TRUE in all circumstances!? Weird things…It probably has to do with the arrays and the extra .size() function we use. Eventually it’ll work, but you see that multiple paths are possible where only one is valid this time.

Is the ‘Document Received’ construct hereby “busted”? Yes, our workarounds (with rules) are not as nice as the initial construct. So, I’ll admit…it’s a usable construct in use-cases it was designed for. It was still a good practice to see if we could do without as that’s where the real learning takes in place.


Nicely “DONE” with the input from my workshop members and a little sauce from myself. Now you see that providing workshops is not only beneficial for the members joining it; Also, the course facilitator can still learn new things possible within the OPA platform. Even after 7 years of eXperience! Thank you for giving me the trust providing the course with a great outcome on knowledge sharing. We continue here with a new post, next week, at “Process Automation Tips”; 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 Process Automation guy”?