本記事は、RESTサービスにおけるライセンス・ログインについて解説します。
はじめに
インターシステムズ社のライセンスポリシーに関して、コミュニティに大変興味深い記事があります。
興味のある方は、一度目を通してみて下さい。
インターシステムズ製品では、同時接続ライセンス数によってシステムの稼働が制御されます。そのため、適切なライセンス管理は安定運用を支える重要な要素といえるでしょう。
インターシステムズのライセンスログイン方式には、「自動ログイン」と「明示ログイン」の2種類があります。
これまでの「そうだWebアプリケーションを作ろう」シリーズでは、すべて自動ログイン方式を前提にサンプルを紹介してきました。
しかし、実運用やアプリケーション設計を考える上では、明示ログインについても理解する必要があります。
本記事では、「明示ログイン」に焦点を当てつつ、自動ログインとの違いを整理して解説します。
2つのログイン方式の特性を正しく把握することは、ライセンス消費の挙動を理解し、より適切なアプリケーション設計を行うための第一歩です。
それでは、それぞれのログイン方法の違いについて見ていきましょう。
明示ログイン
RESTサービスで明示ログインを行うには、「%session.Login()(%CSP.Session.Login())」を利用します。
Login(username As %String, password As %String = "", type As %Integer = 0, oldpassword As %String, apperr As %Status) as %Status【サンプルPG】
「%session.Login()」を記載する箇所は任意です。
アプリケーションの構成や設計方針に応じて、適切なタイミングで呼び出すことができます。
今回のサンプルでは、<Route>要素で指定している呼び出し関数「test」内に%session.Login()を記載しています。
Class developer.rest.Sample Extends %CSP.REST
{
// ～ パラメータとUrlMapは略 ～
ClassMethod test(id As %Integer = "") As %Status
{
s user = $g(%request.Data("user",1))
d %session.Login(user, "", 1)
s ret = {
"SessionId": (%session.SessionId),
"license" : (%session.LicenseId)
}
d ##class(%REST.Impl).%WriteResponse(ret)
q $$$OK
}
}画面からの送信データ「user」の名称を利用して、ライセンス・ログインを行っています。
ライセンス・ログインで使用する「username as %String」は、インスタンスに登録しているユーザ以外でもログイン可能です。
【動作確認】
下記URLをご使用のブラウザに入力して、ログインしたライセンスIDを確認してみましょう。
※ ログインするユーザの名称は「sampleTest」とします。
実行するとブラウザに下記が表示されます。
画面に表示された「license」は、「%session.LicenseId」から取得した値で、セッションに関連付いている名称になります。
無事、ライセンス・ログインができました！
明示ログインの動作を確認する
明示ログインを行うことで、ライセンスが１つに纏まっているか確認します。
■使用するURLは今回も同じものを利用します
検証結果
使用する検証環境は下記４環境で行います。
各環境で、セッションIDとライセンスIDを比較してみたいと思います。
■Google Chrome
■Google Chrome（別タブ）
■Microsoft Edge
■Microsoft Edge（別ウィンドウ）
どの環境でも「ライセンスIDが同じ値」となっているため、ライセンスが１つに纏まっている事が確認できます。
これはメリットともデメリットとも取れ、26接続を行うとライセンスがバラバラにカウントされ、一気に26ライセンス消費する事になります。
システムの性質と運用計画は、良くご検討下さい。
また、セッションIDは、ブラウザ毎に異なっている事も確認できます。
自動ログイン
前回の記事までは、自動ログインを行っていました。
そこで、自動ログインの挙動を確認してみましょう。
■使用するURLは今回も同じものを利用します
検証結果
今回の検証も、同じ４環境で行います。
■Google Chrome
■Google Chrome（別タブ）
■Microsoft Edge
■Microsoft Edge（別ウィンドウ）
結果を確認すると、ブラウザ毎にライセンスIDが纏まっている事が分ります。
今回の検証では、２ライセンス必用になる計算です。
これがアプリケーション的に、意図したライセンス消費であれば問題はありませんが、意図しない挙動であれば、明示ログインを検討した方が良いかもしれません。
セッションを終了する
リクエストが完了したら、セッションを終了しておきましょう。
セッションの終了は、「%session.EndSession」に「1」を設定します。
【サンプルPG】
「%session.EndSession」を記載する箇所は任意です。
アプリケーションの処理フローやライセンス管理方針に応じて、適切なタイミングで呼び出すことができます。
今回のサンプルでは、<Route>要素で指定している呼び出し関数「test」内に%session.EndSession=1を記載しています。
Class developer.rest.Sample Extends %CSP.REST
{
// ～ パラメータとUrlMapは略 ～
ClassMethod test(id As %Integer = "") As %Status
{
s user = $g(%request.Data("user",1))
d %session.Login(user, "", 1)
s ret = {
"SessionId": (%session.SessionId),
"license" : (%session.LicenseId)
}
d ##class(%REST.Impl).%WriteResponse(ret)
s %session.EndSession = 1
q $$$OK
}
}セッション終了を行うと、消費していたライセンスが解放されます。
明示ログインを使用する場合は、ログインだけでなくセッション終了処理までを一連の流れとして設計することが重要だと考えます。
また、ライセンスが開放されるタイミング等は、２つのログイン方法で異なります。
おわりに
いかがだったでしょうか。
本記事では、ObjectScriptを用いた「Webライセンスログインの仕組み」を、自動ログインと明示ログインの両面から検証しました。
それぞれの方式には特徴があり、アプリケーションの用途や運用ポリシーに応じて選択することが重要です。
ライセンスの消費を正しく把握し、意図した挙動を設計できれば、システムの安定運用につながるでしょう。
ぜひご自身の環境でも試して、最適なログイン方式を選んでみてください。
