Skip to main content

Pegaアプリケーションのルール

チェスをするとき、あなたと対戦相手はいくつかの特定の指示に従うことに同意します。 これらの指示は、それぞれの駒がゲームボード上でどのように動くかなどの、ゲームの進行を左右します。 たとえば、ポーンは最初の一手で前方へ1マスか2マス進むことができます。 こうした基本的な指示がチェスのルールとなります。

Chess game play analogy for Pega rules using the pawn piece

同様に、Pega Platformのアプリケーションでケースタイプをモデル化する場合は、ケースを作成、処理、完了するための手順を使用してアプリケーションを構成します。 こうしたインストラクションが、ケースタイプのルールです。

ルールは、プロジェクトチームがクライアント組織とその顧客向けにビジネスソリューションを作成する際に設定できる、Pegaアプリケーションの基本的なビルディングブロックです。 Pega Platformでは、ルールを使用してバックグラウンドでJavaアプリケーションコードを生成します。 Pega Platformアプリケーションには、さまざまなタイプのアプリケーション動作を指定する多くのタイプのルールが含まれています。 ルールは柔軟で再利用可能であり、プロジェクトチームはアプリケーション機能をより効率的に設計し、複数のケースタイプとアプリケーションに実装できます。

このトピックでは、ルールの詳細を確認します。 

App Studioでの自動ルール作成

Pegaのローコードアプローチでは、特にアプリケーション開発プロセスの初期段階において、ユーザーがApp Studioでアプリケーション設計作業の多くを完了できます。 App Studioでワークフローの自動化を追加すると、Pega PlatformはDev Studioで基盤となるルールを自動的に作成および管理します。 たとえば、App Studioでケースタイプを設定する場合、Case Life Cycle Designerと設定パネルを使用して、Collect informationステップにビューを追加します。 バックグラウンドでは、プロセスフローとUIを定義するルールがPega Platformによって作成・管理されています。

以下の図の中央で縦線をスライドして、App Studioで作成したケースのライフサイクルとプロセス、バックグラウンドでシステムが作成したプロセスのフロールールを確認してください。

補足: ケースライフサイクルの各ステップは、フロールールのシェープに対応しています。 フローコネクターは、あるシェープを別のシェープにリンクし、あるシェープ(ステップ)から次のシェープに到達するためにユーザーが完了すべきタスクまたはアサインメントを表します。

App Studioのユーザーフレンドリーなインターフェイスを使用して複雑なルールを作成できる機能は、Pega Platformのローコード機能にとって重要です。

すべての技術スキルレベルのデベロッパーはApp Studioでローコード、ビジュアルモデリングを使用してワークフローの自動化を作成している間、Pega Platformはその自動化に対応するテクニカルルールをバックグラウンドで作成しています。 その結果、プロジェクトチームに参加しているビジネスアーキテクトやシチズンデベロッパーなど、あまり技術力の高くないデベロッパーは、コードではなくビジネスタスクの定義に集中できます。 

補足: テクニカルルールには、Dev Studioを通じて、技術力の高いデベロッパーがアクセスできます。 デベロッパーがDev Studioで作成する高度なテクニカルルールは、App Studioでユーザーが利用できるようにすることができます。

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

ルールによるアプリケーションのモジュール化

個々のルールを使用すると、アプリケーションがモジュール化されます。 モジュールかつタスクに焦点を当てたルールを使用してケースの動作を記述することで、必要に応じてルールを組み合わせて再利用できます。 たとえば、住所変更に際して顧客に送信するメールの内容を記述するルールが作成されます。 ケースライフサイクルにメールメッセージを埋め込むのではなく、メッセージを別のルールとして作成することで、他のビジネスプロセスに影響を与えることなくメールの内容を更新できます。

このモジュール方式にはバージョニング、委任、再利用という3つの大きなメリットがあります。

バージョニング  デベロッパーは、ケースの動作を変更する必要が生じるたびに新しいバージョンのルールを作成します。 Pega Platformはルールの変更履歴を保持するため、デベロッパーは変更履歴を確認し、必要に応じて変更を元に戻すことができます。 各ルールはケースの特定の動作を記述するため、ケースの他の部分は影響を受けません。 たとえば、デベロッパーは、指示に従ってUIフォームを更新し、重要なフィールドを削除します。 アプリケーションの他のルールを変更することなく、フォームの履歴を確認して、変更が行われる前のバージョンに戻すことができます。
委任  デベロッパーは、ビジネス条件が変更された場合にビジネスユーザーがケースの動作を更新できるように、ビジネスユーザーにルールを委任します。 ビジネスユーザーが委任されたルールを更新しても、アプリケーションの他の部分は変更されません。 たとえば、合計25米ドル以下の経費報告については、自動承認が行われます。 経費報告の合計が25米ドル以下であるかどうかをテストするためのルールを作成し、該当するルールを経理部署に委任します。 その後、経理部署は、アプリケーションの変更要求を提出する必要なく、自動承認のしきい値を50米ドルに引き上げるようにルールを更新できます。
再利用  デベロッパーは、アプリケーションが既存のケースの動作を組み込む必要がある場合に、いつでもルールを再利用します。 それ以外の場合は、動作の必要が生じるたびに動作を再設定する必要があります。 たとえば、UIフォームを作成して、自動車保険請求の契約者情報を収集します。 その後、このUIフォームを財産保険の請求および海上保険の請求に再利用できます。
補足: ルールを委任する方法については、「Delegating a rule or data type」を参照してください。 ルールの再利用性を高めるには、パラメーター化を活用し、ハードコードされたデータではなく、パラメーターとして渡された値に基づいてルールのロジックが駆動するようにします。 パラメーター化はコードの重複を防ぎ、ルールの特殊化の実装に要する時間を削減するのに役立ちます。 パラメーター化の詳細については、「Defining the input parameters of a rule」を参照してください。

ルールの整理

Dev Studioでアプリケーションルールを直接操作する時間はありませんが、リードシステムアーキテクトと協力してアプリケーションのルールの整理方法を理解することは重要です。

Dev Studioでは、ルールはクラスとルールセットにグループ化されているため、アプリケーションの開発に簡単に使用できます。

クラス

Pegaにおいて、クラスは、再利用の可能性に応じてシステムがグループ化するルールのコレクションを記述します。 各アプリケーションは、次の3つのタイプのクラスで構成されます。

  • ワーククラス:ワーククラスには、プロセス、データ要素、ユーザーインターフェイスなど、ケースを処理するエンドツーエンドの「ワーク」を定義するルールが含まれています。
  • データクラス: データクラスには、アプリケーションが使用するデータオブジェクトを定義するルールが含まれています。
  • インテグレーションクラス: インテグレーションクラスには、クライアントが管理する外部データベースなど、アプリケーションと外部のシステムオブレコード間のインタラクションを定義するルールが含まれています。

親クラスと子クラス

クラスには他のクラスを含めることができます。 別のクラスが含まれているクラスは親クラスと呼ばれ、別のクラスに含まれているクラスは子クラスと呼ばれます。 子クラスは、その親クラスに定義されているルールを再利用、つまり継承できます。

次の図で、「+」アイコンをクリックすると、親子クラスの詳細が表示されます。

補足: Pegaアプリケーションのクラスの詳細については、「ルールのクラスへの整理」を参照してください。

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

ルールセット

ルールはルールセットに整理され、アプリケーションを定義するルールの完全なセットを識別、保存、管理します。 ルールセットには、あるPegaアプリケーションから別のアプリケーションに移行できる再利用可能な機能が保存されます。 たとえば、サービスレベルアグリーメント(SLA)ルールを保存するルールセットを作成できます。 SLAルールセットは、同じSLAを必要とする、ケースを処理する任意のアプリケーションで再利用できます。 ルールセットを保存して再利用できる機能により、時間を短縮し、クライアント向けアプリケーション開発のコストを削減できます。

各ルールセットには、アプリケーションの名前などの名前と、バージョン番号があります。 新しいルールセットを作成すると、デフォルトバージョンは01-01-01になります。 ルールセット名とバージョンの組み合わせの例としては、GoGoRoad 01-01-01になります。

バージョン番号は、メジャーバージョンマイナーバージョンパッチバージョンの3つのセグメントに分けられます。 各セグメントは、01から99までの2桁の数字です。 ルールセットのバージョンの番号は、01-01-01から始まり、値が増加していきます。

次の図で「+」アイコンをクリックすると、ルールセットのバージョニング規則の詳細が表示されます。

2023年から、Pega Infinity製品バージョンは、Year.Minor.Patchという形式に準拠しています。 Pega Infinity '23の場合、製品バージョンは23.1.1です。 Pegaルールセットのセマンティックバージョニングは、 Major-Minor-Patch形式に準拠しています。 Pega Infinity '23の場合、ルールセットバージョンは08-23-02です。

補足: Pega Infinity™ '23は最新のマイナーリリースです。 Pega Infinity製品の命名規則の詳細については、「Pegaソフトウェアのメンテナンスプログラム」を参照してください。

ロックされたルールセットおよびロック解除ルールセット

ルールセットが作成されると、ロックまたはロック解除のいずれかが指定されます。 デベロッパーはロック解除ルールセットで作業し、ルールセットのロックによってデベロッパーが誤って変更することを防ぎます。 デベロッパーは、ロックされたルールセットのロックを解除して編集する前に、パスワードを入力する必要があります。

補足: Pegaアプリケーションのルールセットの詳細については、「ルールのルールセットへの整理」を参照してください。

リードシステムアーキテクト(LSA)は、開発プロセス中にアプリケーションに関連するルールセットのバージョニングとロック設定の両方を管理します。 ルールやルールセットに関する質問が生じた場合は、プロジェクトのLSAに相談してください。

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


このトピックは、下記のモジュールにも含まれています。

If you are having problems with your training, please review the Pega Academy Support FAQs.

このコンテンツは役に立ちましたか?

このコンテンツは 100% のユーザーにとって役に立ちました。

改善できるところはありますか?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice