Declarative Alternatives to Using Siebel Scripting
(Doc ID 477842.1)
Last updated on NOVEMBER 22, 2019
Applies to:Siebel Tools - Version 7.0.4  and later
Information in this document applies to any platform.
Release(s):V7 (Enterprise), V8 (Enterprise)
Database(s):All Supported Databases
App Server OS(s):All Supported Platforms
Latest release tested against:V8 (Enterprise)
Keywords:scripting, configuration, personalization, state model, workflow
””Checked for Relevance on 27-09-2012””
This document was previously published as Siebel Technical Note 591.
**Checked for relevance on 08-12-2015**
There are two approaches to implementing custom business requirements in a Siebel application. The first is to apply scripting; the second is to apply declarative configuration alternatives.
Common reasons for using scripting include:
- Data validation
- Triggering action based on data changes
- Navigation through the application
- Populating fields with default data
- Preventing the copy of field data
- Integration with external systems
It is recommended that you avoid using scripting where ever possible. Use scripting only when no other configuration alternative is appropriate.
Reasons to avoid scripting include:
- Scripts are interpreted at runtime and therefore have a performance impact; use of compiled classes is more efficient.
- Scripts introduce potential for data integrity issues and runtime errors.
- Scripts require continued maintenance.
- Scripts introduce an additional level of configuration complexity.
- Scripts are sometime used to reproduce functionality that is already available in the Siebel application.
This document is informational and intended for any user.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|Triggering Actions Based on Data Changes|