サーバー側では、LANSA のサーバー・モジュールにより、ビルトインのセッション管理機能が提供されています。
次の例では、セッション開始時、サーバー・モジュールのタイムアウトが 900 秒に定義されています。セッションのアクティビティがない状態が 15 分になると、セッションを必要とするサーバー・ルーチンを次に使用しようとするとた時、エラーになります。
サーバー・モジュールで最初に呼び出されたサーバー・ルーチンは、通常サインオンのようなルーチンで、セッションを開始させ、セッション内で使用される必要な値を設定します。
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
この Signin ルーチンには、黙示的な Session(*None) があり、ルーチンの実行にセッションが必要ないことを意味しています。ユーザー ID とパスワードはルーチンに渡され、有効であるという想定のもと、永続のフィールド (persitent) として、ソース内に定義された変数に格納されます。
検証が完了すると、StartSession メソッドを使ってセッションが作成されます。これは、EndSession を使っていつでも終了させることができます。
後続のルーチンにはすべて、Session(*Required) が付きます。セキュリティを強化するため、ユーザー ID を含めることも可能です。そして、これを永続のセッション・データと比較します。
SrvRoutine Name(DoSomething) Session(*Required)
Field_Map For(*Input) Field(#User)
If (#User = #SessionUser)
Endif
Endroutine
SrvRoutine が実行されると、必要なセッション・データがサーバーに渡され、タイムアウトに達していないかが確認されます。タイムアウトの場合、Visual LANSA で Failed イベントが起動され、ステートフルなクライアント側がこれに反応して、サイオン画面が再度表示されます。注- 「Web アプリケーションの期限が切れました」のメッセージが表示されないようにするために、実際はこの応答を処理する必要があります。
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
注：クラウドで実行時のタイムアウト・ポリシー負荷分散装置を使ってクラウドで実行する場合、自身のアプリケーション内の「スティッキー・ポリシー」のタイムアウトがどのセッション・タイムアウトよりも大きいことを確認することが重要です。
最大のセッション・タイムアウトが 900 秒であるとの前提で、スティッキー・ポリシー・タイムアウトの省略値は 930 秒になっています。最大セッション・タイムアウトがこれよりも大きい場合、負荷分散装置が次の要求を別のアプリ/Web サーバーに移動させる際にスティッキー・ポリシーの期限が切れてしまい、想定より早くタイムアウトするエラーが発生する可能性があります。逆に、負荷がより均等に分散されるよう、スティッキー・ポリシー・タイムアウトを出来る限り低く抑えるのがベストです。例えば、セッションの最大タイムアウトが 600 秒だった場合、負荷分散装置のスティッキー・タイムアウトを 630 に下げると良いでしょう。
