siebel

I crunched one. This post is an addendum to one of my previous "Food for Thought" post where the main challenge was to display different columns in Query Mode when applet is displayed in Edit List Mode. with some configuration-Scripting-Luck i am able to achieve this scenario. The key ingredient here is the usage of Dynamic Toggle. Following necessary steps are required to achieve desired solution. 1 - Create a clone of the list applet which should be displayed in Query Mode. Remove unnecessary Columns which are not required to be displayed while querying. Consider two applets are: a) SR List Applet b) SR Query List Applet 2 - Make the "SR Query List Applet" as the default applet to be displayed in the view. 3 - Create a calculated field in the Service Request BC with following values: Name: QueryCalc Value: IIF(GetProfileAttr('QueryMe') = 'Y','Y','N') 4 - Now create a dynamic toggle in the "SR Query List Applet". Set the ...

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

Issues are inevitable as sugar and cholesterol. In my recent heist in configuring recipient groups i was dumbstruck with some untold user property. We wanted to add Person as recipient group for Service Request. As per siebel support we added desired values in the "COMM_RECIP_SRC" LOV table. Email started to flowing using this recepient group. But the interesting part is "Person" BC is not defined with the Recipient* user properties instead of that only one user property is defined as Name - SecUsernameFieldSubstitution: EMail Addr Value - Email Address Unknown of its usage thought of throwing this to siebel forum. A little insight on this user property will be of great help. Happy Cracking!!

It is very critical that one should have appropriate access to information available. Thus siebel has given comprehensive access control mechanism which helps in restricting data visibility. We can have visibility filter at multiple levels including View, Business Component, Picklists, Drilldowns, Links . However the modes which we can set is restricted to following values: All Personal Sales Rep Manager Organization Sub Organization Group Catalog Recently i was asked to have a visibility control based on the Division during the assignment of Service Request. One should see employees related to his division only when he opens employee pick applet. We opted for Personalization to implement this as it gives a flexibility to change the filter dynamically without any srf change. Steps required are: 1 - Set the Popup Visibility Type to "All" for employee buscomp. (Please check before doing this as this will impact all Picklists based on Employee BC) 2 - Create a Personalization ...

I am pretty sure you will find this post very interesting, if you ever get a requirement to send a email in HTML format and email should have the details of the child records(dynamic data) as well.XSLT (XSL Transformation) can do wonders for this kind of requirement where the basic idea is to get data in XML hierarchy from Siebel (which you can easily do via EAI Siebel Adapter and convert it into

Today I am going to discuss one interesting requirement where you are required to make all the Child Business components read only as soon as the Parent business component 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

A few days back a client asked me if we could have Google maps integrated with their Siebel application, that would enable their reps to locate their contacts/accounts on Google maps, and find the best way to reach them based on their mode of commute. Initially, they had planned to do this for single addresses. However, I tried to convince them to go for multiple address selection. The key business driver here in my opinion would be that, the user can optimize his/her travel route based on the proximity of his/her reps, thus saving time and money. Google maps also offers a few more features like checking for traffic, avoiding tolls, taking highways etc. Google maps is really cool, and integrating it with Siebel makes it cooler ;) Really!! show me how? Step 1: The first step would be to get the Google map applet setup on your Siebel application. There are many ways to do this. For this example lets go with Mash-up your CRM with Google maps in < 30 minutes . Step 2: On...

Sometimes we write script and never realize it might result in error due to record set on which it is getting operated and it becomes issue in live environment. Similar kind of scenario I observed while using "GetAssocBusComp()". Siebel geeks who have used this method before must be aware that this is being used to get the Association business component and it's "Associate" method is being used

Siebel is mysterious. Along with those magical user properties there exists hidden methods that can do wonders for you. It is a real Archimedes-Eureka-Feeling when we encounter any of these hidden methods in siebel. Recently i was struggling with Update Siebel Operation Step in Workflow with some context issue till i found "UpdateRecord" hidden method for "Inbound E-mail Database Operations" business service. This method is not displayed in the available list of methods for this business service but however can be comprehensively used in the workflow (we can verify with Business service simulator). Usage: Business Service: Inbound E-mail Database Operations Business Service Method: UpdateRecord Method Argument: BusComp - Name of the Business Component BusObj - Name of the Business Object Id - Row ID of the record to be updated Field: FieldName1 - Value to be updated Field: FieldName2 - Value to be updated Field: FieldName3 - Value to be updated The only curse...

Ignorance is bliss.A lot has been written about the cursor modes when using ExecuteQuery method. As a general rule by birth we are told, when using the ExecuteQuery method in scripting, the recommended cursor mode is ForwardOnly if there is no need to step backward through the result set. But ForwardOnly cursor mode should not be used in a user interface context, for example, when the business component being queried is displayed within an applet of the current view. I was victim of this ignorance. We had a requirement of querying on the EBC based on the query spec we get from other applet in the view. I have added ForwardOnly mode in the executequery method and to my horror query results were always returning only one record in the applet. Turning on the ForwardBackword cursor mode in the ExecuteQuery method fixed this isssue. The issue was When accessing database records with a cursor mode of ForwardOnly, only one record at a time is retrieved and kept within the Siebel Object Manage...

In continuation of the previous post, I found another good way to achieve the requirement of sending email in HTML format and moreover you are required to replace the field values dynamically from business component. So the extra information you need to provide to Outbound Communication Manager is the ROW_ID of the record in context.Suppose, here below is the Email Template need to send in HTML