Posts filed under 'Configuration'
In a many-to-many relationship, it’s possible in the child business component to retrieve and set data on the current intersection record through an implicit join to the intersection table. In Siebel 7 you can see an example of this in action in the Opportunity: Contacts view: the Contact has a ‘Role’ on the Opportunity and this is displayed in the list of Contacts. Examining the config in Tools, this role actually sits on the intersection record between the Opportunity and Contact, yet there’s no S_OPTY_CON join defined for Contact. Unlike most joined fields, the UI also allows the Role field to be edited, automatically saving data back to the intersection. The joys of implicit joins.
This behaviour is supported everywhere there’s a many-to-many parent-child relationship. When defining a new field, the Join property is bound to the list of joins defined for the business component. So the trick is to create a basic join to the intersection table - no need to specify a join spec or any details - then you can define your new fields and, when you’re done, delete the join. Siebel will recognise it as an implicit join and pick up data from the intersection record used to retrieve the child.
June 14th, 2007
There are a couple of options to display a hyperlink to an external site from Siebel 7. The simplest is to set the following properties on an applet control:
- HTML Type: URL
- HTML Display Mode: EncodeData
This will URL-encode the field and wrap it in an HTML link tag <a></a>. As long as your field contains a valid URL, you’ll have a working hyperlink. In the high-interactivity client the URL will by default open in a new browser window; to support the same behaviour in the standard interactivity client, set:
- HTML Attributes: target=’_blank’
This approach doesn’t allow you to change the link title, however, so if it’s a big ugly URL you’ll have a big ugly field displayed in your applet. As an alternative, you can hand-code the hyperlink. Set the calculated value on your field as follows:
“<a href=’http://yourURL.com/yourtargetpage.html‘ target=_blank>Your Link Text</a>”
(Note the enclosing double-quotes.) Then set up your applet control:
- HTML Type: Field
- HTML Display Mode: DontEncodeData
- Runtime: Y
This tells the Siebel UI to interpret the contents of the field as raw HTML - so you see your hyperlink exactly as constructed.
June 5th, 2007
Nathan’s enthusiatically followed up on his first contribution to eulogise about a couple of new Runtime Events…
This one is relatively simple but it is worth pointing out. Sometimes its the little things that make you weep for joy as a developer.
In the bad old days of Siebel (i.e. before 7.7), the world was running around clubbing each other over the head, saying “ugh” a lot and wearing animal skins. Then the light shone upon the world and we were given:
WriteRecordNew and WriteRecordUpdated.
These are Runtime Events that I noticed just recently. Many many times in config, you need to do something when a record is written. You place code on the WriteRecord event (so that you can avoid having to worry about the user doing Undo, stepping off a field and recorrecting etc). But then you need to do different things depending on whether the record is new or updated.
Usually what you needed to do was set some global variable when the NewRecord event fired, test that variable in WriteRecord, then clear the variable. It usually worked, but it was not elegant. I have seen implementations where the code on the WriteRecord event runs into the thousands. But we won’t mention those.
Now, the great and glorious Siebel gods have seen fit to now provide us with Runtime Events that distinguish between New and Updated records! Hallelujah brother!
May 1st, 2007
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 5th, 2007
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:
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 3rd, 2007
Next Posts
Previous Posts