My Oracle Support Banner

Siebel Returns The Same Exact SessionToken Value In Multiple Subsequent Response Output (Doc ID 2781942.1)

Last updated on JUNE 04, 2021

Applies to:

Siebel CRM - Version 17.0 [IP2017] to 21.5 [Release V17]
Information in this document applies to any platform.

Symptoms

Siebel SessionTokens are regenerated for each response, thus it should be a brand new/unique/different SessionToken value for each response returned.

Please refer to the following Siebel documentation:

 

However, it has been observed that on some occasions, the SessionToken value returned in a response is the same exact value as what was received in the request associated to that response.

For example:

• SessionToken value string 'abcdefg' was sent in for a soap request.

• The request was processed successfully and a response was returned.

• The soap response contains a SessionToken, however, it is the same exact value string 'abcdefg' as its original request.

• This is not expected. The correct result should be that the SessionToken value string should be different, it should not be the same string value as its request and it should also not be any string value that was issued before either.

 

Steps to reproduce the behavior:

1. Send 1st request with Stateless and username/password (U/P), get a TOKEN_01 back

Request:

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

Response:

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

Where TOKEN_01 is an actual SessionToken value string returned by Siebel in the soap response.


2. Send next request with Stateless and this TOKEN_01 in, get TOKEN_02 back

Request:

<SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType>
<siebel-header:SessionToken xmlns:siebel-header="http://siebel.com/webservices">TOKEN_01</siebel-header:SessionToken>

Response:

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

 

3. Send next request with Stateless and this TOKEN_02 in, get TOKEN_03 back

Request:

<SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType>
<siebel-header:SessionToken xmlns:siebel-header="http://siebel.com/webservices">TOKEN_02</siebel-header:SessionToken>

Response:

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


4. Send next request with Stateless and this TOKEN_03 in, get TOKEN_04 back

Request:

<SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType>
<siebel-header:SessionToken xmlns:siebel-header="http://siebel.com/webservices">TOKEN_03</siebel-header:SessionToken>

Response:

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

...
...
... so forth and eventually there will be an instance (or some as one continue to repeat the steps), where the SessionToken string returned is exactly the same string as what was passed in the request.

 

Here is an example from internal testing:

Request:

<SessionType xmlns="http://siebel.com/webservices">Stateless</SessionType>
<siebel-header:SessionToken xmlns:siebel-header="http://siebel.com/webservices">8YpImnUvH5vrh20n8OnZuIRVsjUmblvK3XRmwIEn*ctvjcAORMdPJDFdxdlirP*znbinBqJ33T476RvdtBoLXFsKEQj0E9QIi&apos;DL3Wcu6Ow0nlVx2Fpl1v7*kONzE5Ka8mqk3Et0ILeGxKx07GGRVSc9NfEd&apos;*4gSIVE&apos;ppfRW1f63C652UMrZ00F3tvceotPgi&apos;iXEXHNmrBzpGzUlpaBb3CcMTKtcPiGh1m5Ny8wZdVKMD4j718*rNwrLYTPHOyL84t7DwjhoAVihOA0r7Gvz*XVKNFmI6oAn87tjvFUOVjb4x39D4Rp2HQok9jjoHcDHKJAdqPC0WsQFEIetfbLbDCgL9SVe1mDTB9xTbuTY9gb&apos;XSMSLxyMzqMbJFzMhf8evFejC3n6c052vrLMPoA!!</siebel-header:SessionToken>

Response:

<siebel-header:SessionToken xmlns:siebel-header="http://siebel.com/webservices">8YpImnUvH5vrh20n8OnZuIRVsjUmblvK3XRmwIEn*ctvjcAORMdPJDFdxdlirP*znbinBqJ33T476RvdtBoLXFsKEQj0E9QIi&apos;DL3Wcu6Ow0nlVx2Fpl1v7*kONzE5Ka8mqk3Et0ILeGxKx07GGRVSc9NfEd&apos;*4gSIVE&apos;ppfRW1f63C652UMrZ00F3tvceotPgi&apos;iXEXHNmrBzpGzUlpaBb3CcMTKtcPiGh1m5Ny8wZdVKMD4j718*rNwrLYTPHOyL84t7DwjhoAVihOA0r7Gvz*XVKNFmI6oAn87tjvFUOVjb4x39D4Rp2HQok9jjoHcDHKJAdqPC0WsQFEIetfbLbDCgL9SVe1mDTB9xTbuTY9gb&apos;XSMSLxyMzqMbJFzMhf8evFejC3n6c052vrLMPoA!!</siebel-header:SessionToken>

 

The logs show:

• All request ran in the same EAIObjMgr_enu_0012_12582935.log task

• It returned 3 responses with SessionToken values, as can be seen in these dmp files:

InboundDispatcher_output_args_12582935.dmp - response from the 1st request with Username/Password to open the EAI session:

8YpImnUvH5vrh20n8OnZuIRVsjUmblvK3XRmwIEn*ctvjcAORMdPJDFdxdlirP*znbinBqJ33T476RvdtBoLXFsKEQj0E9QIi&apos;DL3Wcu6Ow0nlVx2Fpl1v7*kONzE5Ka8mqk3Et0ILeGxKx07GGRVSc9NfEd&apos;*4gSIVE&apos;ppfRW1f63C652UMrZ00F3tvceotPgi&apos;iXEXHNmrBzpGzUlpaCAicQ1X&apos;c1ZdosGLtiwPQPtmsNCE*tI6BoZTio4eehLSG0jYhCEYit4l2DQKETfu*1hAIhWDchQ0cfQosGH*O*hoQwhk6H2JTqVekKQCDNtOkbDqkK5Fd7CHiPWDVUcqhz9jeI8Fjm&apos;LjnwKaC6sZa9NhtDG7NX3c8mvXU0cbfNazhk&apos;6adMJLdWiFGMkpDNw!!


InboundDispatcher_output_args_12582935(001).dmp
- response from the 2nd request where the above SessionToken was passed in (this one is fine)

8YpImnUvH5vrh20n8OnZuIRVsjUmblvK3XRmwIEn*ctvjcAORMdPJDFdxdlirP*znbinBqJ33T476RvdtBoLXFsKEQj0E9QIi&apos;DL3Wcu6Ow0nlVx2Fpl1v7*kONzE5Ka8mqk3Et0ILeGxKx07GGRVSc9NfEd&apos;*4gSIVE&apos;ppfRW1f63C652UMrZ00F3tvceotPgi&apos;iXEXHNmrBzpGzUlpaBb3CcMTKtcPiGh1m5Ny8wZdVKMD4j718*rNwrLYTPHOyL84t7DwjhoAVihOA0r7Gvz*XVKNFmI6oAn87tjvFUOVjb4x39D4Rp2HQok9jjoHcDHKJAdqPC0WsQFEIetfbLbDCgL9SVe1mDTB9xTbuTY9gb&apos;XSMSLxyMzqMbJFzMhf8evFejC3n6c052vrLMPoA!!


InboundDispatcher_output_args_12582935(002).dmp
- response from the 3rd request where the above SessionToken was passed in (this one returned the same string for the SessionToken in the output as what was passed in the input):

8YpImnUvH5vrh20n8OnZuIRVsjUmblvK3XRmwIEn*ctvjcAORMdPJDFdxdlirP*znbinBqJ33T476RvdtBoLXFsKEQj0E9QIi&apos;DL3Wcu6Ow0nlVx2Fpl1v7*kONzE5Ka8mqk3Et0ILeGxKx07GGRVSc9NfEd&apos;*4gSIVE&apos;ppfRW1f63C652UMrZ00F3tvceotPgi&apos;iXEXHNmrBzpGzUlpaBb3CcMTKtcPiGh1m5Ny8wZdVKMD4j718*rNwrLYTPHOyL84t7DwjhoAVihOA0r7Gvz*XVKNFmI6oAn87tjvFUOVjb4x39D4Rp2HQok9jjoHcDHKJAdqPC0WsQFEIetfbLbDCgL9SVe1mDTB9xTbuTY9gb&apos;XSMSLxyMzqMbJFzMhf8evFejC3n6c052vrLMPoA!!


Notice here, the same token received for processing from the input(002) is returned as the token in the output(002)

This means the same SessionToken was returned for 2 different request at different times and the output from 002 has same token as what was sent in its input.

Changes

 

Cause

To view full details, sign in with your My Oracle Support account.

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


In this Document
Symptoms
Changes
Cause
Solution
References

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.