Difference between logontoken and serializedsession?

[first_last]

What is the conceptual difference between a logontoken and a serializedsession? Should I prefer one over the other?

ISessionMgr sessionMgr = CrystalEnterprise.GetSessionMgr();
IEnterpriseSession enterpriseSession = sessionMgr.Logon([userName], [password], [cmsName], [authentication]);

// create token
string token = enterpriseSession.LogonTokenMgr.DefaultToken
...
// use token to recreate new EnterpriseSession
IEnterpriseSession enterpriseSession = sessionMgr.LogonWithToken(token);

// create serialized session
string serializedSession = enterpriseSession.SerializedSession;

// use token to recreate new EnterpriseSession
IEnterpriseSession enterpriseSession = sessionMgr.getSession(serializedSession);

Does the LogonWithToken method hit the repository where the getSession method does not? Is one smaller (fewer bytes) than the other? Is one faster?

PS: is there a way to mark code inline, rather than using italics as I've done?

[TJe]

As it is the same user, would assume it doesn't consume another concurrent license.

[daniel_paulsen]

Logon is an expensive operation from a performance standpoint, so tokens that are shared with existing sessions are faster.

CreateLogonToken(numUses, numMinutes)

• This will create a token valid for the specified number of logons or expires after numMinutes, whichever comes first. It consumes a license whenever used, so an existing session can be logged off and the token can be used to start up the session again

CreateWCAToken()

• The WCAToken can be used and shared without consuming additional licenses. Once the session that created the token expires or is logged off, the token is invalidated and cannot be used elsewhere (ie opendoucment calls)

SerializedSession()

• the serializedsession behaves the same as a WCAToken.

Dan

[first_last]

Which type of token mechanism is used internally by the RESTful SDKs /logon/long method?

If I wanted to create a RESTful application that passes a token in the HTTP headers, like what the RESTful SDK is doing, which token mechanism would you suggest? Currently, I'm using the DefaultToken.

[daniel_paulsen]

If you want to use restful, then you must log on and create an X-SAP-LogonToken.

you can log on using

1. /logon/long (username and password)
2. /logon/token (token or serialized session created from Java or .Net SDK)
3. /logon/trusted (trusted authentication)
4. /logon/adsso (single sign-on)
5. /logon/saml/saml

With an X-SAP-LogonToken, regardless of how it was created, it is terminated when the originating session is logged off or timed out, but an additional license is not used if created from an existing session (/logon/trusted). In this aspect, it behaves like a WCAToken. If you use this token outside of RESTful, (ie openDocument) then it will consume a license, which is like a default token.

So in answer to your question, a RESTful token is sort of a combination of default and wca tokens. You will need to consider how you will be using restful and what will or can happen to the originating session when going from one SDK to another.