Avoid duplicates using eScript.

To avoid duplication in Contact BC based on First Name and Last Name. If Firstname and LastName already exists then we have to raise a message.

BusComp_PreWriteRecord()
{

var oBO = TheApplication().GetBusObject(“Contact”);

var oBC = oBO.GetBusComp(“Contact”);

With(oBC)

{
SetViewMode(AllView);
ClearToQuery();
SetSearchSpec(“First Name”, this.GetFieldValue(“First Name”));
SetSearchSpec(“Last Name”, this.GetFieldValue("Last Name”));
ExecuteQuery(ForwardOnly);

if (FirstRecord())

{

TheApplication().RaiseErrorText (“Sorry this record exists”);

}
oBC = null;
0BO = null;
return(ContinueOpertion);

}

Compile and test. Please Note :
1. CancelOperation stops the execution of the underlying Siebel code associated with the event.
2. and no need to activate fields as it will be taken care by "SetSearchSpec".

ALSO Please Note:
About ExecuteQuery(ForwardOnly);
Use ForwardOnly Cursor Mode if you will traverse through the record set from FirstRecord using NextRecord and will not return to a previous record. If ForwardOnly cursor mode is not mentioned, it will be defaulted to ForwardBackward and to support this Siebel system has to create a Cache to maintain the entire record which would degrade the performance.

This is particularly true if you perform a look up or if you access a pick list.


Happy eScripting!!!!

Debugging Siebel Applications

It is essential that you understand how to debug Siebel applications. There are four basic techniques:
• Use alerts or RaiseErrorText methods to pop up message boxes
• Write to a file using Trace or custom methods
• Use the Siebel Debugger
• Use object manager level logging

Alert and RaiseError-Text
The alert method in browser script and the RaiseErrorText method in server
script enable you to display message boxes to the user.
The RaiseErrorText method stops the execution of a script; therefore, it is
only appropriate for a quick check of something and is not a good way to
debug scripts where the source of the error is hard to determine.
Alerts do not stop the execution of browser scripts and therefore are a quick
and easy way to debug browser scripts.

Writing to a Text File
The most common way to debug a script is to write information to a text file.
Accomplish this using the Trace function or an Siebel VB or eScript function.
Using Trace, you can write the actual SQL to a file.

Using the Debugger in Siebel Tools
This is a useful tool for visually stepping through the code and looking at the
values of variables real time. You can set break points anywhere until you
isolate a problem.

Using Object Manager Settings
When an application is in production, it is not always possible to add
debugging statements to script. In this situation, developers or systems
administrators can change settings in the object manager to trace events and
SQL.
Defined in the Component Parameters View:
• OM - EL Tracing User Name: a comma separated list of logins to trace (for
example, SADMIN)
• OM - Trace EL Allocation: traces object memory allocation (Set to 1)
• OM - Trace EL Events: traces which events are triggered (Set to 1)
• OM - Trace EL SQL: traces the SQL generated by script (Set to 1)

When to Use Browser versus Server Script

Browser script is recommended for:
• Communication with the user
• Interaction with desktop applications
• Data validation and manipulation limited to the current record

Server script is recommended for:
• Query, insert, update, and delete operations
• Access to data beyond the current record

Preferred alternatives to scripting include::

• Field validation
• User properties
• Workflow
• Personalization
• Run-time events
• State model

Difference between Alert() and SWEAlert Functions

• In Siebel 2000 and earlier releases, developers could use the application methods such as MsgBox and InputBox to create a dialog box and get input from the users.
• In Siebel 7, these methods are not supported, but the developer could still achieve the same in browser script with the help of JavaScript functions such as Alert, Prompt and Confirm.
• Siebel applications version 7.5.3 and higher also includes a method known as SWEAlert method 

The Alert Function and SWEAlert Method:

These functions allow you to display messages and obtain input through browser scripting.

The alert function will pop up a message box and display an OK button.

The syntax is as follows: alert(The Message To Display );

Where as from Siebel applications version 7.5.3 and higher, the Alert function is incorporated into the Siebel interfaces methods through the application SWEAlert method.

and you should use the SWEAlert method rather than the alert function in versions 7.5.3 and higher, unless the script is running in standard interactivity (SI) mode.

PLEASE Note:

The Alert function is only supported in Standard Interactivity mode. 

while the SWEAlert method is only supported in high interactivity mode.

the syntax for SWEAlert method is :

theApplication().SWEAlert("message")

One advantage of using the SWEAlert method instead of the Alert function is the behavior. If the alert is invoked on a popup applet such as an MVG applet. When Alert window displayed using Alert(), the MVG applet disappears behind the main application applet, but it won't when used with SWEAlert().

RaiseError Method

To Start, RaiseError Method is one of the Application Methods.

The RaiseError method raises a scripting error message to the browser.

When invoked, the RaiseError method causes execution of the script to terminate, and sends a notification to the browser. Therefore, CancelOperation is not required after RaiseError.

Be careful when using RaiseError, because it cancels operations. For example, if it is used

in BusComp_PreWriteRecord, the user or code will not be able to step off the current record until the

condition causing the RaiseError method to be invoked is addressed.

The following eScript example raises the error message “This user-defined test error is used in

PreDelete, as an example for RaiseError Method” when deleting an opportunity with the “Pipeline”

revenue class. Note that the key "user-defined test error1" is predefined as "This user-defined test

error is used in %1, as an example for %2". When the script runs, 'PreDelete' is substituted for %1

and 'Raise Error Method' is substituted for %2.

function BusComp_PreDeleteRecord ()

{

try

       {

var revClass = this.GetFieldValue("Primary Revenue Class");

if (revClass == "1-Pipeline")

   {

TheApplication().RaiseError("user-defined test error1", "PreDelete",

"RaiseError Method" );

      }

else

{

return (ContinueOperation);

}

}

catch (e)

 {

     throw e;

 }

}

Scripting Capabilities

Scripting is commonly used by customers and partners to implement procedural logic or complex business rules within their applications. Customers often have complex business rules pertaining to what are their required fields when a user creates a record. The rule of thumb is always to rely upon configuration to enforce data integrity and entry into a required field wherever and whenever possible. For situations where requirements cannot be met using configuration, developers can turn to Siebel Scripting as an alternative.

1. Business rule definition
2. Perform complex data validations and manipulations
     Which cannot be achieved by declarative configuration
3. Incorporate validations based on internal or external data
     Example: Compare data in different records
4. Dynamic user interaction, for example

•   Inform user of something
•   Collect information from user
•   Custom HTML dialogs

5. Custom behavior definition for user interface controls
     Examples:

•    Custom menus, buttons, and toolbars
•    Color coding user interface

 6. Communication with external sources

•  Desktop applications
•  Workflow processes

7. Integration solutions

•  Data transformation
•  Data sharing
•  Data transport

Reasons to Avoid Siebel Scripting (music to my ears :))

--Slows processing, Interpreted at runtime

--Introduces potential for data integrity issues and runtime errors

--Requires continued maintenance

--Introduces complexity

--Often reproduces functionality available through configuration

--Complicates upgrade process

Server Scripts vs Browser Scripts:

Server scripts written in eScript and Siebel VB
Interact with database (query, insert, update, delete)
Execute in Object Manager
Limited support for user interaction
Authored in Siebel Tools or in Client
Access to data beyond the current record (validation and manipulation)


Browser scripts written in JavaScript
Interact with users and desktop applications
Download to client and execute in browser
Authored in Siebel Tools
Data validation and manipulation limited to the current record