Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Ohhhh, did we face a challenge during our project some weeks ago! It was all about lifecycle updates on an entity. More specific; lifecycle updates in relation with parent- and current-states, and showing the correct state in your solution where possible. So, in the ‘Lifecycle’ progress bar for your layout, ‘List’ BB as a column, or on your ‘Form’ as information field. Continue your read as I will exactly explain the issue here…

Let get right into it…

Let’s skip all the overhead and let us directly follow these steps to have a head start for our challenge:

1. Have an entity case ready with just one case_name property and generate all the rest (there is no need to make it ‘shiny’ this time!)
2. Add the lifecycle BB with just one Draft state…We’ll update it after
3. Update the ‘DefaultList’ to show the ‘Current’ state and the ‘Parent’ state!
4. Update the ‘Create’ form to show also those 2 lifecycle fields
5. Manipulate the ‘DefaultLayout’; after a publication you should have a view like this in runtime:

Comment me if you need guidance on the layout panels, but I think the image is sufficient to build the same result yourself!

The ‘Results’ panel just shows all entity instances for now!…You can filter it down for the current entity, but that’s not in our scope for this post!

Now, back into the lifecycle and update it to a flow like this:

Make sure to mark the ‘Primary transition’ checkmark for each flow (incl. the sub-states; between ‘Close’ and ‘Archive’!)
An easy task; The outcome in runtime is a lifecycle progress like this: Draft -> Review -> Close -> Archive

I also added the ‘Tasks’ panel into my layout (as tab next to the ‘Results’ panel) to manage the lifecycle activities! 😉

Publish the entity, create a first instance and move through the flow completing the tasks now; Watch the current/parent state field of the lifecycle closely; Especially after completing the activity 4 task! Let me complete all 5 tasks for you, so we have a check on this screenshot:

Now you tell me what I need to communicate to my end-users what the truth is for test002/case-2? The end-user focuses on the progress bar, so in their experience the state is ‘Archive’; Looking with a technical-eye the state is (in my opinion) ‘Close’…I agree that both are correct, but what if you have business requirements that only allow you to show the ‘Parent state’ of the lifecycle, or you have ‘Rule’ BBs applied with condition checks on only the lifecycle parent state!? Yes, now we’re talking…So, again…Is it wise to build a lifecycle like this? Well, not in my opinion; It only makes things unclear.

Well, the solution is really simple, but the migration of the ‘Old’ instances (once you’re in production) is a whole difference journey…

You can raise the valid question “How on earth would you implement something like this?”; Yes, my friends…That’s the power of “being Agile”, scrambling with teams, mixing developers, mixing mindsets, and working without a design-plan on what the future will bring. It’s a common mistake which I also understand, but with dramatic results on continuation, improvement, and innovation.

The solution

Well, the lifecycle update should be done like this:

Publish it, create a new instance in runtime and compare it with the previous instance (after completing all activity tasks!):

This is now much cleaner! You can even mix the usage of parent/current state as they are always the same.

I know of course this is not the best failure use-case, but it’s one we faced during our project. There are probably use-cases possible where you would want a sub-lifecycle in a lifecycle, but I haven’t seen them yet…Please comment me if you have one; I’m pleazzzed to try it out for you! 😅

The migration

That’s where the fun starts! The old instance followed the old lifecycle path and had a parent lifecycle state of ‘Close’ which we want to migrate to ‘Archive’. For this we have a look in our database to see where this data is stored. My first guess is just the instances table for my entity o2aw_tipsaw_genericcase:

1
2
3
4
5
6
7
8
9
10

SELECT id,
       case_name,
       s_lbb_id,
       s_lbb_current_state,
       s_lbb_current_state_id,
       s_lbb_parent_state,
       s_lbb_root_state,
       s_instance_status
FROM   o2aw_tipsaw_genericcase
WHERE  s_instance_status = 'Complete';

This output clearly tells me to run an update statement on the ‘parent’ and ‘root’ lifecycle columns for this result:

1
2
3
4
5
6

UPDATE o2aw_tipsaw_genericcase
SET    s_lbb_parent_state = 'Archive',
       s_lbb_root_state = 'Archive'
WHERE  s_instance_status = 'Complete'
       AND s_lbb_parent_state = 'Close'
       AND id = 2;

NOTE: Always be extremely specific on the where-clause during an UPDATE statement and triple-check! Especially on production data!

Notes

• I use HeidiSQL to do SQL magic on my database; Ask you administrator for any connection details and type of database where mine is ‘Postgres’.
• You can find your organization ID (o2 in my case) with this query: SELECT s_organizationid, s_payload FROM s_elementdefinitions WHERE s_payload LIKE '%{"organizationName%';

The result is a happy customer, with happy end-users, and a happy low-code developer bringing the solution back on its path…

Great, that’s a given “DONE” with the best insights you’ll face when you want to have your lifecycle upgraded to the next level of implementation after you’re landed already into production. This also proves again the importance of the principle to first think, then act. It’s not the first time I have seen this principle being removed from the team scope, but it’s highly effective and limits migration problems in the future. Have your benefits again from this post, and we’ll meet again next week. Over-and-out on this one!

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