How Does The Caching For Promotion Constraints Work Via Web Service?

(Doc ID 1421889.1)

Last updated on APRIL 02, 2017

Applies to:

Siebel eConfigurator - Version 8.1.1.1 SIA [21211] and later
Information in this document applies to any platform.
***Checked for relevance on 06-09-2015***

Goal


The BeginConfiguration operation from Product Configurator Web Service is invoked using the Stateful session to insert a quote with a product promotion.
When invoking the BeginConfiguration method, a new configurator (cfg) session is created and linked to the session token generated in the response. The 1st time its executed, it takes 2 minutes to retrieve the record and usually calls the "Promotion Definition Loader.QueryById" and "ISS Promotion CP Admin Service.GetPromotionContraints" methods.
After 10 minutes, for the next BeginConfiguration WS method call passing the session token which was generated by EndConfiguration response then the BeginConfiguration will be linked with both the session tokens. At this time, it runs quickly. It calls the ISS "Promotion CP Admin Service.GetPromotionContraints" method, but does not call the "Promotion Definition Loader.QueryById" method any more.
The session timeout parameter is set to 3600 seconds and if we run the same WS again, in 30 or more minutes, the performance is going to be bad and is going to take 2 minutes again.

The EAI component is used with standard workflow process (WF) ConfiguratorWebChannelBeginConfigQuote. This is generating the request to Configurator Session Service.LoadInstance that needs to access the promotion constraints (standard WF ConfiguratorWebChannelBeginConfig).

During performance optimization, a Siebel log file analysis highlighted the behavior of the ISS Promotion CP Admin Service within the handling of cached promotions: Sometimes it calls the GetPromotionConstraints method and invokes the Promotion Definition Loader.QueryById method instead of accessing cached information. This will generate a long series of queries to retrieve promotion constraints from the database, impacting the performance.

Note that the Promotion Definition Loader uses EAI to query for promotion definitions and stores it in a C++ map. There are no parameters avaiable to set the number of promotions to cache or where to cache file/memory) etc.


=> Question:
How does the caching for Promotion Constraints work when using Product Configurator Web Service (WS), in an eConfigurator embedded in the Application Object Manager (AOM)?


Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms