Hi there “Process Automation” fans,

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

This post is a small follow-up on the post from last week when we discussed a fascinating relation issue. Let’s put the discussion to a test where we remove a relation between 2 entities from a solution after you create a set of entity instances (with relations) in runtime. Just to see what will happen in runtime and what happens at database level.

Just to be straight; This is not the same situation from last week! Last week was indeed a double relation to solve a nasty situation on instantiation of an entity. The end-result was still one relation with the second relation removed but still possible to recover (accidentally or on purpose).

Let’s get right into it…

Boot up your VM and in your favorite spot of the platform, create a new case entity with some interesting properties to play with and generate the default set of building blocks with some smart naming. Next, create a second entity object with again some properties, default BBs, and smart naming.

Now create a ‘toOne’ relation from case to object:

On the lst_cases, add one property from the related object entity:

On the ‘Create’ form of case add the relation as a dropdown:

Nice and simple…Right? Publish it into runtime and create some instances of object and create some instances of case with a relation to object…A task on your own!

…

My first question for now would be: What’s going on at database level and what’s the query behind lst_cases? Well, I always use the small tool HeidiSQL for database insights. On my organization (tables starting with o2), I can clearly see an extra column in case:

So, I expect the query behind it to look something like this:

1
2
3
4
5
6

SELECT c.case_name,
       c.case_budget,
       o.obj_type
FROM   o2opa_tipsprj_genericcase AS c,
       o2opa_tipsprj_genericobject AS o
WHERE  c.to_one_object_id = o.id;

Where my ChatGPT friend makes this out of it (because Postgres likes this better):

1
2
3
4
5
6

SELECT c.case_name,
       c.case_budget,
       o.obj_type
FROM   o2opa_tipsprj_genericcase AS c
       JOIN o2opa_tipsprj_genericobject AS o
         ON c.to_one_object_id = o.id;

FYI; This is how the OPA platform receives our list from the database; I agree…It’s more robust indeed!

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

SELECT o2opa_tipsprj_genericcase.id AS col1, o2opa_tipsprj_genericobject.id AS col2, o2opa_tipsprj_genericcase.case_name AS col3, o2opa_tipsprj_genericcase.case_budget AS col4, o2opa_tipsprj_genericobject.obj_type AS col5, o2opa_tipsprj_genericcase.s_item_status AS col6, o2opa_tipsprj_genericcase.s_is_temporary_copy AS col7, o2opa_tipsprj_genericcase.to_one_object_id AS col8 FROM o2opa_tipsprj_genericcase LEFT JOIN o2opa_tipsprj_genericobject ON o2opa_tipsprj_genericobject.id = o2opa_tipsprj_genericcase.to_one_object_id WHERE ( o2opa_tipsprj_genericcase.s_item_status = '1' OR o2opa_tipsprj_genericcase.s_item_status IS NULL) AND ( o2opa_tipsprj_genericcase.s_is_temporary_copy = 'f' OR o2opa_tipsprj_genericcase.s_is_temporary_copy IS NULL) ORDER BY o2opa_tipsprj_genericobject.obj_type DESC limit '200' offset '0'

…We’re going off-track!

Imagine yourself a full-blown production database with these related entities in place as dataset for the future. You replaced your premium skilled developer with a new newbie developer in the market (and there is nothing wrong with it!) while the team has a wish to clean up relations from the current solution? Well, watch and learn…

So, on the case, we drop the relation to object:

We do a save AND we do a quick publication into runtime (which has almost the same impact as the deployment of a CAP file into project!). Now you guess what will happen. Yes, my friends, the relation is gone!! This includes the relation selection on the case ‘Create’ form and the lst_cases with a result like this:

The object instances are still available, but not related to any case instance!? I’m glad not to be in such a situation, but you’ll not be the first one hitting this wall hard! That’s why we assess things, review each-others work, and accept it as a team effort.

What about the database table structure? Good question! The system removed the column ‘to_one_object_id’ from the case table! Can you restore this? Well, I’m not testing it out, but I hope you have a database backup available; then I would restore the ‘Relation’ BB, the ‘Create’ form, and the ‘List’ BB, do a publication/deployment into runtime (with no further relations in place), and do a restore of the database!

That’s a relative “DONE” where we got some interesting insights about entity relations and the impact on changing them! Always know what you do with the platform before making a choice or introduce a new change. Keep your fellow developers informed about the impact and continue sharing these details with the rest of the team/world. We all know the impact now, learned from it, which brings us to the end of the post. Have a great weekend, and we continue our journey, next week, with another fantastic post! 💪

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