OutgoingMessageクラスでWebアプリケーションに力を

今日のデジタルの世界では、スムーズで直感的なユーザーエクスペリエンスが、Webアプリケーションの成功の鍵を握っています。このユーザーエクスペリエンスの重要な部分は、ドキュメント・画像・その他のデータタイプなど、さまざまなリソースへの容易なアクセスにあります。これを可能にするには、サーバーが異なるコンテンツフォーマットを効率的に管理し、配信する必要があります。

4D 20 R7 の新しい RESTサーバー機能により、多様なコンテンツ配信の管理がこれまで以上に簡単になりました。いままで RESTサーバーは、スカラー・エンティティ・エンティティセレクションのデータしか返すことができませんでした。現在では、ブラウザーが扱える完全な Webコンテンツを直接配信することができます。

新しい OutgoingMessage クラスのおかげで、RESTサーバーからのファイルのダウンロードやバイナリーデータの受信が簡単になりました。このクラスを使えば、必要に応じてレスポンスを簡単にカスタマイズできます。

OutgoingMessageクラスがあなたのアプリケーションをどのように向上させることができるのか、続きをお読みください!

HDI: OutGoingMessageクラス

RESTサーバー上で公開された関数を呼び出す

リマインダー: ORDAデータモデル関数とシングルトン関数は、REST API として呼び出すことができます。このブログ記事このブログ記事 をご覧ください

これまで RESTサーバーは、スカラー・エンティティ・またはエンティティセレクションという様々なデータ型をオブジェクト内にラップして、result プロパティで返すことができました。

例題

これは DataStoreクラスの getSomeInfo() 関数です:

exposed Function getSomeInfo() : Text
	return "This is the info"

そして、この関数を /rest/$catalog/getSomeInfo リクエストで呼び出したときの結果です:

{
    "result": "This is the info"
}

4D Webコマンドはこのような関数の中では使用できないため、新しい OutgoingMessageクラスはとても便利です。

新しいOutgoingMessageクラス

ORDAデータモデル関数 と シングルトン関数 は、この新しい OutgoingMessageクラスのインスタンスを返せるようになりました。

このようなオブジェクトはどのブラウザーでも Webコンテンツとして直接扱えます。

したがって、ファイルや画像のダウンロードのほか、あらゆるコンテンツをブラウザー経由で受信する機能をエンドユーザーに提案することができます。

OutgoingMessageクラスのオブジェクトインスタンスのJSON表現の例です:

例題

この例では、getFile() 関数を DataStoreクラスに実装しています。その目的は、リクエストに対して testFile.pdf ファイルをレスポンスとして返すことです。

まず、OutgoingMessageクラスのオブジェクトインスタンスを生成します。

ボディには testFile.pdf ファイルのバイナリーコンテンツが含まれ、ヘッダーはコンテンツタイプを示します。

exposed onHTTPGet Function getFile() : 4D.OutgoingMessage
	
var $result:=4D.OutgoingMessage.new()
var $file:=File("/RESOURCES/testFile.pdf")
	
$result.setBody($file.getContent())  // これがバイナリーコンテンツです
$result.setHeader("Content-Type"; "application/pdf")
return $result

OutgoingMessageクラスは 3つのプロパティを持ちます:

    • header: クライアントが処理する HTTPヘッダーを設定します (たとえば、ボディのタイプを示す content-type)。
    • body: リクエストに対し、レスポンスとして送信したいコンテンツを設定します。String または Blob (バイナリーコンテンツとしてのファイル、ドキュメント、イメージなど) を指定できます。
    • status: リクエストの結果に応じて、任意の HTTPステータス・コードを設定します。これによりクライアントは、リクエストがどのように処理されたかについての情報を得ることができます (たとえば、リクエストが拒否された場合はステータス403)。デフォルト値は 200 です。

 

注記: bodystatus プロパティは、:= 演算子または setBody() / setStatus() 関数を使用します。

RESTサーバー上の関数呼び出しを容易に

関数用の新しいonHTTPGetキーワード

これまで、ORDAデータモデルクラスや シングルトンの関数を RESTサーバーを介して呼び出す場合は、POST動詞を使う必要がありました。これは、リンククリックのような単純なアクションで機密性の高いコードを実行することがないよう、セキュリティ上の理由でおこなわれました。

しかし、POST は必ずしも提供したいユーザーエクスペリエンスに適合しないため、これらの関数は GET動詞 (つまり ブラウザーで URL を入力すること) でも呼び出せるようになりました

これには新しい onHTTPGetキーワードを使います。このキーワードを関数に適用すると、この関数を GET動詞で呼び出すことができます!

exposed onHTTPGet Function getSomeInfo() : 4D.OutgoingMessage

注記: このタイプの呼び出しは簡単に提供されるアクションであるため、開発者はこのような関数で機密性の高いアクションがおこなわれないようにしなければなりません。

引数の受け渡し

引数は $paramsパラメーターを使って関数に渡すことができます (コレクションで格納する必要があります)。

この例では、Productsデータクラスの getThumbnail() 関数が呼び出され、指定商品のサムネイル写真を取得します。

引数として受け渡されるのは、商品名と、必要な幅および長さです。

IP:port/rest/Products/getThumbnail?$params='["Yellow Pack",200,200]'

関数を呼び出すときに引数を送信する方法については、ドキュメントを参照ください。

例題

次のユースケースを考えましょう: エンドユーザーが選択した製品について、複数形式のユーザーマニュアルをそれぞれダウンロードできるリンクを提供します。

リンクのリクエストは次の通りです:
IP:port/rest/Products/getUserManual?$params='[1, “pdf”]’

選択された製品ID (1) が引数として渡され、必要なフォーマット (pdf) を指定します。

Productsデータクラスの getUserManual() 関数が呼ばれ、商品ID とフォーマットを受け取ります。

対応する文書が取得されます。対応するコンテンツタイプが指定され、このバイナリーコンテンツはレスポンスのボディに置かれます。

exposed onHTTPGet Function getUserManual($productId : Integer; $type : Text) : 4D.OutgoingMessage
	
var $file : 4D.File
var $response:=4D.OutgoingMessage.new()
var $doc:="/RESOURCES/User manuals/product_"+String($productId)

Case of 
	: ($type="pdf")
		$file:=File($doc+".pdf")
                $response.setBody($file.getContent()) // これがバイナリーコンテンツです
		$response.setHeader("Content-Type"; "application/pdf")
			
	: ($type="jpeg")
		$file:=File($doc+".jpeg")
                $response.setBody($file.getContent()) // これがバイナリーコンテンツです 
		$response.setHeader("Content-Type"; "image/jpeg")
End case 
	
return $response

 

以下は、ブラウザーの画面です:

 

blank

試してみてください

HDI をダウンロードしてこの新機能を試してみてください。 OutgoingMessageクラスの使い方についての詳細はドキュメントをご覧ください。

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