さまざまなユーザー層に合わせたアプリケーション拡張
既存のアプリケーションの拡張
グローバルエンタープライズアプリケーションでは、事業拡大要件を満たすために既存のアプリケーションを拡張する必要が生じる場合があります。 一般的なアプリケーション拡張要件の例を以下に示します。
- 新しいユーザー層に向けてアプリケーションを拡張する
- 既存のユーザー層を分割する
新しいユーザー層に向けてアプリケーションを拡張する
新しいユーザーセット用に既存のアプリケーションを拡張するには、次のいずれかを行います。
- 既存のデータベース内でアプリケーションを拡張する
- 新しいデータベースにデプロイしてアプリケーションを拡張する
方法1:既存のデータベース内でアプリケーションを拡張する
既存のデータベース内で新しいユーザー層をサポートするには、New Application wizardを実行して、既存のアプリケーションのケースタイプのクラスを拡張するアプリケーションを生成します。 新しいユーザー層の新しいクラスグループがウィザードによって作成されます。ケースデータは別のテーブルに保存されます。
たとえば、現在のFSGアプリケーションでOnline Streamingイベントを処理するために新しいユーザー層が必要になる場合があります。 Bookingアプリケーションを拡張して、新しいアプリケーションであるOnline Streaming Eventを作成します。
ケースタイプ |
クラス名 |
ワークテーブル |
---|---|---|
Book Event |
FSG-Booking-Work-BookEvent |
pegadata.pc_FSG_Booking_Work |
Online Streaming Event |
FSG- OnlineSt -Work-BookEvent |
pegadata.pc_FSG_OnlineSt_Work |
アプリケーションのアサインメントインスタンスと添付ファイルインスタンスをアプリケーションに基づいて異なるテーブルに分割することはできません。 次のOrganizationプロパティを利用して、これらのアプリケーション間のアクセスを制限できます。
アプリケーション |
ケース |
Assignment |
Assignment |
---|---|---|---|
pyOwningOrganization |
pyOrigOrg |
pyOwnerOrg |
pxAssignedOrg |
pyOwningDivision |
pyOrigDivision |
pyOwnerDivision |
pxAssignedOrgDiv |
pyOwningUnit |
pyOrigOrgUnit |
pyOwnerOrgUnit |
pxAssignedOrgUnit |
|
pyOrigUserDivision |
|
|
新しいユーザー層が新しい部門に関連付けられており、この新しいユーザー層が元の部門で作成されたアサインメントにアクセスできないようにする必要があるとします。 最も簡単な解決策は、次のアクセスポリシー条件を参照するWork-クラスに読み取りアクセスポリシーを実装することです。
pyOwnerDivision = Application.pyOwningDivision
AND pyOwnerOrg = Application.pyOwningOrganization
方法2:新しいデータベースにデプロイしてアプリケーションを拡張する
新しいアプリケーションが新しいデータベース内でホストされている場合、既存のアプリケーション上に構築された新しいアプリケーション内でルールセットを特殊化すれば、新しいユーザー層をサポートするのに十分です。
たとえば、Online Musicイベントを処理するために新しいユーザー層が必要であるとします。 この場合は、Bookingアプリケーションを拡張して、新しいアプリケーションであるOnline Music Eventを作成します。 その新しいOnline Musicイベントアプリケーションを新しいデータベース内でホストします。
ケースタイプ |
クラス名 |
ワークテーブル |
ルールセット |
データベース |
Online Music Event |
FSG- OnlineMu -Work-BookEvent |
pegadata.pc_FSG_OnlineMu_Work |
OnlineMu |
New |
既存のユーザー層を分割する
アプリケーションの既存のユーザー層をサブセットに分割する必要が生じる場合があります。 結果の各サブセットは、元のアプリケーション上に構築されたユーザー層固有のアプリケーションにアクセスします。
ユーザー層全体にアクティブなケースが存在し、そのユーザー層を2つの異なるアプリケーションに分割する必要がある場合は、レポートとセキュリティーが問題になります。 既存のデータベースのクローンを作成することは適切なアプローチではありません。 アプリケーションでバックグラウンド処理が使用されている場合は、重複した処理が生じます。
デプロイメントには次の2つの主要なアプローチがあります。
- 既存のユーザー層のサブセットを新しいデータベースに移動する
- 既存のユーザー層のサブセットを元のデータベース内に作成する
既存のユーザー層のサブセットを新しいデータベースに移動する
細分化されたユーザー層をサポートする新しいデータベースを作成しており、ただちにユーザーを移行する必要はないとします。 その場合は、ユーザー/アカウントデータを既存のデータベースから新しいデータベースに徐々に移行できます。 依存関係が最も少ないクラスから始めて、ユーザー/アカウントデータを移行するのが理想的です。 たとえば、添付ファイルデータは他のインスタンスを参照しません。
特定のユーザー/アカウントの解決済みケースを新しいデータベースにコピーした後も、それらの解決済みケースを元のシステムからすぐにパージしないでください。 ユーザーまたはアカウントの移行プロセスが完了するまで待つことをお勧めします。 このタスク(Dev Studio > Configure > System > Operations > Purge/Archive)を実行するには、Purge/Archive wizard を使用します。 (オプション)新しいユーザー層を反映するようにケースデータ編成プロパティを変更します。
既存のユーザー層のサブセットを新しいデータベースにただちに移動するという要件は、未解決ケースの可能性があるため、より複雑です。 このタスク(Dev Studio > Configure > Application > Distribution > Package Work)を実行するには、Package Work wizard を使用します。
既存のユーザー層のサブセットを元のデータベース内に作成する
最も複雑な状況は、同じデータベース内でユーザー層の即時分離が義務付けられている場合です。 この要件をサポートするには、既存のケースのサブセットを別のクラス名にリファクタリングする必要があります。
ケースがアクティブになっている間にケース階層全体のケースデータモデルを操作することは、リスクが高く複雑です。 そのため、同じデータベース内の同じアプリケーションに対してユーザー層の分割を試みる前に、Pegaの担当者からのアドバイスと支援を求めてください。
このトピックは、下記のモジュールにも含まれています。
- アプリケーションの拡張 v3