18.2 Server Based Sessions
On the server-side, LANSA Server Modules provide a built-in session management feature.
In this example, when the session is started the server module is defined as having a timeout of 900 seconds. If there is no activity in the session for 15 minutes, the next attempt to use a server routine that requires a session will result in a failure.
The first server routine called in the Server Module will typically be some kind of sign on routine which initiates the session and sets any required values to be used within the session:
Begin_Com Role(*EXTENDS #PRIM_SRVM)
Persist Fields(#SessionUserID #SessionPassword)
SrvRoutine Name(Signin)
Field_Map For(*Input) Field(#User)
Field_Map For(*Input) Fields(#Password)
Field_Map For(*Output) Fields(#io$sts)
If (#Com_owner.VerifyUser( #User #Password ))
#Com_owner.StartSession Timeout(900)
#io$sts := OK
* Store Persistent Data
#SessionUserID := #User
#SessionPassword := #Password
Else
#io$sts := ER
Endif
Endroutine
SrvRoutine Name(DoSomething) Session(*Required)
Field_Map For(*Input) Field(#User)
If (#User = #SessionUser)
* process request
Endif
Endroutine
SrvRoutine Name(SignOut) Session(*required)
#com_owner.EndSession
Endroutine
The Signin routine has an implicit Session(*None) parameter meaning that no session is required to execute the routine. The User ID and Password are passed into the routine and assuming they're valid, are stored in variables that have been defined elsewhere in the source as persistent.
Once validation is complete, the StartSession method is used to create a session. It can be stopped at any point using EndSession.
All subsequent routines will have Session(*Required). For added security, they may require the User id to be included. This can be compared to the persistent session data.
SrvRoutine Name(DoSomething) Session(*Required)
Field_Map For(*Input) Field(#User)
If (#User = #SessionUser)
Endif
Endroutine
When a SrvRoutine is executed, the necessary session data is passed to the server and tested to ensure that the timeout hasn't been hit. If it has, the Failed event will be fired in Visual LANSA and the stateful client side can respond accordingly, perhaps showing the sign on screen again.
Note: You need to actually process this response to avoid Web Application has expired message.
Mthroutine Name(DoSomething) Session(*Required)
Define_Com Class(#SessionServices.DoSomething) Name(#DoSomething)
#DoSomething.ExecuteAsync( #User )
Evtroutine Handling(#DoSomething.Completed)
#MyApplication.ShowDetails
Endroutine
Evtroutine Handling(#DoSomething.Failed)
#MyApplication.ShowSignon
Endroutine
Endroutine
Note: Time out policy when running in the Cloud.
When running in the Cloud with a Load Balancer, it is important to ensure that the 'Stickiness Policy' timeout is greater than any Session timeouts in your application.
The default Stickiness Policy Timeout is 930 seconds which presumes that the maximum Session timeout is 900 seconds. If this is not the case, session timeout errors may occur earlier than expected if the Stickiness Policy expires when the load balancer directs the next request to a different App / Web Server. Conversely, it is best to keep the Stickiness Policy timeout as low as possible so that the load may be balanced more evenly, so if the maximum session timeout is, say, 600 seconds, then it would be good to lower the load balancer Stickiness Policy timeout to 630.