v9 BO Refresh

Hello

I want to describe some scenario, and want to know if there is workaround for this issue.

I have an BO created based on external table.

I have an form with controls bound to this BO.

If i want to add some column to this table, i have to refresh BO. Is there any other possilibity, than change query (even If i had SELECT * FROM ...)?

If I will change query to some other table, and next again change to proper table, BO has proper definiotion. But unfortunatly all bindings with form controls dissapear.

Is any other way to refresh BO without loosing controls binding?

Find more posts tagged with

BPM

Comments

Ben Hartwich

Hi Greg,

An interesting issue. Unfortunately I don't have an answer for this, but wanted to mention that I have been caught out by needing to change something simple in a BO query, and losing all of my current form bindings.

I could see this been a real pain in certain scenarios when working on a detailed process. I think there needs to be some smarter validation in the designer when deciding to drop the existing BO associations, I'm sure Metastorm have tried to avoid this issue, but hopefully in another release can address the problem in a different way?

Any other thoughts on the topic?

Jerome_Pearce

If it is a Query BO, just add a space somewhere, click on the variables tab, and it should refresh after a warning.

Grid fields will tend to lose the field selection we have found, but form fields are normally OK.

For table BOs, no chance, as I have pointed out:
http://metastorm.processmapping.com.au/post?id=4410215

Grzegorz Lag

I was hopeing I don't know some trick. But as I see, any one has the same issue:(

It's like Sisyphean challenge. It's HUGE problem. With big project with many changes in the middle of implementation you have to double the time spending on it!

I hope it could be hotfix, rather than new release. Becouse anyone who want to implement something on v9 need it right now

I hope if i have conditions on conditional actions based on BO, it will not disapear. I will check and post this as soon as possible.

Sisyphean challenge

Grzegorz Lag

It seems that fields on forms are the only one place where association with BO dissaper.

I hope it will be some solution for it soon!

Jerome_Pearce

We are already implementing systems with v9, and only find it a slight pain when it comes to Query BO's. I do not recall losing form field associations for these in 9.0.1, but I could be wrong.

We do not use Edit BO's much except for edit grids.

Interestingly, Process BOs do NOT have this problem, so it should be an yeasy for for Metastorm.

Grzegorz Lag

Jerome

There is another funny thing with editable BO. You cannot bind it to checkbox.

And as you said. Process BO don't have this problems!

Paul Denton

So I just did a quick test with v9 SR1 and a Table BO.

I generated a table using the solution table with 3 columns. I deployed to create the table and then created a Table BO and pointed it to my solution table.

A associated the Table BO with a Form (Form1) and displayed all the fields as a Grid. I deployed this and made sure it worked.

Then I added another column to the Solution table and deployed to update the table in the DB. I then selected my Table BO, I pointed to a different table in the DB and then back to my solution table. Now when I check the variables list my new column is there.

At this point I save the solution and then go back to Form1 when I check the instance of the BO associated with the Form, it now has the new column as well and I can go into the Grid properties and simple add a new column and associate it with BusinessObject11.Column4...

No remapping required as far as I can see (expect maybe the parameters in the BO, I did not test that)...

Have I missed something?

Grzegorz Lag

Let me describe my scenario

1) create table in db using management studio

2) create editable table BO in this table

3) create form

4) associate BO with form

5) create fields associated with this BO

6) alter table - add some new column

7) go to BO definition

8) refresh BO by

8a) change table to another one

8b) change table to proper one again - parameters should refresh

9) go to form definition - there should be no more association between fields on form and BO.

Jerome_Pearce

I just did a test with the four different types of BO in 9.0.1. These are:

Table: editable, in a grid. Table BO

Edit: editable, in fields. Table BO

List: Read only in a grid. Query BO

Data: Read only in fields. Query BO

I then updated the table and updated each BO, Queries by adding a space, Tables by selecting another table, then selecting the correct table again.

All form and grid fields attached to the Table BOs lost the reference. I can see no way to avoid it.

All Query BO fields were intact, although if you make an error in the SQL and no fields are selected at any point, they will be lost too.

achopra

My experience has been the same as Jerome describes. Paul, using the steps you described, the new column should indeed appear in the form's BO instance, and can be added to the grid columns, but existing grid columns typically will have lost their BO variable association and need to be re-mapped in order for the solution to publish.

Sounds like the workaround is to use Query BO's when at all possible, and test your queries out in SQL management studio or the like before changing the BO query, otherwise all associations will be lost.

Jerome_Pearce

We ualways use Query BOs where possible, for this reason and the fact that you cannot explicitly sort a Table BO.

Paul Denton

To double check, are all using v9 SR1 or just plain old v9?

Grzegorz Lag

v9 SR1