A Story of a Dynamic Drilldown Issue

Don't worry I am not going to narrate any story out here like there was a king who's name was "drilldown" and there was a queen :) . There is really a nice and hidden fact that people rarely know when they are configuring Dynamic Drilldown in an applet. I came across this fact when we got stuck in one of the Production issue which was being faced by only one user and for rest of the users that dynamic drilldown was working fine.

So, the story goes this way : In our Siebel application, we had configure a dynamic drilldown on field "Opportunity Name" which exist on list applet "Quote List Applet" in My Quotes View. The drilldown was dynamic in nature as depending upon the "Business Type" of Opportunity, system can drilldowns to various views. For Eg:

Business Type ================= View to drilldown ===========

Manufacturing =================== Opportunity View - Manufacturing

Retailing ======================= Opportunity View - Retailing

Production ===================== Opportunity View - Production

Service ======================== Opportunity View - Services

and in-case no business type has been defined for an Opportunity, then system should drilldowns to "All Opportunities View" view. That means "All Opportunities View" was the default view for this dynamic drilldown.

Now, the issue faced by the user in Production env was, whenever he tries to drilldown on "Opportunity Name" field in "Quote List Applet", he was getting the error "You don't have priviledge to see this record" and seeing this error he got shocked as the record he wanted to see was created by him only. He can very well see that Opportunity record in "My Opportunities" view with no issues. But the only thing that was not working is the drilldown.

Now, after getting this issue, the first thing that will come into the mind is : "just go and check if "Opportunity View - Retailing" view" is available under user's responsibility or not and when we checked, we found it was there. We took a deeper dive and checked the drilldown for the same user for Business Type = "Manufacturing" (already confirmed "Opportunty View - Manufacturing" view was there under the responsibility), but again the same error "You don't have priviledge to see this record"........ So, no matter what the "Business Type" is, he was not able to drilldown on any of the Opportunities.

After lot much of head-scratching, we observed that there was a difference between the number of views available under the responsibility for the user who was able to do the drilldown and which one not. The difference was : "the default view of the dynamic drilldown was not available under the responsibility of the user". Somehow it got deleted or something, not sure how it was happened, but there on we come to know this basic learning while implementing dynamic drilldown, i.e.

"Don't forget to include the default view of the dynamic drilldown under the user's responsibility, otherwise it will not work".

.

.

cheers :)

try it out

PickLists in Siebel

Generally two ways are there in Siebel, by which we can categorize the Picklists in Siebel.

a) Static V/s Dynamic Picklist.

b) Bounded V/s Unbounded Picklist

So, let start with the first categorization.

Static Picklist is the one which is based on "PickList Generic" or "PickList Hierarchical" Business Component and fetches the values from "Administration-Data -> List of Values". "Type Field" & "Type Value" are the two fields where you specify the field name where the LOV Type has been stored (i.e. Type) and the LOV Type value respectively. So the values which appears in this PickList remains same in number (unless & untill you go to "List of Values" view and add some values, and do clear cache).

On the other side, as the name depicts, Dynamic PickList are one whose values can increase and decrease at the run time, due to the fact that these Picklists are based on any business component which is being used for transactional data in the application (like Accounts, Contacts, Orders) etc. So, what happens is, as soon as transactional data is being added by the user, it starts appearing inside the picklist.

The one very well known fact is that generally Static picklist shows as a drop-down on the applet, while values from the dynamic picklist display with the help of Pickapplet.

Second categorization :

When bounded picklist is being used for a field, then user can only selects the value from the values provided by the picklist. Even if user tries to type in the wrong value and tries to step off from the field, system will automatically opens up the pickapplet/drop-down and force the user to selects the value from picklist only.

On the other side, Unbounded Picklist are the one from where user can selects the value from the picklist and also system allows the user to type in some new values in the field as well, which is not existing in the picklist.

Note : When we use the "SetFieldValue()" method on any picklist field of any business component, it does not fire the pickmap, if the picklist is unbounded. To overcome this, we need to used the ".pick()" method.

Record Count : Interview Question

I thought its worth sharing this interview question which one of my friend faced during his siebel technical interview. Here you go :

"I have an "Opportunity" business component with a searchspec {[Opty Status] = "Won"}, whose underlying table is S_OPTY. This table has 100 records, out of which 50 records has Opty Status = "Won" and 50 records having Opty Status = "Lost". Now I have configure an applet on "Opportunity" business component and applet has the searchspec {[Opty Status] = "Lost"}. "

With the above configuration described, I compiled the srf. How many records I will see on the applet?

People have different views on this question. Some will say "50 records with status = Won" because Business Component's search spec will override the applet's searchspec. While some will say applet's search spec will take the precedence, so will see 50 records with Lost Status.

Here is the correct answer : "You will see Zero records".

Explanation:-

let me take you back to the Siebel architecture where we have learned during the Siebel training class, which says Siebel has 3-tier architecture with 3 layers i.e.

a) User Interface Layer (UI Layer)

b) Business Object Layer (BO Layer)

c) Database Layer (DB Layer)

So, when data is being fetched on the UI, database layer will provide 100 records. By the time it reaches BO Layer, due to the searchspec on Opportunity business component, only 50 records with "Won" status will pass the condition. Now when these 50 records will pass onto the UI layer, no record will satisfy the searchspec available on applet (Opty Status = Lost), so no record will be available on the UI.

In technical terms this fact can be easily proved if you go and check the "SQL spool" generated by the siebel via dedicated client. You will see the both condition will be available in "Where" clause of the query and joined with the "AND" clause. So, none of the Opportunity can its Opty "Status = Won", and "Status = Lost", at the same time, consequently no record will appear on the UI.

Join v/s Link : Interview Question

I was just sitting with my colleagues and suddenly one of junior member of our team asked what is the difference between a Join and Link? He was new to Siebel and started learning it, so I thought to make him understand my way. Here is what my view point says :

Anybody came from database background knows, "Cardinality" between two tables can be of four types :
a) One to One
b) One to Many
c) Many to One
d) Many to Many

So, a very simple way to define a Join in Siebel is, "When you have "One" on the right side of the cardinality, there you need to implement Join". Similarly, "When you have "Many" on the right side of the cardinality, there you need to implement Link". That means, "One to One" and "Many to One" corresponds to the Join, while "One to Many" and "Many to Many" corresponds to the Link.

Secondly, a Join exist between a Business Component & a table while Link always exists between two different business Components.

Thirdly, via Join system fetches a single record while Link fetches multiple records.

Fourthly, while implementing Join, we can use the "Join Constraint" to specify the condition on the child entity. In link, we can specify the condition on child entity by putting "Search Specifications".

Note : For "Many to Many" link, we need to make use of Inter table which stores the unique Id of Parent and Child Business Component.