SBL-GEN-00003

pplies to:

Siebel CTI - Version: 7.5.3.11 [16199] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.11 [16199] DEU

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 2.8

Database Server OS: Sun Solaris 2.8



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

Symptoms

We get Errors when we connect to Siebel-CTI with the CTI Toolbar. Sometimes it works, but sometimes (ca. 10%) not.



GenericLog    GenericError    1    2006-03-01 08:49:52    (srbroute.cpp
52(6729) err=5700061 sys=0) Prozess CommSessionMgr auf Siebel Server
dab-cti01 beendet

GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp
2(2976) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel
Server (null) beendet

GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp
2(2630) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel
Server (null) beendet

GenericLog    GenericError    1    2006-03-01 08:49:52    (srmconn.cpp
2(2244) err=5700061 sys=0) SBL-SRB-00061: Prozess (null) auf Siebel
Server (null) beendet



I looked for the Task ID of the crashed Communications Session Managers
(Error code SBL-GEN-00003) in order to check out the Logfiles at the CTI
Server Machine, but there are no logfiles for the specified Task ID at
the CTI Server! Nor for this one Crashed Task, eihter for the other
crashed tasks.

Cause

Customer had set a higher value (greater than 1) to MaxMTServer and
MinMTServer parameters for the Communication Session Manager component.
They were encountering the behaviour where when the agent logs into the
Application with Communication Toolbar enabled, it would throw error.
This was intermittent. Customer was using the Aspect CTI Driver.

Solution

The Aspect driver can not handle more than one process. Expert Services
suggested the customer to set MaxMTServer = 1, MinMTServer =1 and
MaxTasks = 200. Once after re-setting these parameters on the
Communication Session Manager component, the error was resolved.

SBL-GEN-00002

Applies to:

Siebel System Software - Version: 7.5.2.100 [15252] to 8.1.1.1 SIA [21211] - Release: V7 to V8
Generic UNIX
Generic Linux

Product Release: V7 (Enterprise)

Version: 7.5.2.100 [15252]

Database: IBM DB2 8.1 FixPack 6b

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-GEN-00255, SBL-OSD-00220, SBL-OSD-02006, SBL-OSD-02011, SBL-OSD-00204, SBL-ADM-02049, SBL-GEN-00001, OSDmprotect

The Siebel Server was running fine until a few weeks ago. Now
we are unable to start the Siebel Server. The Siebel Gateway Name Server
is running fine.


When we start the Siebel Server by using start_server all command,
the main thread starts (siebsrvr) but when it spawns the child threads
(siebmtsh), they are not staying alive.


No Siebel multithreaded server processes are started after running
start_server all and no Application Object Manager log files are being
generated.


The SiebSrvr.log under siebsrvr/log directory may contain the following error:

    SBL-OSD-00220: Internal: pthread_mutex_trylock () failed with error. (22)


In some situations the following error may also be seen:


   OSDmprotect: mprotect(0xf7400000, 0, 0x00000001) failed with error 22



In addition to SBL-OSD-00220 error messages in SiebSrvr.log log
file, error messages like the following are being logged in the
Enterprise Server log file
(<enterprise_name>.<server_name>.log) under
$SIEBEL_ROOT/enterprises/<enterprise_name>/<server_name>/log
directory:

<NoCompName> 64527 SBL-GEN-00002 Process exited with error - Error code SBL-GEN-00002

Changes

 

Cause

A) This situation has been reported when the Unix machine has been
shutdown without having run the stop_server script. The stop_server
script should remove the
osdf.<enterprise_name>.<server_name> file that resides in
the $SIEBEL_ROOT/siebsrvr/sys directory.

B) This situation has
also been reported when the
svc.siebsrvr.<enterprise_name>:<server_name> was duplicated
under $SIEBEL_ROOT/siebsrvr/sys directory.

When you specify the
ALL argument, the start_server script searches for all files under
$SIEBEL_ROOT/siebsrvr/sys in the format svc.siebsrvr.* and parses it to
identify the Enterprise name and the Server name.
The first string after svc.siebsrvr. is the Enterprise name and the second one is the Server name.
The start_server script skips all filenames ended with the .bak extension, because they are considered backup files.
Then it starts the service and creates the OSDF file based on these parsed names.

Customer has three svc* files on his system:

- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.bak
- $SIEBEL_ROOT/siebsrvr/sys/svc.siebsrvr.<enterprise_name>:<server_name>.OLD1

The second file is considered as a backup file by start_server script.
However,
the other two files are used by start_server to start up the Siebel
Server, and both point to the same Enterprise and Server names.
Therefore, the start_server script is starting the same Siebel Server twice.

The
problem is that, when the second instance is started, the OSDF file is
overwritten, and the information used by Siebel about the memory
structures used by the first instance is lost. The second instance will
conflict with the first one, and the processes end up failing.

Solution

In order to fix this behavior and guarantee you have a clean environment, please do the following:

1. Shutdown the Siebel Server and run the following commands to clean all structures that may remain:

    % stop_server ALL
    % reset_server -e <enterprise_name> <server_name>
    % siebclean -f $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm -q
    % cleansync -f $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name> -d
    % siebctl -r $SIEBEL_ROOT -S siebsrvr -i <enterprise_name>:<server_name> -k -q
    % mwcleanup -silent 2>/dev/null

2. If using AIX, log into UNIX as root and run the following command:

    % /usr/sbin/slibclean

3.
Ensure no Siebel processes are running and check that there are no
semaphores or shared memory segments allocated for the UNIX user who
owns the Siebel Server installation:

    % ps -ef | grep <username>
    % ipcs -b

4.
If there are any processes, shared memory segments or semaphores stuck
in memory, they can be killed by using the following commands,
respectively:

    % kill -9 <process_ID>
    % ipcrm -m <shared_memory_segment_ID>
    % ipcrm -s <semaphore_ID>

5. Remove the following files if they still exist:

    $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name>
    $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm

6. Remove all svc* files or move all of them out from $SIEBEL_ROOT/siebsrvr/sys directory.

7. Recreate the correct svc* file:

 

For Siebel 8.0.x and earlier please use the comand: 

%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name>"

For Siebel 8.1.x and later please use the comand: 

%
siebctl -S siebsrvr -i "<enterprise_name>:<server_name>" -a
-g "-g <gateway_name> -e <enterprise_name> -s
<server_name> -u <sadmin_user>" -e <sadmin_password>

please note that the siebel server service needs user and password for gateway authentication starting with Siebel version 8.1

8. Restart the Siebel Server:

    % start_server all

Customers
should note that if there are still any processes, semaphores or shared
memory segments stuck in memory, the machine will need to be rebooted
before recreating the svc* file (between steps 6 and 7).


Customers should also note that recreating the svc* file (steps 6
and 7) is not necessary in all situations, and in most cases step 1 only
is sufficient to guarantee a clean startup.

KEYWORDS:
start_server all, failure to start Siebel on Unix server,  OSDmprotect,
err=1300220 sys=22 sys=0 SBL-GEN-00001 SBL-GEN-00002 SBL-GEN-00003
SBL-GEN-00004 SBL-GEN-00005 SBL-GEN-00006 SBL-GEN-00007
pthread_mutex_trylock AIX slibclean ipcrm

SBL-GEN-00001

Applies to:

Siebel System Software - Version: 7.7.1 [18306] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.1 [18306]

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 8

Database Server OS: Sun Solaris 8



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

Symptoms

Customer reported the following:
One of our Siebel Object Manager on our QA server failed and is not coming up
now. Along with the Object manager we have Assignment manager and EIM components running on this server.
All the other components apart from Object managers are running fine.
We have tried restarting
this server and complete environment after disabling and enabling the Siebel object manager for this server but it
failed to come up regardless.

siebmtsh and siebsvc processes are coming up after restarting , below
is the output of prstat cmd.

   PID USERNAME SIZE   RSS
STATE PRI NICE      TIME CPU PROCESS/NLWP
19742 siebel77 305M
191M sleep   58    0   0:00.22 0.0%
siebmtsh/10
19706 siebel77 226M 223M
sleep   58    0   0:00.13 0.0% siebsvc/6

19743 siebel77 146M   37M
sleep   59    0   0:00.00 0.0% siebmtsh/16

22158 siebel77 143M   26M
sleep   58    0   0:00.00 0.0% siebsess/4

19735 siebel77 131M   20M
sleep   59    0   0:00.00 0.0% siebmtsh/9

19736 siebel77 127M   18M
sleep   58    0   0:00.00 0.0% siebmtsh/8

19741 siebel77 124M   16M
sleep   58    0   0:00.00 0.0% siebproc/4

20981 root       71M   43M
sleep   29   10   0:00.00 0.0% vxsald/15
20698
root       64M   36M
sleep   29   10   0:00.03 0.0% vxsvc/21
3940
root       48M   27M
sleep   58    0   0:00.00 0.0%
java/22
   829
root       30M   28M
sleep   59    0   0:00.00 0.0%
dsmc/6
   916 pat340     16M   14M
sleep   28   10 12:03.05 0.1% PatrolAgent/4
21026
root       14M 4328K
sleep   28   10   0:00.00 0.0% vxsragt/4
13311
root       12M   11M
sleep   52    0 30:05.09 0.6%
PatrolAgent/1
    20 root       10M
8680K sleep   58    0   0:10.19 0.0%
vxconfigd/1
1442 pat340   9240K 6688K
sleep   29   10   0:44.27 0.0% dcm/1
5313
root     7800K 5528K
sleep   59    0   0:00.00 0.0% dsmc/4
1452
pat340   6888K 4872K
sleep   28   10   3:27.24 0.0% bgscollect/1
5277
root     6592K 4680K
sleep   58    0   0:00.11 0.0% mstragent/6

5275 root     6096K 4136K
sleep   59    0   0:00.06 0.0%
mstragent/4
   390 root ...

Solution

For the benefit of other readers:



After a restart of the Siebel Server the customer was unable to launch
any Siebel Application e.g. Siebel Sales (SSEObjMgr_enu). The
start_server.sh script would execute without error. On further
investigation it was found that no log files were created for the
SSEObjMgr_enu   component. The enterprise log file shows many processes
exiting on startup e.g.



ServerLog    ProcessExit    1    0    2006-01-06
02:48:16    SSEObjMgrRS_enu 35879     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001

ServerLog    ProcessExit    1    0    2006-01-06
02:48:16    SCCObjMgr_enu   35880     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001

ServerLog    ProcessCreate    1    0    2006-01-06 02:48:16    Created
multithreaded server process (OS pid = 835) for Communications Inbound
Processor with task id 35887

ServerLog    ProcessExit    1    0    2006-01-06
02:48:16    EAIObjMgr_enu   35881     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001

ServerLog    ProcessExit    1    0    2006-01-06
02:48:17    SSEObjMgr_enu   35876     SBL-GEN-00001   Process exited
with error - Error code SBL-GEN-00001



To troubleshoot the behavior the customer was asked to run truss on the server startup i.e.

truss -aefd -o truss-startup.txt start_server all



An examination of the truss output showed that there was a problem with
the Mainwin regss process (pid=1186) at startup. The truss output shows:





1186:   58.1163 open64("/app/siebel/siebel7/siebsrvr/mw/.mw/core_data//gpsapp115

/.mw/hklm_sunos5.bin.gpsapp115.1186_1", O_RDONLY) = 16

1186:   58.1165 fstat64(16, 0xFFBECF68)                         = 0

1186:   58.1166 fcntl(15, F_FREESP64, 0xFFBECEB8)               = 0

1186:   58.1168 read(16, " R E G 3\0\0\002\0\0\018".., 32768)   = 32768

1186:   58.1169 close(16)                                       = 0



The Mainwin registry file hklm_sunos5.bin.gpsapp115.1186_1 was
truncated, must like due to a disk space problem and only 32768 bytes of
the file were present. This in turn caused the regss process to exit.
The Mainwin daemons regss, watchdog and mwrpcss process must all be
running in order for the Siebel Server to startup without error.



The workaround was as follows:

     

1. cd $SIEBEL_ROOT/mw/.mw/core_data/<server-name>/.mw/ , where
<server-name> is the name of your siebel application server
instance.

2. Move all occurrences of files starting with prefix hklm_sunos5.bin to a backup directory



When the Siebel server is restarted the Mainwin processes also startup and a new registry file is created.

Applies to:

Siebel Financial Services CRM - Version: 7.8.2.14 SIA[19251] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Symptoms

A new siebel applications server environment version 7.8.2.14 was
setup. The application server was up and running, however after
enabling/disabling components for the specific servers and tried to
restart afterward it was noticed that the AOM are not starting up,
although the application server is up and running.



More in detail:

There are 3x application servers and 2 of those are load balanced for object manager components i.e. FinsObjMgr_enu.



These two servers are SS_PRD2 and SS_PRD3.

Application server SS_PRD2 is up and running.

Application server SS_PRD3 was also up and running, however after doing
some additional configuration in terms of enabling components, many
components fail to start after server startup.

Cause

Steps as per article Siebel Server threads fail when using
start_server all (Doc ID 524537.1) were already executed and this didn't
help to resolve the issue.

Likely cause is some corruption somewhere else.



Steps in article Siebel Server threads fail when using
start_server all (Doc ID 524537.1) should have helped to resolve the
issue. Because it didn't there could be corruption in mainwin part.

Solution

1> Open a new connection / session via telnet of ssh to the system

2> source the siebenv.sh environment variables by navigating to <SIEBEL_ROOT>/siebsrvr and execute:

. ./siebenv.sh

3> Stop the siebel server service and confirm with list_servers
command and ps -elf command to ensure all siebel related processes are
terminated.

4> navigated to the $MWHOME/bin directory

5> executed the "mwadm status" command and confirmed mainwin was not running

If they are running execute "mwadm stop"

and again executed the "mwadm status" command and confirmed mainwin was not running

8> rename the folder $MWHOME/.mw (please take attention to the "." in ".mw")

9> navigated to $MWHOME/bin directory

10> executed the "mwadm start" command

11> executed the "mwadm status" command and confirmed mainwin was successfully started.

12> start the siebel server using the command "start_server all"

References

NOTE:524537.1 - Siebel Server threads fail when using start_server all

NOTE:476830.1 - How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0

NOTE:473791.1 - What Are These Third Party MainWin MSC Server Processes: watchdog, regss and mwrpcss?

Applies to:

Siebel System Software - Version 7.7.2 SIA [18325] and later
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2 [18325] Com/Med

Database: Oracle 9.2.0.5

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: IBM AIX 5L 5.2



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

Symptoms

SBL-GEN-00001


Hi there,



We are having a major issue now in production one of the siebel servers
in the enterprise was mistakenly started up with other user and
afterwards it was recognized and the services were stopped and all the
cleansync procedures were followed on support web and started with
Siebel service owner user even then the server is starting up and few of
the component like eCommunciation_enu the one which is used is coming
unavailable. This server is so critical that we are having all workflow
process running on it and they interact with middleware. As we are not
having this system up all the business related activities such as
activations, sales order submission are getting impacted. Please kindly
get back to us as soon as possible.



Thanks & Regards,

Cause

Configuration/ Setup

Solution

Message 1

For benefit of other readers, customer encountered issues when
starting up Siebel server. The components would start and then
immediately stop.



Resolution



1) It was verified if mainwin processes namely regss, mwrpcss and watchdog were running or not. They were not running.



2) mTried to manually start the mainwin processes by issuing the following command:


mwadm start

It exited with error "Core services not started"



3) This confirmed that the Siebel components were going down with the
SBL-GEN-00001 error after the services were started as they were not
able to connect to mainwin.



4) Customer had mistakenly tried to start the siebel services earlier as
a non-siebel service owner account and after which start having
problems with this particular Siebel server. It was suspected that the
mainwin related files may not have got cleaned up properly as it was
attempted to startup siebel server as a incorrect user.



5) Navigate to $SIEBEL_SERVER/mw directory and rename the .mw directory underneath the mw directory.



6) Mmanually tried to start the mainwin processes by executing :



mwadm start



This time it started successfully and noted all the three mainwin processes running.



7) Sarted the siebel server and all the components came up successfully.

Applies to:

Siebel System Software - Version: 7.5.3 [16157] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3 [16157] ESN

Database: Oracle 9.2.0.4

Application Server OS: IBM AIX 5L 5.1

Database Server OS: IBM AIX 5L 5.1



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

Symptoms

SBL-GEN-00001We are upgrading from 7.0.4 to 7.5.3

We are running upgrep and there is an issue that
aborts the
process:

Trace   Trace   3       2004-06-17
04:37:09           Modifying
index                   S_SRC_GOAL_U1
...
SQLError       
Statement       0       2004-06-17
04:37:13     create unique index S_SRC_GOAL_U1 on S_SRC_GOAL
(SRC_ID,
GOAL_CD, CONFLICT_ID) parallel nologging
tablespace
SIEBELI
GenericLog      GenericError    1       2004-06-17
04:37:13     [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error
signaled in parallel
query server P000
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate
keys
found

Trace   Trace   3       2004-06-17
04:37:13    
HY000: [DataDirect][ODBC Oracle
driver][Oracle]ORA-12801: error signaled in parallel query server P000
ORA-01452: cannot
CREATE UNIQUE INDEX; duplicate keys
found

Trace   Trace   3       2004-06-17
04:37:13       Dropping index with the same column signature
and
retrying...
Trace   Trace   3       2004-06-17
04:37:13     create unique index S_SRC_GOAL_U1 on S_SRC_GOAL
(SRC_ID,
GOAL_CD, CONFLICT_ID) parallel nologging
tablespace
SIEBELI
Trace   Trace   3       2004-06-17
04:37:13    
;
Trace   Trace   3       2004-06-17
04:37:13     writeExecDDL error (pOperCallback
UTLDbDdlOperIndModify).
Trace   Trace   3       2004-06-17
04:37:15     Error in MainFunction
(UTLDbDdlDbMerge).
Trace   Trace   3       2004-06-17
04:37:15     Error in Main
function...
GenericLog      GenericError    1       2004-06-17
04:37:15     (logapi.cpp 13(167) err=1 sys=0) SBL-GEN-00001: (logapi.cpp
13: 167) error cod
e = 1, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4
= (null)

--------------

We understand that this is a problem due to Vanilla
repository definition were the sentence
create unique index S_SRC_GOAL_U1 on SIEBEL.S_SRC_GOAL
(SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging tablespace SIEBELI;

Cause

Change Request 12-MU33J

Solution

Description:

------------



During upgrade from 7.0.4 to 7.5.3, the following error causes upgrade to abort:





Trace   Trace   3       2004-06-17 04:37:09           Modifying index                   S_SRC_GOAL_U1 ...

SQLError        Statement       0       2004-06-17 04:37:13     create unique index S_SRC_GOAL_U1 on S_SRC_GOAL

(SRC_ID, GOAL_CD, CONFLICT_ID) parallel nologging

tablespace SIEBELI

GenericLog      GenericError    1       2004-06-17
04:37:13     [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error
signaled in parallel

query server P000

ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found



Trace   Trace   3       2004-06-17 04:37:13    

HY000: [DataDirect][ODBC Oracle driver][Oracle]ORA-12801: error signaled in parallel query server P000

ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found







Resolution:

----------



* In the version 7.0.4, the index S_SRC_GOAL_U1 indexes (SRC_ID, NAME,
CONFLICT_ID) while in version 7.5.3, the index S_SRC_GOAL_U1 indexes
(SRC_ID, GOAL_CD, CONFLICT_ID)



* In the version 7.5.3, this table is being used in a Standard installation by BC "Marketing Plan Goals"



* In the version 7.0.4 this table is NOT being used. So, in this case,
customer had customizations using this table. When customer upgraded,
this issue occurred because it is not expected that this table contain
rows.



* you have rows that differs only by the value of NAME column being
different (SRC_ID, NAME, CONFLICT_ID), which is fine for the unique key
in 7.0.4. During upgrade, the GOAL_CD is populated with null, and NAME
is not part of the unique key, and hence violating the unique key and
giving the errors that they saw.



After consulting internal resources, this is what you have to perform:



1) Prior to upgrade, the customer uses the Table Wizard in Tools to
create a new custom CX_ table (CX is the default prefix when using the
Table Wizard). Customer can name the table based on the data stored in
the old S_SRC_GOAL.



2) Prior to upgrade, the customer DBA manually renames the S_SRC_GOAL table to a temporary name (such as TEMP_SRC_GOAL)







3) Prior to upgrade, the customer DBA drops all indexes from the table S_SRC_GOAL.



4) Customer runs the Production upgrade (which recreates the S_SRC_GOAL table

and creates their new CX_ replacement table)



5) After the upgrade, the customer DBA runs a SQL statement to copy the rows from TEMP_SRC_GOAL to their CX_ replacement table



This way, you should not have issues on this table during the upgrade.
The objects that used the old S_SRC_GOAL will now use the new CX table.



Change Request 12-MU33J1 was logged to address this issue. Please, use the workaround above to perform the upgrade.



Thank you.

Applies to:

Siebel System Software - Version: 7.7.2 [18325] and later   [Release: V7 and later ]
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.2 [18325]

Database: IBM DB2 8.1 FixPack 8

Application Server OS: IBM AIX 5L 5.2

Database Server OS: IBM AIX 5L 5.2



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

Symptoms

SBL-GEN-00001We are unable to get our internal siebel server and custom object managers up and
running.    The gateway starts fine and our external servers start
fine.
We cannot login to internal urls, however we can login to external urls.

I have
attached a tar file of all our logs on the internal siebel server

This error is occurring
on our test system that mirrors production.

We have recycled our database and rebooted the
aix box that runs our gateway and internal siebel server.

Thanks

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



The /tmp filesystem had become full immediately prior to the behavior occurring.

This caused a corruption of the MainWin Registry, even though space was since freed up in /tmp.



Siebel 7.7 MainWin uses file
$MWHOME/.mw/core_data/<hostname>/.mw/hklm_<OS>.bin, instead
of the $SIEBEL_ROOT/mw/system/registry.bin file, that was used in Siebel
7.5.

If this file is removed, it is copied from $SIEBEL_ROOT/mw/system/hklm.bin.



The following steps resolved the behavior:



    - stop your Siebel Server

    - run siebenv.sh shell script from siebsrvr directory

    - go to $MWHOME/bin

    - execute “mwadm status” to confirm that MainWin is not running

    - run “ps -ef | grep regss”, “ps -ef | grep mwrpcss” and “ps -ef |
grep watchdog” to confirm that no MainWin-related processes are running

    - navigate to $MWHOME/.mw/core_data/p2st77gs/.mw directory and rename file hklm_<OS>.bin

    - go to $MWHOME/bin directory

    - run “mwadm start”

    - run “mwadm status” command to confirm that MainWin was successfully started

    - start your Siebel Server

Applies to:

Siebel System Software - Version: 7.7.2.2 SIA [18356] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2.2 [18356] ESN Engy/Oil

Database: Oracle 9i

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: HP-UX 11i



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

Symptoms

SBL-GEN-00001Hi support,

- We have Siebel 7.7.1 environment and we've tried to do an export of the
repository for all languages but an error has ocurred.

command line with parameter ALL:

D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p sadmin /d siebel /r "Siebel
Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w ALL

Two files attachments:
repimexp_7.7.1_ALL.log, repimexp_7.7.1_ALL2.log

- When we do the export for one language
(in this case ESN) procedure with Siebel 7.7.1 environment, it works fine.

command line
with parameter ESN:
D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p sadmin /d
siebel /r "Siebel Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w ESN

Two files
attachments: repimexp_7.7.1_ESN.log, repimexp_7.7.1_ESN2.log

- But the same sentence for
all languages with Siebel 7.7.2.2 environment works correctly:
One file attachments:
repimexp_7.7.2.2_ALL.log

Thanks

Cause

Change Request 12-18GQP3H

Solution

For benefit for other users, customer was trying to export repository
using repimexp.exe for all languages in Siebel 7.7.1 release.



To export ALL languages in the repository, following syntax can be used:



D:\Siebel\siebsrvr\BIN\repimexp /c SiebSrvr_NATI /u sadmin /p ***** /d
siebel /r "Siebel Repository" /f c:\rep_erm\SIENATI20050316.dat /a E /w
ALL



/w - parameter specifies to export either ALL or individual language such as ENU, FRA, ESN etc.



When customer tried to export ALL languages, following errors are encountered and reported in exprep.log file:



GenericLog    GenericError    1    0    2005-11-04 17:19:01    Unable to create process instance.

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Unable to start common api.

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Unable to start common api.

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Error in initiate function..

SQLDBUtilityLog    SQLDBUtilityLog    3    0    2005-11-04 17:19:01    Elapsed time: 3 sec.

GenericLog    GenericError    1    0    2005-11-04
17:19:01    (logapi.cpp (167) err=1 sys=126) SBL-GEN-00001: (logapi.cpp:
167) error code = 1, system error = 126, msg1 = (null), msg2 = (null),
msg3 = (null), msg4 = (null)







Change Request 12-18GQP3H is raised regarding export of repository for all languages does not work in 7.7.1 release.



The same syntax worked fine in Siebel 7.7.2 release. Also an individual
language can be exported in 7.7.1 successfully using /w parameter e.g.
/w FRA or /w ESN and so on.

Applies to:

Siebel CRM - Version: 8.1.1.3 SIA[21219] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

Repository migration fails when performing Repository Import. The imprep.log has below error:

2011-03-07
12:08:57 /app/sba_81/siebsrvr/bin/repimexp /a I /g ALL /u SIEBEL /p
***** /c SBA_81_DSN /d SIEBEL /r "SS Temp Siebel Repository" /f
/app/sba_81/dbsrvr/common/migrep.dat /l
/app/sba_81/siebsrvr/log/dev2prod/output/imprep.log /M y
2011-03-07 12:08:57
2011-03-07 12:08:57 Connecting to the database...
2011-03-07 12:09:00 Connected.
2011-03-07 12:09:00 Starting common api.
2011-03-07 12:09:00 SQLstyle is 'Oracle'

2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 SARM is OFF -change param SARMLevel to enable
2011-03-07 12:09:00 SARM Client is OFF -change param SARMClientLevel to enable
2011-03-07 12:09:00 Unable to verify login name SIEBEL.
2011-03-07 12:09:00 Unable to start common api.
2011-03-07 12:09:00 Unable to start common api.
2011-03-07 12:09:00 Error in initiate function..
2011-03-07 12:09:00 Elapsed time: 3 sec.
2011-03-07
12:09:00 (logapi.cpp (184) err=1 sys=0) SBL-GEN-00001: (logapi.cpp:
184) error code = 1, system error = 0, msg1 = (null), msg2 = (null),
msg3 = (null), msg4 = (null)

Cause

The cause is related to ODBC data source. Data Source Name for both source and target Database is the same:

[SBA_81_DSN]

QEWSD=40525

ColumnSizeAsCharacter=1

ColumnsAsChar=1

ArraySize=160000

ServerName=<source DB>

Driver=/app/sba_81/siebsrvr/lib/SEor823.so



[SBA_81_DSN]

QEWSD=40525

ColumnSizeAsCharacter=1

ColumnsAsChar=1

ArraySize=160000

ServerName=<target DB>

Driver=/app/sba_81/siebsrvr/lib/SEor823.so



This will cause the import to use the first data source connecting to the first server, <source DB>

Solution

Change the data source name for <target DB> to a different name and rerun the repository migration.

keywords: repository, import, dev2prod, migration, SBL-GEN-00001, Unable to verify, ODBC

SBL-GEN-00000 Unable to load message 0xffff

Applies to:

Siebel CRM - Version: 8.1.1 [21112] to 8.1.1 [21112] - Release: V8 to V8

Information in this document applies to any platform.

Symptoms

Customer reported the following:



In our new Siebel TEST environment, 2 Application Servers failing with Handshake failed error.



This is newly built Siebel environment, we have multiple servers



Ntsydasu304 - gateway and app server



Ntsydasu303 - App Server



Ntsydasu1186 - App Server



Ntsydwbu117 - Web Server







The Siebel gateway is up and running, all the application servers are started. But 2 application servers Ntsydasu304 and Ntsydasu1186 are failing with handshake Failed error

Cause

The issue seems to be caused by either port number being used by other non Siebel process, or the mapping between the hostname of the servers and the IP addresses. This analysis was based on the fact that when srvrmgr tried to communicate with the ServerMgr, it threw errors below:





- Handshake(siebel://ntsydasu1186:49162/es_obfstsb1/servermgr/ntsydasu1186) on conn 0x3121330 ok



- connect() to ntsydasu303:49168 failed (err=10060 | Connection timed out.



- connect() to ntsydasu304:49168 failed (err=10060 | Connection timed out.

Solution

For the benefit of other readers:



It was suggested to the customer to try the following:



telnet ntsydasu1186 49162

telnet ntsydasu303 49168

telnet ntsydasu304 49168



It is expected that the first one should be successful. If the 2nd and 3rd are also successful, please shutdown the Siebel servers and run the telnet again on the last 2 servers, to verify if other non Siebel process is listening on port 49168.



If the second and third fails or not responding, please try telnet the IP address. If successful, then there seems to be problem with the host-IP mapping, please verify.







By following the above steps, customer was able to identify the cause of the problem, They opened up all the required ports and the problem could be resolved.

Applies to:

Siebel Workflow - Version: 7.5.3.6 [16186] to 7.7.2.9 [18382] - Release: V7 to V7

HP-UX Itanium



Product Release: V7 (Enterprise)



Version: 7.5.3.6 [16186]



Database: Oracle 9.2.0.4



Application Server OS: HP-UX 11i



Database Server OS: HP-UX 11i







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

Symptoms

Customer was facing a problem with Workflow process manager in the development.  The application is rolled out in many countries. Each country will have a separate process manager. There are many scheduled workflows in the night by using a repeating batch components



Workflow process manager was failed in the development with the following error.

SiebelError: Unable to load message 0xffffSBL-GEN-00000' for one of the scheduled job.



we have changed the 'OM - Model Cache Maximum property' to zero and it was worked fine but performance of the process impacted significantly.



After that we have set the Cache property on the Business Services which are calling by the process to True and OM - Model Cache Maximum property to 10 on workflow process manager.

But the process was failed again with the following error

ObjMgrLog     Error     4     2005-02-09 13:12:34     SBL-GEN-00000 Unable to load message 0xffff ObjMgrLog     Error     4     2005-02-09 13:12:34     (SBL-EXL-00145) User cancel operation interrupted the running extension language script.

But the process is working fine with 'OM - Model Cache Maximum property' of workflow process manager with 0



Can you please suggest a way to resolve workflow process manager errors without impacting the performance?

Cause

The problem seems to be related the combination of having eScript in the Application_Start event of the application used by the WfProcMgr, SVB script in a buscomp instantiated in the BS.

Solution

For the benefit of other readers the following behavior was encountered.



The execution of workflow process, calling a business service, raises the error below, only at the first execution of the process (just after the restart of the Workflow Process Manager component,WfProcMgr) but not the next times.



SBL-GEN-00000 Unable to load message 0xffff





It does not seem related to the script itself, but just to the presence of the scripts. Here are for instance some steps conducted on top of standard repository that reproduced the problem.



1.    Application "Siebel Sales Enterprise" (used by the Workflow Process Manager component in standard), add following eScript script to Application_Start:

//test



2.    Buscomp "Account", add following Visual Basic script to BusComp_SetFieldValue

'test



3.    Compile SRF, deploy to server.

4.    Create a BS in the database (client), in eScript with following script, cache=True.

function Service_PreInvokeMethod (MethodName, Inputs, Outputs)

{

switch(MethodName)

{

case "Method1":

          fn_Method1(Inputs);

          return(CancelOperation);

   default:

          return(ContinueOperation);

    } 

}



function fn_Method1(Inputs)

{

var v_boBanner ;

var v_bcBanner ;



v_boBanner = TheApplication().GetBusObject("Account");

v_bcBanner = v_boBanner.GetBusComp("Account");



v_bcBanner = null;

v_boBanner = null;

}

5.    Create a new workflow process, Start > BS > End, that calls the BS created above. Activate the process.



Just after the restart of the component, the process fails with error SBL-GEN-00000 Unable to load message 0xffff when constructing buscomp "Account" in the BS script. Next executions work correctly.



Change request  BUG 10493326 was created to have this product defect addressed.  The issue was not seen beginning in version 7.8 of the application.



Here are few observations and possible workarounds.



a)    Setting the parameter ModelCacheMax to 0 seems to resolve the error but then the performance was very poor and it is not recommended.

b)    If the BS is defined in Tools (compiled in the SRF) rather than in the Client (stored in the database), the problem does not occur.

c)    In the above example, changing the script in Application_Start from eScript to SVB solved the problem.

d)    In the above case, changing the script in buscomp from SVB to eScript solved the problem.

References

BUG:10493326 - [CR#12-U0PRCS][FR#12-U0PRGK] MESSAGES �SBL-GEN-00000 UNABLE TO LOAD MESSAGE 0XF

Applies to:

Siebel System Software - Version: 7.7.2 SIA [18325] and later   [Release: V7 and later ]



Oracle Solaris on SPARC (64-bit)



Product Release: V7 (Enterprise)



Version: 7.7.2 [18325] Pub Sect



Database: Oracle 9.2.0.2



Application Server OS: Sun Solaris 9



Database Server OS: Sun Solaris 9







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

Symptoms

SBL-GEN-00000, SBL-UIF-00276

Hello,

We are currently running some performance load tests using Mercury's LoadRunner.

During our run, we have have 1 user being added every 25 seconds for a maximum of 50 users, which

run until completion. At around the 28 minute mark and 35 users have entered the system, Siebel

starts producing errors causing all subsequent users/transactions to fail. Attached is the error

log. Some of the errors that are produced include: "Communication: User is not associated with

any communication configuration in the database", "Unable to load message 0xffff", "Cannot open

file: /opt/siebel/SBLSRVENV14A/siebsrvr/webtempl/CCError.swt".

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users:







Customer was running a load test with Load Runner where the test scenario consisted of a user logging into the Siebel Application, calls a business service/workflow that makes an external call to outside system, and brings data back to be evaluated and used by the user. They had one user login every 25 seconds, and the following errors occured around the 30 user mark or about 25 minutes into the run.







[LOADTEST061] 686d688 Load Script from Attachment: Error: errCode=65535 errorMsg="Unable to load message 0xffff Parameter 1 = (SBL-GEN-00000)"







(parser.cpp (3522)) SBL-UIF-00276: Cannot open file: /opt/siebel/SBLSRVENV14A/siebsrvr/webtempl/CCError.swt







Technical Support on further research found that the SBL-UIF-00276 was occuring due to the fopen limit as per "'Alert 1025: Siebel Server Components That Read or Write to Files on Solaris May Encounter Fopen() Behaviors".







To resolve the behavior following workarounds were suggested:



The workaround is to :







1) Turn off all extra logging for this Siebel Object Manager component (default settings). This will reduce the number of log files opened and written by this component.







2) Decrease the number of tasks for each Siebel Object Manager process by increasing the number of MaxMTServers.







Customer adjusted the Min MT Server and Max MT Servers for the Object Manager component to resolve the behavior.

Applies to:

Siebel Tools - Version: 7.8.2.3 SIA [19221] to 8.1.1.2 - Release: V7 to V8

z*OBSOLETE: Microsoft Windows Server 2003



Product Release: V7 (Enterprise)



Version: 7.8.2.3 [19221] Life Sci



Database: Oracle 10.2.0.1



Application Server OS: Microsoft Windows 2003 Server SP1



Database Server OS: IBM AIX 5L 5.2







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







""Checked for Relevance on 20-Feb-2012""

Symptoms

Customer tried to add a MVG Applet to a field in Contact Home Add Virtual Form applet in Contacts Home Page view. When adding a text box, it does not display and only the MVG Icon is displayed.



If trying to click on the icon, the following occurs:



Unable to load message 0xffff(SBL-GEN-00000).

Cause

The customer had customized standard applet 'Contact Home Add Virtual Form Applet' by exposing a control based on the MVF 'Street Address' and that had a MVG applet associated.



In the UI they noticed there was no text box displayed for this control. Only the label and the MVF icon appeared. Also when the MVF icon was clicked the following error occurred:

- - -

Unable to load message 0xffff(SBL-GEN-00000)

- - -



This behavior is due to the fact it is currently not possible to used MVG applets in "Add" and "Search" screen home page applets. This matter is documented in the Bookshelf:



Configuring Siebel Business Applications > Configuring Screens and Views > Process for Creating Screen Home Page Views >Creating Rapid Search and Rapid Add Virtual Business Components.

- - -

...

CAUTION: MVGs are not supported on Rapid Search or Rapid Add applets.

...

- - -



Bug 10501236  has previously been logged asking for the possibility of using multi-value fields in Rapid Add applets. This matter is discussed in Note 534213.1 Hierarchial Picklist on homepage not working properly.

Solution

The customer wanted even so being able to select one address when adding contacts via the "Add" applet. It was suggested the following to achieve this requirement:







1 - Add 2 dummy fields in BC 'Contact Home Add Virtual', for example:



- - -



Name: Dummy Address Id



- - -



Name: Dummy Street Address



Pick List: MyPickList



- - -





'MyPickList' would be a pick list based on BC 'Pharma Address' and the 2nd field would have 2 pick maps:



- - -



Field: Dummy Street Address



Picklist Field: Street Address



- - -



Field: Dummy Address Id



Picklist Field: Id



- - -





2 - Add a control mapped to field 'Dummy Street Address' on applet 'Contact Home Add Virtual Form Applet' and expose it on the "Edit" applet web template. Set a pick applet based on BC 'Pharma Address' to this control.







3 - In the WebApplet_PreInvokeMethod event of applet 'Contact Home Add Virtual Form Applet' test if the method invoked is 'Mirror Add GotoView' and if yes set a specific dynamic user profile attribute (Method: SetProfileAttr) with the value of the BC field 'Dummy Address Id' and set the 2 dummy BC fields to NULL.







NOTE: "Mirror Add GotoView" is the method invoked by the "Add & Go" button.







4 - In the BusComp_PreWriteRecord event of BC 'Contact' test if the specific dynamic user profile attribute is set (Method: GetProfileAttr) and if yes, associate the address to the contact by using the address id stored in the profile attribute. For example:







(a) Instantiate the MVG BC associated to the MVF 'Street Address' of the active BC



> Method: GetMVGBusComp







(b) Instantiate the associate BC tied to this MVG BC



> Method: GetAssocBusComp







(c) Query the field 'Id' in the associate BC using the value stored in the local variable



> Methods: SetViewMode, ClearToQuery, SetSearchSpec, ExecuteQuery







(d) If a record is retrieved associate this one



> Methods: FirstRecord, Associate







(e) Set the 2 BC objects to null or nothing to destroy them







NOTE: Do not forget to reset the dynamic user profile attribute.







For further information about the programming possibilities and Siebel interface events and methods, please refer to the Bookshelf:







# Siebel Object Interfaces Reference



- Programming



- Interfaces Reference

Applies to:

Siebel Pharma Handheld - Version: 7.7.2.10 [18385] and later   [Release: V7 and later ]

Information in this document applies to any platform.

Symptoms

We are trying to synchronize our PDA in Companion Sync method against a local DB and a 7.7.2.10 SIA [18385] QF0A08 local client in a machine with a Vista O.S always unsuccesfully. The siebel application in the PDA is installed using a CAB 7.7.2.10 PDA [18385]. The synch process begins as expected:

- Login Complete

- Initialization Complete

- Configuration Updade Not Required

- Setting Filters complete

- Transaction Upload Complete

- No Transaction Errors Reported

And then, at the start of the Extracting Database phase, the following error typically appears:

- Server returned NOTOK. Fatal error etc.

After reviewing the log (attached), the following error appears 3 or 4 times:



(buscomp.cpp (25186)) SBL-GEN-00000: Unable to load message 0xffff



After searching at the metalink I find out a SR with the similar error on PDA synchronization. The solution provided is to set the EnableScripting cfg parameter to FALSE. I tried this solution and the synchronization works fine. The problem is that we use scripting in our application at synchronization level and we can't disable that cfg parameter.



Another important point to notice is that without uninstalling the PDA siebel application, using the same local DB and local client (7.7.2.10 SIA [18385] QF8) in a W2000 machine, the synchronization works absolutely fine with the EnableScripting parameter set to TRUE.



Our question is:



- Why the PDA synchronization is not possible in a Vista machine and it is on a W2000 machine on the same conditions?

Changes

This behavior is triggered through the introduction of scripting to any of the following methods :

PreGetFieldValue

ChangeRecord

PreQuery

Query

PreInvokeMethod

InvokeMethod

but only affects environments in which Siebel Handheld Clients are synchronizing with Siebel Mobile Clients (Companion Synchronization).

Cause

The behavior is caused by changes to the way in which Microsoft Vista handles COM initialization.

Solution

In order to resolve the behavior users have a number of options :

1) Set EnableScripting=FALSE on the appropriate .cfg file used for handheld synchronization (e.g. pharmace.cfg, cgce.cfg, etc)

2) Ensure that no scripting is included in the following events :

PreGetFieldValue

ChangeRecord

PreQuery

Query

PreInvokeMethod

InvokeMethod

3) Apply the fix for CR #10560131  "PDA Synchronization in a Vista OS machine failing".

Fixes have been included in the Siebel 7.7.2.12 FixPack and the Siebel 7.8.2.13 FixPack.

References

BUG:10560131 - [CR#12-1RVORD3][FR#12-1RVORDO] PDA SYNCHRONIZATION IN A VISTA OS MACHINE FAILING

How to Optimize Siebel Application Login Time

Recently, we've had a lot of users complaining about the homepage taking too long to load. Why does the login page take long to load? What happens when the login page loads. Below are some of the tasks that Siebel performs while loading the application.

- Verifying Application Schema Version
- Loading / validating State Models (checks whether or not the expiration date is greater than current date)
- Verifying State Model values for transition
- Loading / Validating Personalization rules and rule sets for each event on applets, Business Components, - - Business services and application
- Loading / validating user profile data.
- Loading / validating System preferences
- Loading localized data (Phone format, date format, time zone, currency etc)
- Loads user reporting hierarchy
- Loads application view-responsibility data.
- Message Broadcast (This can be inactivated by inactivating the Message broadcast bar)

The reason behind such a behavior is that some of the static data (localization, license keys etc) and SRF data that are common to all business components are initialized for the object manager process with the first task or user login request. It is this initialization of tasks that causes the delay in service to the first user.

Setting the “OM - PreLoad SRF Data” (PreloadSRF) parameter to TRUE will trigger the loading of this global data for the object manager process when it is initialized upon starting the services. Now the first login should be faster as the burden of reading the static data is pushed to the component startup phase.

NOTE:  After setting the parameter to TRUE, you must recycle the services for the parameter value to take effect.

If setting the parameter at the enterprise level, all the object managers in the environment will automatically inherit the parameter value (unless an administrator has specifically set the value on the lower object manager level).

Also, if this parameter is set to be TRUE in conjunction with the MinMTServers parameter, the static data will be loaded for the number of object manager processes specified for the MinMTServers parameter when the component is initialized. This way there will be no delay in service for a large volume of users since the minimum required multi threaded object manager processes would already be initialized.

M.O.S Reference:  Doc ID - 476878.1

Profile Hunter 1.0

Off lately i have been involved in the training and knowledge transfer sessions so delay in writing post. Trust me training is definitely not the best part of job. In one of the sessions i was asked a scorcher of question.

Is it possible to find all the places where we have used any profile attribute including tools and client side artifacts ?

This prompted me to learn some excel vb and i have come up with an alpha profile hunter tool which guns down profile attributes used in client side artifacts. This tool is available for you for download and trial. It is also available under Downloads link.It takes profile attribute you have specified and searches this attribute in below objects

Personalization Applet
Personalization Applet - Rule Set
Personalization View
Personalization - Rule Sets
Runtime Events - Objects
Runtime Events - Action Sets
DVM
DVM - Rule Set

A simple SWOT analysis will give you a better detail.

Strength
- It searches for given Profile attribute across all configurable client side artifact where we can use GetProfileAttr or SetProfileAttr methods.
- It gives results in the Output sheet which can be very useful in any support or maintanence project.
- It is easy to configure.
- It is flexible enough allowing user to select or deselect objects to be searched.
Weakness
- When searching across all objects watch out for performance.
- As it is based on Siebel mobile web client automation server it needs dedicated or mobile web client running in background.
Opportunities
- With ever increasing configuration and customization, this can be very handy tool for maintanence of project.
- Most of the time development is done by some team and support by other. In such scenarios this tool can be very helpful.
Threats
- Unattractive UI
- It doesn't search in siebel repository for profile attribute in this release.


Regarding search on the tool side there are already couple of options available including siebel repository search and awesome Oli has developed terrific repository analyser. I am also in process of enhancing this to make it search on tools side artifacts. As usual as it is in crude phase any input, suggestion and comment to improve are most welcome.

Happy Hunting!!

Disclaimer: It can be taxing on system to search on all objects, please do a dry run by selecting one or two objects to search in order to ensure it is working fine on your machine.

Confirm in Standard Interactivity

"Confirm" function in javascript is as powerful as batmobile which work as check for users prior setting or clicking mission critical values. It allows developer to seek user blessings if they want to perform particular operation or not.In ongoing series on Standard Interactivity, here we will discuss usage of "Confirm" and use the result to set/reset values in SI mode.

Problem Statement: In eService Portal, whenever user is changing status values, he/she should be prompted with confirmation message and based on Yes/No values should be set.
Solution: As in HI client it is cake walk solution to implement where one can use BS "PreSetFieldValue" event of BC. However with SI client under question things become different with architectural limitation. The solution is orchestrated using the DOM events available in SI application. Following piece of browser script code is written on onfocus and onchange events. The key here is to determine the sequene of events. onfocus happens before onchange event for Status column.

general declaration:
var preValue;

function Edit_SList__0__Column__Status__onfocus (applet, id)
{
preValue = document.getElementById(id).value; // Fetch current value of status
}

function Edit_SList__0__Column__Status__onchange (applet, id)
{
if(confirm("Are you sure you want to change Status"))
{
document.getElementById("WriteRecord").click();
}
else
{
   document.getElementById(id).value = preValue;
   document.getElementById("WriteRecord").click();
}
 }

This will set/reset the values of status column based on user consensus. A curious mind by now must be thinking can we have Confirm on button click also. Yes we can. My support(ID 745518.1) already have solution to that.

Happy Crunching!!