CA Gen model corruptions: deal with them now before they halt your project

JJ for blog

Jeff Johns: Principal Consultant

This month, Jeff Johns tackles errors and corruptions in CA Gen models, and looks at how they can be identified and fixed.

The vast majority of users will know that CA Gen (also known as COOL:Gen) models can contain potentially harmful errors and inconsistencies. We usually refer to these as model corruptions and they are found in the majority of CA Gen encyclopaedias.

It’s not hard to find them (CA Gen includes an option to run an Encyclopaedia Validation Report) but what do you do once you’ve found them? Do you actually need to do anything? Also, not all types of corruption are detected by this report, so how can you be sure you’ve found them all?

eraser and word error

Model corruptions: deal with them before they become a problem.

Most organisations, when they find such errors, frankly tend to ignore them. And that might be fine for a while if the model isn’t actively being maintained. But that all changes when those errors start to rear their heads and cause problems during development (“missing mandatory association” anyone?), code generation, deployment or, worst of all, at runtime. Now, they can’t be ignored. In this blog, we look at how these corruptions – which can have potentially expensive and damaging consequences – can be dealt with once and for all.

To begin with, let’s explore how they originate.

At a very low level, CA Gen has an underlying schema which contains all the objects it needs to define an application – data types, logic statements, UI controls, flows, etc. All of these objects are interrelated, and the schema keeps track of these relationships.

Corruptions happen when, for whatever reason (usually through hardware or software failure), the rules that define the schema are broken. For example, there may be an association missing that the schema expects to be there. It can’t therefore link these objects to one another. There may be an Attribute that’s not associated with an Entity Type, or a Logic Statement that’s not associated with an Action Diagram. Or the corruption may be more complex – perhaps the Attribute is associated with TWO Entity Types when the schema requires that it is associated with one and only one.

The more a model is worked upon, or the more version upgrades it undergoes, the more scope there is for these errors and corruptions to creep in.

Prevention is – in this case – much easier and quicker than cure

In our experience, users tend not to run Encyclopaedia Validation Reports regularly, and most tend to only discover them when they have problems with their models. Most CA Gen users adopt the mentality of ‘it doesn’t seem broken – so why fix it?”. It’s simply not a priority in their day-to-day business.

The problem is that these errors, when they do present themselves, always do so at the most inconvenient time – when you are trying to create a new version of an application, whether as part of on-going maintenance or some modernisation or replatforming exercise. Corruptions can stop a project in its tracks, while everyone wonders what to do. This abrupt halt usually results in, at least, a small panic.

This tends to be the point where we are contacted – and there’s usually, not surprisingly, a sense of urgency.

So what can be done?

Whether being carried out before or after the situation becomes critical, the process is largely the same.

The first thing is to look at nature of the errors. To do this, we have developed our own Schema Tool, which allows us to look at the ‘nuts and bolts’ of the CA Gen model at a very low level. This allows us to see the vast number of objects, and examine all of their properties and associations, just as the Gen toolset does.  However, our tool provides us with the deepest level of information, presented in a meaningful and structured way, allowing us to capture the inter-relationships within a model and between models.

Schema tool

Jumar’s Schema tool is used to examine the contents of a Gen model at the lowest level, allowing the user to navigate around the model’s objects and display their properties and associations.

We can therefore see where things are missing, and where there are invalid properties or associations where they shouldn’t be.

It is very common to discover that there are associations missing – and we are left with orphaned objects. Usually these can simply be deleted using the Schema tool. Alternatively, if we decide that an orphaned object should be retained and we can find out which other objects it should be related to, we can reinstate those relationships.

If there is a large number of corruptions in a model we will usually want to apply automation to apply fixes in bulk and we have created a dedicated tool for this purpose. Additionally, it’s not unusual for us to write one-off pieces of automation to fix unusual or non-standard problems. To do this, we have to find a pattern within a group of the errors, and let the automation carry out a consistent process of correcting them.

It’s also worth asking yourself at this point, ‘am I sure that I have detected all the errors?’ As previously mentioned, the validation report doesn’t necessarily detect all types of corruption. It’s quite possible to have invalid scenarios in models which do not actually break the rules of the schema. Because of this, we have created additional reporting tools to check for some of these other types of corruption.


Identifying, and then removing the corruptions makes for a smoother project.

Looking at the bigger picture, when we carry out any type of modernization or upgrade activity, we always strongly advise that an error correction process is carried out at the start. It makes sense to fix these at the outset to prevent potential project hold-ups, and because if we’re using automation to modernise a system, we don’t want that automation to be operating on invalid source information. So we run the validation reports, fix the errors that in our experience actually have an impact (there are some harmless ones that we may leave alone), and then run the validation reports again to satisfy ourselves and the client that the errors that we fixed have really gone.

We’re very proud of this capability because there are very few people who can do this. Even the most sophisticated CA Gen users tend not to work at this low level. They’re used to using the toolset and the functionality it offers – whereas we’re 100% familiar with the API and schema where problems like this can be identified and remediated.

Why not try running an Encyclopaedia Validation report on one of your key models and see what you get. You might be surprised. If you’d like to talk to us about the results – or any other aspect of your CA Gen portfolio – please contact us.