Skip to main content

業界基盤データモデルのメリット

Pegaの業界基盤データモデルでは、ゼロから論理データモデルを構築するのではなく、既存の論理データモデルを活用し、拡張できます。 Pegaには、ヘルスケア通信およびメディアライフサイエンス保険金融サービス向けの業界データモデルが用意されています。 データクラスを自分で構築する代わりに、システムオブレコードのプロパティを業界のデータモデルのデータクラスとプロパティにマッピングできます。

HealthCare
上の図は、ヘルスケア業界基盤におけるメンバーデータタイプの論理モデルを示しています。

業界基盤データクラスに、必要に応じて外部のシステムオブレコードからのプロパティを追加することができます。

Pegaの業界基盤データモデルには、関心の分離(SoC)という設計原則が適用されています。これは、ビジネスロジックとデータを取得するインターフェイスを分離しておくというものです。 ビジネスロジックは、データが必要となるタイミングや、データを取得した後のデータの処理方法を決定しますが、 インターフェイスがビジネスロジックを分離するため、データの取得方法がわからなくなります。

Pega Platformでは、データページがビジネスロジックとインターフェイスロジックを接続します。 次の図は、データページ、データクラス、データを取得する仕組みの関係を示しています。

Data Page Bi-directional Mapping
この図は、外部のシステムオブレコード(SOR)からのデータが、どのようにして左側のDATA CLASSから右側にあるそのDATA CLASSのSORデータモデル表現に変換されるのかを示しています。 このプロセスは双方向です。 さらに左のデータページにより、この双方向マッピングが管理されます。 コネクターとデータマッパー(前後処理のデータ変換)は、データページで設定されます。  

この設計パターンにより、データモデルやアプリケーションの動作に影響を与えることなく、統合ルールを変更できます。

プロジェクトでは、業界基盤データモデルを直接拡張するのではなく、Enterprise Service Bus(ESB)専用データモデルの使用が義務付けられている場合があります。 ESBの目的は、バスにアクセスするクライアントが、バス上で宣伝されているどのサービスとも対話できる、正規データモデルを実装することです。

Enterprise Service Bus
Enterprise Service BusまたはESBは、バス上のすべてのサーバーからの送受信先にできる、統合データモデルを定義します。 各サーバーは独自の内部データモデルを持つことができます。 これにより、各サーバーが別のサーバーに対して送信する発信用マッピングロジックを開発する必要性を排除でき、独自の受信用マッピングロジックを開発して、そのサーバーからの応答を受信することができます。  

ESBを使用する状況では、Pega開発チームは正規データモデルを定義しませんが、 正規データモデルと基盤データモデル間のマッピングを維持する可能性はあります。

補足: この場合のベストプラクティスは、Pegaの開発チームが必要に応じて基盤データモデルを活用して拡張することです。 外部SORプロパティとPegaの基盤データモデルプロパティのマッピングはすべて、Pega開発チームがデータページを使用してPegaアプリケーション内で行う必要があります。

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

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

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

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

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