Applies to:Siebel eConfigurator - Version: 188.8.131.52 SIA 
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 184.108.40.206  ESN Com/Med
Database: Oracle 9i
Application Server OS: Microsoft Windows 2000 Advanced Server SP 2
Database Server OS: Microsoft Windows 2000 Advanced Server SP 2
This document was previously published as Siebel SR 38-1494798497.
I'm working with Product Scripting within the Product Configurator.
My trouble is the following:
I want to set the value of a given attribute within a specific product, using the method "SetAttribute". And the product whose attribute value is being set relays on a relationship with cardinality 999, therefore, in order to identify the right instance whose attribute will be set, I'm using the Product Name syntax "ProductName; AttributeName=Value".
It's like the following:
SetAttribute("$.[Root]#1.[TargetRel]#[TargetProduct; SomeAttr=0]", "SomeAttr", NewAttrValue );
This way, I'm replacing the value of "SomeAttr" with "NewAttrValue" instead of "0", which is the default value of the attribute on the class to which "TargetProduct" belongs. The trouble is that this is not working as I'm having the following error:
ObjMgrLog Error 4 2004-09-09 11:10:16 (SBL-CFG-00108) Invalid path: .[TargetRel]#[TargetProduct; SomeAttr=0]
Please correct the error and try again.
If I omit the attribute on the object path (like "$.[Root]#1.[TargetRel]#[TargetProduct]") it works fine (does not signal any error), but it updates always the first instance of "TargetProduct" within the relationship "TargetRel", and I want to update exaclty one of that instances that not necesarily is the first one.
Could you please tell me what is wrong with the syntax I'm using? Why it is not working as expected?
--- Symptoms ---
For the benefit of other users,
The syntax for product path is completely described Product Administration Guide > Customizable Product Scripts > About Product Path.
Currently there is no possibility to achieve your goal via the Product Path. You cannot address specific instances or check attribute values. We created change request #12-PHFIRQ as a future enhancement for this requirement. With later Siebel 8 versions you are able to use integration id's in the product path.
Regarding the usage of attribute values in product paths:
"Product Administration Guide > Configurator Scripts> About Product Names in Configurator Scripts" allows following syntax:
ProductName; VendorName; VendorLocation}; AttributeName1=Value1; AttributeName2=Value2; ...
This is implemented with later Siebel 8 versions but is a documentation defect for Siebel 7.8. Change request #12-1Y28A47 was created to correct this in bookshelf.
One approach is to have only one instance of a product in each relationship. This only works if the quantity is low; otherwise it would require a large number of relationships. The UI could be modified to hide the additional relationships so the user experience would be simplified, but this would require a significant level of customization.
Siebel Technical Support
Keywords: product path, configuration, product configurator, relationship, cardinality, instance, attribute
Applies to:Siebel CRM - Version: 7.5.2  to 7.8  - Release: V7 to V7
Sun Solaris SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 220.127.116.11 
Database: Oracle 18.104.22.168
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8
This document was previously published as Siebel SR 38-3155380661.
SymptomsSBL-CFG-00108, SBL-GEN-00000, SBL-OSD-02006, SBL-OSD-02011, SBL-OSD-00205, SBL-OSD-00204, SBL-SVR-04000, SBL-SVR-00106, SBL-SMI-00114, SBL-SMI-00049, SBL-SMI-00034, SBL-SMI-00057, SBL-SMI-00101, SBL-NET-01033, SBL-NET-01201, SBL-NET-01204, SBL-GEN-05009, SBL-ADM-01042, SBL-SCB-00005, SBL-SCB-00013, SBL-SSM-00004, SBL-SSM-00003
We have been experiencing frequent situations when users are unable to log into the application.
We have recently applied Fix Pack 22.214.171.124 on top of Siebel 126.96.36.199.
CauseMemory segment used by Mainwin was defined too small.
Message 1For the benefit of other readers:
Customer uses Resonate and Netegrity Siteminder for Web Single Sign-On.
Users are getting Server Busy Error when trying to log into Sales and eChannel Applications, but only for ENU locale.
Currently logged users are working fine, and users are able to successfully log into applications for other locales, such as FRA.
If the system is rebooted, everything comes up again and users can log in normally.
This behavior is being reproduced every day, during peak hours.
We have reviewed Siebel Web Server Extension log files, and found several occurrences of SISNAPI Hello handshake timing out:
Hello handshake to (...) timed out in 60 secs
SBL-NET-01033: The SISNAPI handshake timed out, the Siebel Service may not be running
After 11 retries, the following is being logged by SWSE:
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
Open(..., 60, 3600) = [NULL, 2100101]
Open Session failed (0x6ce5) after 711.2367 seconds.
OpenSession Timing: 711.23671 seconds
New anon session open failed.
Could not get an anon session...PROBLEM
after the timeout/broken anonymous connection impersonate failed. Login failed attempting to connect to %1
Set Error Response (User: Session: Error: 00027877 Message: Login failed attempting to connect to...)
Login failed. SBL-SMI-00101: The server is busy, please try again later.
No Application Object Manager log files are being generated for those failing connections.
We noticed that all Siebel Servers contain many 5 MB core dump files.
According to pstack and pmap outputs, the complete Call Stack of the processes that crashed is always the following:
libkernel32.so sys_setup (be395d50, be392d4c, 0, be395cf4, 0, be3a65a0) + 498
libkernel32.so MwKernel32Init (3, be39aa60, be39aa5c, be39aab0, b9ca0, ffbef147) + 4b8
libgdiuser32.so MwMainwinInit (1, be73f6f0, 2, 3, a89b4, ffbeea80) + 298
siebmtshmw mainwin_init (0, 0, 0, 0, 0, 51e40) + 8c
libkernel32.so MwInitDLL (be744980, be722478, 0, be78cabc, be392d4c, bdfeae98) + 20
libgdiuser32.so void _Initializergdiuser_33_32::pre_construct() (be73f6f0, bdfeaf74, 15688, 20, 13984, be7448e0) + 44
libgdiuser32.so _init (0, bfbde7a8, bfbde0c4, bfbde7a8, 31fcc, bfbb00ac) + 48
ld.so.1 call_init (0, 0, bfbde270, bfbde7a8, 200000, bdc000a8) + 198
ld.so.1 setup (bfbde0d0, bfbde190, bfbde7a8, bfbe0f20, 0, bfbde0c4) + 13a8
ld.so.1 _setup (7, b00, ffffffff, ffffffff, bfba0000, ffbef070) + 3e8
ld.so.1 _rt_boot (0, 0, 0, 0, 0, 0) + 88
???????? (0, 0, 0, 0, 0, 0)
Error messages related to the crashes were logged in the Enterprise Server log file:
Created server process (OS pid = 12098) for Siebel Server Scheduler with task id 15255
<NoCompName> 15255 SBL-OSD-02011 Process exited with error - Process exited because of a segment violation (SIGSEGV)
This means that a Server Component needed to start a new process in order to handle more tasks, but the process startup failed during Main Win Initialization.
This caused the Component to crash.
The log file does not show us the Component name, but if this was an Object Manager, new users would be unable to login, while current sessions would not be affected.
A new Multithreaded Server Process is started for an Object Manager whenever the process currently running reaches the MaxTasks/MaxMTServers ratio.
This happens only for Components with a certain amount of concurrent user sessions.
That could explain why this behavior affects only some specific Object Managers (probably the ones with higher demand for user sessions).
It also explains the timeout error messages we found in the Siebel Web Server Extension log files.
There are some known situations that could cause this behavior to happen, as described in the following document:
Document 478173.1 : MainWin Crashes Causes Component Restart Failure on UNIX
Customer checked all possible causes mentioned in Alert 1174, but everything seems fine.
This was determined as being caused by a memory segment used by Mainwin which was defined too small.
The resolution is to set $MW_GMA_SEGSIZE environment variable in siebmtshw shell script.
We suggest to add the following to $SIEBEL_ROOT/bin/siebmtshw, above the “exec siebmtshmw $@” line:
Then, restart the Siebel Server for this change to take effect.
For further details, please refer to the following document:
Document Doc ID 503016.1 : Memory allocation failure brings system down
Setting MW_GMA_SEGSIZE environment variable to 0x1000000 avoided reoccurrences of the crash.
Post a Comment