Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
praxkan

Veteran
Registered:
Posts: 142
Reply with quote  #1 
I figured this would be a better place to get a truly unbiased opinion :)

Is there a true business case for Scripted BO's that cannot be achieved without them ? Also, there's so many posts about bugs with scripted BO's - have they all been fixed? 
0
lqc1

Member
Registered:
Posts: 13
Reply with quote  #2 

I have used scripted business objects without issues, knock on wood.

In my case, I had to create a complicated search form with multiple filter options. 

Don't use scripted business object if a simple business object or a function returning a list will suffice.

Good luck...

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #3 
Scripted BO's are a must, eg when a dynamic query is required. The are also a must for anything that requires complexity, like code. In these cases they are very powerful. Check out our library where we show all variables with their values in a grid. We used to use an awkward view, but a scripted BO its much cleaner.

You need to be careful, and it is easy to make mistakes. I find the awful syntax checking the worst, because it just says everything is broken if one line is wrong. You need to be very careful with case sensitivity as well, I've found.

All in all, powerful, but not easy to use at all.

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

Veteran
Registered:
Posts: 142
Reply with quote  #4 
Thanks for the response !

Jerome - by dynamic query, do you mean the actual columns returned by the query can vary at runtime versus just the WHERE clause?  I'll check your library.

lqc1 - I had to do something similar with a complicated search and multiple filters.
Got around that (at that time) by building a dynamic where clause as a string, and then using
a query bo with 1 paramater


EXEC('select * from table where ' + @WHERESTATEMENT  )
0
pdkaman

Senior Member
Registered:
Posts: 71
Reply with quote  #5 
Hey praxkan,

I think by dynamic that a DataTable can be return in the ServerScript... as well the changes can be committed within said ServerScript.

The query is what you want it to be w/in the SBO as well as adding columns/attributes to your object.

Jerome, good to know you guys have SBO examples!

Paul
0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #6 
Quote:
Originally Posted by praxkan
Thanks for the response !

Jerome - by dynamic query, do you mean the actual columns returned by the query can vary at runtime versus just the WHERE clause?  I'll check your library.

lqc1 - I had to do something similar with a complicated search and multiple filters.
Got around that (at that time) by building a dynamic where clause as a string, and then using
a query bo with 1 paramater


EXEC('select * from table where ' + @WHERESTATEMENT  )


Columns (names/types/number of) cannot be dynamic. These are set in the BO utself, and cannot changes. I was referring to the dynamic 'where' clauses, yes.

If you use the approach you mention (and that Metastorm appear to recommend), then you leave your system WIDE OPEN to SQL Injection. If I knew you had this, I could update your database, or even kill the system, at will. This would never be allowed in any system with any security evaluation whatsoever, in my experience. Just don't do it.

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

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #7 
As  pdkaman says, you can return any datatable. It needs to conform to the column names and types defined in the BO.

What is actually more interesting, is that you do not (I believe) need the datatable at all. The 'get' functions should be able to get hold of any data from anywhere. I have not proved this, as I think you need to manage the row number, but it should be possible. In essence you can define any parameters to a 'function' and then return data in a grid.

If I get time, I will try this out. As yet I do not have an idea of any data to get without it being in a datatable, but if I do (or anyone has an idea that could be easily implemented), I'll give it a go.

To be brutally honest, I firmly believe it should be possible to fill any grid using a simple function that returns a datatable in any case. It would make grids much easier to build, and reduce the Business Object Bloat we see in most solutions.

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