Hi there “Process Automation” fans,

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

A fascinating and valid discussion with our development team this time. It’s all about relations between entities and whether we want to inherit or if we want to relate. This is also a discussion at every project so that’s why a post about it would be in place and for us all to learn from.

FYI, this post will not create anything in a workspace/project this time. So, we don’t need any VM…I just want to explain and let you think into different directions. There are always multiple ways to the city of Rome; There is also not “the best way”. All roads have bumps you need to overcome, and sometimes it’s hard to choose the less bumpy road unless you’ve inspected the road from close by!

When you inherit entities, your Entity Relation Diagram (ERD) can look like this (check the “extends” arrow):

Simple to create and easy to understand with the benefit that you can access the optional object entity (as relation to case) directly from case_a when the relation is in place! Agree? So far, so good.

…

Now for the discussion! We have a complex situation where the inherit situation causes a lot of problems at database level. Why? Well, an inherited subtype entity will live in the same database table as its parent; Let’s not dive into this in this post, you can read about it here. Because of the issues, we made a choice to replace the “extends” arrow with a relation; Like this:

That’s all nice and great (and fully agreed as a team), but with this choice we don’t have direct access to the optional object entity (from a case_a point of view). I hear your thinking, but that’s something you solve with bidirectional relations; right? Well, I agree, but not if these entities live in different projects where you must work yourself through the maze of avoiding so-called “circular dependencies”; Again, read about that specific topic here. So, in that situation case_a can depend on (or relate to) case, but case can’t depend on (or relate to) case_a!! Ahaaa; So, now what? How can you access the object entity in this situation!? Well, there are two option to work around it; Both have their advantages and disadvantages.

---

Let’s get right into it…

The big problem starts of course when you want to instantiate the case_a entity from runtime and want to choose an object entity as a relation. Without the instantiation and relation of the case entity this is impossible! There are two ways to work around this issue, and we figure both out in this post.

---

Create an extra relation from case_a to object

In this situation the ERD will get an update like this:

It’s indeed a solution to first select the object on case_a instantiation and build a ‘Rule’ building block to ‘onCreate’ (or on lifecycle instantiation!) start a BPM which instantiates the parent case entity and remaps the relations as it should be; including the removal of the initial relation from case_a to object (something to not forget!).

But now imagine you have 5 other case_x specific entities? That will eventually look like this in terms of ERD:

This is exactly what you want to avoid for these reasons:

1. A situation like this will have a dramatic impact when you want to change relations, but you already have data in production.
2. A new developer will first need to figure out what choice was behind this (long after your premium tear developers are to the next project!)
3. You want to avoid the situation where a developer forgets or accidentally leaves the relation in place between case_a and the object entity.

And let’s face it, this (for the next section) reads a lot nicer…right?:

Let’s be clear that I do agree on the simplicity of the above way of implementation but have a comment at the end when you read about the next section on a different approach to still make it work; without all the extra relations!

---

Leaving the ERD as is and instantiate a “temp” case entity instance

So, we aim for that last image in the previous section, but how do we solve the big issue that you want can select an object entity on instantiation of the case_a entity…That’s impossible without a case instance in between! Agree? But what if I tell you to create an ‘onInit’ ‘Rule’ building block on case_a triggering a BPM that creates an instance of the parent case entity and relates the new instantiated case_a to this new case instance! Aha!! So, now we can indeed select an object on the case_a entity (via the in between relationship)…Niceee! 🧐

Ok, but what if we hit “Cancel” on the case_a initialization screen!? Aha…We have smart a person in the room paying attention; Very good…Well, the cancellation triggers a ‘Rule’ BB of type ‘onDelete’ on the entity that can start a BPM cleaning the “temporary” related case instance…Niceeee again! 😎

Is this all to overcome the discussion!? Nope! As there is always an extra entity between case_a and the object entity (which is case), you always need to do an extra service call (a read operation of the case entity) in whatever advanced BPM business logic you require to build.

What else? Well, we found ourselves another platform limitation! Tell me, tell me…It has to do with a ‘Rule’ BB of type ‘onRelationChange’ on the case_a entity! What is wrong here? Well, there is an option to select the case entity as relation change, but there is no option to further drill down to object. Now I hear you say…Well, that’s because you need to define that ‘onRelationChange’ rule at case level; Again, I agree; Only, that’s where you will hit the wall of circular dependencies again! Hmmmmm…🤔

To overcome this last ‘onRelationChange’ struggle it’s possible to work with ‘Rule’ BBs of type ‘onPropChange’ (on both case_a and case), but that requires additional Boolean type of property as “flags” to trigger a BPM; It must be on both entities because my BPM still not fires if I purely check at case_a entity the related case flags (it only fires the BPM when the flag changes at the case_a entity)…Well, this is an implementation choice against my intuition (so, not agreed!), but still overrules the usage of relations across several entities. Why? Because you can easily remove and replace the Boolean flags with ‘onRelationChange’ rules once OpenText solves this issue. Why do I know this issue is solvable? Because I do see that my “show info message” action does trigger on change of the related case entity flags! Aha…

Are you still with me? I know it’s complex stuff and hard to explain in pure text, but also images don’t help here either.

This is how you build the Boolean “flagging” to trigger a BPM at case_a when the relation changes between case and object (which you can’t directly detect with an ‘onRelationChange’ at case_a neither directly with a ‘onPropChange’ at case_a):

1. On the case entity, add a true|false flag to tell it’s inObjectEntityChange (with a default value of ‘false’)
2. On the case entity, create an ‘onRelationChange’ rule on object change that sets the inObjectEntityChange to ‘true’
3. On the case_a entity, add (also) a true|false flag to tell it’s inObjectEntityChange (with a default value of ‘false’)
4. On the case_a entity, create an ‘onPropChange’ rule checking the inObjectEntityChange flag of case and sets the inObjectEntityChange on case_a to ‘true’
5. On the case_a entity, create an ‘onPropChange’ rule checking the inObjectEntityChange flag of case_a which can validly start a BPM to do any further advanced logic (including the reset of the Boolean flags inObjectEntityChange at both entities!)

To complete the discussion; What extras do you need for this second implementation:

• An extra initialization BPM creating the relation structure
• An extra cancel BPM if the end-user hits cancel over creation
• Always an extra ‘ReadCase’ service call in advanced logic for BPMs (initiated from the case_a entity)
• And…because of the platform limitation in the ‘Rule’ BB of type ‘onRelationChange’, extra Boolean flags as workaround to detect a relation change between case and object from a case_a perspective; I agree…Not nice, but solvable as #FEATURE at OpenText for our beloved OPA platform.

Are the extra efforts worth it to keep the ERD pure compared to extra relations; In my opinion “Yes” IF OpenText solves the issue for our project which should be possible because the “show message” does respond on our implementations.

---

I know, it’s a complex use-case, but I give it a “DONE” where you just read about the two ways of implementing an advanced relation feature. The first one with all the relations, but fewer steps for configuration. The second step with a purified ERD model, but more steps for configuration. Which one is your favorite? Let me know in the comments. FYI; My favorite is the second one as I know the power of a solid ERD model for the long run (whatever the extra steps required). I leave you all with a great weekend ahead; we continue our life, next week, on another topic on “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”?