Friday, 27 May 2011

Alternatives to siebel Scripting

Data Validation

It is critical that data being entered into the system either via the User Interface or any of the object interfaces is consistent with the business rules for the specific implementation. The data must be in the correct format and data integrity to other objects must be correctly maintained.
Use the Validation field property to specify an expression that defines the valid field value. The expression should evaluate to the Boolean value True to determine that the value entered in the field is considered valid. There are many functions that can be used in the expression. See Bookshelf for more details on supported functions and the expression syntax.
Here are some examples of possible validation rules:

  • A date field that must always have value before the current date: < Today() - 1.
  • The Name field must be greater that 5 characters in length: Len([Name]) > 5.
  • A date field must be after the current value of the Start Date field: > [Start Date].
Use the Force Case field property to ensure that data entered in a field is stored in the correct case format. Specifying this property will cause the entered value to be automatically converted to the specified format.
Valid Force Case property settings are:

  • FirstUpper: Will capitalize the first letter of every word in the value
  • Upper: Will uppercase all characters in the value
  • Lower: Will lowercase all character in the value
Data entered in the user interface typically has two types of validation script associated with it.
In Siebel 7 browser script often validates data entry at the client side. To do this, code is placed on the BusComp_PreSetFieldValue event.
All versions of Siebel support data validation at the server side. Validation code can be implemented on the PreSetFieldValue, SetFieldValue, PreWriteRecord and WriteRecord business component events.

Triggering Actions Based on Data Changes

Sometimes it is necessary to trigger actions in response to data changes, for example when records are created, deleted or updated. The response can be required to be triggered before or after the date change has been applied.
"Pre" scripting events such as PreSetFieldValue, PreWriteRecord and PreDeleteRecord are used to perform validation prior to performing a record create, update or deletion.
Within the Siebel Application there is standard functionality to allow you to implement automated response to data changes without the need to use custom scripts. These tools include:

  • Applet User Properties
  • Business Component User Properties
  • Workflow
  • Personalization
  • Run-Time Events
  • State Model
  • Data Validation Manager
Applet User Properties
The Named Method applet user property can be used to invoke methods in a certain order.
It can be used with applets based on the base classes CSSFrameBase and CSSFrameListBase. This user property can also be used with the business components with the class CSSBCBase
Here is example of using the Name Method applet user property to update a legacy system with new Account records after a new record is created in the Siebel application. It first commits the record in the Siebel application, and then invokes a workflow process to update the legacy system.
Name Value
Named Method: WriteRecord 'INVOKE', 'WriteRecord', 'INVOKESVC', 'Workflow Process Manager', 'Run Process', '"ProcessName"', '"Account - New Order"', '"RowId"','[Id]'
For more information on this user property please refer to the following bookshelf reference: Siebel Developer's Reference > User Properties > Named Method n
Business Component User Properties
Read-only Behavior
Sometime it is required to dynamically prevent users from being able to update certain records or even certain field values. Frequently scripts are placed on the the PreWriteRecord or PreSetFieldValue business component events to implement this requirement.
There is a declarative alternative to this approach. Use the BC Read Only Field, Field Read Only Field or Parent Read Only Field user properties to make certain records or fields read only on a given condition.
For more information on how to utilize these user properties please refer to following bookshelf reference for more information: Configuring Siebel eBusiness Applications > Configuring Business Components > Configuring Data-Driven Read-Only Behavior
Updating Other fields When a Field is Changed
A frequent requirement is to update other fields in a record when a field is picked or edited by the user. Script is often implemented on the PreSetFieldValue or SetFieldValue business component events to implement this requirement.
The declarative alternative is to use the On Field Update Set business component user property.
Here is an example; the result is that whenever the Description field is edited the Status field is set to the value "Working":
Name Value
On Field Update Set "Description","Status","Working"
For more information on this user property please refer to the following bookshelf reference: Siebel Developer's Reference > User Properties > On Field Update Set n
Triggering a Method To Be Invoked When a Field is Changed
Sometimes there is a requirement for a method to be invoked when a field value has been edited. Script is often implemented on the PreSetFieldValue or SetFieldValue business component events to implement this requirement.
The declarative alternative is to use the On Field Update Invoke business component user property.
For more information please refer to the following bookshelf reference: Siebel Developer's Reference > User Properties > On Field Update Invoke n
To Dynamically Make a Field Required
It is possible to declare a field to be statically required by setting the Required property of the Field object to "Y" in Siebel Tools.
It might be a business requirement that a field is required under certain conditions and not required under other conditions. This behavior could be implemented as validation logic placed on the business component's PreWriteRecord event.
The declarative alternative to this approach is to utilize the Required field user property, where the value is an expression that should return the value "Y" when the field should be required and "N" when it should not be required.
For more information on the Required field user Property please refer to the following bookshelf reference: Siebel Developer's Reference > User Properties > Required
Using Siebel Workflow
It is possible to configure a workflow that is triggered when a specific field value is changed or a certain data criterion is met. The triggered workflow process can perform a variety of actions including data updates and triggering other activities such as communication with external systems.
For more information on Siebel Workflow functionality please refer to the Siebel Business Process Designer Administration Guide.
Personalization
Personalization is a commonly used control that determines which applets are visible to the user.
Personalization contains a great deal of information about the current user and their current session. The information is stored in persistent profile attributes, which are initialized when the application is started. The values of the profile attributes can be used in the application configuration.
Personalization can be used to:

  • Display read-only applets dynamically
  • Provide Clicksteam analysis
  • Enable persistent user data
  • Filter Data
  • Enable Messaging
  • Direct Users Path through the application
For more information on Siebel Personalization functionality please refer to the Siebel Personalization Administration Guide.
Run-Time Events
Run-time events all for real time response to user actions such as:

  • Application Login
  • Creation of a record
  • Changing the value of a field
  • Deletion of a Record
Run-time Events can be used to trigger a workflow process that immediately performs an action in response to what a user has done. They can also be used to trigger the Data Validation Manager functionality to apply defined rules to evaluate if data entered into a record is valid.
Use of run-time events and workflow is a very good declarative alternative to the use of custom scripting.
For more information run-time event functionality please refer to the following bookshelf reference: Siebel Personalization Administration Guide > Run-time Events.
Data Validation Manager
DVM functionality was introduced from Siebel version 7.7 and above. It provides a declarative way of specifying rules to evaluate and determine when a record or field value is considered valid and define an appropriate error message to be displayed.
The validation rules and error messages are defined using an administration screen in the Siebel application and are stored in the database.
To typically invoke the evaluation of a rule against a new or updated record you would define a runtime event on the PreWriteRecord event of the business component, the runtime event would invoke the Validate method of the standard Data Validation Manager business service specifying the name of the rule set as an argument.
For more information and examples please refer to following reference:
Data Validation Manager Examples (Doc ID 478298.1)

Siebel State Model
The Siebel State model is a set of rules and conditions that can allow or disallow the change of a field's value from one state to another. For example, these conditions can be used to enforce the business rule that only certain employees can change a field's value.
The state model can be used as a declarative alternative to custom scripts that implement validation logic.

Reference: Support Web

1 comment:

  1. Best 20 Casinos Near Harrah's Casino and Fremont Street, NV
    Harrah's offers 경상북도 출장샵 one of the best places to 경기도 출장안마 stay when 경산 출장안마 you're in Las Vegas. The casino features over 포항 출장마사지 2,500 slot machines, including more than 50 거제 출장샵

    ReplyDelete