Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #1 
Such a waste of an opportunity!

One of the most common complaints of Metastorm BPM is the inability to populate grids will data from all sorts of sources. I assumed that having teh Business Object abstraction layer would allow you to use a stored procedure to fill a grid.

No chance, sorry.

The designer cannot 'see' the returned field names, although the test facility gets the data perfectly. But because it cannot 'see' the field names, it cannot build the BO.

Such a shame, guys, it could have been pretty easy, I should think. Perhaps nobody in Metastorm knew this was a core feature that customers (and potential customers) have been asking for.

__________________
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
Meatstorm

Member
Registered:
Posts: 34
Reply with quote  #2 

If this is true, then it really is a shame.  Have you worked out if there is a way (via C# code presumably) to call a web service and set a complex result set to a business object, in order to display results (such as a list of client names and addresses) in a grid?

0
Meatstorm

Member
Registered:
Posts: 34
Reply with quote  #3 

Also have you tried using "as [fieldname]" in the query?  I did this with a "count(*) as [folderCount]" and it was then able to recognize the variable in the business object.

0
Griff

Member
Registered:
Posts: 38
Reply with quote  #4 
See the following link for a working example.

http://metastorm.processmapping.com.au/post?id=4267221
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #5 
Quote:
Originally Posted by Griff
See the following link for a working example.

http://metastorm.processmapping.com.au/post?id=4267221

I just tried my own again, and it works fine - the field names come through immediately.

I was trying to creating a temprary table in the previous stored proc and returning results from it, and that was obviously what was stopping it working correctly.

OK - non-issue, sorry about that.

__________________
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
Griff

Member
Registered:
Posts: 38
Reply with quote  #6 
One of many things I have learned about business objects is that when the object has been created but the variables are unable to come across it most likely is an issue with the method (Query - database - LDAP......).  I kept this as a rule of thumb when working with the betas and early releases.  I recall an issue when writing a JOIN and both tables had the same column name (e.g. eFOLDERID) it prevented the creation of the variables but it pass the design testing portion until I applied the business object to the form.  So I noticed that there were two columns with the same name, so I created and alias for one of them and presto it worked.  I am pretty sure development fixed that in the latest release but always keep this back in your mind.
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #7 
I am getting interested in what happens when BO's are changed, too. I get a bad feeling we may end up with the same problem we have with datasets in v 6 & 7, as well. I will try the same tests and see. Hopefully the only difficulty will be with the UserInput value, as that may the only situation where an index is used instead of a field name.

__________________
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!