OutgoingMessageクラスでWebアプリケーションを活性化する

Deeplからの自動翻訳

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

4Dの新しいRESTサーバー機能により、多様なコンテンツ配信の管理がこれまで以上に簡単になりました。以前は、RESTサーバーは、スカラー、エンティティ、エンティティ選択データしか返すことができませんでした。現在では、 完全なウェブコンテンツを直接配信することができます。

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

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

HDI_OutGoingMessageClass

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クラスのインスタンスを返すことができるようになった。

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

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

これは、このような 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()) // This is binary content
$result.setHeader("Content-Type"; "application/pdf")
return $result

この OutgoingMessageクラスには3つのプロパティが含まれており、 必要に応じてこれを埋めてください:

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

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

レストサーバでの関数の呼び出しを容易にします。

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

これまで、RESTサーバを介した(ORDAデータモデルクラスや シングルトンの)関数呼び出しは、POST動詞で行わなければなりませんでした。これは、リンクをクリックするような単純なアクションで機密性の高いコードを実行することを避けるため、セキュリティ上の理由から行われました。

POSTは必ずしも提供したいユーザーエクスペリエンスに適合しないため、これらの関数はGET 動詞でも呼び出すことができます

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

exposed onHTTPGet Function getSomeInfo() : 4D.OutgoingMessage

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

パラメータの受け渡し

パラメータは$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()) // This is binary content
$response.setHeader("Content-Type"; "application/pdf")

: ($type="jpeg")
$file:=File($doc+".jpeg")
$response.setBody($file.getContent()) // This is binary content
$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デベロッパーとして勤務。最近は、機能要件の分析・記述、ビジネスチームと開発チームの調整などを主に担当しています。