BookingアプリケーションとFSGアプリケーションの作成

Pega Academyでは、学習したことを実践する機会を提供しています。

Pega Academyでは、演習を行うためのさまざまなタイプの演習システムを用意しています。

1. Cloudインスタンス（オンライン）
2. 仮想マシン（VM）（オフライン）

Cloudインスタンス（利用可能な場合）は、シナリオチャレンジインストラクションにある「Initialize Pega」ボタンをクリックしてアクセスできます。

VMは、仮想マシンを圧縮して「インストール可能」な状態にしたOVA（Open Virtualization Archive）ファイルとして提供されます。  

Virtual Box（Windows、macOS）、VMWare Player（Windows）、VMware Fusion（macOS）など、任意のVMプレーヤーをお使いいただけます。 VMプレーヤーのダウンロードとインストールは各自の責任で行ってください。

演習用VMアーカイブ

演習用のVMは、仮想マシンを圧縮して「インストール可能」な状態にした.ova（Open Virtualization Archive）ファイルとして提供されます。 VMの.ovaファイルとそれに対応するチェックサム（.md5）は、以下のリンクからダウンロードできます。

LinuxLite-Pega861.ova 

LinuxLite-Pega861.md5

.ovaファイルは7.5GBで、ダウンロードに時間がかかることがあります。 ファイルサイズが大きいため、ChromeまたはMozillaを使用してダウンロードすることをお勧めします。 .ovaファイルをダウンロードした後、チェックサムファイル（.md5）を使って、.ovaファイル内のデータが完全であり、ダウンロード中に破損していないことを確認できます。 ダウンロード後、ファイルの拡張子が.tar（Tape Archive）の場合は、チェックサムを実行する前に、またはインポートする前に、.tarファイルの拡張子を.ovaに変更します。  Windows、macOS、Linuxには、チェックサムを生成するユーティリティが組み込まれています。 たとえば、Windowsの場合、Windows PowerShellから「Get-FileHash LinuxLite-Pega861.ova -Algorithm MD5」というコマンドを実行できます。 

Microsoft Internet Explorer、Microsoft Edge、またはGoogle Chromeを使用している場合は、Pega_Virtual_Machine_User_Guide_85.pdfで演習用VMを正しく構成するための重要な情報をお読みください。

仮想化ソフトウェア（VMプレーヤー）を使って、.ovaファイルを開いてインポートし、展開します。

PegaではVMプレーヤーを提供していませんが、Virtual Box（Windows、macOS）、VMWare Player（Windows）、VMware Fusion（macOS）のいずれかを使用することを推奨しています。 OVAファイルをダウンロードしてインポートし、推奨されるVMプレーヤーでVMを実行する方法については、「Virtual Machine User Guide」に詳細が記載されています。 VMプレーヤーのダウンロードとインストールは各自の責任で行ってください。

Linux-Lite VMをインストールしたら、コースの最初に提供されるFSG予約ソリューションのRAP（Rule Application Product）ファイルをPega Platformにインポートする必要があります。  RAPファイルのインポートですべてのオペレーターIDを有効にするには、「Enable advanced mode to provide more granular control over the import process」および「Enable new operators and overwrite existing operators on import」の各オプションを有効にします。

Bookingアプリケーションの要件を分析した結果、次の結論が得られました。 

• このアプリケーションには、Divide-and-Conquer（分割統治）設計パターンが最も適している。
• サブケースの階層化は、同一ケースの並列プロセスを使用するよりも優れたアプローチである。
• Weatherサブケースが1つ無条件に作成される。
• Parkingサブケースが1つ条件付きで作成される。
• Rooms Requestサブケースが、選択された各ホテルにつき1つ条件付きで作成される。

PegaRULESアプリケーションにはPegaSampleという名前のクラスグループがあります。 このクラスグループの目的は、Pega Platform™の特徴と機能を示すことです。 PegaSample クラスグループに関連付けられているレコードの数は、PegaRULESアプリケーションの他の部分と比較すると非常に少なくなっています。 ただし、PegaSampleのレコードが本番アプリケーションで使われることはありません。 PegaSampleアプリケーションはPegaRULESをベースに構築された別のアプリケーションとしてパッケージ化されている場合があります。

エンタープライズアプリケーションには、ケースタイプを含める必要はありません。 エンタープライズアプリケーションの主な目的は、標準化されたビジネスオブジェクトデータモデルに加え、ライブラリなど他の再利用可能なレコードタイプを提供することです。 この説明は、理論的にはFSGのセンターオブエクセレンス（COE）グループが管理するFSG Enterpriseアプリケーションについての記述です。 FSGアプリケーション自体には、ケースタイプは含まれていません。 FSGEmailなど、COEグループが管理する他のアプリケーションは、FSGアプリケーションをベースに構築されており、ケースタイプが含まれています。

New Applicationウィザードで作成したどのアプリケーションにも、ワークプールクラスとクラスグループが含まれています。 New Applicationウィザードを使用すると、ORG-APP-[Data/Work/Int/UIPages]で始まるクラスとORG-[Data/Int]で始まるクラスが出力されます。 New Applicationウィザードで「Framework」を選択した場合でも、ORG-FW抽象クラスが作成されますが、使用しない場合は無視して構いません。

PegaRULESがPegaSampleを使用するのと同様に、エンタープライズアプリケーションに含まれる機能をテストし、デモを行う方法を用意する必要があります。 PegaRULESと同様に、エンタープライズアプリケーションは、そのテストやデモのレコードをアプリケーション内に含める必要はありません。 その代わりに、エンタープライズアプリケーションをベースとしてテストとデモのためのアプリケーションを構築できますが、ここで、エンタープライズアプリケーションをどのように構築するかという点が問題になります。

FSG Enterpriseアプリケーションは、New ApplicationウィザードでFSGSampleという名前のアプリケーションを作成することで構築されます。 当初のアプリケーションには、下の表のFSGSample App BEFORE 列にリストされている4つのルールセットが含まれています。

次に、FSGSampleアプリケーションのコピーが、FSGルールセットにFSGとして保存されます。 さらに、FSG とFSGInt の各ルールセットが、FSGSampleの定義の中で、アプリケーションルールセットスタックから削除されます。 削除されたルールセットの代わりに、FSGSampleアプリケーションでは、FSGアプリケーションが組み込みアプリケーションとして宣言されます。 一方で、FSGアプリケーションでは、FSGSample とFSGSampleInt の各ルールセットがルールセットスタックから削除されます。 

FSGアプリケーションを有効にするためには、いくつかの変更が必要です。まず、一般的なCosmosSkinや他のFSG組織レベルのスキンなど、利用可能なスキンルールを選択します。 また、「Cases and Data」タブの「Associated Classes」セクションでは、有効なクラスを参照するためにクラス名を更新する必要があります。 たとえば、FSGアプリケーションの場合、すべてのORGクラスがWork-Cover- を継承しているため、参照されるクラスはFSG固有のものである必要があります。FSGクラスをクラスグループとして宣言することで、App ExplorerにFSGクラスが表示されるようになります。 最後に、「Application Wizard」タブを編集して、FSGアプリケーションを組み込みアプリケーションとして使用するという意思表示をします。

一貫性を持たせるために、FSG およびFSGInt ルールセットの「Validation mode 」を「Ruleset Validation」から「Application Validation」に変更します。 このオプションを使用して、任意の時点においてどのバージョンのFSG ルールセットが他のアプリケーションで使用されるかを、より詳細にコントロールできます。

Bookingチームは、FSGアプリケーションをベースにしてBookingアプリケーションを自分たちで構築できます。 一方で、BookingアプリケーションはFSGの成功に不可欠であると考えられているため、センターオブエクセレンス（COE）チームは、BookingアプリケーションのBookEventケースの最初のステージを定義し、残りの部分をBookingチームに開発してもらう方法が最善であると考えています。

COEがこの方法を採用する理由は、価格設定が適切に初期化されるようにするためです。 また、COEでは、「Customer」がFSG-Data-Contact参照として実装され、イベントの会場がFSG-Data-Venue参照として実装されるようにしたいと考えています。 CustomerDataスキーマの顧客情報をBLOB外に保存することで、リピート客が別のイベントを予約する際に同じ情報を再入力する必要がなくなります。

Bookingチームは、高度にモジュール化された方法でアプリケーションを開発することにします。 これにより、より多くのコーディングを並行して行うことができ、スピーディーな開発が可能になります。 加えて、Bookingチームは、将来的にアプリケーションをリファクタリングして1つまたは複数のサブケースを再利用可能なコンポーネントアプリケーションに分解することは考えていません。 小規模なアプリケーションは柔軟性が高く、メンテナンスやデプロイが容易です。 この戦略は、モノリシックアプリケーションを避けるマイクロサービス戦略に似ています。

Bookingアプリケーションを開発してテストするためには、組み込みアプリケーション内で定義されたすべてのケースタイプは、直接継承を使用して拡張する必要があります。 拡張された各組み込みケースタイプはBookEventケースの子ケースとして実装されます。 Bookingチームは最初に、Bookingアプリケーション内で作成する各子ケースタイプごとに、ルールセットを作成します。 Bookingチームは次に、対応する各ルールセットの中に、子ケースを作成します。 その後で、生成されたケースタイプクラスの直接継承は、対応する組み込みアプリケーションのケースタイプのクラスに変更されます。 最後に、各Bookingアプリケーションの子ケースタイプルールセットに生成されたCase Typeルールが削除されました。

BookingアプリケーションのCase Designerで、WeatherPrep、BookingParking、RoomsRequestの各ケースタイプは、Case Typeルールが存在しないため、編集できません。 Case Designerの編集は、組み込みのWForecast、Parking、Hotelの各アプリケーション内で行われます。 この手法により、「2つのアプリケーションが同時に編集される」という問題を回避し、間違ったレイヤーやルールセットにルールが組み込まれないようにします。

このアプローチはBookingチームにとっても首尾よく動作し、結果は満足のいくものになりました。 よくあることですが、開発中に不要または陳腐化していると判断されたいくつかのルールは消去されます。 すべてのルールセットに対して大規模なスキミングが行われ、不要なルールや陳腐化したルールは表示されなくなります。