4D Japan
テクニカルサポートブログ-
ファイルシステムパスと4Dfolder定数
Folderコマンドには，ファイルシステムパス（例："/PACKAGE"）または定数（例：fk database folder）を渡すことができます。コンポーネントからホスト側のパスを取得するには，アスタリスクオプション（*）を指定します。このオプションが使用できるのは，定数でパスを指定した場合だけです。この点は，ドキュメントに明記されています。ファイルシステムとアスタリスクオプションを組み合わせて使用することはできない点に留意してください。
-
２次元配列の要素をクリアするには
CLEAR VARIABLEは，変数または配列をクリアするコマンドです。インタープリターモードでは，２次元配列の要素もクリアできるかもしれませんが，これは従来の振る舞いを変えないための特別な措置であり，コマンドに２次元配列の要素を渡すことは想定されていない点に留意してください。コンパイルモードで配列の要素を
CLEAR VARIABLEでクリアすることはできません。２次元配列の要素は，変数（配列）とは違います。DELETE FROM ARRAYを使用してください。
-
4D v17.4 Hotfix 1 修正リスト
-
Write Proドキュメントの要素リストを取得する
WP Get elementsにWrite Proドキュメントを渡した場合，要素のid順にソートされたコレクションが返されます。本文に出現する順序ではない点に留意してください。これは仕様です。本文に出現する順序で要素を取得したいのであれば，Write Proドキュメント本文のレンジオブジェクトを渡してください。$Paragraphs:=WP Get elements(WParea;wk type paragraph) //ID順 $Paragraphs:=WP Get elements(WP Get body(WParea);wk type paragraph) //出現順
-
4D v18.1 Hotfix 1 修正リスト
-
4D v18r2 修正リスト
-
4D RESTセッションの理解を深める
前回のブログで、4D RESTサーバーを開始する方法をご覧いただきました。Postmanを使って異なるCRUD操作を経験し、完全なるRESTドキュメントへと導きました。今回のブログでは、4Dの中でセッションがどのように働くのかを説明します。これを理解することで、4D RESTサーバーを使ったセッションベースの承認システムの構築ができることを確信しています。
4D RESTセッション
認証システムの構築を目指すなら、あなたの探しているものはセッションベースのシステムです！
4DRESTサーバーへの接続は、セッションベースです。これは、4Dサーバーがセッションを作るのは、最初のリクエストがクライアント(WASID4D)によって送られ、セッションクッキーが返送された時であるということです。全てのサブスクエント・リクエストに対して、クライアントはリクエストへのヘッダー中のセッションクッキーを返さなければなりません。これは、サーバー側にはセッションが残っていないけれどクライアント上に保存されている、トークンベース認証とは反対になります。
RESTサーバーを構築
では、セッションの扱い方をよく理解できたところで、さらに前進します。始める前に、4D RESTサーバーを開始しえて、構成します。さらに始める前に、このブログあるいはドキュメントセンターを参照してください。
ON REST AUTHENTICATIONメソッド
データベースメソッドのOn REST Authenticationによって、4D上でRESTセッションの開き方のコントロールをカスタマイズする方法が使えるようになります。RESTセッションを開くリクエストを受けた時、接続確認（例：ユーザー名とパスワード）がリクエストのヘッダーに提供されます。On REST Authenticationデータベースメソッドが呼ばれるので、これらの認証を評価でき、True（セッションの開始を承認）あるいはFalse（セッションの開始を拒否）を返します。
注記：このデータベースメソッドがデータベースへの独自のアクセスコントロールのコーディングに使われている間、アクセスは4Dユーザー・グループを使って制限することも可能です。データベースを表示している際に、データベース設定 > Web > RESTリソース・タブにアクセスを許可されたグループを選択します。このブログで記憶を取り戻してください。
セッションを開く
セッションの開始を図解するには、ログインとパスワードを伴うサブミッション・フォームを想像しましょう。POST リクエストのヘッダー内の認証情報を送るのにPostmanを使っています。RESTを通じて4Dアプリケーション内のセッションを開くために、$directory/login:を使います。
4Dに戻ってどうなるか見てみましょう。
ご覧の通り、データベースメソッドはパラメータを受け取ります。
- ユーザー名には$1
- パスワードには$2
- $3は、パスワードがハッシュされたらTrueを、されなかったらFalseを返します。
- $4はコーラーのIPアドレスを保持します。
注記：現実には、パスワードはハッシュされて、暗号化されていない状態で送られることはありません。ハッシュされたパスワードを送るには、password-4Dの代わりにhashed-password-4Dパラメータを使うことができます。このコードサンプルでどのように処理するかチェックしてください。
一度リクエストが受け取られると、サーバーはセッションを開き、セッションクッキーをクライアント (WASID4D)へ送り返します：
これでセッションが作成されました。結果として生じるHTTPリクエストへそのIDを返すにはどうしたらよいでしょう。
待ってください…なぜ、最初にこれをやる必要があるのでしょう。
セッション管理
HTTPは「ステートレス」プロトコルです…クライアントがWebページに接続するたびに、Webサーバーへ区別して接続を開きます。サーバーは以前のクライアント・リクエストのレコードを保持しません。数千のクライアントがサーバーに接続することを想像してみると、どのセッションが自分か知る手段がありません。そこでセッションIDが登場します。セッションIDの交換を通して、ステートが保たれます。正確には何を意味するのでしょうか。同じセッションを再利用するために、全ての後続のRESTリクエストが、リクエストの”Cookie“ヘッダー内にsession IDを含んでいるかを確認する必要があるということです。その一方で、新しいセッションが開かれます（そして新しいセッションとは新しいライセンスを意味します）。
サンプル
セッションを操作する方法は、実際にはHTTPクライアントに依存します。いわば、 HTTP Requestコマンドを通してリクエストが操作されるコンテキストの中にいます。
ヘッダーの中にセッションIDを含めるには、最初にそれを見つけなければなりません。それは簡単です！セッションにはWASID4Dキーがあることは分かっていますので、 Find in arrayコマンドを使ってヘッダーの値の中にこのキーを探すだけです：
Find in array($headerValues;"WASID4D@")見つけたら解凍します。
$start:=Position("WASID4D";$cookie)
$end:=Position(";";$cookie)
$uuid:= Substring($cookie;$start;$end-$start)$uuidは、全ての後続のリクエストの中で送られるセッションIDをホストします。完全なサンプルはここからご覧ください。
セッション・タイムアウトをコントロール
初期設定では、セッションが無活動のタイムアウトは60分でそれより短くはできません。しかし、4directory/loginメソッドを伴ってPOSTヘッダー内へ渡すことのできる”session-4D-length”パラメータの値を使って、タイムアウトの長さを増やすことはできます。
おまけ
4D Serverは、前回のクエリーやオーダー・コマンドをベースにしたエンティティー・セレクションを保存しているセッションを持っています。そのため、データの次の”範囲”（あるいはチャンク）が必要なとき、クエリー/オーダーを再度行う必要がありません。シンプルにデータの次のセットを送るだけです。このメカニズムは、トランザクションやペシミスティック・ロックなどの使用を可能にしています。
次回予告
RESTサーバーは4D v18で大きく拡張され、将来にはさらに多くの機能が登場します。しばらくの間、サンプルや実際の使用例を提供する予定です。4Dフォーラムでの意見交換にご参加ください。
-
ピクチャ演算子の変更
-
強力な4D RESTサーバーをPOSTMANでテストする
4Dは、あなたの4Dデータベースに保存したデータへ直接アクセスできる強力なRESTサーバーを提供しています。これによって、例えば、モダンなフロントエンド・テクノロジー（Angular、Reactなど）を使ったAPIの構築が可能です。このブログでは、4Dの堅牢なRESTサーバーを初めてご紹介します。また、APIテストツール、Postmanを使用して、作成、取得、更新、削除 (CRUD) の各操作をテストする方法を説明します。
RESTサーバーの構成
注意：もしすでにRESTサーバーと4Dデータベースの構成方法をご存知の場合は、この後の２章はスキップしてください。
4D RESTサーバーを使えるようにするには、最初に構成が必要です（シングル・クリックで起動して動作します）。「データベース設定」の「Web / RESTリソース」ページの「RESTサーバーとして公開」にチェックするだけでRESTリクエストを処理することができます。
4Dデータベースを作成して構成する
このステップは、すでにデータベースを作成してRESTサーバーを有効にしていると仮定しています。ストラクチャーに新しいテーブル [Tasks]とその２つの属性：Title (Alpha)とComplete (Boolean)を作成します。初期設定では、全てのテーブルはRESTで公開されます：
重要：テーブルとフィールド名はJSONに準拠（発音区別文字やスペースは不可）しなければなりません。
- では、入力と出力のフォームを作成します。Tasksテーブルにいくつかのタスクを入力します。
- 『実行メニューから「WEBサーバーを開始」（もしまだ開始していない場合）を選択し、次に「WEBサーバーをテスト」を選択します。
- おめでとうございます！RESTリクエストだけを使って4D内のデータを読んだり、編集できるようになりました
指示する方法は簡単です。WEBブラウザーを開いて、ADDRESS/PORTの後に”/rest”を挿入します。（全ての4D REST URLリクエストは/restで始まります。） 例えば、[Task]データクラスの全てのエンティティーを得たい場合は、以下のように処理できます：
Postmanを使ってAPIをテスト
4D RESTサーバーについて驚くべきことは、CRUD（とそれ以上の）操作をAPIが提供することです…では、見てみましょう！ エンティティーの作成、読み込み、更新あるいは削除にあたっては1行のコードも必要ありません。全てがセットアップされています。よく知られているように、CRUDはデータベース操作の中で最も重要なグループです。ユーザーがデータを作成し、管理するのに必要なメインの機能だからです。
この驚異的なAPIをテストするために、Postman（RESTに最適のAPIをテストするための素晴らしいツール）を使います。Postmanは、GET、POST、PUT/UPDATE、DELETEや様々な他のリクエスト・メソッドのように、HTMLメソッドを作るための洒落たユーザー・インターフェイスを提供します。
注意：Postmanの使用は単純明快ですが、もし始めるにあたってヘルプが必要であれば、このビデオを見てください。
タスクのリストを得る
Postmanをダウンロードしたら、異なるリクエストを作ります。とても明快なリクエストから始めましょう。タスクのリストを（[Tasks]テーブルから）検索します。前に述べたように、[Task]データクラスの全てのエンティティーを得るためには、ADDRESS/PORTの後に/rest/NameOfTheDatabaseを挿入します。
- メソッドのリストからGETメソッドを選択します。
- URLをコピーします。
- 送信をクリックします。
- ほら、できました。
ご覧の通り、タスクのリストを検索するためには１行のコードも必要ありません
新しいタスクを作る
データクラスに新しいタスクを加えることもできます… これもコード不要です。 APIはすでに設定されています！
新しいエンティティーを作成するために、このURLは新しいポスト・リクエストを起動します： ADDRESS/PORP/rest/NameOfTheDataclass/?$method=update。それを実行するには、アプリケーションにJSONリクエストを送る必要があります。もしGETリクエストから結果をチェックすれば、新しいタスクを作成するのに必要な鍵となるアイデアが得られるでしょう。では、このロジックに従って、私たちにはタイトルと完全なフィールドだけが必要で、その他（キー、タイムスタンプ、スタンプ、ID）は4Dが対応します。
- メソッドをPOSTに変更します。
- URLを挿入します。
- 送信をクリックします。
- 新しいタスクを追加します。
- 成功=trueを確認します。
最初のタブ（GETメソッド）に戻り、送信をクリックしてタスクが追加されたことを確認します。4Dの出力フォームにも行き、新しいタスクが追加されているか確認します。
タスクの更新
エンティティーを更新するには、エンティティーを作成したのと同じメソッドを使います。$method=updateは１つのPOST中の１つ以上のエンティティーを更新できます。それを実行するには、オブジェクトの中の_KEYと_STAMPパラメータを修正した属性とともに渡す必要があります。
サンプルでは、ヘミングウェイの不朽の名作のひとつ『老人と海』を読みました。従いまして、タスクのcompleteステータスをtrueに変える必要があります。簡単にできます：
タスクの削除
エンティティーの削除もシンプルです。サンプルでは、ID=3 (“test”のコール）のタスクを削除します。問題ありません！deleteメソッドを呼び出して、そのIDを特定します：dataclass(ID)?$method=delete。
データベースに戻り、エンティティーが削除されてことを確認します。
この次には
ご覧の通り、4D RESTサーバーはとても強力です。たった今、デモしたようなこと以上にリッチなAPIを提供します。わずかな時間でできることはもっとあります。詳細な<a href=“https://developer.4d.com/docs/en/REST/%7BdataClass%7D.html“>ドキュメント</a>を参照してください。この先のブログで、認証についてのtipを共有し、その後で、4DデータベースへwebアクセスするためにAngular 7とRESTで書かれた完全なフロントエンド・アプリケーションも説明します。
-
クライアント/サーバー版のブレークポイント
サーバーに接続されたクライアント（4D Remote）のデザインモードでセットしたブレークポイントは，ユーザー別に管理されており，サーバー側に保存されています。クライアント側から
Execute on serverを呼び出してストアドプロシージャを開始した場合，そのサーバー側プロセスは，コマンドを呼び出した4D Remoteのアカウント権限で実行されます。したがって，ユーザー管理者（Administrator）としてログインしたのであれば，総合管理者（Designer）がセットしたブレークポイントは通過することになります。サーバー側のプロセスを
TRACEコマンドでトレースした場合，サーバー側に表示されるデバッガは，ストアドプロシージャを開始したプロセスのユーザー権限ではなく，サーバー，つまりDesignerの権限で実行されています。クライアント側のユーザー権限でデバッグするためには，クライアント側でブレークポイントをセットする必要があります。