AWS モダナイズされたアプリケーションの Blu Age 構造 - AWS メインフレームのモダナイゼーション
アーティファクトの組織プログラムの実行と呼び出し独自のプログラムの作成完全修飾名マッピング

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS モダナイズされたアプリケーションの Blu Age 構造

このドキュメントでは、デベロッパーが次のようなさまざまなタスクを実行できるように、モダナイズされたアプリケーションの構造 ( AWS Mainframe Modernization リファクタリングツールを使用) について詳しく説明します。

  • アプリケーションへのスムーズなナビゲーション。

  • モダナイズされたアプリケーションから呼び出せるカスタムプログラムの開発。

  • モダナイズされたアプリケーションの安全なリファクタリング。

次の内容に関する基本的な知識を既に保持していることを前提としています。

  • レコード、データセット、レコードへのアクセスモードなどの従来の一般的なコーディング概念 -- インデックス作成、シーケンシャル --、VSAM、実行ユニット、jcl スクリプト、CICS概念など。

  • Spring フレームワークを使用した Java コーディング。

  • ドキュメント全体をとおして、読みやすさを考慮して short class names を使用しています。詳細については、AWS Blu Age 完全修飾名マッピング「」を参照して AWS Blu Age ランタイム要素に対応する完全修飾名を取得し、サードパーティーの完全修飾名マッピング「」を参照してサードパーティ要素に対応する完全修飾名を取得します。

  • すべてのアーティファクトとサンプルは、サンプルCOBOL/CICSCardDemo アプリケーション のモダナイゼーションプロセスの出力から取得されます。

アーティファクトの組織

AWS Blu Age のモダナイズされたアプリケーションは、JEEサーバーにデプロイできる java ウェブアプリケーション (.war) としてパッケージ化されています。通常、サーバーは AWS Blu Age ランタイムを埋め込む Tomcat インスタンスであり、現在 Springboot フレームワークと Angular (UI パート用) フレームワーク上に構築されています。

war は複数のコンポーネントアーティファクト (.jar) を統合します。各 jar は専用の Java プロジェクトを (maven ツールを使用して) コンパイルして生成され、その要素はモダナイズプロセスの結果生じます。

モダナイズされたアプリケーションアーティファクトのサンプル。

基本的な組織は以下の構造に基づいています。

  • エンティティプロジェクト: ビジネスモデルとコンテキスト要素が含まれます。プロジェクト名は通常「-entities」で終わります。通常、特定のレガシーCOBOLプログラムでは、これは I/O セクション (データセット) とデータ分割のモダナイズに対応します。複数のエンティティプロジェクトを使用することができます。

  • サービスプロジェクト: レガシービジネスロジックのモダナイズ要素が含まれています。通常、COBOLプログラムのプロシージャ分割です。複数のサービスプロジェクトを使用することもできます。

  • ユーティリティプロジェクト: 他のプロジェクトで使用されている、共通のツールやユーティリティが含まれています。

  • ウェブプロジェクト: UI 関連の要素をモダナイズしたもの (該当する場合) が含まれます。バッチのみのモダナイズプロジェクトには使用されません。これらの UI 要素は、CICSBMSマップ、IMSMFSコンポーネント、およびその他のメインフレーム UI ソースから取得できます。複数のウェブプロジェクトを使用することができます。

エンティティプロジェクトの内容

注記

以下の説明は、 COBOLおよび PL/I モダナイゼーション出力にのみ適用されます。RPG モダナイゼーション出力は、異なるレイアウトに基づいています。

リファクタリングを行う前に、エンティティプロジェクトのパッケージ構成をモダナイズプログラムと関連付けます。これを実行するための、いくつか方法があります。推奨される方法は、コード生成メカニズムを起動する前に動作する、リファクタリングツールボックスを使用することです。これは高度なオペレーションであり、 BluAge トレーニングで説明されています。詳細については、「リファクタリングワークショップ」を参照してください。このアプローチでは後で Java コードを再生成する機能を維持できるため、将来さらに改善できるというメリットがあります。もう 1 つの方法は、生成したソースコードで、適用する可能性のある Java リファクタリングアプローチを使用して、自己責任で定期的に Java リファクタリングを実行することです。

サンプルプログラム CBACT04C エンティティパッケージ。

プログラム関連クラス

各モダナイズプログラムは、business.context パッケージと business.model パッケージという、2 つのパッケージに関連付けられます。

  • base package.program.business.context

    business.context サブパッケージには、構成クラスとコンテキストクラスという 2 つのクラスが含まれています。

    • プログラムの 1 つの構成クラスには、文字ベースのデータ要素を表すために使用する文字セット、データ構造要素をパディングするためのデフォルトバイト値など、特定のプログラム固有の構成情報が含まれます。クラス名は「Configuration」で終わります。@org.springframework.context.annotation.Configuration アノテーションが付いており、正しくセットアップされた Configuration オブジェクトを返す必要がある単一メソッドが含まれています。

      Java での設定例。

    • 1 つのコンテキストクラスは、プログラムサービスクラス (以下を参照) と、モデルサブパッケージ (以下を参照) のデータ構造 (Record) やデータセット (File) との間のブリッジとして機能します。クラス名は「Context」で終わり、RuntimeContext クラスのサブクラスです。

      コンテキストクラス例 (部分ビュー)

  • base package.program.business.model

    モデルサブパッケージには、特定のプログラムが使用できるすべてのデータ構造が含まれています。例えば、01 レベルのCOBOLデータ構造は、モデルサブパッケージのクラスに対応します (下位レベルのデータ構造は、所有する 01 レベルの構造のプロパティです）。01 データ構造をモダナイズする方法については、「AWS Blu Age のデータシンプリケーターとは」を参照してください。

    レコードエンティティ例 (部分ビュー)

すべてのクラスは、ビジネスレコード表現へのアクセスを表す RecordEntity クラスを拡張します。レコードの中には、File にバインドされている特別な目的を持つものもあります。Record と の間のバインディングFileは、ファイルオブジェクトの作成時にコンテキストクラスで見つかった対応する * FileHandler メソッドで行われます。例えば、次のリストは、 が TransactfileFile File (モデルサブパッケージから) にどのように transactFile Recordバインドされるかを示しています。

レコードからファイルへのバインディングのサンプル。

サービスプロジェクトの内容

すべてのサービスプロジェクトには、アーキテクチャのバックボーンとして使用される、専用の Springboot アプリケーションが付属しています。これは、サービス java ソースのベースパッケージにある、SpringBootLauncher という名前のクラスを通じて実現されます。

サービスプロジェクト SpringBoot アプリケーション。

このクラスは特に以下の役割を果たします。

  • プログラムクラスとマネージドリソース (データソース、トランザクションマネージャー、データセットマッピングなど) を結合します。

  • プログラムに ConfigurableApplicationContext を提供します。

  • spring コンポーネント (@Component) とマークされたクラスをすべて検出します。

  • プログラムが ProgramRegistry に正しく登録されていることを確認します。この登録を管理する初期化メソッドを参照してください。

プログラムの登録。

プログラム関連アーティファクト

事前にリファクタリングを行わなくても、ビジネスロジックのモダナイゼーション出力は、レガシープログラムごとに以下の 2 つまたは 3 つのパッケージにまとめられます。

サンプルプログラムパッケージ。

最も包括的なケースには、次の 3 つのパッケージがあります。

  • base package.program.service: ProgramProcess という名前のインターフェイスが含まれ、これには従来の実行制御フローを維持したままビジネスロジックを処理するビジネスメソッドが含まれています。

  • base package.program.service.impl: には、プログラム ProcessImplという名前のクラスが含まれています。これは、前述のプロセスインターフェイスの実装です。ここでは、レガシーステートメントが Blu Age フレームワークに基づいて「変換」されて java AWS ステートメントになります。

    モダナイズされたCICSステートメントの例 (SENDMAP、RECEIVEMAP）

  • base package.program.statemachine: このパッケージが常にあるとは限りません。これは、レガシーコントロールフローのモダナイゼーションがステートマシンアプローチ (つまり Spring StateMachine フレームワーク を使用) を使用してレガシー実行フローを適切にカバーする必要がある場合に必要です。

    その場合、statemachine サブパッケージには次の 2 つのクラスが含まれます。

    • ProgramProcedureDivisionStateMachineController: Spring ステートマシン構造の駆動に使用される StateMachineController (ステートマシンの実行の制御に必要な操作を定義) インターフェイスと StateMachineRunner (ステートマシンの実行に必須の操作を定義) インターフェイスを実装しているクラスを拡張するクラス (ケース例の SimpleStateMachineController など)。

      ステートマシンコントローラーのサンプル。

      ステートマシンコントローラは、発生する可能性のあるさまざまな状態、およびそれらの間の遷移を定義します。これにより、特定のプログラムの従来の実行制御フローが再現されます。

      ステートマシンを構築する際、コントローラはステートマシンパッケージ内の関連するサービスクラスで定義されているメソッドを参照します。以下で説明します。

      
subConfigurer.state(States._0000_MAIN, buildAction(() -> {stateProcess._0000Main(lctx, ctrl);}), null);
subConfigurer.state(States.ABEND_ROUTINE, buildAction(() -> {stateProcess.abendRoutine(lctx, ctrl);}), null);

    • ProgramProcedureDivisionStateMachineService: このサービスクラスは、前述のように、ステートマシンコントローラが作成するステートマシンにバインドする必要のある、一部のビジネスロジックを表します。

      このクラスのメソッド内のコードは、ステートマシンコントローラで定義された以下のイベントを使用します。

      ステートマシンコントローラーイベントを使用するステートマシンサービス。
      ステートマシンコントローラーイベントを使用するステートマシンサービス。

      また、ステートマシンサービスは、以前説明した以下のプロセスサービス実装を呼び出します。

      プロセス実装への呼び出しを実行する .statemachine サービス

それに加えて、base package.program という名前のパッケージは、プログラムごとにプログラムのエントリポイントとなる 1 つのクラスを集めるという、重要な役割を果たします (これについては後で詳しく説明します)。各クラスはプログラムのエントリポイントのマーカーである Program インターフェイスを実装しています。

プログラムエントリポイント

その他のアーティファクト

  • BMS MAPs コンパニオン

    プログラム関連のアーティファクトに加えて、サービスプロジェクトにはさまざまな目的のアーティファクトを含めることができます。CICS オンラインアプリケーションのモダナイゼーションの場合、モダナイゼーションプロセスは JSON ファイルを生成し、/src/main/resources フォルダのマップフォルダに配置します。

    BMS MAPs リソースフォルダ内の JSON ファイル。

    Blu Age ランタイムは、これらの json ファイルを使用して、SENDMAPステートメントで使用されるレコードを画面フィールドにバインドします。

  • Groovy スクリプト

    レガシーアプリケーションにJCLスクリプトがある場合、それらは groovy スクリプトとしてモダナイズされ、/src/main/resources/scripts フォルダに保存されます (その特定の場所については、後で詳しく説明します）。

    groovy スクリプト (JCLモダナイゼーション）

    これらのスクリプトは、バッチジョブ (専用の、インタラクティブではない、CPU 負荷の高いデータ処理ワークロード) を起動するために使用されます。

  • SQL ファイル

    レガシーアプリケーションがSQLクエリを使用していた場合、対応するモダナイズされたSQLクエリが専用のプロパティファイルに収集され、命名パターンプログラム .sql が使用されます。ここで、プログラムは、これらのクエリを使用するプログラムの名前です。

    SQL リソースフォルダ内の ファイル

    これらの sql ファイルの内容は (key=query) エントリの集合で、各クエリは固有のキーに関連付けられており、モダナイズプログラムはこれを使用して特定のクエリを実行します。

    モダナイズされたプログラムが使用するサンプル SQL ファイル。

    例えば、COSGN00C プログラムはキーCOSGN「00C_1」 (sql ファイルの最初のエントリ) を使用してクエリを実行しています。

    プログラム別のクエリ使用例

ユーティリティプロジェクトの内容

名前が「-tools」で終わるユーティリティプロジェクトには、他のすべてのプロジェクトで使用できるテクニカルユーティリティのセットが含まれています。

ユーティリティプロジェクトの内容

ウェブプロジェクトの内容

ウェブプロジェクトはレガシー UI 要素をモダナイズする場合にのみ存在します。モダナイズされたアプリケーションのフロントエンドの構築に使用されるモダン UI 要素は Angular に基づいています。モダナイゼーションアーティファクトを表示するために使用されるサンプルアプリケーションは、メインフレームで実行される COBOL/CICS アプリケーションです。CICS システムは MAPsを使用して UI 画面を表します。すべてのマップにおいて、対応するモダン要素は Typescript ファイルを伴った HTML ファイルになります。

Angular にモダナイズされたサンプルCICSマップ

ウェブプロジェクトは、アプリケーションのフロントエンドの側面のみを処理します。ユーティリティプロジェクトとエンティティプロジェクトに依存するサービスプロジェクトは、バックエンドサービスを提供します。フロントエンドとバックエンド間のリンクは、標準の AWS Blu Age ランタイムディストリビューションの一部である Gapwalk-Application という名前のウェブアプリケーションを介して行われます。

プログラムの実行と呼び出し

レガシーシステムでは、プログラムはスタンドアロンの実行可能ファイルとしてコンパイルされ、必要に応じて引数を渡す COBOLCALLステートメントなどのCALLメカニズムを通じて自分自身を呼び出すことができます。モダナイズされたアプリケーションでも機能は同じですが、関連するアーティファクトの性質が従来のものとは異なるため、別のアプローチを使用します。

モダナイズされた側では、プログラムのエントリポイントは Program インターフェイスを実装する特定のクラス、Spring コンポーネント (@Component) であり、サービスプロジェクト内の base package.program という名前のパッケージにあります。

プログラムの登録

モダナイズされたアプリケーションをホストする Tomcat サーバーが起動するたびに、サービス Springboot アプリケーションも起動し、これによりプログラムの登録が開始されます。ProgramRegistry という名前の専用レジストリにはプログラムエントリが格納され、各プログラムは既知のプログラム ID につき 1 つのエントリを使用して登録されます。つまり、プログラムが複数の異なる識別子で認識されている場合、レジストリには識別子と同じ数のエントリが含まれます。

特定のプログラムの登録は、 getProgramIdentifiers() メソッドによって返される識別子のコレクションに依存します。

プログラム例 (部分ビュー)

この例では、プログラムはCBACT04C回登録されます ( programIdentifiers コレクションの内容を確認します）。tomcat のログには、すべてのプログラムの登録が表示されます。プログラム登録は宣言されたプログラム ID にのみ依存し、プログラムクラス名自体には依存しません (ただし、通常、プログラム ID とプログラムクラス名は一致しています)。

同じ登録メカニズムが、 AWS Blu Age ランタイムディストリビューションの一部であるさまざまなユーティリティ Blu Age AWS ウェブアプリケーションによって提供されるユーティリティプログラムに適用されます。例えば、Gapwalk-Utility-Pgm ウェブアプリは、z/OS システムユーティリティ (IDCAMS、ICEGENER、 など) と同等の機能を提供しSORT、モダナイズされたプログラムやスクリプトで呼び出すことができます。Tomcat のスタートアップ時に登録された利用可能なユーティリティプログラムはすべて Tomcat ログに記録されます。

スクリプトとデーモンの登録

/src/main/resources/scripts フォルダ階層にある groovy スクリプトでも、同様の登録プロセスが Tomcat のスタートアップ時に行われます。scripts フォルダ階層がトラバースされ、見つかったすべての groovy スクリプト (特別な functions.groovy 予約スクリプトを除く) が、そのショートネーム (スクリプトファイル名の最初のドット文字の前にある部分) を取得用キーとして使用して ScriptRegistry に登録されます。

注記

  • 複数のスクリプトのファイル名を使用して同じ登録キーが生成される場合、最後のものだけが登録され、そのキーに対して以前に登録されたものは上書きされます。

  • 登録メカニズムによって階層は平坦になり、予期しない上書きが発生する可能性があるため、サブフォルダを使用する場合は上記の点を考慮してご注意ください。階層は登録プロセスでは考慮されません。通常 /scripts/A/myscript.groovy と /scripts/B/myscript.groovy の順に生成されると /scripts/B/myscript.groovy により /scripts/A/myscript.groovy が上書きされます。

/src/main/resources/daemons フォルダにある groovy スクリプトの扱いは少し異なります。これらは通常のスクリプトとして登録されていますが、それに加えて、Tomcat のスタートアップ時に一度だけ非同期的に直接起動されます。

スクリプトが に登録されるとScriptRegistry、Gapwalk-Application が公開する専用エンドポイントを使用して、REST呼び出しでスクリプトを起動できます。詳細については、対応するドキュメントをご参照ください。

プログラム呼び出しプログラム

各プログラムは他のプログラムをサブプログラムとして呼び出し、パラメータを渡すことができます。プログラムでは、 ExecutionControllerインターフェイスの実装を使用して (ほとんどの場合、これはExecutionControllerImplインスタンスになります）、プログラム呼び出し引数を構築CallBuilderするための という名前の流暢なAPIメカニズムを使用します。

すべてのプログラムのメソッドは RuntimeContext と ExecutionController の両方をメソッド引数と解釈するため、ExecutionController は常に他のプログラムを呼び出すことができます。

例えば、0CBST03A3CBST03B プログラムをサブプログラムとして呼び出し、パラメータを渡す方法を示す次の図を参照してください。

.sub-program の呼び出し例

  • ExecutionController.callSubProgram の最初の引数は、呼び出すプログラムの識別子です (つまり、プログラム登録に使用される識別子のうちの 1 つです。上の段落を参照してください)。

  • 2 番目の引数は、CallBuilder をビルドした結果で、呼び出し元から呼び出し先に渡されたデータに対応する Record の配列です。

  • 3 番目の、最後の引数は呼び出し元の RuntimeContext インスタンスです。

3 つの引数はすべて必須で NULL にできませんが、2 番目の引数は空の配列でも構いません。

呼び出し先が渡されたパラメータを処理できるのは、元々そのように設計されていた場合のみです。レガシーCOBOLプログラムの場合、つまり、プロシージャ部門が LINKAGE要素を利用するための LINKAGE セクションと USING句があることを意味します。

例えば、対応する CBSTM03B CBLCOBOLソースファイルを参照してください。

COBOL ソースファイル内のサンプルリンク

したがって、CBSTM03B プログラムは 1 つの をパラメータ (サイズ 1 の配列) Recordとして受け取ります。これは、 byReference() および getArguments() メソッドの連鎖を使用して CallBuilderが構築したものです。

CallBuilder fluent API クラスには、発信者に渡す引数の配列を入力するためのいくつかのメソッドがあります。

  • asPointer（RecordAdaptable) : 参照によりポインターの型の引数を追加します。ポインタは対象となるデータ構造のアドレスを表します。

  • byReference（RecordAdaptable): 参照により引数を追加します。呼び出し側は呼び出し先が実行する変更を確認します。

  • byReference（RecordAdaptable): 前のメソッドの varargs バリアント。

  • byValue（オブジェクト): 値Recordごとに に変換された引数を追加します。呼び出し側は呼び出し先が実行する変更を確認しません。

  • byValue（RecordAdaptable): 前のメソッドと同じですが、 引数は として直接使用できますRecordAdaptable。

  • byValueWithBounds(Object, int, int): 引数を追加し、 に変換してRecord、指定された境界で定義されたバイト配列部分を値別に抽出します。

最後に、 getArguments メソッドは追加されたすべての引数を収集し、 の配列として返しますRecord。

注記

呼び出し元は、引数の配列が必要なサイズであること、項目が適切に順序付けられており、リンケージ要素で想定されるレイアウトとメモリレイアウトに関し互換性があることを確認する責任があります。

スクリプト呼び出しプログラム

登録済みプログラムを groovy スクリプトから呼び出すには、その MainProgramRunner インターフェイスを実装するクラスインスタンスを使用する必要があります。通常、このようなインスタンスの取得は Spring ApplicationContext の使用を通じて実現されます。

.MainProgramRunner : インスタンスの取得

MainProgramRunner インターフェイスが使用可能になったら、 runProgram メソッドを使用してプログラムを呼び出し、ターゲットプログラムの識別子をパラメータとして渡します。

MainProgramRunner : プログラムの実行

前の例では、ジョブステップが IDCAMS (ファイル処理ユーティリティプログラム) を呼び出し、実際のデータセット定義とその論理識別子間のマッピングを提供します。

データセットを扱う場合、レガシープログラムではたいてい論理名を使用してデータセットを識別します。プログラムをスクリプトから呼び出す場合、スクリプトは論理名と実際の物理データセットとマッピングする必要があります。これらのデータセットは、ファイルシステム上、Blusam ストレージ内、インラインストリーム、複数のデータセットの連結、または の生成によって定義される場合がありますGDG。

withFileConfiguration メソッドを使用して、データセットの論理マップと物理マップを構築し、呼び出されたプログラムで使用できるようにします。

独自のプログラムの作成

スクリプト、またはその他のモダナイズされたプログラムを呼び出すために、独自のプログラムを作成するのはよくある作業です。通常、モダナイゼーションプロジェクトでは、実行可能なレガシープログラムがモダナイゼーションプロセスでサポートされていない言語で書かれていたり、ソースが失われた場合 (これは発生する場合があります)、またはプログラムがソースを利用できないユーティリティだったりする場合に、独自のプログラムを作成します。

その場合、足りないプログラムを java で、自分で書かなければならない場合があります (プログラムの期待される動作がどうあるべきか、プログラムの引数のメモリレイアウト (ある場合) などについて十分な知識があることを前提としています)。java プログラムは、他のプログラムやスクリプトで実行できるように、このドキュメントで説明されているプログラムの仕組みに準拠している必要があります。

プログラムが使用に適していることを確認するには、次の 2 つの必須ステップを完了する必要があります。

  • Program インターフェイスを正しく実装するクラスを作成して、登録および呼び出すことができるようにしてください。

  • 他のプログラムやスクリプトから見えるようにするため、プログラムを正しく登録してください。

プログラム実装の記述

IDE を使用して、Programインターフェイスを実装する新しい Java クラスを作成します。

新しい java プログラムクラスの作成

次の図はIDE、実装するすべての必須メソッドの作成を処理する Eclipse を示しています。

新しい java プログラムクラスの作成 - ソースの編集

Spring との統合

まず、クラスを Spring コンポーネントとして宣言する必要があります。クラスに以下の @Component アノテーションを付けます。

spring @Component アノテーションの使用

次に、必要なメソッドを正しく実装します。このサンプルのコンテキストでは、モダナイズされたプログラムがすべて含まれているパッケージに MyUtilityProgram を追加しました。この配置により、プログラムは既存の Springboot アプリケーションを使用してメソッドの getSpringApplication 実装ConfigurableApplicationContextに必要な を提供できます。

getSpringApplication メソッドを実装します。

独自のプログラムでは別の場所を選択することもできます。例えば、特定のプログラムを別の専用サービスプロジェクトに配置する場合があります。特定のサービスプロジェクトに独自の Springboot アプリケーションがあることを確認します。これにより、 を取得できます ApplicationContext ( である必要がありますConfigurableApplicationContext）。

プログラムに識別子を与える

他のプログラムやスクリプトから呼び出せるようにするには、そのプログラムに少なくとも 1 つの識別子を与える必要があります。その識別子は、システム内の既存の登録済みプログラムと衝突することはできません。識別子の選択は、既存のレガシープログラムの置き換えをカバーする必要性によって決まる場合があります。その場合、レガシープログラム全体で見つかったCALL出現に応じて、期待される識別子を使用する必要があります。レガシーシステムでは、ほとんどのプログラム識別子は 8 文字です。

その 1 つの方法はプログラム内で変更できない識別子のセットを作成することです。次の例は、単一の識別子MYUTILPGとして「」を選択する方法を示しています。

プログラム識別子の例

プログラムをコンテキストに関連付ける

プログラムにはコンパニオン RuntimeContext インスタンスが必要です。モダナイズされたプログラムの場合、 AWS Blu Age はレガシープログラムの一部であるデータ構造を使用してコンパニオンコンテキストを自動的に生成します。

独自のプログラムを作成する場合は、コンパニオンコンテキストも作成する必要があります。

プログラム関連クラス を参照すると、プログラムには少なくとも以下の 2 つのコンパニオンクラスが必要であることがわかります。

  • 設定クラス。

  • 設定を使用するコンテキストクラス。

ユーティリティプログラムが追加のデータ構造を使用する場合は、そのデータ構造も記述してコンテキストで使用する必要があります。

これらのクラスは、コンテキストのコンポーネントと構成が Spring フレームワークによって処理されるようにするために、アプリケーションのスタートアップ時にスキャンされるパッケージ階層に含める必要があります。

エンティティプロジェクトで新しく作成した base package.myutilityprogram.business.context パッケージに、最小限の設定とコンテキストを記述してみましょう。

新しいユーティリティプログラムのための新しい専用設定とコンテキスト

設定内容は次のとおりです。近くにある他の (モダナイズされた) プログラムと類似した設定ビルドを使っています。おそらく、特定のニーズに合わせてカスタマイズする必要があります。

新しいプログラムの設定

注記:

  • 一般的な命名規則はProgramName設定です。

  • @org.springframework.context.annotation.Configuration アノテーションと @Lazy アノテーションを使用する必要があります。

  • Bean 名は通常 ProgramNameContextConfiguration 規則に従いますが、必須ではありません。プロジェクト全体で bean 名が競合しないようにしてください。

  • 実装する単一メソッドは Configuration オブジェクトを返す必要があります。fluent ConfigurationBuilder APIを使用して構築します。

関連するコンテキスト:

Java ファイル内の新しいプログラムコンテキスト。

メモ

  • コンテキストクラスは、既存のContextインターフェイス実装を拡張する必要があります ( RuntimeContextまたは のいずれか。これはJicsRuntimeContext、JICS特定の項目RuntimeContextで拡張された です）。

  • 一般的な命名規則はProgramNameコンテキストです。

  • これをプロトタイプコンポーネントとして宣言し、@Lazy アノテーションを使用する必要があります。

  • コンストラクタは関連付けされた設定を参照し、@Qualifier アノテーションを使って適切な設定クラスをターゲットにします。

  • ユーティリティプログラムがいくつかの追加のデータ構造を使用する場合、以下のようにする必要があります。

    • base package.business.model パッケージに記述および追加されます。

    • コンテキストで参照します。他の既存のコンテキストクラスを見て、データ構造クラスを参照し必要に応じてコンテキストメソッド (コンストラクタ、クリーンアップ、リセット) を適応させる方法を確認してください。

専用のコンテキストが用意できたので、新しいプログラムでそれを使用しましょう。

新しいプログラムは、新しく作成されたコンテキストを使用します。

注記:

  • getContext メソッドは、 ProgramContextStoreクラスの getOrCreate メソッドへの委任と自動有線 Spring を使用して、図のように厳密に実装する必要がありますBeanFactory。プログラムコンテキストを ProgramContextStore に保存するには単一のプログラム識別子が使用されます。この識別子は「プログラムのメイン識別子」と呼ばれます。

  • コンパニオン設定クラスとコンテキストクラスは @Import Spring アノテーションを使用して参照する必要があります。

ビジネスロジックの実装

プログラムスケルトンが完成したら、新しいユーティリティプログラムのビジネスロジックを実装します。

これをプログラムの run メソッドで行います。この方法は、プログラムが呼び出されるたびに、別のプログラムまたはスクリプトによって実行されます。

コーディングおめでとう!

プログラム登録の処理

最後に、新しいプログラムが正しく ProgramRegistry に登録されていることを確認します。既に他のプログラムが含まれるパッケージに新しいプログラムを追加した場合は、何もする必要はありません。新しいプログラムは、アプリケーションのスタートアップ時にすべての隣接プログラムに取り込まれ、登録されます。

プログラム用に別の場所を選択した場合は、Tomcat のスタートアップ時にそのプログラムが正しく登録されていることを確認する必要があります。これを行う方法に関する注意点については、サービスプロジェクト (複数可) で生成された SpringbootLauncher クラスの初期化方法を参照してください (「」を参照）サービスプロジェクトの内容。

Tomcat のスタートアップログを確認してください。すべてのプログラム登録が記録されます。プログラムが正常に登録されていると、一致するログエントリが見つかります。

プログラムが正しく登録されたことを確認したら、ビジネスロジックのコーディングの繰り返しを始めることができます。

完全修飾名マッピング

このセクションには、モダナイズされたアプリケーションで使用する AWS Blu Age とサードパーティーの完全修飾名マッピングのリストが含まれています。

AWS Blu Age 完全修飾名マッピング

短縮名 完全修飾名

CallBuilder

com.netfective.bluage.gapwalk.runtime.statements.CallBuilder

Configuration

com.netfective.bluage.gapwalk.datasimplifier.configuration.Configuration

ConfigurationBuilder

com.netfective.bluage.gapwalk.datasimplifier.configuration.ConfigurationBuilder

ExecutionController

com.netfective.bluage.gapwalk.rt.call.ExecutionController

ExecutionControllerImpl

com.netfective.bluage.gapwalk.rt.call.internal.ExecutionControllerImpl

File

com.netfective.bluage.gapwalk.rt.io.File

MainProgramRunner

com.netfective.bluage.gapwalk.rt.call.MainProgramRunner

Program

com.netfective.bluage.gapwalk.rt.provider.Program

ProgramContextStore

com.netfective.bluage.gapwalk.rt.context.ProgramContextStore

ProgramRegistry

com.netfective.bluage.gapwalk.rt.provider.ProgramRegistry

Record

com.netfective.bluage.gapwalk.datasimplifier.data.Record

RecordEntity

com.netfective.bluage.gapwalk.datasimplifier.entity.RecordEntity

RuntimeContext

com.netfective.bluage.gapwalk.rt.context.RuntimeContext

SimpleStateMachineController

com.netfective.bluage.gapwalk.rt.statemachine.SimpleStateMachineController

StateMachineController

com.netfective.bluage.gapwalk.rt.statemachine.StateMachineController

StateMachineRunner

com.netfective.bluage.gapwalk.rt.statemachine.StateMachineRunner

サードパーティーの完全修飾名マッピング

短縮名 完全修飾名

@Autowired

org.springframework.beans.factory.annotation.Autowired

@Bean

org.springframework.context.annotation.Bean

BeanFactory

org.springframework.beans.factory.BeanFactory

@Component

org.springframework.stereotype.Component

ConfigurableApplicationContext

org.springframework.context.ConfigurableApplicationContext

@Import

org.springframework.context.annotation.Import

@Lazy

org.springframework.context.annotation.Lazy