Siebel Interview Question

Dynamic picklist is used to update join fields? Explain how?

Ans: By default, we cannot do any type of modification in the join fields. Also, we cannot perform any type of modification and update in these fields. To overcome this problem we have created a Dynamic picklist. The dynamic picklist is used to modify any new data records in the join fields

How to make all Child BCs read-only when Parent BC becomes read-only?

Actual scenario goes like this:
As per the business requirement, we need to have the Opportunity business component read-only when Sales Stage is Approved. For this simple requirement we configure the BC User Property: "BC Read Only Field" based on a calculated field "OpptyReadOnlyCalc" as defined below:

User Property
Name = BC Read Only Field
Value = OpptyReadOnlyCalc

Field Details
Name = OpptyReadOnlyCalc
Calculated = True
Calculated Value = IIf([Sales Stage] = "Approved", "Y", "N")

This was working pretty fine, but complexity get added to it when we are required to make all Child business components read-only as well. Though the Opportunity record was coming read-only on the UI, but it was allowing us to create the child record as per below screen-shot:

You can see in the above screen shot (marked in Red), all the vanilla buttons i.e. Add, New, Delete are enabled. Requirement was to disable these buttons and user not allowed to do any operation on the child BCs as well as soon as Opportunity become read-only.

Solution:
To achieve this requirement, you are required to create two more BC user properties on Opportunity Business component.

User Properties

Name = Aspect Child BC ReadOnly: ReadOnly
Value = OpptyReadOnlyCalc

Name = Default Aspect
Value = ReadOnly

Thats it, compile the SRF and Voilà, now observe the difference on the UI.

What is the difference between Siebel Operation object id and object id in Siebel?

About the Siebel Operation Object Id Process Property
After executing an Insert or Upsert operation, the Siebel Operation Object Id process property automatically stores the row ID of the record that was created. The Object Id for the process is automatically passed to Siebel Operation steps. Because this automatic passing occurs, it is not necessary to define a search specification unless you are updating child records. For example, if you have a workflow process based on the service request business object and you need to update the service request, it is not necessary for you to enter a search specification. However, if you need to update activities for the service request, you can enter a search specification to query the specific activity you need to update. Otherwise, the update step updates every activity associated with the service request.
The Object Id cannot be null if you are executing a Siebel operation, unless you are inserting into the primary Object Id. If the process has no Object Id, the Siebel Operation step returns an error.
Values returned by the Siebel Operation Object Id process property when performing a query operation for child records include:
about the object id process properties
1. Object Id process property will be one of the inputs for a WF if the WF is based on a BO.
2. Object Id process property need not be given as an input even if the WF is BO based. But in this case, you cannot use any Siebel Operation steps in the WF. Basically the WF will be executed without a context.
3. "Context" basically means a record belonging to the Primary BC of the BO (of the WF). WF will keep this record in memory/context throughout the WF execution so that if you are goin to update a field in this record, Siebel will not trigger a query to find the record, instead it will directly fire the UPDATE statement against the record in context.
4. Whenever you pass Object Id as input to a WF and if the WF is based on a BO, in the Start step of the WF there will be a SELECT query triggered on the Primary BC of the BO with the search criteria [Id] = 'Object Id'. This query will be triggered to prepare the record that will be the context for the WF execution.
5. Object Id process property is not required when the WF is NOT BO based.
6. When you perform a Siebel Operation "Query" step in the WF on the Primary BC which will fetch a different record other than the record which is present in the context, then the ROW_ID of this new record will be set as new value for [&Object Id] and the new record will be "Context" for the subsequent steps in the WF.

How to call "Asynchronous Server Requests" business Service?

Sometimes there is a requirement we need to run few processes that should not stop the user on the screen to go further and do next steps when Siebel is processing something in the background. That is the place when Asychronous processes come into the picture and the solution that Siebel provides for these kind of scenarios is to give a call to "Asynchronous Server Requests" business service.

There are only two ways (that I know my past experience, please add if anyone know more) by which you can call "Asychronous Server Requests" Business Service :

a) Via e-Script : easy way to do that and most people know this.
b) Via Workflow : this is bit tricky

Lets see each one of them in detail. Taken an assumption that you need to invoke a workflow (asynchronously). Assume the workflow name is "Send Email Opportunity Sales Rep", which just sends an email to the Sales Person on the Opportunity and the Input Agrument to the workflow is : "OpptyId" (1-XR45)

Via e-Script :
Here is the piece of code that you can to achieve the above requirement :

var svc = TheApplication().GetService("Asynchronous Server Requests")
var input = TheApplication().NewPropertySet();
var child = TheApplication().NewPropertySet();
var output = TheApplication().NewPropertySet();
input.SetProperty("Component", "WfProcMgr");
child.SetProperty("ProcessName", "Send Email Opportunity Sales Rep");
child.SetProperty("OpptyId", "1-XR45");
input.AddChild(child);
svc.InvokeMethod("SubmitRequest", input, output);

very simple, isn't it. We just need to make sure that the Input Argument of the calling Workflow (Send Email Opportunity Sales Rep) should be the properties of the Child Property Set.

Via Workflow :
Here is the example below in which I have used this and you can accomodate the below two steps in any of the workflow you are using :

Process Properties :

Name : Inputs

Type : Hierarchy

Step1: Set Input Arguments

Business Service : Workflow Utilities

Business Service Method : echo

Step2: Call Asynchronous Service
Business Service : Asynchronous Server Requests
Business Service Method : SubmitRequest

Thats it, you are done. Just to add it here, I tried doing the same stuff with the help of runtime events but it is limitation there and we cannot do that.

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.

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.

***************************4

Child Field Read Only depending on Parent Field Value

Sometimes it happens that you get a very simple requirement to implement and in a single glance you say, "Well, this is very easy to implement" and when you actually see the result on the UI after the configuration you have done, you start scratching your head to find out the reason for not getting the result as per the expectation.

Today, I am going to discuss a very simple requirement you might have faced earlier.

Requirement
I have two applet exposed on the UI: 1) Opportunity Form Applet 2) Quote List applet.
Opportunity being the parent applet and quote as the child as per below screen shot.

The simple requirement is to make "Comments" field on Quote List Applet editable, if and only if Sales Stage of Opportunity = Data Entry.

very simple isn't it! Anyone can easily say, go and use "Field Read Only Field" user property at Quote business component and you are done. I reacted to it in the similar manner and followed the below steps:
1. Pull "Sales Stage" value on Quote BC.
2. Create a calc field to set to Y, if Sales Stage = "Data Entry"

3. Create a BC User property, Field Read Only Field based on calc field.

Compile the SRF.

Navigate to Opportuity -> Quote view to verify the results. I created an Opportunity record, set the Sales Stage to "Data Entry" and then created a Quote record. "Comments" field was editable. Then I changed the Sales Stage to "Submitted" and per configuration I was expecting the "Comments" field to be read only, but to my surprise, it was not. Still, I was able to edit the field.

It might happen that change of "Sales Stage" at the Opportunity level is not getting reflected at the quote level. Let me try running a blank query (Alt+Q, then enter) to refresh and now..... yes, "Comments" field get read-only. So, basically the problem is, Quote BC is not aware of the change in Sales Stage at Opportunity level, unless you refresh it.

(Note: this is not the case with "Parent Read Only Field" user property. Change at parent field immediately gets reflected at the child level. You can refer this post for more details.)

Now, the problem here is to get the Quote list applet refreshed, if some change happens at Opportunity. One might point out that you should have "Immediate Post Changes" as True for "Sales Stage". But, keep in mind that "Immediate Post Changes" will only refresh the fields of the same business component, not of the child BC.

One solution, I can think of is to refresh the Opportunity business component in such a way that it should not loose the record context and consequently, Quote BC will automatically gets refreshed. But, I didn't want to do the scripting on Opportunity WriteRecord event, just to refresh the Quote BC, something like:

function BusComp_WriteRecord ()
{

TheApplication().GetService("FINS Teller UI Navigation").InvokeMethod("RefreshCurrentApplet", TheApplication().NewPropertySet(), TheApplication().NewPropertySet());

}

So, I found a better way to achieve to refresh the Opportunity form applet. Just create the following user property on the Opportunity applet:

Compile the SRF and check the result on the UI. Voila, everything is working as desired now.

Question: Is it mandatory to specify Business Object on a Workflow?

Answer: No, Business Object needs to specified only when there is need to use Siebel Operation in Workflow.

Question: What is the difference between Expression business component and Filter business component in Siebel Operation?

Answer: These business components fields are used in Siebel Operation when search spec is built by referencing another business component field.

For Example: To find Account records where Account Id is specified in Contact's Account Id field, expression will be created like :

"[Id] = [Account Id]"

And Filter Business Component will be set as : Account and Expression Business will be set as Contact. Thus it will be evaluated as :

"[Account.Id] = [Contact.Account Id]"

The filter buscomp should be the buscomp you are searching. For example, if the Siebel Operation is defined on the Account BC, the filter buscomp should be the Account BC. The expression buscomp gives you the search expression for searching the filter buscomp.

Square Brackets in the search expression are evaluated according to which side of the comparison operator they are on. Anything to the left of the equals sign is assumed to be the filter BC, and anything to the right is the expression BC.

Here's an example from Bookshelf: if Account is the filter BC and Contact is the expression BC, then the expression "[Id] = [Account Id]" would be evaluated as "[Account.Id] = [Contact.Account Id]"

Question : How to compare two properties in Siebel Workflow?

Answer: Expression on Siebel Conditional branch can be used to compare two properties. To see how to create expression in siebel workflow please see.

siebel

Mark Enjam