EGL ソース・コードを書き込んでテストした後、ターゲット・プラットフォーム用に Java™、JavaScript、または COBOL コードを生成します。
または、『EGL ソフトウェア開発キット (SDK) を使用した生成』で説明されているように、EGL ソフトウェア開発キット (SDK) で生成できます。
Rich UI アプリケーションまたは Web サービス (オプション) を生成した後で、EGL デプロイメントと呼ばれるワークベンチ固有のステップを実行します。最後に、EGL 準備と呼ばれるステップが必要になる場合があります。例えば、COBOL コードをリモート・プラットフォームにデプロイする場合です。
以下のセクションでは、全体のプロセスの概要を示します。
最も効率的な練習は、コードを開発およびデバッグしてから、出力の生成とデプロイを明示的に指示することです。ただし、EGL の作業を開始するときに、ワークベンチのデフォルトの設定を受け入れて、プロセスの各側面が自動的に発生するようにすることができます。
コーディングは開発時に発生し、デバッグはデバッグ時に発生します。
ワークベンチで EGL ソース・コードを開発するとき、 インターフェースは変更に対応します。例えば、EGL エディターは、無効な関数を書き込むとエラーをシグナル通知します。エラーを修正すると、 この関数の名前はすぐに「アウトライン」ビューに表示されます。
ワークベンチは、EGL エディター内で エラーをシグナル通知したり、別のビューに突然データを表示したりするコードに、 どのように応答するのでしょうか。このような振る舞いは、 非表示 EGL コンパイルによって可能です。これにより、ソース・コードは EGL 生成プログラムへの入力として後で使用できる種類の内部フォーマットに変換されます。
各コンパイルで、ソース・コードが構文上および意味上正しいかどうかが検証されます。 検証により、ワークベンチはエラーに応答できます。 この検証ではターゲット・プラットフォーム固有のエラーを キャッチすることはできません。
EGL コンパイラー は、ソース・コードをコンパイルするシステム・コードです。コンパイルはコンパイル時に発生しますが、ユーザーはプロセスのこの側面を制御しません。
EGL コンパイラーは、生成する出力を作成するための他のコードを呼び出します。
EGL ビルド は、 EGL ソース・コード・ファイルをコンパイルして、デバッグおよび生成に使用される 一連のファイルに出力を保存するプロセスです。ビルド・ファイルは中間表現 (IR) ファイル と呼ばれます。ファイル保存はビルド時に発生します。
ビルドの入力は、常に保存済み EGL ファイルです。
デフォルトでは、EGL ソース・コードを保存するごとに、 ワークベンチが EGL ビルドを実行します。デフォルトの動作を受け入れるには、メニュー・オプションのチェック・マークをそのままにしておきます。ビルドはインクリメンタルで、更新を必要とする IR ファイルのみが更新されるため、比較的高速です。
メニュー・オプションをクリックしてどのプロジェクトをビルドするかを示した場合にも、EGL ビルドが実行されます。その場合、ワークベンチは既存の IR ファイルを直ちに除去し、すべての出力をビルドします。生成された出力が予期したとおりでない場合は、「クリーン」オプションを試してください。
ワークベンチのビルド設定が制御するのは EGL ビルドだけではありません。特に、EGL 生成コードやその他の Java ソース・コード (ファイル拡張子 .java) の変換、および Javaバイトコード (ファイル拡張子 .class) への出力の格納を行う、Java ビルドを制御します。次のセクションで、この詳細を再度説明します。
EGL 生成 は、IR ファイルを受け入れ、ターゲット・プラットフォームに固有の出力を生成するプロセスです。生成には、生成でターゲット・プラットフォームに適切な入力が使用されることを 確実にするための検証ステップが含まれています。この検証ステップは、EGL 生成プログラムの ほとんどのメッセージのソースです。
生成の前に、特定のプラットフォームに対して出力を生成するための規則をユーザーが提供します。規則は、出力の生成方法、および後続のデプロイメントに対する出力のビルド方法に影響する XML 定義である、ビルド・パーツ 内にあります。
最も重要なビルド・パーツは、ビルド記述子 です。 そのパーツは、ターゲット・プラットフォームを識別し、必要に応じてその他のビルド・パーツを参照します。
次の理由で、デフォルトの設定値をお勧めします。出力を生成する前にワークベンチが IR ファイルを更新しないと、出力がユーザーのロジックの前のバージョンに基づいている可能性があります。
「書き込み、ビルド、およびデバッグを繰り返し行い、明示的な生成はプロセスの後半に残しておく」という、推奨されるプロセスで問題ない場合は、それらのチェック・ボックスをクリアできます。
デフォルトでは、Java または JavaScript の場合はビルド時の生成が発生します。この設定により、EGL の前のバージョンの動作が継続されます。例えば、EGL JSF デベロッパーである場合は、デフォルトの設定値を受け入れるということは、「サーバーで実行」をクリックする前に再生成することを覚えておく必要がないということを意味します。
COBOL の場合は自動生成は指定されません。これは、ほとんどの場合、生成ステップの効果が COBOL の場合は大きくなるためです。生成ステップでは、通常、その後の準備のために COBOL コードが別のマシンに転送され、そのステップには特に時間がかかります。
COBOL の生成にはこのオプションのみが有効です。
詳しくは、『生成モード』を参照してください。
生成への基本入力は、生成されるパーツが含まれている EGL ソース・ファイルです。 別の入力は、EGL デプロイメント記述子です。これは、サービスのデプロイ、Rich UI アプリケーションのデプロイ、およびサービスのアクセスの詳細を提供するファイルです。ただし、EGL デプロイメント記述子は、生成中ではなく後のステップで使用される場合があります。次のセクションで詳しく説明します。
その 2 番目のオプションに対するショートカットは、CTRL-G のクリックです。 生成可能なパーツが入ったファイルで作業している場合 (現時点で生成モードである場合)、または生成可能なデプロイメント記述子で作業している場合は、ショートカットを使用できます。
Java コードの生成後、メニュー・オプションが有効である場合は、Java ビルドが自動的に発生します。 生成される出力内に未解決の参照があるときに発生するエラーを回避するために、自動的なビルドは、Java ファイルを保存するたびではなく、生成ステップが実行された後でのみ発生します。
EGL 生成プログラム は、ソース・コードを生成するシステム・コードです。EGL 生成プログラムは、生成時に動作します。
デプロイメント・ステップは、Rich UI アプリケーションの場合に必要です。 利点は効率です。デプロイメント・ステップを使用すると、コードの生成後、出力が簡単な変更でさまざまなデプロイメント・ターゲットにプッシュされます。ビルド記述子オプションを変更してからすべての出力を再生成するのではありません。プロジェクト自体に、サーバー・タイプおよび JEE レベルに関する詳細 (それ以外の場合にはビルド記述子で指定される詳細) が含まれています。
Rich UI に固有のデプロイメント詳細については、『Rich UI デプロイメントの概要』を参照してください。
EGL 生成 SOAP サービスおよび EGL REST-RPC サービスの場合、デプロイメント・ステップはオプションです。Rich UI アプリケーションについて示された利点は、それらの Web サービスの場合に有効です (特に、サービスが JEE 準拠アプリケーション・サーバーで実行される場合)。ただし、CICS® 用に Web サービスをデプロイする場合、主な利点は一貫性です。その他の Web サービスの場合に使用可能であるプロセスと同じプロセスを使用して出力を生成できます。
EGL サービスなどのその他の EGL 生成出力を生成および準備するときは、デプロイメント・ステップは存在しません。
生成される出力およびランタイム・アーキテクチャーの概要については、『EGL での SOA サポート』を参照してください。
デプロイメント・ステップを実行するには、次のようにします。デプロイメント記述子またはそれを含むプロジェクトを右クリックしてから、「デプロイ」オプションをクリックします。
EGL デプロイヤーは、内部デプロイメント時にその処理を行います。資料では、外部デプロイメント時を参照する場合があります。これは、後続のステージで、デプロイ可能出力が実稼働環境にインストールされる場合です。
EGL 準備は、EGL 生成の Java コードまたは COBOL コードのコンパイルまたは変換を行うプロセスです。EGL 生成の JavaScript は準備されません。
EGL 準備は準備時に発生します。 詳しくは、『生成された Java 出力または COBOL 出力の準備』を参照してください。