Reporting across multiple applications in same Apps server instance.
Please share your thoughts on the below,
We are trying to build 2 different applications[APP1, APP2] within a same Instance(App Server) they both will be sharing the same Database - Rules/Data Schema. Since these two applications will be parallel not build on top of either, is reporting still feasible having said that they both share the same Data Schema but with different work tables.
Example : If the Customer Number column is common across both the application work- tables, we need to run a report across both the applications to give a consolidated view of all the In progress cases.
We are planning to have a wrapper application which will be built on both the applications (APP1 and APP2) from where we can switch between either of the applications and also to see the consolidated dashboard and wrapper application is not meant for any case creation.
The Question is how feasible it would be to generate the consolidated reports from the wrapper application.
We are planning to have 2 different applications and not as 1 App with multiple case types as they both will be serving for altogether different business purposes. Need to know the best practice of having multiple application vs one with various case types.
Thanks.
Pegasystems Inc.
US
It is possible to define a VIEW that is a UNION to two different tables.
If the column names are same in each table ,and queried in the same order, there should not be any issue.
If column names do not match you can "alias" one of them to match the other.
https://stackoverflow.com/questions/50487707/sql-union-two-tables-with-different-column-names
Lloyds Banking Group
GB
Thanks @pedel for your response that was helpful, could you please advise on the next question "We are planning to have 2 different applications and not as 1 App with multiple case types as they both will be serving for altogether different business purposes. Need to know the best practice of having multiple application vs one with various case types."
Thanks
TCS
IN
If the need is to create a consolidated report then that can be done by creating a View in the database and map a data- class to that view. You can create the class in both the applications within the class structure of respective applications. From either of the applications you can run an RD/DataPage from the dashboard to view the consolidated records of both case types in different applications. We don't need another wrapper application to achieve this objective. Please share updates with this approach.
Coming to your second question: An application is a placeholder for implementing a business need. For ex: you need to build a loan application. A loan application can have various processes - loan management, customer profile management, approvals, compliance, etc. and there might be different case types for these processes. Ideally these related things should go inside one application. If you have processes/purposes which are totally unrelated to the loan process, then that would ideally be a separate application and would be from a different business group. Share if you have other questions.
Pegasystems Inc.
US
The benefits of modular architecture and design are well-known (see Wikipedia, et al.).
An Application fits the definition of a component which fits the definition of an object (and vice versa). Hence the various, above-the-code-level, attributes of OOP apply such as Separation of Concerns. Generally the smaller and more cohesive something is, the greater its flexibility for reuse as well as maintainability on its own schedule.
What you are proposing is to have one application be built on multiple applications. That way the same set of users who work on, or manage, a certain set of case types do not have to switch applications.
If every built-on case type were to be "imported" into the top-most application, those imported case types would directly inherit a case type from the built-on app. Then all of the case types in the top-most application would have the same work pool / class group, hence be written to the same DB table (see Pega Help for “Importing case types”).
But what you are proposing is to have a "wrapper" application be built on two applications, APP1 and APP2, and not import the case types into the top-most application. You only want to use it as a Dashboard - no case creation allowed.
That is fine as long as your "wrapper" application keeps it that way - view and potentially modify only but do not display any case types on the New Work menu.
The benefits of modular architecture and design are well-known (see Wikipedia, et al.).
An Application fits the definition of a component which fits the definition of an object (and vice versa). Hence the various, above-the-code-level, attributes of OOP apply such as Separation of Concerns. Generally the smaller and more cohesive something is, the greater its flexibility for reuse as well as maintainability on its own schedule.
What you are proposing is to have one application be built on multiple applications. That way the same set of users who work on, or manage, a certain set of case types do not have to switch applications.
If every built-on case type were to be "imported" into the top-most application, those imported case types would directly inherit a case type from the built-on app. Then all of the case types in the top-most application would have the same work pool / class group, hence be written to the same DB table (see Pega Help for “Importing case types”).
But what you are proposing is to have a "wrapper" application be built on two applications, APP1 and APP2, and not import the case types into the top-most application. You only want to use it as a Dashboard - no case creation allowed.
That is fine as long as your "wrapper" application keeps it that way - view and potentially modify only but do not display any case types on the New Work menu.
For extra security you could add a ruleset to your wrapper application to define security rules that deny create access when Application.pyProductName = wrapper application's name.