4D開発者として、GUI（グラフィカル・ユーザー・インターフェース）のないアプリケーション、別名ヘッドレスアプリケーションを開発する必要に迫られたことがあるのではないでしょうか。以前の4Dでは、これは完全に不可能でした……4D v18までは!このブログでは、あなたのアプリケーションを “ヘッドレス “にするために、新しく利用できるようになった機能のいくつかを紹介します。
なぜ、ヘッドレスアプリケーションを作るのか？Windowsの動作をmacOSでシミュレートしたり、サービスマネージャーを使わずにWindowsのサービスを動作させたりなど、いくつかのユースケースがあります。しかし、なによりも、4Dを使ったボットの開発など、新しい可能性が広がります。
ヘッドレスモードで4Dアプリケーションを起動するには？
CLI (Command Line Interface)で、新しい“headless“パラメーターを使って、ヘッドレスモードで4Dアプリケーションを起動できるようになりました。すべてのアプリケーションタイプで利用可能です。4D, 4D Server, standalone, remote, merged applications.以下の例では、カレントディレクトリは実行可能なディレクトリです。
macOSの例（バンドル内の “Contents/MacOS “フォルダにterminalを配置した場合）。
| ./4D Server –headless MyDatabase.4DLink ./”4D Server”–headless MyDatabase.4DLink ./4D –headless MyDatabase.4DLink ./MyBuiltRemoteApp –headless |
Windowsの例です。
| “4D Server.exe”–headless MyDatabase.4DLink 4D.exe –headless MyDatabase.4DLink MyBuiltRemoteApp.exe –headless |
コマンドで返されるオブジェクトに、新しい「ヘッドレス」属性を追加しました。 Get application infoコマンドによって返されるオブジェクトに、新しい「ヘッドレス」属性を追加しました。これにより、実行モード（インターフェイスあり、なし）に応じてコードを書くのがより簡単になります。
注：現在、Windowsシステムでアプリケーションをサービスモードで実行すると、自動的にヘッドレスアプリケーションとして実行されます。サービスを停止すると、4Dアプリケーションは正しい方法で終了します（例えば、macOSのアクティビティモニタで “Quit “アクションを使用します）。
実行中は何が起こるのでしょうか？
“さて、楽しいけど、ダイアログが表示されるはずだったのに、どうなるんだろう？”と、疑問に思うかもしれません。実行時に何が起こっているかを知らせるために、4Dはヘッドレスモードで実行すると自動的に診断ログをアクティブにします。ログは、表示されたかもしれないすべてのユーザーインターフェイスをキャッチし、[{applicationName}.HDLS] タグでログを記録します。
一般的な動作は、4Dが何かを表示しようとするコマンドをキャッチし、コマンドの名前とそのコールチェーンで警告イベントを記録し、アクションをキャンセルすることです。いくつかの特殊なケースがあります。
- ライセンスがない場合、4Dはシステムイベントログと標準ストリームにこのことを記録し、終了します。
- データベースの変換が必要な場合、4Dはシステムイベントログと標準ストリームにその旨を記録し、終了します。
- 利用可能なデータベースやデータファイルが見つからない場合、システムイベントログと標準ストリームに記録され、終了します。
- デバッガを表示する必要がある場合、4Dはエラーを記録し、「中止」動作をシミュレートします。
- アラートが表示されると、4Dはログを記録し、その後「OK」アクションをシミュレートします。
- QUIT 4Dコマンドを呼び出すと、4Dはログを記録し、”OK “アクションをシミュレートします。
- マージされたアプリケーションを更新する必要がある場合、ログが生成され、更新が実行され、アプリケーションはヘッドレスモードで再起動されます。
例
例えば、Windows上のサービスとして稼働しているサーバーでALERT コマンドを実行しても、サーバーの実行を停止することはなくなりました。4Dは自動的にこのコマンドを捕捉し、診断ログに警告行を書き込みます。それは次のようなものです。
| 11 2019-07-11 18:53:52 [myTestDatabase Server.HDLS] WARN – (Alert: Test alert label)[{“type”: “projectMethod”, “name”: “myTestAlert”, “line”:2, “database”: “myTestDatabase”}] ]。 |
このシステムは、ヘッドレスアプリケーションで何が起こっているかを確認し、（必要であれば）コードを改善するために作成されました。
システム標準ストリームを使用する
コマンドに新しいセレクタ、Into system standard outputs が追加されました。 LOG EVENTコマンドに新しいセレクタ（）を追加し、標準ストリーム（stdoutと stderr）にテキストを送ることができるようになりました。ご存知のように LOG EVENTコマンドにはオプションで“importance“パラメータがあります。したがって、イベントの重要度に応じて、コマンドは、Information message とWarning message の場合はstdoutストリームに、Error message の場合はstderrストリームにテキストを送ります。
標準出力にテキストを送信します。
LOG EVENT(Into system standard outputs; "これはstdout用のテキストです";Information message)
stderrにテキストを送る。
LOG EVENT(Into system standard outputs; "This is a text for stderr";Error message)
stdoutと stderrのシステム標準ストリームをリダイレクトして、4Dとアプリケーションで生成された情報を取得することも可能です。デフォルトでは、これらのストリームは一般的にコンソールに向けられますが、システム設定によっては、まれにスクリーンに向けられることもあります。例えば、以下のコマンドラインを使用して、標準ストリームをファイルにリダイレクトすることができます。
macOSの場合
| ./4D –headless MyDatabase.4DLink 1>stdout.txt 2>stderr.txt |
Windowsの場合
| 4D –headless MyDatabase.4DLink 1>stdout.txt 2>stderr.txt |
ストリームリダイレクトの組み合わせの注意点
- 1>outputFile：システムのデフォルト出力の代わりに、標準出力ストリームがファイルに書き込まれます。このファイルは、コマンド起動時に自動的に作成されます。すでに存在する場合は、古い内容が消去されます。
- 1>>outputFile: 前の構文と同じ動作ですが、ファイルがすでに存在する場合は、ストリームの内容に追加されます。
- 2>errorFile: システムのデフォルト出力の代わりに、標準エラーストリームがファイルに書き込まれます。このファイルは、コマンド起動時に自動的に作成されます。すでに存在する場合は、古い内容が消去されます。
- 2>>errorFile: 前の構文と同じ動作ですが、ファイルがすでに存在する場合は、ストリームの内容を追加します。
- 2>&1: エラーストリームは、出力ストリームにマージされます。
- 1>&2: 出力ストリームは、エラーストリームにマージされる。
注：macOSシステム上で4Dパッケージを実行するためにopenコマンドを使用することも可能で、ストリームは4Dアプリケーションではなく、このコマンドによって生成されます
まとめ
これらの新しい進歩により、システム要件を満たすことができ、またボットのような新しい機会も生まれます。これを継続的インテグレーション（CI）や継続的テスト（CT）チャンネルと組み合わせて、あなたのソフトウェア工場に導入するかどうかは、あなた次第です。あなたの想像力だけが限界です