Registered: 1158198299 Posts: 5,507
Reply with quote
Scripted Business Objects were a great idea. You can, in theory, get your data from anywhere and then display it in (for example) a grid. The reality is a little bit more awkward.
As several people have asked about this, and in particular how to prevent a refresh, we had a go at making this work. The result is in our Admin Tool procedure here: http://processmapping.com.au/freestuff/freemetastormbpm9solutions/AdminTools.html Points to note, we have created an abstract class that does most of what you need. This is in the PM Library. This makes the class you have to build fairly straightforward: The constructor: As I understand it, this can be empty unless you want to use a created connection (ie not the default). As any Semi-colonist will know, this must be the same name as the class itself. Parameter definitions: Just add an abstract 'get' for each parameter. They can be used any way you wish in the code. add a virtual get function for every column. This must be of the correct type. Add a Read() function that fills your DataSet object. The simplest is just using SQL, otherwise you do have to faff about creating and filling the DataSet object 'manually'. In the Folder Query BO in the linked solution, I cache the dataset on performing the Read() and before returning the data. If the 'Refesh' parameter is true, I read the data from the database. If it is false, I read from the cache (if null, ie the first time, I read the data). On the form, when I select a Process, I want to refresh the Stage list, but not the grid. To do this, I set the Refresh variable to false. When you press the 'Refresh' button, it is set to true. It is a fairly trivial example, but it shows the mechanism. I know there are some things I am going to clean up, but it is late right now. In addition, it shows how you can have dynamic (building SQL 'on the fly', but properly parametrised and safe) SQL once again, and also how we can create an 'IN' clause for our Business Objects. All other approaches to these problem involve using the 'execute' function or similar, and that exposes you to a massive risk of "SQL Injection". Such an approach is not only dangerous, it should be expressly forbidden where any level of security is wanted, let alone required. This approach allows it to be managed safely. let me know if there are any issues - it is still a work in progress. __________________ 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.