SBL-CFG-00157: The Siebel Product Configurator run-time engine isn't initialized.

Applies to:

Siebel eConfigurator - Version: 8.0 [20405] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

When configuring specific products, the session was hanging and causing a crash. In the log file was the following error:

SBL-CFG-00157: The Siebel Product Configurator run-time engine isn't initialized

This behaviour only occurred when using the dedicated Product Configurator object manager i.e. Product Configurator - Use Remote Service set to TRUE.

No hang was experienced running eConfigurator within the calling object manager.

Cause

The specific products which exhibited this behaviour were using product script to call a business service to perform additional configuration. In one situation the business service called the Remote Complex Object Instance Service to modify the existing instance. In another the business service called a workflow which then called the Remote Complex Object Instance Service to modify the existing instance. This configuration was to meet specific business requirements.

Change Request Defect 12-1S1FVNR was raised to address this issue.

Solution

The following solution may work and should be tried initially:

Use: TheApplication().GetService("Configurator Session Service");

rather than

TheApplication().GetService("Remote Complex Object Instance Service");

Otherwise the following fixes are available.

FR 12-1S1FR46 exists as a quick fix for 8.0.0.6 SIA.
FR 12-1TK52YW exists for maintenance release 8.0.0.9 SIA.
FR 12-1TK530Y exists for maintenance release 8.1.1.2 SIA.

Applies to:

Siebel eConfigurator - Version: 7.7.2 SIA [18325] - Release: V7
Sun Solaris SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2 [18325] Com/Med
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 9
Database Server OS: Sun Solaris 9

This document was previously published as Siebel SR 38-2874314031.

Symptoms

SBL-CFG-00157

Hi,

This week, along with Siebel Team conducted series of tests to figure out the actual cause of memory leakage happening in the entire journey. The iterative tests suggest that 65-70 percentage of memory leakage is happening because of a vanilla business. The business service is used for checking whether a given date falls on Weekend or public holiday or not. The detail of the vanilla business service is as given below.

Business Service Name: Availability Service
Method Name: GetEndTimeBasedOnShift

The business service makes use of the schedule configured under Administration- Schedules.

Cause

Customer found memory leaks and performance issues with following business service:
BS = Availability Service, Method Name = GetEndTimeBasedOnShift

The business service makes use of the schedule configured under Administration- Schedules.

Solution

We reproduced the leak on standard environment using your script and logged change request Bug 12-1EEV78L. This will be addressed in fixpacks for Siebel 7.7, 7.8 and 8.0.

We also found 2 other small defects when you use Application().Trace for custom code debugging:

1) Trace allocations and releases
Tracing (TheApplication().Trace(...)) is not showing variables that have been de-allocated. Currently if I instantiate a Business Component or Service and enabled tracing I'll see logfile entries:

07/03/01,19:51:56,ALLOC,2,PropertySet, ,Script

However the Release traces can be missing. This is addressed in change request Bug 12-5O4FSL. Please note:  Trace statement is missing, however Release works fine.

Basically Alloc/Release will be managed internally by the garbage collector in eScript. You do not need to trace the allocations/releases. As it is an automatic mechanism there is no way for the user to influence this behavior. There is no reason as well to expect an object to be released just by setting a variable pointing to it to null. An object is released as a result of the garbage collector running, not by setting a variable to null.

2) TraceOn method
TraceOn itself has a small memory leak which can lead to a wrong picture if you search for memory leaks. We created change request Bug 12-1EA2C6L to address this with Siebel Engineering.

Example: Start a script with TraceOn, you can see a memory leak if you run following code (memory grows with every single loop):

       var i;
        for (i=0; i<=100000; i++)
        {
          var bo = TheApplication().GetBusObject("List Of Values");
          var bc = bo.GetBusComp("List Of Values");
        }



Siebel Technical Support
Keywords: memory leak, performance, TraceOn, allocation, release, alloc, garbage collector, Availability Service, GetEndTimeBasedOnShift