Scripted Business Object help

Does anyone have a simple process using a scripted business object that can update a read only grid when a field is changed on a form using an Sql connection.

I'm completely new to C# and an example would really help so I can see how this works.

I've looked through the Metastorm examples but couldn't find anything with an Sql connection that does what I want.

Any help would be much appreciated :smileyhappy:

Thanks

Rich

Find more posts tagged with

BPM

Comments

McGaw_Phil

Hi Rich,

So you have a read-only grid bound to a business object and you want to update that grid when a user clicks a button or selects something from a dropdown list?

Can you get away with just using the "Insert Rows", "Update Rows" or "Delete Rows" visual scripting activities to do something to the underlying table, then have the grid dependant on another, that way the grid will visibily update when something changes.

Richard Galt

Hi Phil,

Thanks for the response.

To make it clearer I currently have a form that contains 9 business objects populating various drop down menus and grids. When I change one dependant field all the business objects refresh causing a major performance hit.

I was under the impression that a scripted business object would give me more control and allow me to selectively refresh business objects as required rather than all of them at once.

McGaw_Phil

Hi Rich,

That sounds like one big old form to me, and I understand why you are seeing a performance hit with 9 business objects on there.

Firstly, creating a scripted business object gives you flexibility in the sense that you don't need to implement all the interfaces that the other business objects might be implementing, but as far as I'm aware a scripted business object will behave like the other ones as far as refreshes are concerned.

Is the data you are wanting to retrieve from a scripted business object "special" in any way or is it just going to be gently manipulating data from a database table?

Also, is it possible to tune all 9 of the objects you have maybe into one business object, maybe a database view, and then tune the SQL query to improve performance?

If you wouldn't mind because I am interested, could you throw a screenshot of your current design up please to give me an idea of what we're dealing with here? (providing the content isn't sensitive of course)

Apologises for all the questions, it is just that I've only needed to delve into creating scripted business objects when I'm doing some funky stuff in C#, and in pretty much 98% of the time I can use the standard business object types.

Saying that, if I'm having to do lots of C# related code, I end up writing it in Visual Studio and then importing the DLL.

Phil

Jerome_Pearce

Frankly, 9 Business Objects is nowhere near very big. The habit of using BO's for all dropdowns and lists creates what we call "Business Object Bloat". The solution can rapidly become unmanageable in such cases, even if you use the strict naming conventions that we proscribe.

The solution we have is to use promoted functions for everything except grids and reference data (aka recordsets in version 7 & before). The simple reasons are to avoid this bloat, and to give much greater flexibility when you want to change any functiomnlity.

For example, we tend to return a fixed list at the start of development, and then change that to a function when that part is developed. This saves a great deal of database infrastructure work during prototyping. When you need to update, the form does not need changing, and in the future it can also be changed without affecting the form.

Why I point this out here is that it is extremely easy to set a local (or even folder) variable to determine if the function should perform a lookup or not, and pass that value into the function. This gives you all of the flexibility of the scripted business object, with no BO Bloat, and none of the considerable coding pain of scripted BO's.

As an aside, Phil, you can finely control refreshes, and indeed any behaviour, in scripted BO's.

Having said that, if you want to selectively allow grids to refresh, or use safe dynamic SQL, then the only way is a scripted BO.

Phil McGaw wrote:

Hi Rich,

That sounds like one big old form to me, and I understand why you are seeing a performance hit with 9 business objects on there.

Firstly, creating a scripted business object gives you flexibility in the sense that you don't need to implement all the interfaces that the other business objects might be implementing, but as far as I'm aware a scripted business object will behave like the other ones as far as refreshes are concerned.

...

Phil

Richard Galt

The process I'm designing is a homelessness database for a Local Authority; this is to replace an ageing Access database.

The database structure had to remain as I require a quick turnaround and it was necessary to maintain the extremely complex reports that need to be replicated. This has been Imported into SQL tables.

Metastorm is probably not the best tool for this but it has been effective in the past at similar ventures. I've tried to keep everything on one form so it's more intuitive to the users who don't have previous Metastorm experience. Between refreshing there is about a 5 second delay for the form to refill.

Jerome is you could elaborate with an example I would be most grateful

Phil if I don't get anywhere with the scripted BO I will look at creating a view.

Jerome_Pearce

Actually, when I go and look at the example I was thinking of, I realise you cannot choose when to refresh. What we did there was store the option list in a local variable, and then decide if we refreshed that variable. Sorry about that.

It seems that the scripted Business Object is probably the best way to go. I have an example based on a simplified virtual class we have in our library. I am dragging this out for someone on our own forums today. When I do, I'll post a link here.

Jerome_Pearce

I have put together a detailed working example here:

http://metastorm.processmapping.com.au/post/Scripted-Business-Object-demonstration-6126348