14/03/2011 My Oracle Support | Knowledge Brow…

Overview of the Complex Object Instance Service and Remote Complex Object Instance Service in Siebel Configurator [ID 478055.1]

Modified 28-JUL-2010 Type BULLETIN Status MODERATED

In this Document
Purpose
Scope and Application
Overview of the Complex Object Instance Service and Remote Complex Object Instance Service in Siebel Configurator
Key Points
Event Scripting Against Configurator APIs
A Dedicated Configuration Server Environment
No Dedicated Configuration Servers
Using Configurator APIs in Creation of New Workflows and Business Services
Configurator APIs and Configurator Runtime Scripts (Scripted Configuration Rules)
Version 7.8 and higher

Platforms: 1-914CU;

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical
review.

Applies to:
Siebel eConfigurator - Version: 7.0.4 [14068] and later [Release: V7 and later ]
Siebel Configurator - Version: 7.5.2 [15051] to 8.1.1.3[21219] [Release: V7 to V8]
Information in this document applies to any platform.
Area(s):eConfigurator / Siebel Product Configurator
Release(s):V7 (Enterprise)
Database(s):All Supported Databases
App Server OS(s):All Supported Platforms
Latest release tested against:V7 (Enterprise)
Keywords:RCOIS, COIS, Complex Object Instance, Remote Complex Object Instance

This document was previously published as Siebel Technical Note 555.

Purpose

Siebel Configurator provides a dynamically-generated, data-driven user interface to represent complex product structures. Since each product selection is
validated against a server-side engine, standard HTML paradigm forces a redrawing of the whole page. Configurator High Interactivity user interface (HI UI)
overcomes the "frequent refresh" problem and provides a new no-flicker, minimum refresh UI framework. The new framework enhances usability by minimizing
refresh and fewer clicks. It results in a faster response time on each user selection and reduces network traffic due to delta updates only. It also lowers the CPU
utilization and enhances UI flexibility and configurability.

Scope and Application

This document is informational and intended for any user.

Overview of the Complex Object Instance Service and Remote Complex Object Instance Service in Siebel Configurator

The purpose of this document is to provide information on the proper use of the two configuration services Complex Object Instance Service (COIS) and Remote
Complex Object Instance Service (RCOIS). This document applies to Siebel versions 7.5.3.x and 7.7. For Siebel 7.8 and higher please see end of document.

Key Points
1. Complex Object Instance Service (COIS) is the key service that provides the Siebel Configurator functionality.

2. Remote Complex Object Instance Service (RCOIS) is a Siebel business service that is a proxy to the (COIS). The RCOIS never executes Siebel
Configurator logic.

3. The purpose for the RCOIS is to accept a request and determine which server should process the request. RCOIS determines if a dedicated configuration
server is to be used based on the server parameter setting: Remote Server = True/False.

4. RCOIS calls Cfg Server Manager (this is a different object than Siebel Server Manager) on the application server (for example the call center server) to
determine which of the dedicated configuration servers to call. The logic in Cfg Server Manager determines this based on the load balancing algorithm and
any product-to-server assignments made through distributed caching functionality.

5. COIS and RCOIS have identical APIs.

NOTE: Points 3 and 4 have a redundant element; both the User Interface (UI) service and the RCOIS are checking for dedicated configuration servers. The
reason for this redundancy is that RCOIS can be called by services other than the configuration UI service. These could be other standard services or
custom services. Because of these cases, the RCOIS must always check whether it is running in a dedicated configuration server environment. This
subject will be discussed in more detail in the section on scripting.

6. During an interactive configuration session, the Configurator UI service calls RCOIS if the environment has dedicated configuration servers and calls COIS
if it does not.

7. When connecting to a dedicated configuration server from the application server, RCOIS uses an anonymous user login. Because of this, the COIS
service on a dedicated configuration server does not have user context.

Event Scripting Against Configurator APIs

This section is for eScripts written against Configurator APIs, with the intent of enhancing behavior of an interactive configuration session. These are scripts that

support.oracle.com/CSP/ui/flash.html 1/5
14/03/2011 My Oracle Support | Knowledge Brow…
are injected into the methods invoked, directly or indirectly, by the UI service. These scripts can be written against either COIS or RCOIS. For details, see
Technical Note 515 on SupportWeb.

In a dedicated configuration server environment, the scripts will determine on which type of server the script is executed, either application or configuration. It is
important here to re-iterate that RCOIS will not be called by the Configurator UI service when the environment does not have dedicated configuration servers.

In environments with no dedicated configuration servers: All event scripting should be written against the COIS APIs, since RCOIS is never called by the standard
processes.

In environments with dedicated configuration servers: All event scripts should be written against RCOIS APIs, since these scripts run on the server with the
proper user context.

NOTE: This will be more complicated when there are Siebel Remote clients and application developers using dedicated clients. These two client types would not
call RCOIS, because they are not using dedicated configuration servers.

This leaves three options for the application developer for coding:

To code against RCOIS which means the code would not be invoked for the remote and dedicated clients.

To code against COIS which means the scripts invoked by thin client requests would not have the proper user context because they would be running
against COIS on the dedicated Configurator servers.

To code against both COIS and RCOIS which means the script runs twice for thin client requests - with the COIS script often having an error. To solve this
issue, the scripts should be put on both COIS and RCOIS and use a User Profile Attribute to make the running of the script on COIS conditional on the
presence of the profile attribute. The profile attribute could be set at login time and give any value. Since the scripts on the COIS would be conditioned on
existence of the profile attribute, these scripts will only run on the Siebel server (for the dedicated and remote clients) and will not run on the dedicated
configuration servers. The scripts on RCOIS do not have to be executed based on the condition because the only time that RCOIS is called for thin-client
requests, is when the script on RCOIS should execute.

A Dedicated Configuration Server Environment

Dedicated Configuration server script on Invoke_Method of COIS modifying output property set:

With Dedicated Configuration server script on PreInvoke_Method of COIS modifies input property set:

Dedicated Configuration server script on Invoke_Method of RCOIS modifying output property set:

support.oracle.com/CSP/ui/flash.html 2/5
14/03/2011 My Oracle Support | Knowledge Brow…

Dedicated Configuration server script on PreInvoke_Method of RCOIS modifying input property set:

No Dedicated Configuration Servers

No dedicated Configuration server script on PreInvoke_Method of COIS modifying output property set:

No dedicated Configuration server script on Invoke_Method of COIS modifying output property set:

support.oracle.com/CSP/ui/flash.html 3/5
14/03/2011 My Oracle Support | Knowledge Brow…

Using Configurator APIs in Creation of New Workflows and Business Services

When the configuration APIs are used from a workflow or directly from eScript in a custom business service, for example headless configuration, either of the
business services (COIS or RCOIS) can be called. To determine which business service to use, you should consider the following:

If a workflow calls the COIS service directly, then the request will be processed by the COIS service on the server running the workflow, even in a
dedicated configuration environment. This is because RCOIS was not called to control the passing of the configuration API request to the dedicated
configuration servers. So, calling COIS directly is only appropriate when you want the request from the workflow to go to the COIS on the same server as
where the workflow is running.

In an environment without dedicated configuration servers, any calls to RCOIS would also result in the request being processed by the COIS service on
the same server as the workflow. It is relevant to ask why it would be appropriate to ever call COIS directly from the workflow. There is a certain degree of
processing overhead in calling COIS via the RCOIS proxy. In a non-dedicated configuration server environment, this overhead is un-necessary. So, the
more a workflow makes calls to a Configurator API, the greater the performance effect of the un-necessary overhead. While it should be considered best
practice to always call RCOIS from the workflows, in order to be able to re-use the workflows when switching to a dedicated configuration setup, there
may be occasions where COIS is called directly in order to achieve a needed performance benefit.

NOTE: When RCOIS is used as the proxy to COIS, it always calls the StartNewSession API as the first call. When COIS is used through UI, the UI
service calls start new session as the first call. However, when COIS is called through script or workflow in a headless mode, if the StartNewSession API
is not the first call, the Object Broker executes an extra internal Siebel algorithm on every API request. This results in a large number of queries on every
instance API call. Because of this, workflows calling RCOIS will perform better that those using COIS unless the workflow using COIS calls the
StartNewSession API as the first call. With this API in place, workflows using COIS should show measurable performance improvements over an identical
workflow using RCOIS.

So, if any scripts require user context, then all scripting should be against the RCOIS service. In this case, user context refers to any personalization
variables and any UI information - for example Active Business Object. Profile attributes are session specific, so scripting on COIS does not preclude their
use, even though all sessions have the same anonymous log-in. However, script running on the configuration server cannot refer to a Profile Attribute set
on the application server, and script running on the application server cannot refer to a Profile Attribute set on the configuration server.

The general rule should be to always write script against RCOIS when using Configurator in new business processes because:

The overhead of instantiating the RCOIS in an environment without dedicated servers is minimal since it will only get constructed once and get a handle to
the COIS only once. Invoking methods against it will just check a flag and then delegate to the COIS method directly.

It is more beneficial to use RCOIS, since it calls StartNewSession on LoadInstance which prevents the Object Broker from checking for model updates
within the config session.

It would be easier to migrate the script or workflow to take advantage of COIS API enhancements since we can have RCOIS delegate to various COIS
methods as needed. This will require minimal or no change.

Configurator APIs and Configurator Runtime Scripts (Scripted Configuration Rules)

If you are writing scripted configuration rules in the Customizable Product Administration screens, you should always call the COIS and not RCOIS because
those scripts will execute on the dedicated configuration server.

Version 7.8 and higher

There were some architecture changes with introducing this version. COIS and RCOIS API's are now just proxies to Configurator Service business service. All
previous scripting efforts are kept still supported. Future scripting should be done on RCOIS.

Configurator Service manages connection with Configurator Session Service, which handles session management with thread. Configurator Session Service runs
in either AOM or Prod Cfg OM.

The business service ‘Configurator Service’ combines the features that were previously found in RCOIS and COIS:

It accept a request and determine which server should process the request. Using the parameter Remote Server = False/True it determines if a dedicated
configuration server or component based routing is to be used
It uses functionality provided by Cfg Server Manager and Cache Administration to determine which component or server to call
It always runs on the Application Object Manager

The business service ‘Configurator Service Session’ finally replaces the core logic found in COIS. It contains all APIs and is the key service that provides Siebel

support.oracle.com/CSP/ui/flash.html 4/5
14/03/2011 My Oracle Support | Knowledge Brow…
Product Configurator functionality.

So the BS logic is:

Calls to RCOIS or COIS call (runs on AOM)

Configurator Service BS which calls (runs on AOM)
Configurator Session Service (runs on AOM or eCfg OM)

Related

Products

Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel eConfigurator
Siebel > Customer Relationship Management > CRM - Enterprise Edition > Siebel Configurator

Back to top

support.oracle.com/CSP/ui/flash.html 5/5