BC Read Only Field v/s Parent Read Only Field : A Case Study

We got one requirement to make the Child and Parent Child Applet readonly in a view, if the GrandParent (the applet which is driving the visibility of the view) has got the Status = "Inactive". Sounds interesting, right?

Okayy, let me rephrase it and try to explain you with more details what exactly we want to see.

We have a View in which the following applets are exposed :
a) Accounts Form Applet - Parent
b) Service Request Form Applet - Child
c) Activities List Applet - Grandchild

Accounts applet has a field "Status" exposed on the UI and the requirement is that once Account Status = "Inactive", user cannot do any modification/insertion/deletion on Service Request and Activities applet. Both Child (Service Request) and Grandchild (Activities) applet should become readonly.

I can think of two different User Properties that we can use to achieve this. Lets see the both solution :

First Solution

So, the very first BC user property comes into mind is "BC Read Only Field", which just require a BC Field as a value and depending upon the field's value (Y/N), the BC become readonly. To achieve the solution with this user property, follow the below steps :

a) Create Calc field in Service Request BC:
Field Name : SRReadOnly
Calculated : TRUE
Calc Value : iif(ParentBCName() = "Account" AND ParentFieldValue("Status") = "Inactive", "Y", "N")

b) Create BC User Property in Service Request:
Name : BC Read Only Field
Value : SRReadOnly

c) Create Calc field in Action BC :
Field Name : ActivityReadOnly
Calculated : TRUE
Calc Value : iif(ParentBCName() = "Service Request", ParentFieldValue("SRReadOnly"), "N")

d) Create BC User Property in Action :
Name : BC Read Only Field
Value : ActivityReadOnly

e) Set Link Specification = True for "Status" field at Account BC.

Second Solution

The next BC User property that we can use here is "Parent Read Only Field", which can be used as follows :

Name : Parent Read Only Field: <_parentbuscompname>
Value : <_parentfieldname>

a) Create a calc field on Account BC :
Name : AccntInactive
Calc : TRUE
Calc Value : iif([Status] = "Inactive", "Y", "N")

b) Create a BC User Property in Service Request :
Name : Parent Read Only Field: Account
Value : AccntInactive

c) Create a calc field on Service Request BC :
Name : AccntInactive
Calc : TRUE
Calc Value : iif(ParentBCName() = "Account", ParentFieldValue("AccntInactive"), "N")

d) Create BC User Property in Action :
Name : Parent Read Only Field: Service Request
Value : AccntInactive

Compile the SRf after using each solution and observe the changes by setting Account Status Active/Inactive.

If you would compare the two solution, both looks same from configuration perspective as both require two calc fields and two user properties in all. But from scalability standpoint, second solution is better as you can easily use as many instances of "Parent Read Only Field" you want, in case Activities/Service Request need to show read only, when exposed under some other Parent BC like Opportunity, Quote etc. While in case of "BC Read Only field" you need to accomodate the business logic inside the calc field itself, as we can have only one instance of this user property at one time.


Third Solution

I can think of one more solution for this problem by, and I think the most efficient, by using both user property. Here it goes :

a) Create a calc field on Service Request BC :
Name : AccntInactive
Calc : TRUE
Calc Value : iif(ParentBCName() = "Account" AND ParentFieldValue("Status") = "Inactive", "Y", "N")

b) Create a BC User Property in Service Request :
Name : BC Read Only Field
Value : AccntInactive

d) Create BC User Property in Action :
Name : Parent Read Only Field: Service Request
Value : AccntInactive

Third solution, we can actually save one more calc field and solution is achieved by creating 1 Calc field and 2 user properties.

Your comments are most welcome, incase you have any other good ideas around this scenario.

Keep commenting !!!!!

.

What is difference between Siebel Table Apply & Activate?

Recently, one of my friend asked me a very interesting question, which he has faced in one of the technical interview. Actually that question has two parts :

a) What is the difference between Apply & Activate?

b) What exactly happens in the background when you click on Activate button?

So, here the answer goes :

a) Once you have made changes in the database logical schema i.e. added column/index under Siebel Tools -> Table Object, you need to apply those changes in the physical schema as well. So when we click on "Apply" button, system actually connects to the database and synchronize the logical schema with the physical database for that particular table.

b) Once you click on "Activate" button, system actually goes and update the Application Version table of Siebel i.e. S_APP_VER, and let the Siebel Server know that some modification has been done in DB Schema that needs to be taken care for any future EIM activity or any future DBXtract task. So what happens is whenever such task run on the Siebel Server, since DB schema version has been changed by "Activate" button, system updates the diccache.dat file. In my opinion, this doesn't make any sense if we do "Activate" against local database (Please correct me if I am wrong)

To verify this, follow the steps :

1. Run the below SQL in DBISQLC.exe against Local Database.

select last_upd, CUSTOM_SCHEMA_VER, from siebel.S_APP_VER

2. Go to Siebel Tools and click on "Activate" button for any table.

3. Run the above mentioned SQL query again and see the difference in the values.

Hope this helps.

.

Extending Tables / Columns in Siebel Local Database

I have started working on new Env these days and due to slow connectivity to the remote database server, I generally connect to my Local Database to see the changes in SRF via dedicated client.

Now while working on one of the requirement I was required to extend one column in Table in local database. So since it was my local database, extratced with my User Credentials, I went into the Siebel Tools -> Tables and here is what I tried :

1. Query for Table.
2. Create the New Column with all the datatype and length details.
3. Clicked on Apply and as used ODBC source : "SSD Local Db default instance". This is the ODBC data source that I have mentioned in Tools CFG to connect to my local Database.
4. Since its my local database, put in Database User : "", Database User Password : "".
5. Clicked on "Apply".

Got surprised to see that, it gave "Permission Denied" error. I was like, "its my database, my tools, in my machine and the same ODBC data source, still its not working......." hmmmmmm

Started looking into the options and workaround, then realized you can only change the Database Schema if you are logging with the Table Owner credentials. And the Table owner of any local database extracted is "Siebel". Soooooo, just tried again applying the table with the same above process, the only parameter I changed was : "Database User = SIEBEL". and yes it WORKED !!!!!

P.S. : The similar process is applicable for Sample Database as well. Database User : "SIEBEL", Database User Password = "SADMIN".

.