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.

[TJe]

One of the major differences is the open session behavior:

• with a token: this will open another user session for the user
• with serialized session: this will work in the same user session, no additional session is opened

[first_last]

If it opens a new session, does it automatically close the other? Does this tend to consume concurrent licenses?

[DellSC]

When you log on with a token, you can set the number of logons and the amount of time a token a valid for. A serialized session is just a serialized version of the session - it is only good for the current logon and for the default amount of inactive time.

I have used tokens in a number of situations, most recently with a web site that had a micro services back end. Within the application, a user could access multiple reports during a session. For each report, there could potentially be multiple service calls - for example, one to get the parameters that are valid in the report, and another to get the full OpenDocument URL for the report, including the user selected parameter values. The token gets passed back to the service with every call and with many of the calls, the user is logged off just before the info is sent back to the GUI. This helps prevent memory issues in the back end because it doesn't have various serialized sessions sitting around in its processes. With the token, I can log the user back in with the same token without having to get another session. This way the token is tracked and stored in the front end as well.

-Dell

[first_last]

I've used the token for similar usage-cases.

But I started to wonder if a serialized session might be more efficient. Can the .Net client assembly create the EnterpriseSession instance w/o a trip to the server? Does the LogonWithToken require a trip to the server? Which is faster? I'll trade a little more memory usage in my web or powershell app for faster transactions.

Also, it's great having a discussion w/ someone with similar experiences. +1

[DellSC]

Thinking about this a little more, one of the reasons I use the token is because the code for logging in is in the back-end, but the token is stored in the front end. In this case, if you create a new session for the next user, how do you know whether it has overwritten the one that was created by the SessionManager for the previous user? Because the back end is not in the context as the front end when the back end is a service, I think you might have issues with the session timing out. Of course, I may be wrong - I mostly write back end utilities where this is not an issue and I sometimes have a hard time grokking the flow of what's valid where in a web application.

-Dell

[TJe]

I'm using token or serialized session in my code:

public static enum TOKEN_TYPE {
	token, serializedSession
}

private void logon(String sessionToken, TOKEN_TYPE tokenType) throws Exception {
// Sends the logon request
Request request = new Request();
request.send(getBIP_RWS() + "/logon/token", "GET", null, false);
if (tokenType == TOKEN_TYPE.serializedSession) sessionToken = StringEscapeUtils.escapeXml(sessionToken);

// Sets logon information
Map<String, String> map = new HashMap<String, String>();
map.put("//attr[@name='tokenType']", tokenType.toString());
map.put("//attr[@name='logonToken']", sessionToken);

String filledLogonResponse = request.getResponseContent().replaceFirst("<attr name=\"logonToken\" type=\"string\"></attr>", "<attr name=\"logonToken\" type=\"string\">" + sessionToken + "</attr>");

// must specify the correct token type
filledLogonResponse = filledLogonResponse.replaceFirst(">token</attr>", ">" + tokenType.toString() + "</attr>");

// Posts logon information
request.send(getBIP_RWS() + "/logon/token", "POST", filledLogonResponse, false);
logonToken = request.getResponseHeaders().get("X-SAP-LogonToken").get(0);