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:
- PaymentCase
- BrokerInvoiceCase
- BookingRequest.
- CashFlowRequest.
- 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:
- PaymentCase
- BrokerInvoiceCase
- BookingRequest.
- CashFlowRequest.
- 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:
- PaymentCase
- BrokerInvoiceCase
- BookingRequest.
- CashFlowRequest.
- 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.
Pegasystems
IN
With either approach 1 or approach 2 (assuming approach 1 is using embedded page and not embedded page list / page group), you will end up creating the properties in the main table and thus the reporting will be the same. Declare index comes into play for page list / page group properties where each of these properties could have 1 or more pages in it.
For a normal Page property, optimize for reporting will create the column in the main table (case / workpool table) and not as a declare index table.
Eclatprime
AU
Hi Rajeev,
Yes you are correct, let say we have pagelist i.e. like InvoiceDetails(1) then it will create declare index. if you consider this.
What would be the best approach here design 1 or design 2 ?
Can database table have 100 exposed properties ?
Does CaseMatch rule considers index when it searches the cases ?
Pegasystems
IN
What would be the best approach here design 1 or design 2 ?
This depends on where all you will use this embedded page (UI, flow actions and processing). If it is just from a reporting stand point and performance is key, I would go with design 2 since all columns are in the same table and you don't need a join.
>> Can database table have 100 exposed properties ?
That would depend on the database vendor limits. But yes, I think 100 columns is possible to have. We have seen in some scenarios, even 200 columns as well.
>> Does CaseMatch rule considers index when it searches the cases ?
I am not sure about this as case management is not really my expertise area. I would assume it doesn't OOTB.
Eclatprime
AU
Hi Rajeev,
One more point we will not directly expose the properties from the embedded page.
we will create index on the embedded page here embedded page can be single page.
We have working solution for single embedded page and have index for this page.
Thanks,
Gopi Penmetsa