Skip to main content

This content is closed to future replies and is no longer being maintained or updated.
Links may no longer function. If you have a similar request, please write a new post.

Question

 Bhagyashree Choudhary (BhagyashreeC9567)
Evoke Technologies

Evoke Technologies
IN
BhagyashreeC9567 Member since 2018 28 posts
Evoke Technologies
Posted: Jun 13, 2018
Last activity: Jul 5, 2018
Posted: 13 Jun 2018 12:00 EDT
Last activity: 5 Jul 2018 10:59 EDT
Closed
Solved

A Pega Application without Work object

Hi,

Is it good to have a Pega Application that isn't leveraging the Case Management/ Work object concept in Pega.
Our application primarily has huge amount of data and reporting involved -with limited processes.
There are various data objects and complex relationships between these. The reporting is going to be intensive. Considering these factors in mind, the current implementation is to have only data tables.
We need to answer the following questions:
Are we going to maintain the huge amount of data in BLOB as well as data tables- if we go for a WO approach?
Work classes would bring additional columns and rules that might be redundant.
What if processes come in future. How can we then change our no-WO-model in future to incorporate a workobject?
Are their some key Pega OOTB advantages that we might seriously be compromising on if we follow the no-WO approach?
What are the tradeoffs?

Thanks much!
Bhagyashree

To see attachments, please log in.
Low-Code App Development
Case Management
Data Integration

Accepted Solution

Posted: 6 years ago
Posted: 19 Jun 2018 23:14 EDT
Raju Botu (Raju Botu)
Aaseya IT Solutions
AVP
Aaseya IT Solutions
IN
Simple answer is Yes. Let me answer your original set of questions. Are we going to maintain the huge amount of data in BLOB as well as data tables- if we go for a WO approach? -- Not Required. Maintain them in the data tables with unique keys. - Create a property to refer to the data instance dynamically based on association. - Ex: Account information can be in account data table, store the account number on your work object and refer to that. Use data pages. Work classes would bring additional columns and rules that might be redundant. - They are not redundant, most them are managed by Pega and they are efficiently stored and retrieved from Blob. What if processes come in future. How can we then change our no-WO-model in future to incorporate a workobject? - You can always change it, but depends on your application. - You can always create utilities to create WOs out of data instances and place them at right stages. Are their some key Pega OOTB advantages that we might seriously be compromising on if we follow the no-WO approach? - Case Lifecycle - OOTB Reporting - Archive or Purge wizrds - You will end up doing lot of customization. What are the tradeoffs? - Need to know more details about your applocation. Hope this helps.
To see attachments, please log in.
Posted: 6 years ago
Posted: 15 Jun 2018 16:45 EDT
Arun Kumar Mahanty (Arun_Mahanty)
Pegasystems Inc.
Principal Technical Solutions Engineer
Pegasystems Inc.
IN

I didn’t understand if you’re not having work objects in your application what kind of data you want to pull out from the reports .

If you’re not having workobjects how are your inserting data into the applications ?

What’s the business requirement based on that we can answer your question .

Thanks,

Arun

To see attachments, please log in.
Posted: 6 years ago
Posted: 17 Jun 2018 13:27 EDT
Bhagyashree Choudhary (BhagyashreeC9567)
Evoke Technologies

Evoke Technologies
IN

Hi Arun,

We have various data objects in the application such as License, License Owner, License Location etc. There are complex relationships between these.
As an end user one should be able to view records corresponding to these in different grids. There would be 'Actions' menu on top of these grids that has options to Edit/Add New Record.
The current implementation in Pega so far includes showing repeat grids on the Portal fetching records from these data tables.
An 'Actions' menu click launches a modal dialog in another harness that takes input from user for a new record or for edit, and on submit saves the data to the associated data table. There is no involvement of work object here.

The entire application would be more or less around these grids and actions similar to the one stated above.

Thanks!

Bhagyashree

To see attachments, please log in.
Posted: 6 years ago
Posted: 18 Jun 2018 2:47 EDT
Rachit Agarwal (Rachit_Agarwal)
PEGA
Principal Technical Support Engineer
Pegasystems Inc.
US

Hi Bhagyashree,

What we can do here is create one work object for one scenario. For example, one showing the relation between License & License owner. Create another work objects for other scenarios. Now, don't allow the users to create more work objects. Rename it appropriately so that it does not seems to be a work object(T-1, T-2 etc).  The users can then work on these appropriately(Add, Edit, Delete). I hope I am clear. Please let me know in case you feel otherwise.

Regards,

Rachit

To see attachments, please log in.
Posted: 6 years ago
Posted: 19 Jun 2018 12:04 EDT
Bhagyashree Choudhary (BhagyashreeC9567)
Evoke Technologies

Evoke Technologies
IN

Thanks Rachit,

My question is more around where it is important to have a WO in Pega and if we dont have one are we compromising on Pega features or not violating best practices.

To see attachments, please log in.

Accepted Solution

Posted: 6 years ago
Posted: 19 Jun 2018 23:14 EDT
Raju Botu (Raju Botu)
Aaseya IT Solutions
AVP
Aaseya IT Solutions
IN
Simple answer is Yes. Let me answer your original set of questions. Are we going to maintain the huge amount of data in BLOB as well as data tables- if we go for a WO approach? -- Not Required. Maintain them in the data tables with unique keys. - Create a property to refer to the data instance dynamically based on association. - Ex: Account information can be in account data table, store the account number on your work object and refer to that. Use data pages. Work classes would bring additional columns and rules that might be redundant. - They are not redundant, most them are managed by Pega and they are efficiently stored and retrieved from Blob. What if processes come in future. How can we then change our no-WO-model in future to incorporate a workobject? - You can always change it, but depends on your application. - You can always create utilities to create WOs out of data instances and place them at right stages. Are their some key Pega OOTB advantages that we might seriously be compromising on if we follow the no-WO approach? - Case Lifecycle - OOTB Reporting - Archive or Purge wizrds - You will end up doing lot of customization. What are the tradeoffs? - Need to know more details about your applocation. Hope this helps.
To see attachments, please log in.

We'd prefer it if you saw us at our best.

Pega Collaboration Center 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