製品ルール

アプリケーションはルール、ルールセット、アプリケーションデータ、システムデータ、およびデータベーススキーマなど、他のオブジェクトで構成されます。 アプリケーションを本番環境に移行する際に、アプリケーションとそのコンポーネントをPegaシステム間で移行する必要があります。 たとえば、アプリケーションを開発環境からテスト環境に移行し、最後に本番システムに移行します。 場合によっては、パッチリリースに含まれる更新されたルールセットやデータタイプなど、特定のアプリケーションコンポーネントのみを移行する必要があります。

次のシナリオについて考えてみてください。家の引っ越しで、移動する荷物のリストを作ることがあります。 作り付けの家具、設備の配管、電気の配線などは、引越し先の家にすでに備え付けられているため、リストには含めません。 次に、荷物リストの荷物を引越トラックに積み込みます。 トラックが目的地に到着したら、トラックから荷物を取り出し、各アイテムを開梱します。

前の例で説明した荷物リストと同様に引越し先となるPega Platformシステムに移動するアプリケーションコンポーネントを識別する製品ルールを作成します。 製品ルールには、アプリケーションを構成するルールセット、データ、その他のオブジェクトがリストアップされます。 通常、製品ルールには標準ルールセットやデータは含まれません。これらのコンポーネントはすべてのPega Platformシステムに組み込まれているためです。 製品ルールは、「Rule-Admin-Product」クラスのインスタンスで、RAPとも呼ばれます。

「Product」ルールから「Product Preview」ダイアログにアクセスすると、アプリケーションのコンテンツの概要を確認できます。

次の画像で、「+」アイコンをクリックすると、「Product Preview」ダイアログの詳細が表示されます。

Pega Platformでは、製品ルールを使用してアーカイブファイルを作成し、選択したコンテンツのエクスポートやインポートを行います。 引越トラックに荷物を積み込むのと同じように、製品ルールのコンテンツを、ZIPまたはJAR方式のいずれかを使用して圧縮アーカイブファイル（RAPファイルとも呼ばれる）に移動します。 アーカイブファイルを移動先システムにコピーし、ファイルのコンテンツをシステムにインポートします。

次のビデオでは、アプリケーション移行の基本について説明します。

動画のスクリプト

アプリケーションの開発過程では、通常、アプリケーションは複数の環境にまたがって移行していきます。 一般的に、アプリケーションはひとつの環境で開発され、別の環境でQAされ、また別の環境でユーザー受入テストを行い、最終的にリリースの準備ができた時点で本番環境に移行します。

環境間の移行は、どの開発サイクルでも常に発生することです。 このような速いペースは、通常、時間的制約のあるホットフィックスやアップデートの必要性によるものですが、アプリケーションの移行中に問題を引き起こす可能性があります。 正しく行われないと、一部の機能やユーザーグループ、外部システムデータなどが抜けたままアプリケーションが移行される可能性があります。アプリケーションの重要なコンポーネントをすべて統合したパッケージを作成する統合移行ウィザードを使用すれば、安全な移行を簡単に計画することができます。

Application packagingウィザード

製品ルールの作成時やRAPファイルの生成時のエラーの発生を防ぐため、Pega Platformでは、一連のステップで製品ルールを作成するのに役立つApplication Packagingウィザードというツールが用意されています。 ウィザードでは、各ステップで含めるアイテムが特定されるため、デベロッパーは不足のあるコンポーネントを特定できます。 たとえば、Google APIキーなどの標準ルールセットに関連付けるカスタマイズデータインスタンスは、手動で追加できます。 ルールフォーム自体から製品ルールを変更することもできます。

データインスタンスをルールセットに関連付けることで、アプリケーションの移行やメンテナンスが容易になります。 移行するアプリケーションをパッケージングする場合は、アプリケーションのルールセットを含めます。 ただし、ルールセットはルールの集合体にとなり、オペレーターID、アクセスグループ、データベーステーブル、データベースなどのデータインスタンスは含まれません。

データインスタンスのパッケージングや移行を容易にするために、データインスタンスとルールセットを関連付けておきます。 こうすることにより、製品ルールで各データインスタンスを指定する必要はなくなります。 製品ルールを作成する際、システムではデータインスタンスがアーカイブファイルに自動的に追加されます。

ベストプラクティスとして、データインスタンスはルールセットを関連付けておきます。 手動またはウィザードを使用して特定のクラスのデータインスタンスを作成すると、システムではインスタンスがアプリケーションのルールセットの1つに自動的に関連付けられます。

関連するルールセットがルールヘッダーに表示されます。 次の例は、Purchasingルールセットに関連付けられているアクセスグループに関するものです。 「Edit」をクリックすると、関連するルールセットを変更できます。 「Associated RuleSet」ポップアップダイアログでルールセットを更新します。

ルールセットを削除すると、データインスタンスはどのルールセットに対しても関連しなくなります。 たとえば、開発またはテスト専用のオペレーターを作成したとします。 これらのオペレーターIDからルールセットの関連付けを削除することで、自動的にエクスポートされないようにできます。 関連するルールセットを削除すると、ガードレールワーニングが表示されます。

データインスタンスをルールセットに関連付けても、実行時の動作が影響を受けたり、制限されたりすることはありません。 データインスタンスは、関連するルールセットに関係なく、すべてのアプリケーションで引き続き使用できます。

ユーザーがアクセスできるルールセットにルールをインポートした場合、ルールの実行をただちに開始できます。 これらのルールは、同じアーカイブ内のすべてのルールがインポートされる前に実行できる場合があります。 同じ理由で宣言型のルールではすぐに実行を開始できます。 このことは宣言型のプロセスで参照する要素やプロパティのアップロードが済んでいない場合は、宣言型のプロセスが失敗する可能性があることを意味しています。 このため、アクティブユーザーがいるシステムにアーカイブをインポートする場合は、計画が必要です。

以下のインタラクションで理解度をチェックしてください。