Archive for April, 2007

Client-side DLLs

The Siebel 7 thin-client is marvellous for many reasons, but sometimes it’s necessary to integrate with an old-fashioned, locally installed thick-client application. In Server Script it’s possible to access any DLL by using the eScript SElib.dynamicLink() function, but browser script doesn’t give us the same flexibility.

What we have in the browser is JScript’s ActiveXObject function, which creates an instance of an ActiveX component. For instance, to get the installed version of Microsoft Word, we do:

var wdApp = new ActiveXObject("Word.Application");
alert(wdApp.Version);

No problemo. (Although note that for the function to work, the ActiveX component must be successfully registered).

The big limitation of this function is in the name: it will only talk to OLE Automation (i.e. ActiveX/COM) components. If your client-side object is an old C library then you’ll have no luck. There is a solution, however: open up any installation of Visual Studio (or similar) and whip up a COM wrapper for your old school object. Performance will take a hit, but it saves rewriting applications from scratch.

Siebel’s explanation of ActiveXObject is buried in the upgrade guide – and is missing from some versions of Bookshelf. Find it here. They’ve also got a good technote on creating a COM wrapper, but note that they’re linking the DLL from eScript using COMCreateObject: for browser script use ActiveXObject as above.

Advertisements

April 17, 2007 at 9:02 am

Workflow Process Business Objects

A first contribution from elsewhere! Outstanding. Nathan kindly offered this note in return for ‘getting famous’. Not sure I can help with that, but everyone has to start somewhere…

I did this trying to prototype a problem I had for an interface I was working on. When you setup a Workflow Process you must assign it a Business Object, or else a whole heap of functionality within that Workflow Process does not work i.e. you cannot select Business Components etc.

My Workflow Process was triggered by a Runtime Event, and all was fine for the UI contexts where the business component of the Workflow action matched the primary business component of the UI. However, when I was in a different business object, the Row Id passed was that of a different Business Component and so my workflow did not “flow”.

For example, upon creation of a Contact in “My Contacts”, the Row Id passed in was the Row Id of the Contact. However, when you create a Contact in Account->Contacts, then the Row Id passed in is that of the Account record.

Well, there is a simple way around this, ready for it?

Are you sure you’re ready?

Okay, here it is…

In the Runtime Event, you need to set a Profile Attribute to the current Row Id to pass into the Workflow. You can then put as many Runtime Events on as many business objects as you require, as long as it always sets that Profile Attribute for the Row Id.

Too easy. A gentle warm-up from Nathan, there’s more to come…

April 12, 2007 at 8:50 am 4 comments

Using MVG aggregate functions

Karan asked a question the other day: how to prevent the Status of a Service Request changing until all child Activities have been completed? This type of business rule is exactly what State Models are designed for: set up a model on Service Request Status and restrict transitions to the target status unless a condition has been satisfied. The difficulty in this example is how to write a rule based on child records?

State Model Rule Expressions use the same format as calculated field values, so the same MVG aggregate functions are available. The functions Count, Sum and EXISTS all derive a single value from a Multi Value Group and are an underused way to reduce scripting.

In the example given, Service Request has an MVG Action linked to the child Activities, so we can add a Multi Value Field to point to Action.Status. A rule expression Not EXISTS([Action Status]<>'Done') in the State Model transition gives the desired restriction.

There’s a good example of the EXISTS function in use in the vanilla Siebel 7 repository: see BC Contact field Exists New OutBound Email Activities.

April 5, 2007 at 12:40 pm 4 comments

Searching Calculated Fields and performance

The other day I was asked whether it’s possible to search calculated fields. The simple answer is yes – as can easily be tested. The complete answer’s a little more complex: query the wrong calculated field and the application will hang, CPU resources off the scale. So how can you predict what calculations are going to cause you problems?

When you execute any query, Siebel converts the user’s logical instructions to SQL. It doesn’t always do an optimal job, but you can usually be sure that most of the effort will be pushed to the database server. The problem with calculated fields is that certain functions don’t have standard cross-platform SQL equivalents.

The IIf function, for example, will never be translated to native SQL. When your field calculation contains an IIf statement, Siebel will write SQL to return a superset of data. The Siebel object manager is then left with the job of paging through the results, evaluating the calculation for each row. Needless to say, if the incomplete SQL returns a large dataset, this ain’t going to be fast.In any particular example it’s worth eyeballing the SQL to confirm where the calculation is happening, but you can definitely expect problems with the following functions:

  • IIf
  • IfNull
  • ToChar
  • Right

Unfortunately, there’s no configuration way to prevent searching on an unpleasant field. If you’re running into problems then you’ll have to hit the PreQuery event with some scripting…

April 3, 2007 at 8:59 am 3 comments


Feeds