TI Process aborted after trying to recompile rules

[usagimd]

Hello everyone,

My problem is kinda hard to explain, I hope I can make myself clear cause my english is not very good...

I have a dimension of metric indicators, their values are going to be entered with TM1 Contributor (for a later use in Cognos Metric Designer/Studio). I'll call this dimension DIM_1.

And their elements have calculations made up by exporting/importing rules in a cube where the user enters data.

But one of the features I need is TO DELETE an element of the DIM_1 dimension.

But I can't do it, cause changing the dimension the rule in the input cube won't compile cause it won't find the deleted element (assuming that it was present anywhere in the rule). Still, as a part of the feature, I'm forced to eliminate the Rule lines so the rule will compile without problems.

But even when I clear the rule archive (.rux) BEFORE trying to recreate the dimension it still give me the same error.

P.S.: I have a implementation for automatic rules update, part of this rule is static (won't change) so I have a backup .txt with it's static part what I'm doing before trying to update the dimension DIM_1 is RuleLoadFromFile with the backup of the static part and I'm 100% sure that there is nothing on this static part that involves the elements of the dimension DIM_1.

Here is the error message:
"Dimension Update Fail. Rule Is Invalid: Error compiling rule, line number 57: Element not found"

Is there anyone who has any idea of what's happenning?

[usagimd]

Ohhh sorry,

I totally forgot to tell.

When we run the process for a second time consecutively it works. And will only happen if there is an element of the DIM_1 dimension deleted AND it's on a rule of the input cube.

Att,

[lotsaram]

If a rule explicitly refers to an element in the LHS area statement then deleting the element will cause a compile error and this will effectively break all rules for the cube in question as you have discovered.

The first question that comes to mind is why would you be deleting a measure element then adding it back? This has a lot of undesirable consequences such as
- rule breakage
- element will be permanently deleted from any static subsets that it belongs to
- potential data loss for any input data held against the element
- loss of any element and cell security settings held against the element

It seems like a very strange course of action. Why do you need to delete the element (or why do you think you need to do the deletion)?

Why delete the element at all, why not simply change the rule file or unwind the element if it is a consolidation? If you avoid the element deletion then you avoid the problem.

Also I just realised reading your post you "clear the .rux file". My interpretation of this is you are deleting the RUX file and thinking this will clear the rules, it will not. The RUX file is just a plain text copy of the rules. Deleting the file will not clear the rules of the current in session server as the rules are in memory. To clear the rules you need to do a RuleLoadFromFile as you are doing already but with an empty text file. You would then be able to delete the element without error. But again I question why you would be doing this in the first place.

[usagimd]

Well,

If we could choose not to do that it would be better for us, but it's a feature to our customer and there's nothing we can say to make them change their mind, they're warned of the problems involved when doing this kind of things.

We have some automatizations for every consequence, the last three you mentioned were easy to avoid, the first one we found a logical way to do it but we still have the same error even when we reset the rules...

We don't have any idea of why it's working this way... First of all in Prolog tab of a process we called a process to reset the rules, the process works fine clearing all lines that makes reference to the dimension DIM_1 (the one that is going to change).

Then in the Epilog tab we execute backups process before executing the process that will delete one or more elements from the dimension DIM_1.

About your first question:

For our customer it doesn't makes sense to hide an element by removing it from a Subset or changing security, cause maybe one day we are going to have a few thousands of "deleted" elements.

We recently found a way to make it work, we can't explain why, but we simply divided the process in some new processes, doing exactly the same thing but in different processes.

Any idea of why or if there is a different way to do this?

[lotsaram]

It still seems like very odd design to be actively deleting and adding elements that are rule calculated. Is it possible to give a more concrete example? I'm just thinking that possibly a more matrix design of splitting the dimension might get around your issue and make the rule statement static ...

The answer to why it works with no error when you split into separate discrete processes is relatively straightforward. TM1 sees each TI process as a discrete transaction, all changes made by the process are committed as a single batch when the process finishes. As the changes are being committed from the new copy held by the process into the base model the meta data changes are committed first before the data changes (which would be the rule file change), this causes a major error as the copy of the rule still held by the base model refers to an element that no longer exists causing the process to abort and roll back. If the rule file is first removed in a separate process before the meta data change to delete the element then there is no conflict and no error.

By the way there is no problem with your English, my Portuguese is rubbish anyway.

[usagimd]

I see,

Well there is no way to split the dimension... Because the Rules are not static too, the calculations may change...almost everything can change in this projetc so we designed a cube where the user can "create rules" with the most user-friendly way we could. The some processes in TI are responsible for the magic of put everything on the Rules Editor sintax for the user. Just because they wanted to change the calculations by themselves.

There is a "static" part in this rule wich doesn't involves the problems of deleting the elements of the DIM_1.

All we do is to load a "backup" rule of this static part, then it removes the rules related to DIM_1, and THEN the user can finally change the calculations in the cube and load again the static part + the volatile part of the rule...

Tha's why we need to maintain the cubes and dimensions as they are...

Thanks,