Siebel Database |
Showing posts with label Configuration. Show all posts
Showing posts with label Configuration. Show all posts
February 14, 2020
How caching work in Siebel?
In any online transaction processing system like CRM most of the processing time is taken in finding the right record in database. No matter what database optimization technique you implement, your db processing time would be the highest among the time spent in web server and application server.
March 10, 2016
Scenario based Interview Questions - Part 1
Long ago an avid reader of the blog requested me to post some scenario based interview questions, and sent some good samples as well. I asked the same on siebel-developers slack community and got some really good answers. This is a three post series so stay tuned for next two posts.
If you like the questions and would like to see more like this, then please +1 this post on google, and don't forget to share your answer in comments below.
October 24, 2015
Links Demystified
I feel no shame in admitting that it took me years to fully understand the extensibility of Siebel links. I hope after reading this post you will start appreciating the Siebel even more as I did.
Let's look at the simpler links first.
1:M links
These links creates simple parent child relationship. One parent can have many children. And children records have parent id (foreign key field).
Order Entry - Orders and Order Entry - Line Items is perfect example. Source Field is "Id" of "Order Entry - Orders" BC and destination field is "Order Id" of Order Entry - Line Items. Whenever system creates a line item under an order record, Siebel populates order id on order item record with ROW_ID of Order to create relationship.
M:M links
These are also comparatively simple links. Two entities (table) are related to each other using an intersection table. Intersection table helps to associate one child to other parents as well.
For example Account and Contact link. This link allows to associate one contact to multiple accounts. In addition to the inter table Siebel stores id of primary record ( primary id field) to improve performance.
Now let's look at the interesting bits.
M:M links with source id field specified.
In standard M:M links these fields are blank and inter table stores the ID of both parent and child records. When parent id field is also specified with inter table Siebel uses field value instead of ROW_ID of parent to create intersection record.These types of links are not very common but are possible.
For Example:
Lets consider Action/FINCORP Account link, this link has Source Field specified as Primary Contact Id which means when child records are created using this link Siebel will populate Contact Id into Inter Parent Column instead of Action Id.
M:M link with both inter table and source and destination field specified.
Things now gets more interesting when both source and destination fields are specified and inter table is also specified.This way Siebel uses fields specified on the links instead of Id to create association.
The link shown above specifies Campain Id and Destiation Field as Contact Id, thus while creating record in inter table Siebel will use Campaign Id fields instead of Id and Same applies for destination field. Interesting isn’t it???
Finally links which are overridden by MVL's
If you are following it correctly then you might think all these complicated links should be able to satisfy all possible scenarios. Just then Siebel steps up the game with multi value links. On these MVL's definition Siebel allows to override the parent id being used on the link.
So with help of primary id field override, potentially in action to contact mvl instead listing all the contacts of selected activity, Siebel can show all the contacts of parent account selected on activity. :) This over riding is allowed both on 1:M link and M:M link.
Cheat sheet for your desk:
If you have understood all of the above then I would recommend you to explore how links are used for access control and visibility of detail bus comps.
Hope it helps.
Let's look at the simpler links first.
1:M links
These links creates simple parent child relationship. One parent can have many children. And children records have parent id (foreign key field).
Order Entry - Orders : Order Entry - Line Items link |
Order Entry - Orders and Order Entry - Line Items is perfect example. Source Field is "Id" of "Order Entry - Orders" BC and destination field is "Order Id" of Order Entry - Line Items. Whenever system creates a line item under an order record, Siebel populates order id on order item record with ROW_ID of Order to create relationship.
M:M links
These are also comparatively simple links. Two entities (table) are related to each other using an intersection table. Intersection table helps to associate one child to other parents as well.
Account Contact link using S_PARTY_PER |
For example Account and Contact link. This link allows to associate one contact to multiple accounts. In addition to the inter table Siebel stores id of primary record ( primary id field) to improve performance.
Now let's look at the interesting bits.
M:M links with source id field specified.
In standard M:M links these fields are blank and inter table stores the ID of both parent and child records. When parent id field is also specified with inter table Siebel uses field value instead of ROW_ID of parent to create intersection record.These types of links are not very common but are possible.
For Example:
M:M link with Source Field specified |
Lets consider Action/FINCORP Account link, this link has Source Field specified as Primary Contact Id which means when child records are created using this link Siebel will populate Contact Id into Inter Parent Column instead of Action Id.
M:M link with both inter table and source and destination field specified.
Things now gets more interesting when both source and destination fields are specified and inter table is also specified.This way Siebel uses fields specified on the links instead of Id to create association.
Link with both Source Field and Destination Field along with inter table. |
Finally links which are overridden by MVL's
If you are following it correctly then you might think all these complicated links should be able to satisfy all possible scenarios. Just then Siebel steps up the game with multi value links. On these MVL's definition Siebel allows to override the parent id being used on the link.
So with help of primary id field override, potentially in action to contact mvl instead listing all the contacts of selected activity, Siebel can show all the contacts of parent account selected on activity. :) This over riding is allowed both on 1:M link and M:M link.
Cheat sheet for your desk:
If you have understood all of the above then I would recommend you to explore how links are used for access control and visibility of detail bus comps.
Hope it helps.
October 09, 2015
Using MVG aggregate functions
Originally posted on blog.notesonsiebel.com on April 5th, 2007 by stuandgravy
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.
October 06, 2013
August 30, 2013
How to create Pick list field in Siebel?
This is one of the most common problem that is faced by new siebel developers. Answer of this question can tell a lot about actual hands on experience of the developer and how much experience he holds in debugging.
There are only few reasons why picklist doesn't work, which can be summarized as below:
There are only few reasons why picklist doesn't work, which can be summarized as below:
- Pick map of the new field is not populating the foreign key field of the field.
- Join created to pull the value of the field is not created properly.
- If no values are shown in drop down then pick list is might not compiled yet, or the LOV type and values are not created in administration views.
- If value is not displayed after selecting value from pick applet then wrong field is selected in pick map of the field.
- Update only if null is not configured properly.
Related Questions:
Question :What are the reasons for field based on picklist not showing drop down or pick applet icon?
Answer: Pick applet might not be selected on the list item or control of the applet or runtime property of the control is set to false.
Please feel free to leave a comment if you have faced any other issue with the pick lists.
Popular Interview Questions:
June 24, 2013
How to make field conditionally editable in Siebel?
Requirement: To make Siebel Fields editable only from certain views or certain users?
This sort of customization could come up when business would like to update fields from certain views only and make then read only from elsewhere.Solution: This requirement can be achieved in many ways, listing script-less solutions here:
1. Clone the Applet and views and make the control read only by setting the read only flag on Applet
Benefits: As the solution makes copy of UI layer, it does not impact the business layer. If there is any script which is updating the field as part of another process it wont require any changes as field on the BC remains unchanged.
Drawbacks: Duplicate objects make application complex and difficult to manage.
2. Create Field Read Only Field user property to make the read only if the active view name is not same as the intended view.
This can be done by using : GetProfileAttr('ActiveViewName').
Benefits: No new object created thus keep the keep maintenance simple and keep the business logic at one location.
3. Use GetProfileAttrAsList in calculated field to check the responsibility of user.
If user has the responsibility then field will be editable and for all other users field will be read only. This responsibility can be added to SADMIN as well so that background workflows can only update this field.
syntax of calculated field:
IIf(InList(“EditableField”,GetProfileAttrAsList(“User Responsibilities”)))If you have come across any other scenario in which you were forced to write script then please share it with us in comments below.
Restrict certain queries on BC/EBC/VBC : GetSearchExpr()
Recently someone posted requirement on it toolbox to capture and change the queries executed by user on certain Siebel business components.
Few consultant suggested use pre query event of business component to change the search spec using GetSearchExpr and SetSearchExpr, however it is not possible to achieve this without releasing srf.
Perhaps there was a solution which could be achieved without releasing srf.In such type of requirements we can use Siebel Run Time events and client side business services which are independent of srf release.
Few consultant suggested use pre query event of business component to change the search spec using GetSearchExpr and SetSearchExpr, however it is not possible to achieve this without releasing srf.
Perhaps there was a solution which could be achieved without releasing srf.In such type of requirements we can use Siebel Run Time events and client side business services which are independent of srf release.
Subscribe to:
Posts
(
Atom
)