Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
Rob_B

Veteran
Registered:
Posts: 109
Reply with quote  #1 
following on from rdalimonte's post, I have another weird situation with 9.0.2.1556

I have a solution with a process which is a parent to multiple sub-processes. To allow the sub-processes to be edited individually I keep all of the variables in a library which is referenced by the solution and a solution for each of the sub-processes; when the sub-processes have been edited they are just exported from the "sub-solution" and re-imported into the "parent" solution

All very grown up, but I have a niggle and a major disaster

The niggle - for some reason once a solution has been saved I can't export the sub-process, I can only export as a process, but it seems to be ok if you select save as "all files" then give it a .SegPkg extension

The disaster - an update of the variables library has corrupted the entire %$£*&^~ solution. All of a sudden items which reference the MBO fail, conditions in conditional actions are displaying a warning that "the name 'AppVariablesData1' does not exist in the current context", the business object icon is greyed out in the expression builder, and clicking on the ellipsis for the assignments in "assign Values" visual scripts gives the error "Object reference not set to an instance of an object"

I have tried re-importing the library, going back to an older one, and using the unbelievably stupid "Backup" facility to no avail.

The only recourse I can currently see is going back to an older version and losing a day's work, which frankly I find rather depressing but all too familiar with this *#~@$%*! software

This is the second time that I seem to have lost the reference to the MBO, the first time it only took an hour or so to recreate the solution, this time I am fuming!!



__________________
There are, essentially, three types of mathematician; those who can count, and those who can't
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #2 
That scenario occurs when there is a reference that is broken. The entire thing becomes unusable.

The only possible way to find the colprit, since a validate shows everything to be an error, is to save as a different solution and remove components one at a time. When you find the offending component (ie the errors stop), open the original, save again, and remove elements from the component until the error stops.

In my experience it is often a Visual Script Activity. Anything on an event visual script can retain an incorrect reference, and it blows the whole thing up.

Be aware that there may be two or more issues. This means that when you done the procedure above, you may have to rinse and repeat until you find the second, third, etc. I also find that once you find the first, the others are immediately obvious.

Not fun. It is just grunt work, however, and you do not have to think.

I feel your pain having been there a few times, once with a severe deadline looming! The air was blue that day.

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Rob_B

Veteran
Registered:
Posts: 109
Reply with quote  #3 
The air around here has been pretty blue too...

Thanks for your words of sympathy Jerome; the way I have approached this is reverting to a previously published version (the best feature of ework ever; it's as if they knew that it would fall apart...) and rebuild

I have reached the point where it blows up again and, for future reference to fellow metasufferers, it appears that somewhere in the putrid tomb that is the "solution", metastorm is storing a reference to a default action name in the library, ie it was once published with "useraction1" in the default process. When adding a user action to the "parent" map, metastorm automatically calls the action "useraction1" and blows up with a duplicate (I really, really hate the fact that whilst every variable has a fully qualified mbo.variable name in code, every single action and stage in the whole process and all of the subprocesses and referenced libraries have to be unique, this is almost impossible to police in large projects with multiple developers)

I don't understand where the reference is, I have completely removed the action, republished the library and updated the reference, but find and replace still finds it.

I have renamed it with find and replace... and can now find the new name although still no idea where it is supposed to be in the project!


==============================edit=======================
This may also have been caused by copying and pasting an action!




__________________
There are, essentially, three types of mathematician; those who can count, and those who can't
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #4 
I think it may be the 'non-action' that starts a sub-process. If it always makes it UserAction1, however, then having two map segments would cause a conflict.

I agree that the need for unique names of all kinds is a pain. It really seems as though the object model is pretty flat. For example, I would have expected that actions would be sub-objects of Stages, as it is in the database. I don't think the object model works that way. There are obvious clues such as the fact that you are unable to have any element the same name as its parent.

Having said that, you do need some way to get intellisense to work for you. I would have expected a more OO object model myself. That would not cause these conflicts to occur.

Good tip on using Find & Replace to rename it even if you can't find it!

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!