
データオブジェクト
ケースを処理するために、Pega Platform™アプリケーションは、データオブジェクトを使用して関連するケースデータを収集します。 データオブジェクトは、関連フィールドをグループ化して、人やアイテムなどのエンティティを説明するためのテンプレートです。
たとえば、アプリケーションには、2つのケースタイプで利用可能なAccountデータオブジェクトが含まれていることがあります。片方は、顧客が銀行口座間で資金を移動できるようにするタイプ、もう片方は、顧客が口座に関連付けられている住所を変更できるようにするタイプ、といったものです。 Accountデータオブジェクトには、Account Number、Current Balance、Next Statement Dateなどのアカウントを説明するフィールドが含まれます。 Accountデータオブジェクトを参照することで、各ケースタイプに対してアカウント関連のフィールドを定義する必要がなくなります。 次の図は、Transfer FundsとChange AddressケースタイプとAccountデータオブジェクトの関係を示しています。
データオブジェクトは、必要に応じて何度でもアプリケーションで使用できます。 前述の例では、Transfer Fundsのケースタイプは、送金元と送金先アカウントの両方をモデル化するために、Accountデータオブジェクトを使用できます。
アプリケーションのケースタイプとデータオブジェクトのコレクションは、アプリケーションのデータモデルを全体的に定義します。
構造(Structure)
各データオブジェクト内では、データタイプは、エンティティに関する情報を取得して表示するために使用されるフィールドの名前やタイプなど、データオブジェクトのための技術的な実装を表しています。 さまざまなフィールドが集合的に単一のオブジェクトを表し、データオブジェクトの構造を定義します。 データオブジェクトを作成すると、Pega Platformは自動的に対応するデータタイプを作成します。
補足: Dev Studioでは、開発者は、データオブジェクトではなく、基礎となるデータタイプを直接使用しています。 その結果、プロジェクトとドキュメンテーションで、データオブジェクトとデータタイプという用語が区別なく使われていることに気づくかもしれません。
たとえば、HRアプリケーションには、求人を管理し、空いているポジションについて応募者を整理するために、ケースタイプが含まれます。 HRは新しい候補者のプロセスのために、候補者に関する基本情報を収集する必要があります。 空いている求人に対して候補者に関する情報を収集するために、開発者は、First name、Last name、Email、Phoneなどのフィールドを含んだ対応するデータタイプで、Candidateのデータオブジェクトを作成することができます。
データ要素のグループ化に加えて、データオブジェクトは、ビューやデータオブジェクトに関連するその他のルールをグループ化できます。 たとえば、Candidateデータオブジェクトには、John Smithのように、フルネームにするために候補者の名と姓を組み合わせる計算を含めることができます。
他のデータオブジェクトを参照することで、データオブジェクトの構造を拡張することができます。 1つのデータオブジェクトが2番目のデータオブジェクトを参照すると、2番目のデータタイプのフィールドは、参照しているデータオブジェクトのデータタイプの一部になります。 参照されたデータオブジェクトは、ニーズに応じて、1回または複数回のいずれか使用できます。
たとえば、Candidateデータオブジェクトはまた、郵送先住所や職歴などの情報に対するフィールドを含む必要もあります。 住所と職歴は、Candidateデータオブジェクトが参照するデータオブジェクトとして設定することができます。 Addressデータオブジェクトは、Street name、City、Postal codeなどのフィールドでCandidateデータオブジェクトを拡張し、一方、Employment historyデータオブジェクトは、Start date、End date、Position、Employerなどのフィールドを追加します。 Addressデータオブジェクトは、1つの住所を取得するために1回使用されますが、一方Employment historyデータオブジェクトは、候補者の前の雇用主のリストを作成するために、1回以上使用することができます。 次の図は、New Candidateケースタイプ、Candidateデータオブジェクト、Addressデータオブジェクト、Employment Historyデータオブジェクトの関係を示しています。
次の画像で+のアイコンをクリックすると、データオブジェクトと対応するデータタイプの関係についての詳細が表示されます。
継承
データオブジェクトを作成して、継承を通じて既存のデータオブジェクトからのアセットを再利用できます。 たとえば、Personは一般的なデータオブジェクトまたは親データオブジェクトですが、CustomerやCall Center Representative(CCR)」はより特殊化されたデータオブジェクトとなります。 親と子のデータオブジェクト間の関係を示すには、「Person-Customer」や「Person-CCR」といった「Parent-Child」パターンを使用します。 3つのデータオブジェクトにはすべて、Name、Telephone、Emailなどの共通フィールドがあります。 Personデータオブジェクトに共通フィールドを作成すると、CustomerやCall Center Representativesデータオブジェクトでフィールドを再利用できます。 Tax Identification NumberフィールドおよびMembership Numberフィールドは顧客のみに適用されるので、Customerデータオブジェクトで定義します。 Employee IDフィールドは従業員のみに適用されるため、Call Center Representativeデータオブジェクトでフィールドを定義します。 次の図は、Person、Customer、CCRのデータオブジェクト間の関係を示しています。
取得
データオブジェクトは、Pega Platformのシステムオブレコードからローカルに、または既存の人事・在庫データベースなどの外部のシステムオブレコードからも取得できます。 その他、データオブジェクトは、ユーザーまたはケース参加者がアプリケーションのプロセス中に入力あるいは変更したデータで、いずれのシステムオブレコードとも関連付けられていないものも取得できます。
データタオブジェクトを取得する方法を決定する際には、次の画像にある質問を検討してください。 質問では、Pega Platformを初めて使用し、アプリケーションをゼロから作成する場合を想定しています。
次の画像で「+」アイコンをクリックすると、各データオブジェクトの取得オプションの例が表示されます。
ベストプラクティス
可能な限り、Address-PostalやAddress-EmailといったPega Platformが提供する一般的に使用される標準のデータオブジェクトを使用してください。 アプリケーションに関連するデータオブジェクトを追加することもできます。
データオブジェクトが一部のみニーズを満たしている場合は、そのデータオブジェクトを拡張できます。 たとえば、Employeeデータオブジェクトを作成する場合、既存のPersonデータオブジェクトを拡張して、Person-Employeeデータオブジェクトを作成できます。
適切なデータオブジェクトが存在しない場合は、新しいデータオブジェクトを作成してください。 たとえば、Airport Codesデータオブジェクトを追加したいけれども、既存のデータオブジェクトを使用または拡張できない場合、Pega Platformで新しいデータオブジェクトを作成します。
ヒント: App Studioのケースワークフローに新しいデータオブジェクトを追加した場合、Pega Platformは、ドラフトオブジェクトとして、データオブジェクトを作成します。 ドラフトデータオブジェクトは、データタイプを参照しません。 ドラフトオブジェクトにより、データタイプの設計に影響を与える可能性があるケースライフサイクルでデータが使用される方法とタイミングを特定できるようになります。 「Data objects and integrations」ページを使用して、ドラフトデータオブジェクトにデータタイプを追加できます。
以下のインタラクションで理解度をチェックしてください。
このトピックは、下記のモジュールにも含まれています。
トレーニングを実施中に問題が発生した場合は、Pega Academy Support FAQsをご確認ください。