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セクションに移動し、有効化するだけです。

blank

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

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

動作の詳細

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

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

 

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

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

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

blank

 

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

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

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

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

blank

blank

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

 

blank

エンドユーザーが 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フォーラムでお聞かせください!

 

Avatar
- プロダクトオーナー - Marie-Sophie Landrieu-Yvertは、2017年にプロダクトオーナーとして4Dプロダクトチームに参加しました。プロダクトオーナーとして、彼女はユーザーストーリー(ユーザーが期待する新機能とその使用法)を書き、それを具体的な機能仕様に変換する役割を担っています。また彼女の役割は、実装された機能が顧客のニーズを満たしているかどうかを確認することでもあります。彼女は1995年にESIGELEC Engineering Schoolを卒業し、IBMでエンジニアとしてのキャリアをスタートさせました。様々なプロジェクト(保守や新規のプロジェクト)に参加し、Cobolのデベロッパーとして働きました。その後、UMLデザイナーおよびJavaデベロッパーとして勤務。最近は、機能要件の分析・記述、ビジネスチームと開発チームの調整などを主に担当しています。