Browser Script Architecture

The Browser Script architecture supports parallel development of browser scripts for those objects that support it, such as Applets and BusComps. It provides this capability by reading browser scripts directly from the various runtime definitions stored in the runtime tables, such as S_RR_APPLET and S_RR_BUSCOMP, which contain the information needed to get the correct version of the script for the user's current workspace context.

The following figure shows how the Browser Script Architecture works.

As shown in this figure, the Browser Script Architecture works as follows:

1. A client requests a browser script from the web server.

2. The Siebel Application Interface requests the definition from the Siebel Server.

3. The Siebel Server retrieves object definition from the Runtime Repository table, such as S_RR_APPLET, if the object definition is not found in the runtime repository cache.

4. The Siebel Server returns the script to the Siebel Application Interface.

5. The Siebel Application Interface delivers the content to the requesting client.

6. The browser can cache the request with the help of a standard HTML cache-control header.

7. Future requests for the same browser script can be delivered by the browser if the cache is managed.

This architecture provides the following benefits:

• Provides true workspace enablement as the browser script is managed within the workspace framework just like any other object type.

• Simplifies deployment by reading directly from the RR definition for an object such as an applet or BusComp.