Configuration Guidelines > Development Standards for Siebel Script Languages and Object Interfaces >

Preimplementation Considerations

Siebel scripting languages can add extensions to the existing declarative configuration capabilities. Along with this additional capability, there are also disadvantages, such as degraded maintainability, compromised upgrade options, and increased debugging time. Generally, you should try all other possibilities before using script to accomplish a functional requirement.

The technologies in Table 12 perform a wide variety of tasks, such as simple data validation, event-driven processing, data-driven read-only behavior, interaction with external systems, security, or state transitions.

The preceding guidelines describe the two factors that have the most significant impact on application quality, maintenance and upgrades. Using standard Siebel components and declarative configuration tools decreases the amount of time and effort required to maintain the application. They also make it easier to get a high-level view of the type of functionality implemented, because all the functionality is stored in one place. Scripts require more research because you must examine each object individually and read script code to determine how it works.

In addition, declarative functionality is upgraded automatically when the application is upgraded, while scripts are not. After an upgrade is complete, you must test all objects that have scripts to make sure functionality has not been lost. You must also review all nontrivial scripts to make sure they are compatible with any changes in the application. Configuration mechanisms are rarely removed from the application, so most standard functionality will upgrade without incident. For information on whether an upgrade will affect declarative functionality, see the release notes documentation for your Siebel application.

 Configuration Guidelines 
 Published: 18 April 2003