If you are one of the unfortunate souls stuck deploying Siebel local clients - you know how annoying is to setup package and deploy it to the users from time to time.
Siebel developers who have configured at least one ‘decent’ associate applet would have seen this dreaded error.
No association list is available in this applet. (SBL-DAT-00276). This is dreaded not because it is difficult to solve, but since it has the ability to provide sleepless night while developers debug on what went wrong.
There are many ways to skin a cat (yes, it is a cliche), and there are indeed many ways to make a field read-only in Siebel .
But you will have this burning question in mind - how about making child fields read-only depending on the parent business component fields?
In Siebel, it is common knowledge that -
Static picklists are shown as values in a drop-down list on the field
These are based on List of Values or Picklist Generic Business Component, and the values are defined in ‘List of Values’.
ShowPopup method is yet another old timer method that I have deployed more than a couple of times.
ShowPopup is self explanatory - the method is used on a button and it will enable you to popup a defined applet on top of the base applet.
Popup applets are not commonly seen in implementations. The objective is simple - how will you popup an applet from an underlying applet.
Though pick applets and MVG applets also are popups, we are not talking about those here.
Of all the Siebel announcements in the past few years in Oracle Open World, I cannot make sense of the integration-related stuff.
I am talking about slides like this.
Imagine this -
A recent announcement of usage tracking feature introduced in Siebel 15.5 (thanks to Alex’s post) brought back more than a few memories.
Application development is a funny business. As COTS product implementers, we try to understand the process, map them to what is available in the OOB solution, and negotiate a way forward for optimal usage of the product.
Siebel has straight forward rules to get an applet into focus when a view is painted.
If the target view is a detail view, the default focus will be the second applet If the target view is a list view or if the view has only one applet, the focus is retained on the first applet This makes sense because you are drilling down from the source view to work on the details - which presumably (considering Siebel standards) is from second applet onwards.
Siebel Symbolic URL is one of the best ways to integrate external applications if you need to integrate at the UI level. If you are finding it difficult to digest the fact that Siebel supports multiple integration mechanisms, you can check out more on which integration method to use in Siebel ?