Map Business Object in a library in v9.1.2.2

Hello,

we found that some form fields, which are referenced to a business object in a library, are lost their mapping to their respective columns in the business object. For instance, a form field ClientName defined as clname in a business object in a library. Later on, we found that ClientName is no longer pointed to clname. We are in v9.1.2 hot fix 2. It is strange that not all fields lost their mapping (some will stay).

We also found that when moving process to a different server, because it's needed to refresh/update librtaries, it is almost certain that some fields would lose their business object mapping.

This seems only happen to business objects that are in a library.

Did this happen to you? How you get around (for us, we have to check those fields again and again after code changes are made)

Thanks.

Find more posts tagged with

BPM

Comments

Jerome_Pearce

Are these Table Business Objects or Query Business Objects?

Are the missing fields recently added to the Business Objects?

Robert Vignerot

I'm not personally aware of issues wrt to business objects contained within libraries, but there is an acknowledged defect (DEF20326) in 9.1.3 in which query business objects lose their bindings whenever they are touched even if no changes have been made. It is a very annoyng issue.

Zhao_Xiao-ou

It's a query business object. We didn't modify that business object for a while and this issue happened. Recently, added two more columns, only to find binding lost in forms that use this business object. Robert is right. That's the case. But we are on 9.1.2, not 9.1.3 yet. So it seems a defect in 9.1.2 too.

Jerome_Pearce

It could be to do with the Library Cache of the Designer. Here's the scenario:

I have a BO with fields A,B,C.

On the Dev server I add field D.

I open the Solution on the UAT server, and the Designer gets my most recent library from the cache which does not have field D.

All references to field D are lost.

The way to avoid it is to always open and deploy libraries on new servers before opening the project.

There are other scenarios, especially to do with deploying to different repositories from the same PC. We do not recommend this at all because of the potential disconnect between the repository and the database connection. As you cannot change the database connection at the same time as the repository, you end up with so many potential and real issues that we have a policy of not doing this at all.

Paul_York

Jerome,

Just to be clear, are you saying you would never use the same designer on one machine to connect to and deploy to a development, a uat and a live server?

I've never experienced an issue that I could completely pin down and we've had a few on deployments but surely a designer for each environment you're deploying too isn't the way forward - that's crazy

Cheers,

Paul.

Robert Vignerot

This does seem a little crazy to me as well. I would think this issue is because you are opening the solution from different machines that have different library versions in their local cache. It wouldn't be an issue if you deploy to DEV from your machine and then deploy to UAT from the same machine.

Zhao_Xiao-ou

Hi,

This is happening right now to us. Here are steps I did: (each server has a designer installed)

No library changes.
Copied whole package from Dev to Prod
Open the library, change connection strings, deployed the library
Open the process solution, updated the library by retrieving the latest library, saved the solution
Go to the form, for some fields, the data binding to the business object in library lost.
It is amazing that not all fields are lost their binding. Compeltely un-predicable

Thanks,

xiao-ou

Paul Lawrence

I tend to concur with Rob.

I have experienced recent problems with libraries when transferring solutions and libraries between environments (different Designer). Typically this manifests itself as Designer not recognising or updating newer versions of libraries.

I have found that removing the library cache helps in some situations but not all. A few restarts of Designer seemed to do the trick earlier this week but it does seem a little strange at times.

I do worry about deployment to production environments where these tasks can often be undertaken by different teams from scripted deployment instructions and where some of these subtleties may not be noticed or picked up.

Jerome_Pearce

Crazy it may seem, but there are problems that are specifically related to deploying to several repositories from one PC.

The main problem is encapsulated by the question “where is my library coming from”. If you have several repositories set up, how can you make sure that the library you are effectively deploying with your solution is the one in the target repository? The answer is not documented.

Scenario One:

I develop on my Development system.

I then open my library and deploy it to Development.

I then open my project, refresh my Library, and deploy to UAT.

The library version I have deployed as part of the project is not the same version that is deployed to UAT.

HOWEVER, if I did not deploy the latest library to UAT, all would ‘work’ as expected, but the new version of the library is not deployed to UAT. If another user goes onto the UAT server, for example, opens the project and refreshes the library, they then have the WRONG version of the library. There is no explicable reason for this occurring at the time, until the logs are examined in detail.

This has caused enormous confusion when diagnosing problems, especially in environments where multiple users work on the same system. It was also possible to do this version 7, BTW.

Scenario Two:

The database in Development is different to the database in UAT. This occurs easily, mainly by adding fields to tables or variables to a process, and then removing them. If you ever do this, there is a risk that any Business Object related to that table will be incorrect in a different environment.

I create a table with fieldA, FieldB and FieldC.

I add some data to this table.

I decide to remove FieldB. It remains in the table, however.

IO create a Table BO based on this table, It has fieldA, FieldB and FieldC.

I deploy to UAT. Bear in mind that my database connection IS STILL DEV. That means that my BO definition still contains the three fields.

In UAT, however, the table is created with TWO fields, fieldA and FieldC.

How is that resolved by the system? What problems will I see? The answers will vary, and are not documented.

The third problem is one of software version. It is a nightmare once it starts.

Scenario Three:

I decide to add a patch to Development. It works, that is OK. I deploy to UAT from my Development system.

It fails at runtime in UAT because the version deployed is incompatible with the UAT engine.

In that scenario EVERY DEVELOPER must have the exact same version on their systems in order for this to work!

If I open in UAT, the Designer may choke on the solution, so I see the problem immediately. It may also deploy correctly (which may or may not be OK).

Summary:

The problems with having multiple repositories for one Designer may be summed up so:

You do not know where the library is being refreshed from. This is not documented or clear.
The Database connection is not related to the deployment service. Multiple problems can be generated by this.
The Designer may not be the same version as the engine using your target repository.

All of these problems are solved by opening the libraries on the target system using the Designer installed there and deploying them, opening the solutions, refreshing the libraries (if required, typically not), and deploying. It is simple, easy to enforce, and it works.

In a shared development environment, all of these issues can and will occur. Please let me know if I have any of that wrong. These are what we have experienced. We have not had the time to investigate the problems we expereinced thoroughly, and so this is based on reasoning, but would be happy to do so if anyone deems it worth the cost. Having found a simple workaround, it did not seem worth us pursuing.