メインコンテンツまでスキップ
バージョン: 21 BETA

クライアント/サーバー管理

組み込みクライアント/サーバーアプリケーションまたはリモートプロジェクトの形で、4Dデスクトップアプリケーションをクライアント/サーバー構成で運用することができます。

  • 組み込みクライアント/サーバーアプリケーションアプリケーションビルダー を使って生成します。 これらは、アプリケーションの運用に使います。

  • リモートプロジェクト とは、4D Server 上で開いた .4DProject ファイルのことで、リモートモードの 4D を使って接続します。 4D Server は、プロジェクトの 圧縮形式 である .4dz ファイルをリモートの 4D に送信します。つまり、ストラクチャーファイルは読み取り専用です。 この構成は通常、アプリケーションのテストに使います。

ただし、4D Server と同じマシン から接続している場合には、プロジェクトファイルの変更が可能です。 この 特殊機能 により、クライアント/サーバーアプリケーションを運用時と同じコンテキストで開発することができます。

組み込みクライアント/サーバーアプリケーションを開く

ビルドされたクライアント/サーバーアプリケーションは起動や接続処理が簡易です:

  • サーバーを起動するには、サーバーアプリケーションをダブルクリックします。 プロジェクトファイルを選択する必要はありません。
  • クライアントを起動するにも、同様にクライアントアプリケーションをダブルクリックします。すると、サーバーアプリケーションへの接続が直接おこなわれるため、

詳細については アプリケーションビルド ページを参照ください。

リモートプロジェクトを開く

4D Server 上で動いているプロジェクトに初めて接続する場合は、通常は標準の接続ダイアログを使います。 以降は、最近使用したプロジェクトを開く メニューや、4DLink ショートカットファイルを使って直接接続できるようになります。

4D Server で実行されているプロジェクトに接続するには:

  1. 次のいずれかの方法をおこないます:
    • Welcome ウィザードにて 4D Serverに接続 を選択します。
    • ファイル メニューより **開く > リモートプロジェクト...**を選択するか、開く ツールバーボタンより同様に選択します。

4D Server に接続するためのダイアログが表示されます。 ダイアログには 最近使用利用可、および カスタム という、3つのタブがあります。

リモートの 4D と同じサブネットワークに 4D Server が接続されている場合は 利用可 タブを選択します。 4D Server には組み込みのブロードキャストシステムがあり、デフォルトで、ネットワーク上に利用可能な 4D Server データベースの名前を公開します。 このリストは、名前が見つかった順に表示され、動的に更新されます。

このリストからサーバーに接続するには、名前上でダブルクリックするか、名前を選択して OK ボタンをクリックします。

公開されているプロジェクトが 利用可 タブに見つからない場合には、カスタム タブを開きます。 カスタムページでは、IPアドレスでネットワーク上のサーバーを指定し、それに任意の名前をつけられます。

  • プロジェクト名: 4D Server プロジェクトのローカル名を指定できます。 この名前は 最近使用 ページでプロジェクトを参照する際に使用されます。
  • ネットワークアドレス: 4D Server が起動されたマシンの IPアドレスを指定します。
    • 2つのサーバーが同じマシン上で同時に起動されているときは、IPアドレスの後にコロンとポート番号を続けます。例: 192.168.92.104:19820
    • デフォルトで、4D Server の公開ポートは 19813 です。 この番号は、プロジェクト設定で変更できます。

開発モードを有効化する オプションは、特別な読み取り/書き込みモードでリモート接続を開きます (互換性オプション)。このモードでは、リモート4D からプロジェクトフォルダーへのアクセスが確保されている必要があります。

このページでサーバーを指定したら、OK ボタンをクリックしてサーバーに接続できます。

サーバーとの接続が確立されると、そのリモートプロジェクトは 最近使用 タブのリストに加えられます。

サーバー上のプロジェクトファイルの更新

インタープリターモードの場合、4D Server は .4DProject プロジェクトファイル (非圧縮) の .4dz ファイルを自動的に作成し、リモートマシンに送信します。

  • プロジェクトが編集され 4D Server にリロードされた場合など、必要に応じてプロジェクトの .4dzファイルは自動的に更新されます。 プロジェクトは次の場合にリロードされます:
    • 4D Server アプリケーションウィンドウが OS の最前面に来たり、同じマシン上の 4D アプリケーションが編集を保存した場合 (後述参照) に自動でリロードされます。
    • RELOAD PROJECT コマンドが実行されたときにリロードされます。 プロジェクトの新しいバージョンをソース管理システムよりプルしたときなどに、このコマンドを呼び出す必要があります。

リモートマシンのプロジェクトファイルの更新

4D Server 上で .4dz ファイルの更新版が生成された場合、その更新版を利用するには、接続中のリモート 4D マシンは一度ログアウトし、4D Server に再接続する必要があります。

4D と 4D Server の同じマシン上での使用

同じマシン上で 4D が 4D Server に接続すると、アプリケーションはシングルユーザーモードの 4D のようにふるまい、デザイン環境にてプロジェクトファイルの編集が可能です。 この機能により、クライアント/サーバーアプリケーションを運用時と同じコンテキストで開発することができます。

同じマシン上で 4D Server に 4D を接続する場合には、 開発モードを有効化 オプションの設定にかかわらず 開発モード が自動的に有効化されます。

デザイン環境にて 4D が すべてを保存 アクションを (ファイル メニューを使って明示的に、または、アプリケーションモードへの移行により暗示的に) おこなうと、4D Server は同期的にプロジェクトファイルをリロードします。 4D Server によるプロジェクトファイルのリロードが完了するのを待って、4D は続行します。

ただし、標準のプロジェクトアーキテクチャー とは次のふるまいにおいて異なりますので、注意が必要です:

  • 4D が使用する userPreferences.{username} フォルダーは、4D Server が使用するプロジェクトフォルダー内のものと同一ではありません。 この専用の "userPreferences" フォルダーはプロジェクトシステムフォルダー内 (つまり、.4dzプロジェクトを開く場合と同じ場所) に格納されます。
  • 4D が使用する DerivedData フォルダーは、4D Server が使用するプロジェクトフォルダー内のものと同一ではありません。 この専用の "DerivedDataRemote" フォルダーはプロジェクトのシステムフォルダー内に格納されます。
  • catalog.4DCatalog ファイルは 4D ではなく 4D Server によって編集されます。 catalog の情報はクライアント/サーバーリクエストによって同期されます。
  • directory.json ファイルは 4D ではなく 4D Server によって編集されます。 directory の情報はクライアント/サーバーリクエストによって同期されます。
  • 4D は、4D Server 上のものではなく、独自の内部的なコンポーネントやプラグインを使用します。

プラグインやコンポーネントを 4D あるいは 4D Server アプリケーションレベルにインストールすることは、推奨されません。

リモートユーザーセッション

サーバー上では、Session コマンドはカレントユーザーセッションの情報を格納する Session オブジェクトを返します。 このオブジェクトを扱うには、Session クラス の関数とプロパティを使用します。

効果

The session object allows you to handle information and privileges for the remote user session.

ユーザーセッションのすべてのプロセス間でデータを共有するには、Session.storage 共有オブジェクトを使用できます。 たとえば、クライアントがサーバーに接続する際にユーザー認証手続きを開始し、メールや SMS で送信されたコードをアプリケーションに入力させることができます。 次に、ユーザー情報をセッションの storage に追加し、サーバーがユーザーを識別できるようにします。 この方法により、4Dサーバーはすべてのクライアントプロセスのユーザー情報にアクセスできるため、ユーザーの役割に応じてカスタマイズされたコードを用意することができます。

You can also assign privileges to a remote user session to control access when the session comes from Qodly pages running in web areas.

利用可能性

リモートユーザー Session オブジェクトは以下から利用できます:

  • サーバー上で実行 属性を持つプロジェクトメソッド (クライアントプロセスの "双子" プロセスで実行されます)
  • トリガー
  • ORDA データモデル関数 (local キーワードで宣言されたものを除く)
  • On Server Open Connection および On Server Shutdown Connection データベースメソッド
info

サーバー上のすべてのストアドプロシージャーは、同じ仮想ユーザーセッションを共有します。 詳細については、doc.4d.com のこのページ を参照ください。

Sharing the session with Qodly pages in Web areas

Remote client sessions can be used to handle Client/Server applications where Qodly pages are used for the interface, running on remote machines. With this configuration, your applications have modern CSS-based web interfaces but still benefit from the power and simplicity of integrated client/server development. In such applications, Qodly pages are executed within standard 4D Web areas.

To manage this configuration, you need to use remote client sessions. Actually, requests coming from both the remote 4D application and its Qodly pages loaded in Web areas need to work inside a single user session. You just have to share the same session between the remote client and its web pages so that you can have the same session storage and client license, whatever the request origin.

Note that privileges should be set in the session before executing a web request from a Web area, so that the user automatically gets their privileges for web access (see example). Keep in mind that privileges only apply to requests coming from the web, not to the 4D code executed in a standard remote session.

Shared sessions are handled through OTP tokens. After you created an OTP token on the server for the user session, you add the token (through the $4DSID parameter value) to web requests sent from web areas containing Qodly pages so that the user session on the server is identified and shared. On the web server side, if a web request contains an OTP id in the $4DSID parameter, the session corresponding to this OTP token is used.

例題

var $otp : Text

// Some privileges are put in the remote user session on the server for a further web access
ds.resetPrivileges("basic")

// An OTP is created on the server for this remote client session
$otp:=ds.getOTP()


// The user has already the required privileges for a web access
// and the same session is shared between this remote user and the web Qodly app
WA OPEN URL(*; "Welcome"; "http://127.0.0.1/$lib/renderer/?w=People&$4DSID="+$otp)

resetPrivileges() function in the Datastore class:

// This function is run on the server
// and puts some privileges in the session for a further web access

Function resetPrivileges($priv : Text)

Session.clearPrivileges()
Session.setPrivileges($priv)

getOTP() function in the Datastore class:

// This function is run on the server 
// and generates an OTP able to retrieve this remote user session

Function getOTP(): Text

return Session.createOTP()