RetrieveFromSession is used to retrieve already existing session variables from the user’s session. If this service is used to retrieve a variable which does not exis yet or existed in a previous session, the service will return the requested variable and will not throw an exception, but it’s value will be blank.
Storing information in session variables can be useful if you want a certain value to be accessed after a few pages, but won’t be carrying that information forward via query strings.
Session variables are special variables that exist only while the user's session with your application is active. Session variables are specific to each visitor to your site. They are used to store user-specific information that needs to be accessed by multiple pages in a web application. Unlike a cookie, the information is not stored on the users computer.
The default behavior is to store the session variables in the memory space of the Internet Information Services (IIS) worker process. If you are using this default in-memory session management, the session variables will be cleared when worker process recycles. IIS Worker Process Recycling is the process whereby IIS kills off the child processes that it spawns to handle incoming requests and starts clean copies of them. Over time, problems could arise in the processing (memory leaks in the application code, undisposed resources, etc.) that IIS wants to clean up without having to shutdown the server. So it will periodically tell the worker process to die off, and spawn a new one.
The user’s IIS session ends when the worker process is killed. This happens on the session timeout (timeout set in IIS on application pool) or when closing the browser. After this point the session variables saved previously will be lost. If you need the variables to be around for longer than this, consider using cookies.
RetrieveFromSession Use Examples
Basic Use Example
In this example we have a button process which first tries to retrieve our TestVariable. If it is not found, it adds it.
Here is a closer look at the input used in RetrieveFromSession:
When the page loaded, we clicked the button, and the logs showed this variable did not exist, so it returned blank.
Notice the service didn’t throw an exception, it returned the requested variable, but since it did not exist, the value was blank.
Since we set up our process to create the variable if it wasn’t found, the next time we click the button it should be found
We also set up our process to show a message on the webpage when the variable exists:
Now if we close the browser and try again, it again will not be found. The same will happen if we let the page sit long enough to reach the session timeout. Usually users see this as leaving the page open for a long time and when they return, they are required to log in again. This is because we keep track of the logged in user by their session variables.
Using RetrieveFromSession to Find CartId
In this example, the shopping cart id is saved as a session variable when the user logs in and every time they need a new cart. This way, anywhere on the site, when a new cart is requested, developers only need the RetrieveFromSession service.
When Calculating Tax in Cart
Here is one of the places that uses the session variable we just saved. When the tax amount is needed the GetTax process is called.
- It first checks if tax should be hidden for the site.
- Then it checks if this particular user should have tax hidden.
- After that, it checks if we are finding the tax for the cart or for an already placed order in JDE.
- If the tax needs to be calculated for the cart, it then checks if the CartTotal was passed in through the input. If not, it will need to be calculated.
- If we are going to calculate the CartTotal, we will need the CartId. Retrieve CartId with RetrieveFromSession service.
Here is a closer look at the service’s inputs:
In the Cart Overview Section and the Site Header
These sections give a summary of the items in your cart and the order you are able to place. One of the things they provide is the current cart subtotal. Here is the process that sets those values:
The first thing it does it Retrieve the cart id with RetrieveFromSession. With that it calculates the subtotal for the cart. Depending on whether there are any items in the cart it takes different action. For the site header that means displaying either “Cart” or “Cart ($[Subtotal])”.
When Reordering an Order From Order History
There is a Reorder process that is called from a couple of places. Each place that has a Reorder button calls this process.
The process starts by retrieving the current cart id from the session. It needs to do this because sometimes reorder should clear your existing cart. It might have to do this if the order you are trying to reorder has a different branch plant then your current cart and the site you are on limits your shopping cart to one branch plant. In this case, we can’t just clear your cart, because it might be an important cart.
There is another feature called saved carts, which allows you to save your cart and give it a nickname. When your current cart is saved as has a nickname, instead of clearing it, we should just set it aside for you to come back to later.
After retrieving your cart id, it then queries JDE for the order you want to reorder. At this point it does the comparison to see if they have different branch plants and whether or not they can be combined.
If your current cart does need to be cleared, it then checks if your current cart is saved. If it is, it will need to be set aside, while the user is assigned a new default cart. The order from JDE will then be duplicated in that default cart.