Siebel: Increase Tracing for Workflow Process Manager and Workflow Process Batch Manager

Workflows in Siebel can be run in the below ways:

• Server Component: Workflow Policy, Repeating component request, srvrmgr, submitting a task for the component, eScript (submitting request for the component), Runtime events (submitting request for the component). In all the above ways, the request for the Workflow process execution is done by the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.
• Application Object Manager:  Runtime event, Scripting and simulation in the Thin Client.
• Client: Runtime event, Scripting and simulation in the mobile web Client or the Dedicated Client.

Tracing on Server:

Increase the Log level for the below events for the Workflow Process Manager component (WfProcMgr) or the Workflow Process Batch Manager (WfProcBatchMgr) component.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes will take effect immediately and does not need a server bounce.The Workflow Process Batch Manager log file (WfProcBatchMgr_xxx.log) and the Workflow Process Manager log file (WfProcMgr_xxx.log) are located in the SIEBSRVR_ROOT\log directory.

Tracing on the Application Object Manager:

Increase the log level for the below for the Application Object Manager component like the Callcenter Object Manager.

Event Type	Log Level
Task Configuration	5
Object Manager SQL Log	5
Workflow Definition Loading	5
Workflow Engine Invoked	5
Workflow Process Execution	5
Workflow Step Execution	5
Object Manager Business Component Operation and SetErrorMsg Log	5
Object Manager Extension Language SetErrorMsg Log	5
Object Manager Business Service Operation and SetErrorMsg Log	5
SQL Tracing	5

The changes do not need a server bounce and the log for the application Object manager is generated at SIEBSRVR_ROOT\log directory.

Tracing on the Client:

Set the below environment variable and the siebel.log will be generated in <ClientRootDir>\log directory

SIEBEL_LOG_EVENTS = 5

Siebel: How to manage the size of Siebel Log Files

2 Siebel component parameters will help us in managing the size of the logs and also to restrict the amount of disk space that is used.

• LogSegmentSize

This parameter defines the size of each segment of the log file. If we give the value as 128, then each segment will be of 128 kilo bytes. A value of  '0' turns off segmenting.

• LogMaxSegments

This parameter defines the maximum number of  segments that are kept. when it reaches the maximum value, it overwrites the segments. A value of '0' turns off segmentation.

Configuring Log Segments on the Siebel Server

 Run the below commands from the server manager command line interface (SIEBEL_HOME\siebsrvr\BIN\srvrmgr.exe):

change param LogSegmentSize=<value> for comp <comp name>

change param LogMaxSegments=<value> for comp <comp name>

Restart the component for the changes to take effect.

Configuring Log Segments on Siebel Web Server Extension

We set the parameters "LogSegmentSize" and "LogMaxSegments" in the eapps.cfg file.

The eapps.cfg file is located in the SIEBEL_HOME\SWEApp\BIN directory.

Bounce the web server for the changes to take effect.

To set the parameters back to default, set them to '0'.

Siebel: How to Analyze FDR output in Siebel

FDR or Flight Data Recorder is a Siebel server framework which collects the data about the siebel application in a buffer and flusher the data into a binary file with .fdr extension in the event of a crash. The file is located in the /bin directory. This binary .fdr file can be processed into a readable csv file to help us analyze and understand the exact prior steps before the crash has happened.

Identifying the correct FDR file when a crash occurs

We can use the information in the file name of the .fdr file to identify the correct file.

The file name has the timestamp and the process id that crashed in the below format:

T<YYYYMMDDHHMM>_P<process id value>.fdr

for example:

T201503130749_P017144.fdr 

Is a file name that is based on a component that was started on March 13, 2015 at 7:49 AM where the process id value was 17144.

If we know the process id that has crashed, we can find the file by it or else we can look at the files at with the timestamp.

If we have the crash_***.txt , we can convert the hexa decimal process id found in the file to a decimal value and then find the correct fdr file.

Process Binary .fdr file to .csv file

• In UNIX environment, run the environment variables before running the sarmanalyzer.  run the below command from the $SIEBEL_ROOT/siebsrvr directory:
• . ./siebenv.sh
• Run the sarmanalyzer by issuing the below command:

                       sarmanalyzer -o <output_csv_file> -x -f <fdr_file>

                       For example:

                       sarmanalyzer -o T201503130749_P017144.csv -x -f T201503130749_P017144.fdr

 The output .csv file will be written to the SIEBSRVR_ROOT\bin directory.

Analyze output of fdr file

1. Open the csv file using microsoft excel and add custom filters to the top column as below
   
2. Filter the SubAreaDesc column by the value ** CRASHING THREAD **.
   
3. Note down the value in the "ThreadID" column. in this case it is 163. This is the crashing process Id.
   
4. Now, remove the filter for the "SubAreaDesc" column and filter the "ThreadID" column with the earlier noted down Process Id (pid) which is 163 in this case like below
   
5. Now navigate to the end of the document to reach the crashing thread and then we can see the steps that got executed just before the process crashed. you can get more details from SubAreaDesc, UserInt1, UserInt2, UserStr1, UserStr2 columns
   
6. The fdr output file created by sarmanalyzer.exe is not sorted in chronological order fro performance reasons. we can sort the csv file on the "FdrID" column to sort in reverse chronological order.
   

Siebel: Testing Siebel Inbound Web Service on a Mobile Web Client

Siebel Mobile Web Client can serve the same web services that are deployed on the Siebel server.
This helps developers in testing their Inbound Web Services without going through installing the whole Siebel enterprise.

The Web service functionality is an extension of the Siebel mobile web client and is processed by a second siebel.exe process. As soon as the siebel mobile client is started, this second siebel.exe process also starts and listens on a specific port which we define in the client's .cfg file. The child process exits once we logoff the mobile web client.






This setup supports authentication in URL format, SOAP headers, WS-Security headers.
It does not support Single sign-on,  stateful and stateless.

We need to add the below 2 parameters in the client's .cfg file to enable Web services on mobile web client.

• set the following parameters in the [siebel] section of the client's .cfg file:
• EnableWebServices = TRUE
• WebServicesPort = port number to lister (default is 2330)

After this, once the siebel mobile web client starts, you can see 2 siebel.exe processes, one if which will accept and process web service requests.

We can also start the siebel.exe process which will support the web services without starting the siebel mobile web client by running the below command:

• SIEBEL_CLIENT_ROOT\bin\siebel.exe /l <language_code> /c <configuration_file> /u <username> /p <password> /d <datasource_in_cfg> /webservice <port_number>

• for example:  C:\Siebel\8118\client1\bin\siebel.exe /l enu /c enu\uagent.cfg /u SADMIN /p SADMIN /d Sample /webservice 2330
• To stop the process, you have to manually end the process from Task manager.

You can use the netstat utility from the DOS prompt to determine if the siebel.exe process is listening to accept and process requests:

• From the DOS prompt, give the below command:
• netstat -a -p TCP
• examine the output for the port number and it should be "LISTENING"

Now, we can invoke Web services on the Siebel mobile web client by passing credentials in the URL, in the SOAP header, or in the WS-Security header.

Example of Passing User Credentials in the URL

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&Username=<username>&Password=<password>

For example:

http://localhost:2330?SWEExtSource=WebService&Username=<username>&Password=<password>

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header/>

  <soapenv:Body>

<asi:SiebelContactQueryById>

<PrimaryRowId>1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById >

  </soapenv:Body>

</soapenv:Envelope>

Example of Passing User Credentials in the SOAP Header

The URL format is:

http://<host>:<port>?SWEExtSource=WebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=WebService&WSSOAP=1

The following is an example of a request:

soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header>

<UsernameToken xmlns="http://siebel.com/webservices">SADMIN</UsernameToken>

<PasswordText xmlns="http://siebel.com/webservices">SADMIN</PasswordText>

<SessionType xmlns="http://siebel.com/webservices">None</SessionType>

  </soapenv:Header>

  <soapenv:Body>

<asi:SiebelContactQueryById >

<PrimaryRowId>1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById >

  </soapenv:Body>

</soapenv:Envelope>

Example of Passing User Credentials in the WS-Security Header

The URL format is:

http://<host>:<port>?SWEExtSource=SecureWebService&WSSOAP=1

For example:

http://localhost:2330?SWEExtSource=SecureWebService&WSSOAP=1

The following is an example of a request:

<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:asi="http://siebel.com/asi/">

  <soapenv:Header>

<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<wsse:UsernameToken xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">

<wsse:Username>SADMIN</wsse:Username>

<wsse:Password Type="wsse:PasswordText">SADMIN</wsse:Password>

</wsse:UsernameToken>

</wsse:Security>

  </soapenv:Header>

  <soapenv:Body>

<asi:SiebelContactQueryById soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<PrimaryRowId xsi:type="xsd:string">1-ABC</PrimaryRowId>

</asi:SiebelContactQueryById>

  </soapenv:Body>

</soapenv:Envelope>

Siebel: Server Request Processor (SRProc)

Server Request Processor (SRProc) component processes asynchronous server requests.
Asynchronous server requests are those requests from the originating component for another destination component, which the originating component doesn't wait for the request to be processed.
Once an asynchronous server request is generated, a record in inserted into S_SRM_REQUEST table.




SRProc component periodically checks the table for any eligible records to be processed based on the below 3 conditions:

• The request is in "Queued" state.
• The start time for the request has elapsed.
• The target siebel server is not specified while submitting the request or the component which can process the request is running on the specified siebel server.

If a server request satisfies all the above 3 conditions then the SRProc component forwards the request to SRBroker to run the request.

By default SRProc runs on all the siebel servers and asynchronous requests can be read by any SRProc component from any Siebel server as long as the target siebel server is not specified, in which case the SRProc on the specified siebel server has to process the asynchronous request.

Siebel: Server Request Broker (SRBroker)

The Server Request Broker (SRBroker) component routes and processes both synchronous and asynchronous server requests from the application object manager to a batch component or between 2 batch components.

• Synchronous server requests are those requests from the source component which waits till the request gets processed.
• asynchronous server requests are those requests from the source component which does not wait for the requests to get completed.

Any server requests that are originating from the Application Object manager always go to the SRBroker component which further routes the request to the appropriate server component for further processing.

SRBroker determines what to do with the request based on the below logic:

• If the destination component which can process the request from the application object manager is in the same Siebel server, then SRBroker routes the request to the component. If there are multiple instances of the same component enabled and running on the same siebel server, it routes the request on a Round robin fashion.
• If the destination component is not available on the same server where the request was originated from the application object manager, then SRBroker will route the request to SRBroker on another siebel server where the destination component is available. If the destination component is enabled and running on multiple other siebel servers, then SRBroker will route the request to SRBroker on another siebel server on a round robin fashion.
• If the destination component which is needed to process the originating request from the application object manager is not available in any of the servers, then the request will fail.

SRBroker performance tuning

MaxTasks, MaxMTServers and MinMTServers component parameters of the SRBroker component determine the performance of it.

MaxTasks by default is set to '100'

You can adjust the value of MaxTasks by using the below formula:

MaxTasks=number_of_batch_components_in_siebel_server + number_of_siebel_servers + 10 (buffer)

By default MaxMTServers and MinMTServers are set to '1'. Increasing the value will not have any performance improvement.

Siebel Connection Broker (SCBroker)

SCBroker is a background mode server componet which provides intra server load balancing by routing the incoming login requests to the MT processes of the application Object manager.
SCBroker serves the new login requests from the web server by listening to a static, configurable port 2321 which is set by the parameter "Static Port Number" (alias portnumber). once SCBroker receives request from the web server, it forwards the request to the processes in the application object manager running on the Siebel server.




SCBroker uses a connection forwarding algorithm to forward the requests to the processes depending on the value set in the hidden parameter "Connection Forward algorithm" (alias ConnForwardAlgorithm). This parameter has 2 possible values:

• LL (Least Load)
• RR (Round robin)

LL is the default value. This identifies the process which has the lowest number of tasks/threads running in the application object manager and assigns the request to the process. The RR algorithm distributes the request to the next process running in the application object manager in a round robin fashion.

LL is advisable interms of performance. Although LL is recommended it is sometimes necessary to change to RR to troubleshoot SCBroker Hangs where the least loaded Process (pid) has hanged.

In this case, SC Broker will try to repeatedly send new login requests from the web server to the least loaded MT server (pid), but the process has already hanged and we see a server busy message on the UI.

changing the parameter to "ConnForwardAlgorithm" to "RR"  has got the below advantages:

1. The hanging process(pid) will be contacted by the SCBroker only once and the next request is routes to another process. Thus the user gets error on UI only once until it comes back to the hanging thread again in round robin fashion.
2. By monitoring how the new tasks are getting created on the MT processes (pid), we can narrow down to the process (pid) that has hanged and further troubleshoot by taking userdump and pstack for the single process and then bounce it.

SCBroker forwarding mode is specific to each siebel server and thus we can have a mix of LL and RR setup in the siebel enterprise.

We need to bounce the component when we change the parameter. existing users are not affected by this bounce.

Note:  You can stop routing requests from the web server to a specific Siebel server by temporarily shutting down the SCBroker component.

Siebel: MaxTasks, MaxMTServers, MinMTServers

The values of these 3 Application Object Manager component parameters are set to guide the performance of the Application.
Setting the values of these 3 parameters determine how good the system behaves during user load.
These parameters control the capacity of each server and indirectly control the performance of the whole enterprise.


MaxTasks (Maximum Tasks): This Specifies the total number concurrent threads/tasks that can be run by the Application Object Manager (AOM). Beyond this limit, the AOM will not process any new requests or it will not create any new tasks/threads.

MaxMTServers (Maximum MT Servers): The AOM is a multithreaded process and this parameter specifies the maximum number of multithreaded processes that can concurrently run on this AOM.
After the threshold limit is reached, no more multithreaded processes are generated on the AOM.

MinMTServers (Minumum MT Servers): This parameter specifies the default number of multithreaded processes that are started on the AOM when the parent process is started.The parent AOM process can be started manually from server manager or automatically when the Siebel server starts. The AOM can be disabled by setting this parameter to '0'.
As more number of users start to login to the application, new MT processes are started to serve the additional tasks until the threshold of MaxMTServers is reached.

• Ideally both MaxMTServers and MinMTServers are set to the same value. Doing this will avoid the performance impact to the user, whose login creates a new MT Process. MaxMTServers value should be greater than or equal to MinMTServers.
• The ratio of MaxTasks/MaxMTServers defines the Maximum number of tasks each MT Process can handle.

Let us try to better understand with an example:

If MaxTasks = '300' and MaxMTServers = '3', then MaxTasks/MaxMTServers= 100. This means each MT Server can handle 100 tasks each on the AOM.
Ideally we set both MinMTServer and MaxMTServers to the same value. But let us assume the MinMTServers is set to '2'.
In this case:

• When the Application Object Manager is started, it starts 2 multithreaded processes which can serve 200 tasks/threads.
• As the number of users logging in rises but remain below 200, they are all processed by the 2 MT processes. The requests are distributed evenly between the 2 processes. This is Intra server load balancing which is done by the SC Broker.
• If the number of tasks/threads reach 200 and then a new user request is received, then Siebel starts a new MT process to serve the 201th request. Now, the AOM distributes the tasks among the 3 MT processes.
• If the AOM reaches 300 tasks/threads and a new request comes in, then the AOM cannot handle the request and is termed as "maxed out".

Formulas for calculating the parameter values

• MaxTasks = total_number_users + anon_users
• MaxMTServers = MaxTasks/100
• MinMTServers <= MaxMTServers

The value of 100 in the MaxMTServers formula is taken as a rule of thumb for the AOM.

For special OM's like the eCommunications OM and eProduct Configurator OM, the value is generally 20.

total_number_users is the total number of users the AOM will support.

anon_users is the number of anonymous browser users. HI applications does not support anon users.

for SI application, it would be around 25% of the total_number_users.

Siebel: SBL-DAT-00500: There were more rows than could be returned. Please refine your query to bring back fewer rows

This error can be frequently generated in Inbound Web Services using EAI Siebel Adapter or EAI UI Data Adapter Business Services.

This error occurs due to the setting of the "DSMaxFetchArraySize" subsystem parameter which controls the maximum number of records that can be retrieved from a Business Component in "ForwardBackward" cursor mode. It does not affect the maximum number of records retrieved when using "ForwardOnly" cursor mode.

By default the "DSMaxFetchArraySize" parameter is set to '0', which allows the Object manager to return a maximum of 10,000 records in "ForwardBackward" cursor mode.




The default cursor mode is "ForwardBackward" or Bidirectional.
"ForwardOnly" cursor mode is more efficient and should be used when we need to process large number of records.
"ForwardOnly" cursor mode does not restrict the number of records fetched in a query.

To implement the "ForwardOnly" cursor mode in EAI Siebel Adapter or EAI UI Data Adapter Business Services, we need to add the Argument "ExecutionMode" to the input Arguments.

Name:  ExecutionMode
Type: Literal
Value: ForwardOnly

Note:  ExecutionMode = ForwardOnly should not be used when changing the Primary of a MVG field like IsPrimaryMVG = "Y", which will result in a n error, because it cannot get back to the parent record to update the primary.

Also check for the "Maximum Cursor Size" property on the Business Component.
With this property set to some value greater than "0" and a Query is run on the BC either in Workflow or thru eScripting and a "NextRecord" Method reaches the last record in the cursor, it throws the same error.

Siebel: Capture SOAP XML Payload (Dump) for Siebel Inbound Web Services

We can create and capture the SOAP XML Payload or dump files for the Siebel Inbound Web Services by setting the component parameter "enableserviceargtracing" to "true" for the EAI Object Manager.

This parameter can be set to "true" from the server manager by issuing the below command:

srvrmgr> change param enableserviceargtracing=true for comp eaiobjmgr_enu

The log levels for the EAI Object Manager have to be increased in order to generate the dmp files.

Setting the LogLevel = 3 will write the input arguments when an error occurs.
Setting the LogLevel = 4 will write both the input and output arguments to a file.

The Log level can be increased from the server manager by executing the below command:

srvrmgr> change evtloglvl %=4 for comp eaiobjmgr_enu

Once these 2 are set, Siebel will generate eaiobjmgr_enu_*.log and *.dmp sharing the same number making easy for us to correlate.

It creates different types of dmp files:




1.) *Transport*.dmp:  this is generated by the Transport layer.
2.) InboundDispatcher_input*.dmp: This contains the SOAP request for the Inbound Web Service.
3.) InboundDispatcher_output*.dmp: This contains the SOAP response for the Inbound Web Service.
4.) EAISiebelAdapter_input*.dmp: This contains the Integration Object instance that is sent as input to the EAI Siebel Adapter Business Service.
5.) EAISiebelAdapter_input*.dmp:This contains the Integration Object instance that is returned as output from the EAI Siebel Adapter Business Service.

Testing with Dedicated Client

To capture the dmp files, add the below entry in the client's .cfg file

[EAISubsys]

EnableServiceArgTracing = TRUE

Also, add the below environment variables in the machine and start Siebel Client or tolls to start generating the logs and dmp files too.

SIEBEL_LOG_EVENTS=ALL

SIEBEL_LOG_DIR=<directory of your choice>

Siebel: "SetMinimalreturns" argument of the EAI Siebel Adapter Business Service

The "SetMinimalreturns" argument is available in all the methods of the EAI Siebel Adapter Business Service except for the Query and Query Page methods.

This argument when set to "true" suppresses the output of the EAI Siebel Adapter and there will not be any output. Output is generated only when there is an error.




It accepts only "true" or "false" values, and is useful to enhance the performance.

This parameter is overridden even when set to "true", when the "StatusObject" argument is set to "true"

Siebel: "ObjectLevelTransactions" Argument of the EAI Siebel Adapter Business Service

"ObjectLevelTransactions" Argument is available in all the methods of EAI Siebel Adapter Business Service except for the Query and Query Page methods.

By default, Siebel treats all Integration Object instances in the Siebel Message as a single transaction.
Assume an input Siebel Message has 10 records to be inserted into Siebel.
Siebel successfully inserts the first 6 records and an error occurs while inserting the 7th record.
Siebel will roll back all the 6 successfully records too.
It either successfully inserts all 10 records or none of them will gets processed.

By setting the "ObjectLevelTransactions" argument to "true", siebel will ignore the error out 7th record and it continues processing the 8th, 9th and 10th records.
Siebel treats each record as an individual transaction instead of treating the whole Siebel Message as a single transaction.




The output Siebel Message will contain the reason for the failed record.
The status of each record is recorded in the "ErrorCode" and "ErrorSymbol" Integration Component Fields of the root component in the Integration Object.

We need to process the output Siebel Message to identify and process the failed records/transactions.

1.) Create a Business Service or eScript to process the output Siebel Message from the EAI Siebel Adapter Business Service to traverse the message searching for error messages and process them as required.

2.)Write the output Siebel Message from the EAI Siebel Adapter Business service to an xml file.
You can use either "EAI XML Write to File"  Business Service with method "WriteXMLHier" or "XML Hierarchy Converter" Business Service with method "XMLHierToXMLDoc".
In both the Business Services, set the "EscapeName" argument to "false" to remove any invalid xml characters in the Integration Component Field names.

We cannot use "WriteEAIMsg" method of the "EAI XML Write to File" Business Service as it expects a Siebel Message and will not save the ErrorCodes and ErrorMessages from the output of the EAI Siebel Adapter Business Service.
To Summarize, we need to identify the output of the EAI Siebel Adapter as a generic XML message but not as a Siebel Message.

Siebel: Remove NULL Tags from Siebel Message using Data Maps

We can remove Null/Empty tags from the Siebel Message using Data Maps.
Any Integration Component Fields which are mapped to System Fields will be removed from the Siebel Message after the data map is executed.
We use the same to our advantage to remove Empty/NULL tags from the Siebel Message before processing.

Use the syntax below to map the Integration Component field to a system field if it has NULL values or else retain the value in a datamap.

Specify the below syntax in the Source Search Expression in the Integration Component Field map.

Example:

We want to remove the [Account Status] tag from the Siebel Message if it contains NULL values.
Then, we can put the below statement in the Source Search Specification.




IIF([Account Status] IS NULL, [Created By], [Account Status])

If, the [Account Status] field has Null Value, it will get mapped to [Created By] which is a system field and finally gets removed from the Siebel Message.

Note: Make sure the [Created By] field is Active in the Integration Object.

Siebel: Remove Empty XML Tags

We can use the "siebel_ws_param:RemoveEmptyTags" parameter to remove empty xml tags during web service calls.

The "RemoveEmptyTags" parameter can be used in 2 ways to remove the empty xml tags as below:



1.)Add the "RemoveEmptyTags" parameter to a property set in the input xml file.

Add the Highlighted text in bold to the parent <Propertyset> Tag as below.

<?xml version="1.0" encoding="UTF-8"?>

   <?Siebel-Property-Set EscapeNames="true"?>

        <PropertySet siebel_undws_undparam_clnRemoveEmptyTags="Y">

                <SiebelMessage>
                 ...
                  ...
               </SiebelMessage>

</PropertySet> 







2.)Add the "siebel_ws_param:RemoveEmptyTags" parameter to the workflow process to enable the workflow to automatically remove all the empty tags from the xml message.
This is achieved by adding the parameter as a Workflow process property and then using it as an input argument to the workflow step where we read the xml file.

In the workflow process, add a new process property:

Name = Remove Empty Tags
Data Type = String
In/Out = In


Add the below input argument to the workflow step which is sued to read the xml message:

Input Argument = siebel_ws_param:RemoveEmptyTags
Type = Process Property
Value = Y
Property Name = Remove Empty Tags

Siebel: Ignore User Key to create duplicate records with Integration Objects

User Key's are used to uniquely identify a record while you insert/update/delete records using Integration Objects.
We can ignore defining User Key's if w are using Query/Query Page operations.

The idea of ignoring user key's to create duplicate records could be misleading but we might have some requirements like below.

Example: Create a Service Request record in Siebel from an external application where the user submits the Error description in a form and hits submit.
No matter how many times the user puts the same description and hits submit, it should create multiple Service Requests in Siebel.

In other way, all Insert operations should never error out, but can create multiple duplicate records.




Solution:

Create an Integration Component User key with the Integration Component Field as "Id".
"Id" is a system field and the value will be generated by siebel irrespective of whatever value you send as input.
instead of sending "NULL" value to the "Id" Integration component field, we can map the Workflow Process Instance Id property to this "Id" field.

Now Siebel will always create records without erroring out.

Siebel: Field Dependency User Property

We can define dependency between Integration Component fields by using this User Property.
The EAI Siebel Adapter uses this User Property in defining the order in which the field values are Updated/Inserted.

For Example:

Let us assume we are trying to update Service Request records and would want to update "Status" field and then only update "Sub - Status" field.
i.e "Sub - Status" is dependent on "Status" Field.




In this case, we need to add the Integration Component Field User Property for the "Sub - Status" field.

Name:   FieldDependency
Value:   Status


Make sure not to get into cyclic dependency while defining the User Property on multiple fields, which will result in an error message.

Siebel: Create user in Sample Db

Creating User in Siebel through dbisqlc.exe in Sample dbf

1. Open dbisqlc.exe, then write and execute these below SQL statements

a) IF NOT EXISTS (SELECT NAME FROM SYSUSERS WHERE NAME= 'NEWUSER')execute sp_adduser NEWUSER

b) GRANT CONNECT To "NEWUSER" IDENTIFIED BY "NEWUSER"

c) sp_changegroup SSE_ROLE, NEWUSER




2. Enter in the Siebel application using userid/pwd SADMIN/SADMIN and create one employee "NEWUSER"

3. Give some responsibility to the employee "NEWUSER"

4. Give some position to this employee "NEWUSER".

5. Try to login using "NEWUSER/NEWUSER" to the sample db.

Siebel: Export System Fields in Integration Objects

In Siebel Integration Component Fields of Type = "System" are not exported to Propertyset or xml even if they are active.
This is the default behaviour of Siebel.




If we need to export the data of system fields, then change the Integration Component Field Type property value to 'Data' from 'System'.

Siebel: Create Siebel Anonymous Web Service

(1) Make sure the eapps.cfg entry for the OM you will use has the following entries:

UseAnonPool = TRUE
AnnonUserPool = <size of the pool>
You can use the [/eai_anon_enu] as it should already contain all the parameters required.

Make sure you have the parameters below set either on the eai_anon_enu section or on the [defaults] section of the eapps.cfg. If you set it on the eai_anon_enu section it will override the defaults section values.

AnonUserName = GUESTCST
AnonPassword = ********

The user set as AnnonUserName will be the one used for the web service. so if you want only the eai_anon_enu anonymous user to be different then you need to set it up on the eai_anon_enu section.




(2) You need to have a named subsystem with the following parameters:

AllowAnonymous = TRUE
Impersonate = FALSE
You can copy the WebService or SecureWebService named subsystems and give it a name like AnonWebService and set the above parameters.






(3) Locate the <Siebel Enterpise Server Home>/siebsrvr/bin/enu/<language>/eai.cfg file, open the eai.cfg file and review the [HTTP Services] section. Add the 'AnonWebService' service to the eai.cfg file as follows:

[HTTP Services]
....
WebService = WebService
SecureWebService = SecureWebService
....
AnonWebService = AnonWebService


(4) On your web service you need to change the address from for example:
http://MyWebServer/eai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&Username=EAIUSER&Password=EAIUSER
to

http://MyWebServer/eai_anon_enu/start.swe?SWEExtSource=AnonWebService&SweExtCmd=Execute

Note the change on the address to point to the eai_anon_enu (or the one you created) and change the SWEExtSource to point to AnonWebService (assuming this was the name you gave to the named subsystem).

Along with that, make sure the operations have the Authentication Type set to None.

After the changes are made, restart the Siebel Server, Gateway and web server so that all the changes take effect.

Siebel Web Service session management

Using sessions can improve the performance of the web service calls as the session is kept open for subsequent requests.There is no need to login and logoff for each request.

There are 4 different session types:

None: A new session is opened for each request and then closed after a response is sent out. This is the default.

Stateless: A new session is opened for an initial request and the session remains open for subsequent requests. Relogin occurs automatically (transparent to the user) if the session is closed.

Stateful: A new, dedicated session is opened for an initial request and the session remains open for subsequent requests. Relogin does not occur automatically if the session is closed.





To enable the session management you need to change the following:

1) Add "&WSSOAP=1" to the URL and remove the "UserName" and "Password" arguments from it as well as shown below:

Original URL:


http://mywebserver/eai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&UserName=SADMIN&Password=SADMIN

Changed URL:


http://mywebserver/eai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute&WSSOAP=1

2) Set the Web Service Port’s Operation’s Authentication to "None".

3) Add the Session Management and Authentication Header to the SOAP request.

This is the header where you will send the UserNameToken, PasswordText and SessionType or the SessionToken and SessionType.

The UserNameToken and PasswordText must be sent only when the SessionType is None or when you are creating a new session.

After opening a session, a SessionToken will be returned on Siebel’s successful response. This SessionToken must be used along with the SessionType on subsequent requests and the UserNameToken and PasswordText must be removed from the header.





Please check the below examples for different session types:

SessionType = None

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

    <soap:Header>

        <UsernameToken xmlns="http://siebel.com/webservices">EAIUSER</UsernameToken>

        <PasswordText xmlns="http://siebel.com/webservices">EAIUSER</PasswordText>

        <SessionType xmlns="http://siebel.com/webservices">None</SessionType>

    </soap:Header>

    <soap:Body>

        <!-- data goes here -->

    </soap:Body>

</soap:Envelope>

SessionType = Stateless OR Stateful

Initial Request:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

    <soap:Header>

        <UsernameToken xmlns="http://siebel.com/webservices">EAIUSER</UsernameToken>

        <PasswordText xmlns="http://siebel.com/webservices">EAIUSER</PasswordText>

        <SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType>

    </soap:Header>

    <soap:Body>

        <!-- data goes here -->

    </soap:Body>

</soap:Envelope>

Response:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

    <soap:Header>

        <siebel-header:SessionToken xmlns:siebel-header="http://siebel.com/webservices">ugvfdpiuhw345074gbjng945ht894nhjbn49258ut24tignwfn4985ht4ugn</siebel-header:SessionToken>

    </soap:Header>

    <soap:Body>

        <!-- data goes here -->

    </soap:Body>

</soap:Envelope>

Subsequent Request:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

    <soap:Header>

        <SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType>

        <SessionToken xmlns="http://siebel.com/webservices">ugvfdpiuhw345074gbjng945ht894nhjbn49258ut24tignwfn4985ht4ugn</SessionToken>

    </soap:Header>

    <soap:Body>

        <!-- data goes here -->

    </soap:Body>

</soap:Envelope>

Note 1: When using sessions, a SessionToken will be returned on every successful response from Siebel. This SessionToken will change after every request and the latest SessionToken must always be used on the next request.

 

Note 2: The SessionType used with the SessionToken must be the same as the request that opened the session otherwise it may lead to unextected results.

 

Note 3: The Session Management and Authentication Header is not the same as the WS-Security and cannot be used together.

There are three types of timeouts that affect the Web Service sessions:

* SessionTimeout (in seconds): The total number of minutes a session can remain inactive before the user is logged out and the session is closed.

* SessionTokenTimeout (in minutes): The Siebel Web Server Extension (SWSE) rejects the session token if the token is inactive for more than the SessionTokenTimeout value. Whenever the token is used, this value is refreshed.

* SessionTokenMaxAge (in minutes): The SessionTokenMaxAge parameter will make the SWSE reject the token if it has been used for more than the SessionTokenMaxAge value. This is different from the SessionTokenTimeout because it does not refresh every time the token is used.

It is advisable to set the values in the following manner:

SessionTimeout < or = SessionTokenTimeout < or = SessionTokenMaxAge

This is due to the following:

a) If the SessionTokenTimeout times out before the SessionTimeout, an error about the Token being timeout will be generated and a new session will need to be opened. However the old session will still be active so it will be wasting resources as the token that uses it will not be valid anymore. 

In certain situations it is possible that all tasks are opened due to the situation above and thus errors about no more sessions being available on the EAI Object Manager can happen.

When the SessionToken timeout has the same or a bigger value than the SessionTimeout, the above situation will not happen and while the SessionTokenTimeout is still valid, a relogin can occur (if Stateless SessionType is used) or a new session can be explicitly opened without wasting resources.

b) The SessionToken has a maximum time to live controlled by the SessionTokenMaxAge. If the SessionTokenTimeout is set to a bigger value than SessionTokenMaxAge, that token will be invalidated, even though it has not timed out yet.

Siebel: Setup Siebel to send the WS-Security header in Web Services

To generate the WS-Security header content for outbound web service calls, we need to add the below input arguments for the Proxy Business service.
This is possible from Siebel versions 7.7.x and above.

The below arguments are not displayed in the Proxy Business Service, but we can go ahead and add them in the Input Arguments when calling the BS.

Input Argument:  Username
Type:Literal
Value:<UserName>

Input Argument:  Password
Type:Literal
Value:<Password>




To use the WS-Security header, you need to change the Authentication Type column to "Username/Password - clear text".

Siebel will recognize the input arguments for the Proxy Business Service and it will automatically generate the header like below

<SOAP-ENV:Header>
    <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
        <wsse:UsernameToken>
            <wsse:Username>xxxxxx</wsse:Username>
            <wsse:Password>xxxxxx</wsse:Password>
        </wsse:UsernameToken>
    </wsse:Security>
</SOAP-ENV:Header>