Q & A

Hi,

If You have any Questions / Doubts / Some important info on siebel to share.Please share us with me.I can get back to u ASAP.

Scenario's on scripting

Scenario II

User needs to save a newly created opportunity along with proper validations in the various fields.

Following are the Events applicable to these scenarios

Event 2.1

BC: Opportunity

Event : BusComp_NewRecord

The NewRecord event is called after a new row has been created in the business component and that row has been made active.

Functional Use: This event is used set up default values for Field ‘Sales Method’ in the Opportunity BC.

Code:

 function BusComp_NewRecord ()

{

            this.ActivateField('Sales Method');     

            this.SetFieldValue('Sales Method', 'XYZ Sales Methodology');

}

Event 2.2

 BC: Opportunity

Event : BusComp_PreWriteRecord

The PreWriteRecord event is called before a row is written out to the database. The event may perform any final validation necessary before the actual save occurs.

 Functional Use: This event is used check the Sales stage in the Opportunity BC. Depending on the Sales stage of the Opportunity, the Account Status is changed. Eg. If the Opportunity Sales Stage is ‘Closed/Won’ the Account status changes to ‘Initiate Request’.

 Code :

function BusComp_PreWriteRecord ()

{

    var SalesStage,AccountStatus,bcAccount,boAccount,AccountId,Name,Stat;

             this.ActivateField("Sales Stage");

            SalesStage=this.GetFieldValue("Sales Stage");

            if (SalesStage == "" || SalesStage == null )

            {

                        this.SetFieldValue("Sales Stage", "01 - Prospecting")

            }

     else if (SalesStage == "10 - Closed / Won")

            {

                        ActivateField("Account Id");

                        AccountId = GetFieldValue("Account Id");

                         with(bcAccount)

                        {

                                    SetViewMode(AllView);

                                    SetSearchSpec("Id", AccountId);

                                    ExecuteQuery(ForwardOnly);

                                    Name= GetFieldValue("Name");

                        ActivateField("Account Status");

                                    Stat=GetFieldValue("Account Status");

                        }

                         if (Stat == "Prospect")

                        {

                                    bcAccount.SetFieldValue ("Account Status","Initiate Request");

                                    bcAccount.WriteRecord();                 

                        }

                 bcAccount=null;

              boAccount=null;                                

            }

           return (ContinueOperation);

}

Event 2.3

BC: Opportunity

 Event: BusComp_WriteRecord

This event is fired after the record is written to the database. This event can be used to perform any associated actions immediately after the record is written to the database.

 Functional Use: This event is used to write date value in the Field ‘Expected Delivery date’ in the Opportunity BC, when a record is saved.

Code:

function BusComp_WriteRecord ()

{

   var SalesStage,clsdate,boOpty,bcRealizable,month,day,year,Fyearret;//declared for realizable revenue

           if (ibProdModify || ibProdModifyMore)

            {

                        var Id = GetFieldValue("Id");

                        var CloseDate = GetFieldValue("Close Date");                   

                        var BOCurrent = TheApplication().ActiveBusObject();

                        var BOOpty, BCOpty, BCOptyProd;

                        if ( BOCurrent == "Opportunity" )

                        {

                                    BOOpty = BOCurrent;

                                    BCOptyProd = BOOpty.GetBusComp('Opportunity Product');

                            }else

                        {

                                    BOOpty = TheApplication().GetBusObject("Opportunity");

                                    BCOpty = BOOpty.GetBusComp('Opportunity');                            

                                    BCOptyProd = BOOpty.GetBusComp('Opportunity Product');

                        }                                               

                        BCOptyProd.ClearToQuery();

                        BCOptyProd.ExecuteQuery();

                        var Ret = BCOptyProd.FirstRecord();

                  if (SalesStage != "14 - Closed / Scrapped" && SalesStage != "10 - Closed / Won" && SalesStage != "12 - Closed / Lost" && SalesStage != "13 - Closed / Shelved")

               {

            while(Ret)

           {

             BCOptyProd.SetFieldValue("Expected Delivery Date",CloseDate);

     BCOptyProd.WriteRecord();                          

              Ret = BCOptyProd.NextRecord();

            }

            }

                        

Enabling n disabling a Button

Enabling n disabling a Button

There are two methods used to enable or disable buttons. One involves configuration and the other involves scripting. The complexity of the logic surrounding the button state drives which approach to take.

Steps

1. Examine the logic required to enable the button.
1. If the logic is unconditional (for example, always display the My Method button) then use the configuration method.
2. If the logic is conditional (for example, only enable the Close SR button if all child activities are Completed on satisfying a condition) then use the scripting method.

Configuration Method

                                   The configuration method can be applied either at the Applet or Business Component level. Think carefully about where to place the configuration. If it will be needed in many applets based on one BC, then it is probably best to place it directly on the BC. If it is only likely to be needed for a single applet, then you may feel it is more appropriate to enable the method only on the Applet.

Applet Level

1. Create a new Applet User Property called

"Named Method: Method Name" where Method Name is the name of the method being enabled.

2. Set the value of this user property to be 'INVOKE', 'MethodName' where MethodName is the name of the method being enabled.

BC Level

1. Create a new BC User Property called "Named Method X" where X is a sequential number (starting from 1).
2. Set the value of this user property to be "MethodName", "INVOKE", "BC", "MethodName" where MethodName is the name of the method being enabled and BC is the name of the business component on which it is enabled.

Scripting Method

The scripting method is applicable when the logic needed to enable or disable the button is complex (for example if you have to check or satisfy a field value)

1. Edit the Server script on the Applet
2. Within the WebApplet_PreCanInvokeMethod function enter script for the method that you need to enable.
• Note that it's essential to minimize any script placed in the WebApplet_PreCanInvokeMethod event handler as this function is called a lot of times!

2.      If the button is to be enabled the CanInvoke parameter must be set to "True" (Note this must be "TRUE" in some versions)

3.      If the button is to be disabled the CanInvoke parameter must be set to "False" (Note this must be "FALSE" in some versions)

3. If you have finished processing the logic, then return Cancel Operation.
4. If the internal Siebel classes also need to process this request (for example if you're modifying the behavior of Write Record), then you may need to return Continue Operation.
5. Ensure that the script returns ContinueOperation for all methods that you haven't explicitly dealt with.

Examples

To enable a button invoking the "MyMethod" method on the Service Request List Applet.

Configuration Method

Assuming that the button is to be enabled unconditionally.

Applet Level

1. On the Service Request List Applet create a new User Property called "Named Method: MyMethod".
• Set the value of this property to 'INVOKE', 'MyMethod'

BC Level

1. On the Service Request BC create a new User Property called "Named Method 1". Note that the number 1 represents the appropriate value for the 7.7 Sample database for the Service Request BC. Ensure that you check the appropriate value for yourself.
• Set the value of this property to "MyMethod", "INVOKE", "Service Request", "MyMethod".

 Scripting Method

If the button is to only be enabled if the Status field is set to "Completed".

eScript

function WebApplet_PreCanInvokeMethod (MethodName, &CanInvoke)

{

  switch(MethodName)

  {

     case "MyMethod":

        //The status field has Link Specification set to True so it will always be     Active, so does not require additional code to acitvate and retreive the value.

        if(this.BusComp().GetFieldValue("Status")=="Completed")

           CanInvoke = "True";

        else

           CanInvoke = "False";

        return(CancelOperation);

        break;

     default:

        return(ContinueOperation);

  }

               There is one more way to enable the method Methods that use the naming format EventMethodxxx do not require any applet or business component script to enable the event. for example, if we set MethodInvoked='EventMethodTestMethod' you need not use a userpropery

}

Scenario(Config)

1.  If the account type is insurance provider, then account class must be insurance company.

 

2. If the quote status is cancel, then the quote should be read only.

3. If the status of the quote is close, then the user should not allowed to delete the record.

4. Hierarchical picklist:

     Account Group: Personal

                                Corporate

     

	Personal	Corporate
Account Category	Resident	Public
	Non-Resident	Private
		Limited

 

5. Display all the quotes of an account which are active and the status is in progress and which are created before the login date.

Ex: if login date = 13^th June display all quotes created before 13^th.

Access Control Mechanism

Their are two type of access control mechanism(ACM)

View level & Data Level

View-Level Access Control

 Organizations are generally arranged around functions, with employees being assigned one or more

functions. View-level access control determines what parts of the Siebel application a user can

access, based on the functions assigned to that user. In Siebel applications, these

functions are called responsibilities.

Responsibilities define the collection of views to which a user has access. An employee assigned to

one responsibility may not have access to parts of the Siebel applications associated with another

set of responsibilities. For example, typically a system administrator has the ability to view and

manage user profiles, while other employees do not have this ability.

Each users primary responsibility also controls the users default screen tab layout and tasks. 

Record-Level Access Control 

Record-level access control assigns permissions to individual data items within an application. This

allows Siebel customers to authorize only those authenticated users that need to view particular data

records to access that information.

Siebel applications use three types of record-level access: position, organization, and access group.

When a particular position, organization, or access group is assigned to a data record, only

employees within that position, organization, or access group can view that record.

 A position represents a place in the organizational structure, much like a job title. Typically, a

single employee occupies a position; however, it is possible for multiple employees to share a

position. Position access allows Siebel customers to classify users so that the hierarchy between

them can be used for access to data.

For example, a supervisor would have access to much of the data that a subordinate has access

to; the same applies to others who report to the same manager.

 

 Similarly, an organization such as a branch of an agency or a division of a company is a

grouping of positions that map to the physical hierarchy of a company. Those employees assigned

to a position within a certain organization are granted access to the data that has been assigned

to that organization. Visibility to data can be set up to restrict employees from accessing data

outside their own organization.

  An access group is a less-structured collection of users or group of users, such as a task force.

Groups can be based on some common attribute of users, or created on an ad hoc basis, pulling

together users from across different organizations and granting them access to the same data.

User Properties(Read Only behaviour)

BC USER PROPERTIES (READ ONLY BEHAVIOUR)

Configuring Data-Driven Read-Only Behavior

---------------------------------------------------------

Business components and fields can be configured as dynamically accessible, with their read-only status turned on and off depending on the value in a particular field in the current record. This is accomplished using one of the following Business Component object type user properties, depending on the requirement:

 

BC Read Only Field :

                               Specifies a TRUE or FALSE field in the record that, when TRUE, causes the current record to become read-only.

 

Field Read Only Field: fieldname

                                                  Specifies a TRUE or FALSE test field and a target field in the same business component. When the TRUE/FALSE field is true, the target field becomes read-only.

 

NOTE:  Fieldname syntax works if Fieldname is not a join field. If Fieldname is a join field to another table, then this syntax does not prepopulate the field that uses this syntax in its Pre Default Value.

 

Parent Read Only Field

Specifies a TRUE or FALSE test business component or field combination in the parent chain (parent, grandparent, and so on) that, when TRUE, causes the target business component to become read-only.

 

For more information about user properties, see Siebel Developer's Reference.

 

When configuring read-only behavior, consider the following:

 

                                        Wherever a business component or field name is specified, whether in the Name or Value property of the user property object definition, make sure that the capitalization, spelling, and use of blank spaces are correct. Also make sure that quotation marks are not present.

These user properties do not function when used in an applet in a view where the view's Admin Mode property is set to TRUE.

Admin Mode, when TRUE, turns off all insert and update restrictions for the business components used by the view, including those specified by business component user properties. The business component Sales Rep and Personal visibility modes are ignored. Records that do not have a primary team member are also visible. However, pop-up visibility is not overridden.

 

NOTE:  The Admin Mode flag should be set to TRUE only in a view that is part of a screen containing all administration views. Do not use the Admin Mode flag for a view in a screen that contains any non-administration views.

 

You can have a list view with Admin Mode set to TRUE that drills down to a detail view not marked as an administration view, while remaining in Admin Mode. This allows you to share detail views with non-administration list views.

 

BC Read-Only Field:

                               This user property specifies a Boolean field that, when TRUE, causes all fields in the current record to become read-only. This also prevents the user from updating or deleting the record, but does not prevent the addition of new records to the business component. The Name and Value properties in the user property record are specified as follows:

 

Name: Contains the literal text BC Read Only Field.

Value: Contains the name of a field in the same business component as the parent object definition of the user property. This field must be a TRUE or FALSE field.

                        An example of the use of BC Read Only Field is the situation in which you need to prevent users from updating inactive accounts. The Inactive Account field in an account record is a TRUE or FALSE field that, when TRUE, indicates that the account is inactive. To configure dynamic read-only behavior for the Account business component based on this field, add a business component user property child object definition to the Account business component, with the following property settings:

 Name: BC Read-Only Field.

Value :Inactive Account.

 

Field Read Only Field

This user property is similar to BC Read Only Field, in that it tests the field specified in the Value property and enforces a read-only restriction when the test field has a value of TRUE in the current record. However, unlike BC Read Only Field, the Field Read Only Field user property restricts one field in the same business component, rather than the entire business component record.

 

The Name and Value properties in the user property record are specified as follows:

 

Name. Contains an expression in the following format:

Field Read Only Field: fieldname

 

For example:

 Field Read Only Field: Account Status

 Note that there is only a single space between the colon and the field name.

 Value. Contains the name of the test field. This is a TRUE or FALSE field in the same business component as the parent object definition of the user property.

One Field Read Only Field user property must be created for each field you want to make conditionally read-only.

 An example of the use of Field Read Only Field is the situation in which you want to make the Competitor field in an account record read-only when the Type field has a value of Competitor. In other words, if an account record has been included because that account is a competitor, you do not want users to be specifying that account's competitors. The following procedure describes how to accomplish this.

 To restrict the Competitor field in an account based on the account's type

 Navigate to the Business Component object type in the Object Explorer, and then to the Account object definition in the Object List Editor.

Create a calculated Boolean field in this business component that will have a value of TRUE when the Type field has a value of Competitor.

For purposes of the example, the name of this test field can be Competitor Calc, although the name is unimportant as long as it is referenced correctly in the user property.

 In the calculation property of the Competitor Calc field, enter the following value:

IIf([Type] = "Competitor", "Y", "N")

 Expand the Business Component object type in the Object Explorer, and select the Business Component User Prop object type. Click the Object List Editor to make it active, and choose Edit > New Record.

Set the following values in the new Business Component User Prop object definition:

Name. Field Read Only Field: Competitor

Value. Competitor Calc

 

Parent Read Only Field

This property, like BC Read Only Field, places a read-only restriction on an entire business component, rather than a single target field. This restriction occurs when a TRUE or FALSE test field has a TRUE value. However, unlike BC Read Only Field and Field Read Only Field, this user property is used to place a restriction on a child or grandchild (and so on) business component of the business component containing the test field. In the other user properties, the read-only restriction is placed on the business component containing the test field, or on another field in the same business component.

 

Parent Read Only Field is used primarily to restrict the detail records in a multi-value group. It could also be used to restrict the detail records in a master-detail view, but in that case you need to make sure that the restricted business component is not also used in the context of some other business object than the intended one.

 

The Name and Value properties in the user property record are specified as follows:

 

Name. Contains the literal text Parent Read-Only Field.

Value. Contains an expression in the following format:

buscompname.fieldname

 where fieldname is the name of the test field, that is, the TRUE or FALSE field to be evaluated, and buscompname is the name of the business component in which the test field is located. For example:

 Account.Inactive Account

 The business component to be conditionally restricted is the one to which you add the user property as a child object definition. The business component containing the test field must be a parent or grandparent of the restricted business component by way of a link or series of link relationships.

 

An example of the use of this user property is the situation where you want to disable the update of the Account Address multi-value group when the account record has a Type of Competitor. To accomplish this, you add the same calculated field as in the Field Read Only Field example, and then add a user property to the Business Address business component with the following values:

 

Name. Parent Read Only Field

Value. Account.Competitor Calc

This causes the Account Address multi-value group to be read-only when the account record is for a competitor.

 NOTE:  When using the Parent Read Only Field user property, the test field must have its Link Specification property set to TRUE. Otherwise the dynamic read-only functionality does not work. However, if the child record is displayed in the multi-value field in the parent business component, it is not necessary to have the Link Specification property of the field set to TRUE.

 

   

  

Scripting Cheat sheet(All at a one place)

Siebel eScript 7.7 Cheat Sheet Business Component (Methods ) : ActivateField ActivateMultipleFields Associate BusObject ClearToQuery DeactivateFields DeleteRecord ExecuteQuery ExecuteQuery2 FirstRecord GetAssocBusComp GetFieldValue GetFormattedFieldValue GetMultipleFieldValues GetMVGBusComp GetNamedSearch GetPicklistBusComp GetSearchExpr GetSearchSpec GetUserProperty GetViewMode InvokeMethod LastRecord Name NewRecord NextRecord ParentBusComp Pick PreviousRecord RefineQuery SetFieldValue SetFormattedFieldValue SetMultipleFieldValues SetNamedSearch SetSearchExpr SetSearchSpec SetSortSpec SetUserProperty SetViewMode UndoRecord WriteRecord --------------------------------------------------------------- Events BusComp_Associate BusComp_ChangeRecord BusComp_CopyRecord BusComp_DeleteRecord BusComp_InvokeMethod BusComp_NewRecord BusComp_PreAssociate BusComp_PreCopyRecord BusComp_PreDeleteRecord BusComp_PreGetFieldValue BusComp_PreInvokeMethod BusComp_PreNewRecord BusComp_PreQuery BusComp_PreSetFieldValue BusComp_PreWriteRecord BusComp_Query BusComp_SetFieldValue BusComp_WriteRecord ***************************************************** Bus Object (Methods) GetBusComp Name ***************************************************** Bus Service Methods GetFirstProperty GetNextProperty GetProperty InvokeMethod Name PropertyExists RemoveProperty SetProperty ------------------------------------------------------------- Events Service_InvokeMethod Service_PreCanInvokeMethod Service_PreInvokeMethod Application ***************************************************** Application Methods ActiveBusObject ActiveViewName CurrencyCode GetProfileAttr GetService GetSharedGlobal GotoView InvokeMethod LoginId LoginName LookupMessage NewPropertySet PositionId PositionName RaiseError RaiseErrorText SetPositionId SetPositionName SetProfileAttr SetSharedGlobal Trace TraceOff TraceOn ------------------------------------------------------------- Events Application_Close Application_InvokeMethod Application_Navigate Application_PreInvokeMethod Application_PreNavigate Application_Start ****************************************************** Applet Methods ActiveMode BusComp BusObject FindActiveXControl FindControl InvokeMethod Name ------------------------------------------------------------- Events Applet_ChangeFieldValue Applet_ChangeRecord Applet_InvokeMethod Applet_Load Applet_PreInvokeMethod WebApplet_InvokeMethod WebApplet_Load WebApplet_PreCanInvokeMethod WebApplet_PreInvokeMethod WebApplet_ShowControl WebApplet_ShowListColumn

Configuration

If you want to get child Bus Comp Record count without scripting? For Example: The End Date of any Service Request should not be modifiable if any child Activity Status is Active, the customer wants error message. Implementation without scripting: * Create a calculated field: Check End Date * Calc Expression : GetNumBCRows ("Service Request", "Action", "'[SR Id] ="' + [Id] +'"' AND [Status] = "Active", ","All") * Return child record count * Set Validation Property for Service Request End Date to avoid modification * Value: [Check End Date] <1 Syntax: GetNumBCRows (BO, BC, search_expr, visibility)

Hi This Blog Will help the Siebel CRM Developers to learn & share the knowledge.We will be dealing all versions of siebel crm ,all domains and all parts of the siebel domain