Bookshelf Home | Contents | Index | Search | PDF |
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.
- During the initial high-level design, determine if the desired functionality is already part of the Siebel application or is available as a separate Siebel application module. The Siebel product suite is broad, and already includes a variety of business requirements as business components, business services, or separate products. Sometimes, the solution may be only a small piece of functionality (for example, visibility settings, user properties, search specifications on links, or specialized behavior of the base class) or it may be entire application modules (such as Forecasting, ePricer, or eConfigurator). In either case, you should always use standard Siebel features instead of building a custom solution.
The future benefits from using existing product functionality outweigh the additional licensing costs you may incur for using additional Siebel modules. Development costs for maintaining, upgrading, and debugging code can be considerable. Using or augmenting existing product behavior leaves the majority of these issues to Siebel engineering.
- Use existing business services for modular, generic behavior.
There are over 300 prebuilt business services available, most of which can be used by scripts, workflows, or external programs. These business services provide data transformation, communication, server requests, and many other common functions. Using these business services either individually or in conjunction with each other can help avoid duplicating your development efforts.
- Use declarative configuration mechanisms whenever possible.
There are many ways to configure different types of functionality in Siebel eBusiness Applications. Though they are not immediately obvious, most types of functional behavior are possible through declarative configuration.
Table 12 lists the different ways to achieve application behavior that is often implemented in script.
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.
Bookshelf Home | Contents | Index | Search | PDF |
Configuration Guidelines Published: 18 April 2003 |