Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Register Latest Topics
 
 
 


Reply
  Author   Comment  
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #1 
Using Metastorm 9.3.2, with a library, containing a lot of business objects and a lot of C# classes.

I have inherited this behemoth, which is written well enough, but the c# code base is the largest I have seen in a v9 process.

The problem I am currently facing is that when I make changes to the library and deploy it and all the processes that use this library into the DEV environment, everything is fine.

The moment I go to deploy to UAT it breaks. Same environment structure, software versions etc etc. The error was essentially that a form, on a user action had field behaviours for fields that didn't exist.
I took it back to DEV and where it had once deployed fine, it now does not. Same error.

Examined the library and the process in Windiff across the previous versions that had deployed OK and noticed that the main change was GUIDS, in that in the versions that did deploy, the GUIDS in the process map, match the GUIDS of the library, and yet in this version the GUIDS have changed to seemingly random values. I changed all the GUIDs back to the previous values, and it now it deployed OK in DEV but not in UAT.

I am at a loss as to say how the GUIDs became corrupted, and the fact that I managed to get it deploying again in DEV shows me I am along the right lines in my troubleshooting.

I'm fortunate enough to still have contact with my predecessor, who said he had previously experienced problems with this and the quickest way to solve it was to revert to a previous version of the code that did deploy, and do the changes over. This for me is not a good solution, as my company now have me producing "hot fixes" at very short notice, in tandem with the main code branch scheduled for release every quarter.

One thing that does worry me is the sheer size of the c# code base, and compilation errors are common, and near impossible to track down as the c# all gets munged together and the errors reported are often very misleading.

I commented to my boss that the c# code (business, workflow and gui logic all mashed in there) really needs to be split out into managed dlls, giving us the benefit of being able to unit test this beast, and reduce this validation errors by plugging in a known good series of business logic dlls.

It seems to me that this behemoth has just about hit critical mass, and the slightest changes bring the whole house of cards down. I've rather lost confidence in the code, and the environments and just need some perspective.

Has anyone experienced anything even remotely like this?

TIA
0
BMellert

Guru
Registered:
Posts: 672
Reply with quote  #2 
I've not encountered this directly, though over time I've leared a couple things that may, or may not, help.

From experience, when we promote code from Dev -> QA/UAT -> Prod which uses libraries (which is all of out solutions), we "add this library to the curren project" of the library from the current enviroment to the solution beore deploying.  Just doing an update doesn't [always] seem to update correctly when copied/exported from the prior envionment.  This may at least help with the GUID issue, though that's pure conjecture on my part.

You mention the C# code is large.  Is it one huge server script, or broken into multiple scripts in the library / solution?  Either way, you can / should validate script on the individual scripts.  The error reporting is a lot better -- still not perfect but a lot better -- when validated at that level instead of validating the solution as a whole.  When the initial messages don't help, I've found clicking the red X on the bottom tool bar usually gets to the real issue (or first one anyway).

Thankfully the above helps most of the time, however we have had to revert and reapply changes when it can't be readilly worked through.  Thankfully not very often.
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #3 
Thank you BMellert.

I have done some more digging and the process to break it is this :

Take code from DEV (Library and Project) and first deploy the library to UAT. Then open the project, and click on update library. Now try and deploy the project. It fails.

Windiff the original library and project against the newly broken files and bingo, the GUIDs have changed.

So it does seem to be the update lib that breaks it.

Someone suggested copying the code over, resetting the library version to the latest version of the library in notepad on the project file, then deploy. It works, but still makes me nervous that this hack means it picked up the correct version of the library.

I did spot this gem in the 9.3.2 release notes :

"An incorrect behavior with shared libraries is observed when a library is shared with two or more projects, and the connection point parameters are set to null and overridden in projects. (Issues# 2029196, BPM-8458)"

Not sure what this incorrect behaviour is as they don't describe it, but the scenario is perfect.
0
BMellert

Guru
Registered:
Posts: 672
Reply with quote  #4 
We share 2 libraries in all projects, and 1 additional in several projects with never encountering an issue.  One of these libraries have different database and web connections.  (Though none are set to null.)

However, as mentioned in our last post, we learned along ago that a straight "update" after opening the solution from an export in a different environment doesn't usually work.  (My theory is it doesn't necessary grab everything from the current enviroment and some hooks into the old remain.)

This is why we always use the "add this library to the current" solution from the Repository to gaurantee the correct library is updated and refreshed when moving code between systems.  If the GUIDs change then, you are at least garuanteed to have the right ones from the current enviroment, not "left over" from the prior enviroment.
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #5 
I did try the "add this library to the current" solution, and this did not help me, although I do take your point and recall something about this in the past.

I believe I have found the problem, and I think it is a bug in the designer.

To keep this as simple as possible let me start at 10,000 feet and tell the tale of what I have discovered.

So we have a library, with Query BOs, forms, c# scripts etc etc. This is used by 6 different processes. 5 of which deploy fine.

What I have noticed is that the action of just opening up the problem process, and updating the library, causes changes in multiple files in the solution. These are GUID changes.

If I deploy using deploy.exe from the command line, then it deploys fine, and there are no GUID changes in the solution.

OK now down to ground level with a bump.

This is one example of how it breaks.

I have a QueryBO in the library, called "Customer" for example, and it has a variable called "CustomerID".
This QueryBO is used in the process, in a form called "Customer Details".

If I look at the QueryBO definition in the the library, this variable is represented by a GUID. For example :

"9f988780-3609-4e8e-bbd1-1fdf00870034"

When I look in the form definition in the parent solution, there is a field for CustomerID that has this exact same GUID.

After I update the library (by either method) in the Designer the GUID changes to :

"9246436a-4ffb-4f96-8db4-2b988babbdbc" for example, and now the process is broken and will not deploy.

Where is this GUID coming from?

Well the parent process also has a Query Business Object, called for example "Customer Products", and in it it has a variable called "CustomerID", which has a GUID called "9246436a-4ffb-4f96-8db4-2b988babbdbc".

This is the only process out of the 6 to have it's own QueryBOs, and wherever there is a name the same, it brings the GUID in from the parent, rather than the Library.


0
BMellert

Guru
Registered:
Posts: 672
Reply with quote  #6 
MBPM is particularlly sensitive to the same name being used in a solution.  If I'm understanding what you are saying correctly, that may be the problem, though I have no way to confirm that.  (Personally, we have never had to worry about things a the GUID level.)

When delpoying with deploy.exe are you using the parmater which forces it to update to the current version of libraries?  (I usually deploy via the Designer, but deploy.exe should work as well.)

If I think of anything else, I'll repost.
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #7 
That is the voice of hard fought and won experience there BMellert. :)

Yes I was using the deploy.exe with the force update library. This still broke I'm afraid.

I created a simple library, with one sub process with one variable called field1. Then I added a queryBO to the library with a variable called field1. Then I deployed the library.

Then I created a solution with 1 form, and added a field to the localBO called field1.
Then I added a queryBO to the solution with a variable called field1.

Then I added the queryBO to the form, and dragged both the local and the queryBO field 1s onto the form.

I added the library to the solution and deployed.

Then I added the sub process BO and library level BO to the form and dragged their field 1s onto the form.
Then I deployed.

Then I added field 2 to the queryBO in the library, and deployed a new version of the library.
Then I updated the library in the solution, went to deploy and boom. It is now badly broken.

I have all this neatly zipped up and ready to go to OpenText. Do you guys want a copy? Can I upload files here?
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #8 
Just a quick update. I raised a ticket on 10th March. This has now been assigned to a developer (yesterday) to investigate.

Hopefully have some news soon.
0
suityou01

Avatar / Picture

Veteran
Registered:
Posts: 213
Reply with quote  #9 
OK a brief update. I am told this is still with the developers for investigation.

What I have found is another issue, that is sort of related.

If you have a process, with a form, and fields bound to a query business object in a library, try the following steps :

Open the library. Open the business object designer. In the query tab, change the SQL, but to something syntactically incorrect. Click on the values tab and wait. No variables are listed.

Change back to the SQL tab and fix the SQL. Change back to the values tab. Your values are now there.

Publish your library.

In the solution, update the library. Your solution will no longer publish.

The reason is that if you break your sql and click on the values tab, it will apply new GUIDs to the variables on the query business object. However when you update the library in your solution, your field bindings are to the old GUID values and are not updated. So you have to rebind all your fields on every form that uses this query business object.
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!