Qodly Studio for 4D による 4Dクライアントライセンス消費方法の改善

Qodly Studio for 4D を使い始めた方は、ビジネスWebアプリケーションの開発をするのにこの新しいツールがどれだけパワフルかすでにご存知でしょう。まだ使い始めていない方は、こちらをご覧ください。

Qodly Studio for 4D で作られたアプリケーションは、REST API に依存しています。4D 20 R5 には素晴らしい新機能が搭載されています: “強制ログイン” モードです。

強制ログインモードでは、ユーザーがログインに成功し、アプリケーションのデータやロジックを操作し始めた時のみ、4Dクライアントのライセンスが消費されます。

続きをお読みください！　デモのダウンロードもお忘れなく！

PIQS: 認証とセッション終了

強制ログインモードとは？

Qodly の Webフォームは HTML ではありません。実際、Qodly Studio for 4D はフォームを JSONファイルとして記述し、これがエンドユーザーの Webブラウザーで HTML としてレンダリングされます。

エンドユーザーの Webブラウザーで Qodlyフォームがレンダリングされるには、ブラウザーから RESTリクエストが送信され、サーバーからフォームの JSONがダウンロードされます。

フォーム上でのエンドユーザー操作は、サーバー上でデータを処理し、ORDAデータモデルクラスの関数を呼び出すための RESTリクエストをトリガーします。

4D 20 R5 以前では、他の RESTリクエストと同様に、サーバーはセッションのストレージと権限をホストする Webセッションを作成・維持し、同時に 4Dクライアントのライセンスを消費します。

その結果、Qodly Studio for 4D でシンプルな認証フォーム (ログイン＋パスワード入力) を実装した場合、エンドユーザーがこのフォームにアクセスするとすぐに (認証プロセスの開始前に) 4Dクライアントライセンスが消費されます。

消費された 4Dクライアントライセンスは、少なくとも 1時間の非アクティブタイムアウト (またはサーバーの再起動) の後、Webセッションが閉じられたときにのみ解放されます。このため、ユーザーがアプリケーションを使用するための 4Dクライアントライセンスが不足する可能性があります。

この問題を解決するため、4D 20 R5 では、REST API の使用にあたって、新しい “強制ログイン” モードを使用することができます。

このモードは、Qodly Studio for 4D アプリケーションに大きなメリットをもたらします。このモードは、4Dクライアントライセンスの消費をコントロールするのに役立ち、ユーザーがアプリケーションの使用を終了したときに、4Dクライアントライセンスを解放することができます。

要約すると

強制ログインモードでは、RESTサーバーが提供するデータやロジックをユーザーが使用し始めた時のみ、ライセンスが消費されます。これは、次のことを意味します:

ライセンス消費量の削減: ログインフォームでライセンスが消費されなくなります。
ユーザーエクスペリエンスの向上: 利用可能なライセンスの数に影響を与えることなく、ユーザーがログインを試みることができます。
リソース管理の向上: ユーザーがアプリケーションを終了すると、ライセンスは解放されます。

いつでも 4Dクライアントライセンスが解放できます

ログアウト標準アクションをトリガーするだけで、セッションを終了し、4Dクライアントライセンスを解放することができます。

これは重要な機能強化です。では、この機能からどのような恩恵を受けることができるのか、詳細を説明しましょう。

強制ログインモードを有効にする

強制ログインモードを有効にするのは簡単です。Roles and Privilegesセクションに移動し、有効化するだけです。

これにより、プロジェクトの roles.jsonファイルが更新されます。

{ "permissions": { "allowed": [ ] }, "privileges": [ ], "roles": [ ], "forceLogin": true }

動作の詳細

このモードが有効になると:

記述的な RESTリクエスト (つまり、rest/$catalog や Webフォームをレンダリングする rest/$getWebForm などのリクエスト) は、ライセンスを消費しません。
その他の RESTリクエスト (データを扱うリクエストや ORDAデータモデルクラスの関数を呼び出すリクエストなど) は、認証が完了するまで拒否されます。
DataStore クラスに、authentify() という名前の関数を実装する必要があります。この関数が認証を処理し、認証なしに受け入れられる唯一の記述的でない RESTリクエストです。

認証に成功すると、すべての RESTリクエストが受け入れられ、4Dクライアントライセンスが消費されます。

認証には、Session.setPrivileges() 関数を呼び出します。

以下はそのタイムラインです：

例題: 営業担当者用アプリケーション

この例題では、営業担当者が顧客ファイルを操作するためのアプリケーションを紹介します。

エンドユーザーは、All という初期値を持つエンティティセレクション型 (Customers データクラス) のデータソースを持つ Webフォームをレンダリングします。

認証がまだ成功していないため、このエラーが表示されます：

しかし、データを処理したりロード時に関数を呼び出したりしない単純な Webフォームであれば、エンドユーザーはレンダリングすることができます。このとき、4Dクライアントライセンスは消費されません。

エンドユーザーが Goボタンをクリックすると、authentify() 関数が呼び出されます。これはデータストアクラスに実装されています。

exposed Function authentify($credentials : Object) : Text
	
var $salesPersons : cs.SalesPersonsSelection
var $sp : cs.SalesPersonsEntity
	
$salesPersons:=ds.SalesPersons.query("identifier = :1"; $credentials.identifier)
$sp:=$salesPersons.first()
	
If ($sp#Null)
	If (Verify password hash($credentials.password; $sp.password))
		Session.clearPrivileges()
		Session.setPrivileges("")
		return "Authentication successful"
	Else 
		return "Wrong password"
	End if 
Else 
	return "Wrong user"
End if

この呼び出しは受け入れられます。

認証に失敗した場合、Session.setPrivileges() 関数は呼び出されません。したがって、ライセンスは消費されず、記述的でない RESTリクエストも拒否されたままです。

認証に成功すると、Session.setPrivileges() 関数が呼び出されます。4Dクライアントライセンスが消費され、あらゆる RESTリクエストが受け入れられるようになります。これで、データを操作することができます。

注記: この例では、Session.setPrivileges() 関数に空の文字列を渡し、ゲストとして認証しています。もちろん、認証したユーザーに対応する権限を設定することもできます。

さらに、前述のログアウト標準アクションのおかげで、エンドユーザーにログアウト機能を提供することができます。セッションの権限はクリアされ、エンドユーザーは “認証されていない状態” に戻ります。記述的な RESTリクエストのみが受け付けられ、データを扱うには再度認証しなければなりません。

まとめ

4D 20 R5 で実装された強制ログインモードにより、Qodly Studio for 4D Webアプリケーションにおける 4Dクライアントライセンス消費の最適化が可能になり、ユーザーエクスペリエンスとサーバーリソース管理が改善されます。この機能についてのご意見を 4Dフォーラムでお聞かせください！

Discuss

Tags 20 R5, ORDA, ORDA Data model classes, Qodly Studio, REST, REST server, Session, Web session