Solved: What is the difference between context.session['he... - Page 2

anilsr · 11-07-2016 04:15 AM

I believe it's same & there is no difference. Is there any reason why there are two ways to do same ? Any difference between them ?

$$$REWARD$$$: If someone proves there is a difference, I will reward 50 Community Points from my own account. Any takers ?

Report Inappropriate Content

You should use context. {setVariable, getVariable }

context.session will probably be deprecated in future releases.

View solution in original post

omidt

I've used and relied on context.session before (quite a lot, actually) for what I believe to be valid use-cases.

As pointed out by Carlos, a major difference is variable types and, in the case of retrieval, how a non-existent variable will evaluate to null/undefined. In my opinion though, the fundamental difference is in what Mohammed started to share.

The scope covered by context.session versus context.[get|set]Variable() is completely different. Variables set to context.session are only available to the JavaScript policies executing in the flow and do not overlap with any of the standard variables available to the Edge runtime. In other words, neither of the following lines are valid.

context.session['request.verb']; // undefined
context.session.request.verb; // Cannot read property "verb" from undefined

There's no sharing across requests either; don't be fooled by the name "session" 🙂

Now, onto a use-case for when I have previously used context.session. Let's assume a simple proxy; with a callout for translations, some mediation/mash-up of the two responses and a final response back to the client.

Target request sent
Target response received

JS policy to modify the response:

var targetResponseObj = JSON.parse(context.getVariable('response.content'));
targetResponseObj.foo = 'awesome bar';

Now, we still need to make a callout and merge the two responses before responding to the client. Here are our options for the next step:
1. Serialise the modified object and set it as a runtime flow variable for later access where it will need to be parsed again:
```
var serialisedModifiedResponse = JSON.stringify(modifiedTargetResponse);
context.setVariable('flow.modifiedTargetResponse', serialisedModifiedResponse);
```
  or
2. Set the modified object to a JavaScript variable that can be picked up later, as an object. You skip serialising, the setting of the runtime flow variable and the parsing:
```
context.session.modifiedTargetResponse = modifiedTargetResponse;
```
Service callout request sent
Service callout response received

JS policy to merge the two responses. Again, the options:

Get the serialised modified target response from a variable, parse it, get the callout response, parse it, add the callout response and set the final client response:

var modifiedTargetResponse = JSON.parse(context.getVariable('flow.modifiedTargetResponse'));
var calloutResponse = JSON.parse(context.getVariable('calloutResponse.content');

modifiedTargetResponse.translated = calloutResponse;
context.setVariable('response.content', JSON.stringify(modifiedTargetResponse));

or

Get the callout response, parse it, add the modified response object and set the final client response

var calloutResponse = JSON.parse(context.getVariable('calloutResponse.content'));
context.session.modifiedTargetResponse.translated = calloutResponse;
context.setVariable('response.content', JSON.stringify(context.session.modifiedTargetResponse));

The point here isn't a comparison of the amount of code, but rather, the number of times data is parsed/serialised within your flow. With large responses, avoiding these additional steps can reduce the work MPs have to do and the footprint per request. This can make a difference at high levels of traffic.

Another use-case, more relevant to slightly larger proxies, would be to abstract common JavaScript function definitions to a single place.

// you could have a "set-functions" policy
context.session.functions.padLeft = function(str, len) {...};
context.session.functions.isNaN = function(n) {...};
context.session.functions.validateEmail = function(email) {...};

// and later use these from other JS policies
context.session.functions.padLeft('pad me', 10);

We now understand why getting and setting on context.session doesn't show in the trace tool. It's the same reason you don't see anything in the trace for if(){} -- it's just executing JavaScript internally.

cc: @Anil Sagar, @Peter Johnson

View solution in original post

What is the difference between context.session['hello'] = {} and context.setVaraible("hello", {})