Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
For this week, an interesting experience on the ‘Lifecycle’ BB for our entity implementations. I always implement lifecycles with a specific set of states and activities; It’s almost fixed (like a BPM), but that’s exactly what a lifecycle should NOT be. So, for this post we’ll find out about the edges of the ‘Lifecycle’ BB that will help your knowledge workers to work efficiently with input from their expertise instead of building it already in concrete.
Let get right into it…
Boot up your AppWorks VM, and we’ll dive directly into the ‘Workspace documents’ artifact where we find our workspace and corresponding project. Create yourself a new entity (with just one property) and generate all the rest of the building blocks. There is no need to publish yet as we first add the ‘Lifecycle’ BB with a first implementation like this:
???…But this lifecycle is empty…right? Correct! Is it valid? Yes, my friend…That’s a valid implementation! Do a publication and see it’s not complaining about anything. WHAT!? What about runtime…When I create a new entity instance? Well, try it out and check the CIM artifact:
Please, don’t ask why it shows “Untitled_Entity” here…I think it’s a bug (or maybe cache!?)
#WTF…So, it does start a lifecycle; An empty one! With a “Default State” as a root…See for yourself in the developer console of Chrome:
Interesting…We’re learned something here! What else can we do? What about this:
Only an activity! Do a publication and check it out in runtime; It will start a lifecycle, and you can add a new task to (a new created!) entity instance:
Why only new instances and not the old instances? Well, that’s because the old instances still follow the previous version of the lifecycle!
Interesting insights!…What else? Let’s do something like this:
The outcome in runtime? The lifecycle jumps directly into the state State1 where we also receive Activity2 in our inbox, and we still have the option to add extra tasks to the current- and “Default State”-state:
What about an implementation like this:
What is the first initialization state now? Is it valid? Yes, it is! After a quick assessment in runtime my conclusion is that everything still works the same, and it totally ignores my State2. How to make sure it starts in the new State2 state? Well, watch this:
Now you see a valid usage of the ‘Initial State’ construct!
We can discuss if these implementation examples are valid for a production environment. For me, it’s not, as I would always like to “understand” the intention of a specific implementation (also for my fellow low-code developers). That’s also why I always use the ‘Initial State’ construct to start the lifecycle which simply makes things clear.
A great “DONE” where we learned more about the ‘Lifecycle’ building block for an entity. We learned about the edges of the building block and that an “empty” lifecycle is starting something in runtime; even an ‘Activity’ can live on its own to help your knowledge workers to make (optional) choices. We’ve seen things that I was not aware were possible; That’s already an achievement. Again, an interesting post with information you can use in your projects. Comment me on your thoughts and I see you next week, with a new topic on AppWorks Tips.
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”?
