Question

4
Replies
483
Views
Gopi Penmetsa (Gopi_Penmetsa)
Incessant
Architect
Incessant
AU
Gopi_Penmetsa Member since 2015 4 posts
Incessant
Posted: June 22, 2016
Last activity: June 23, 2016
Posted: 22 Jun 2016 22:48 EDT
Last activity: 23 Jun 2016 8:40 EDT
Closed

Design Question: Casematch vs Casetypes  - We have 5 different case types in workpool and each case has atleast 20 properties to be exposed so that we can show them in reports

We have 5 different cases in single workpool and each case has atleast 20 properties which needs to be exposed for reporting purpose.

Design 1:

Have embedded page which captures all the 20 different properties for each casetype and we can have index on this embedded page so that we can report on index for solve reporting issues.

Example:

CaseTypes:

  1. PaymentCase
  2. BrokerInvoiceCase
  3. BookingRequest.
  4. CashFlowRequest.
  5. FuturesCashRequest.

pyWorkPage(BrokerInvoiceCase)

  • InvoiceDetails(embedded page)

pyWorkPage(BookingRequest)

  • BookingDetails(embedded page)

pyWorkPage(CashFlowRequest)

  • CashFlowDetails(embedded page)

pyWorkPage(PaymentCase)

  • PaymentDetails(embedded page)

pyWorkPage(FutureCashRequest)

  • FutureCashDetails(embedded page)

We have no issues with this design, however we have duplicate case search on all these cases, if we use Casematch rule then we should use the properties from embedded pages for finding the duplicates

Is this not performance hit when we use OOTB Casematch rule ?

I know we have option not use case match rule and build our own duplicate functionality search on index tables.

Design 2

Example:

CaseTypes:

We have 5 different cases in single workpool and each case has atleast 20 properties which needs to be exposed for reporting purpose.

Design 1:

Have embedded page which captures all the 20 different properties for each casetype and we can have index on this embedded page so that we can report on index for solve reporting issues.

Example:

CaseTypes:

  1. PaymentCase
  2. BrokerInvoiceCase
  3. BookingRequest.
  4. CashFlowRequest.
  5. FuturesCashRequest.

pyWorkPage(BrokerInvoiceCase)

  • InvoiceDetails(embedded page)

pyWorkPage(BookingRequest)

  • BookingDetails(embedded page)

pyWorkPage(CashFlowRequest)

  • CashFlowDetails(embedded page)

pyWorkPage(PaymentCase)

  • PaymentDetails(embedded page)

pyWorkPage(FutureCashRequest)

  • FutureCashDetails(embedded page)

We have no issues with this design, however we have duplicate case search on all these cases, if we use Casematch rule then we should use the properties from embedded pages for finding the duplicates

Is this not performance hit when we use OOTB Casematch rule ?

I know we have option not use case match rule and build our own duplicate functionality search on index tables.

Design 2

Example:

CaseTypes:

  1. PaymentCase
  2. BrokerInvoiceCase
  3. BookingRequest.
  4. CashFlowRequest.
  5. FuturesCashRequest.

Expose all these 20 properties from each case to workpool worktable so that it has around 100 exposed properties.

Do you consider this best approach so that we have OOTB casematch rule and not have any performance issues as casematch uses exposed properties ?

Note : All these cases must belong to single workpool they are related and they have parent and child relations.

We are planning to go with design 1 and our own custom duplicate functionality instead of casematch rule.

Any suggestion from pega product support.

Any alternate approaches from pega product support.


Rajiv Nistala Pradeep Kumar Vangala Brendan Horan

Pega Customer Service System Administration Case Management Data Integration Reporting
Moderation Team has archived post, This thread is closed to future replies. Content and links will no longer be updated. If you have the same/similar Question, please write a new Question.