Question
WellsFargo
IN
Last activity: 15 Apr 2020 9:11 EDT
App Studio - Data Types and Integrations landing page
Hi there, I have below queries on the way Pega is generating the rules and the behaviour of Data Types and Integrations landing page from app studio. Note that questions are specific to consuming the REST service and pega version is 8.3
1) Why is Pega generating the data class/ data type as concrete classes. When I try to create a new data type with REST connector , why is Pega generating data type as concrete class? It does not make sense for me why it should be a concrete class and mapping it to pr_other table. In earlier version of Pega this is a severe warning
2) Regarding simulation , when I try to create a simulation Pega create a table only for the single value properties. But typically the response of a connector will have a complex JSON strucutures , how is these simulation help for complex data structures?
3) I tried to use the Connect REST wizard from dev studio and created all the required data types and REST rules. When I navigate to ' Data Types and Integrations' landing page and then to data view , the SOURCE column is showing as REST undefined. I opened the data class which was created and updated the class to concrete , then the data view showed the SOURCE as REST defined. Is it mandatory to have all classes defined as concrete for all data types?
Accepted Solution
Updated: 15 Apr 2020 9:11 EDT
Pegasystems Inc.
US
We make the classes as concrete because there are instances of this class. Those instances may not be stored in Pega but there are clearly instances of it that a user is going to need to access in their application. Marking the class as abstract did not seem like an accurate reflection of the state of that class, concrete is more accurate.
I'm not familiar with the guardrails violation you're referring to or what version of Pega you last saw that in. But the reason we consider it ok to have a concrete class which says it is mapped to pr_other is because these generated classes from the REST wizards do not have keys specified. Pega Platform will not let you create instances of this class in pr_other without keys specified so it is not encouraging a bad practice. Classes which have instances in the pega database should not be mapped to pr_other but without keys there shouldn't be any instances.
For your last question about App Studio requiring concrete classes, I'm not aware of any such restriction. @chinm is this a restriction we have currently?
Pegasystems Inc.
IN
2) Regarding simulation , when I try to create a simulation Pega create a table only for the single value properties. But typically the response of a connector will have a complex JSON strucutures , how is these simulation help for complex data structures?
Yes, it does expose only scalar properties to the table as records editor does not allow you to manage embedded structure. The table is created in PegaDATA schema. So it comes with pzPVStream column, which can be used to maintain the simulated data for embedded structure. You can always use the data import wizard to create simulated data for even complex data structures.
WellsFargo
IN
Thanks for the reply. Can you elaborate more on the data import wizard? How can this be helpful to import complex data structures?
Pegasystems Inc.
US
Simulating complex embedded data structures is a bit difficult right now, this is something we need to work on more to make it easier. However the data import wizard does support this capability.
In the data import wizard when mapping CSV columns to fields there are two ways to pick the field to map to. The first is using the autocomplete in the target field column. Since autocompletes can only prompt on a flat list this autocomplete just lists scalars of the class as that is the most common use case.
If you need to map a CSV column to a field within a page or pagelist property then you can click the "select" button. This opens an overlay which allows you to navigate through page and pagelist properties to pick the one you want to map to. I attached a screenshot of this picker below.
So to simulate complex structures right now you would need to create a CSV file and use this wizard to import it. Like I said, this user experience still has room for improvement and we will work on it but for now this is the way to accomplish this.
WellsFargo
IN
Thanks for the response. I am not able to download attachment , when I click on the its navigating to mypega. Could you please check?
WellsFargo
IN
I was able to navigate through the steps you mentioned. And yes , as you said If I have to map the complex JSON structure to each column in a database table it is very tough. If I have a JSON structure pagelist this approach will not work as the wizard provides me to identify single value properties from a pagelist and map it to a database column , one record in simulation table is equal to one response from connector.
Instead I would think of an dynamic UI which should be presented based on the response parent class and provide an option for user to enter values for a response and save it as BLOB in the simulation table and during the simulation I will retrieve the BLOB value and map it to the data page.
Accepted Solution
Updated: 15 Apr 2020 9:11 EDT
Pegasystems Inc.
US
We make the classes as concrete because there are instances of this class. Those instances may not be stored in Pega but there are clearly instances of it that a user is going to need to access in their application. Marking the class as abstract did not seem like an accurate reflection of the state of that class, concrete is more accurate.
I'm not familiar with the guardrails violation you're referring to or what version of Pega you last saw that in. But the reason we consider it ok to have a concrete class which says it is mapped to pr_other is because these generated classes from the REST wizards do not have keys specified. Pega Platform will not let you create instances of this class in pr_other without keys specified so it is not encouraging a bad practice. Classes which have instances in the pega database should not be mapped to pr_other but without keys there shouldn't be any instances.
For your last question about App Studio requiring concrete classes, I'm not aware of any such restriction. @chinm is this a restriction we have currently?
WellsFargo
IN
Thanks for the reply. Couple of more queries
1) Why is the creation of classes different from REST wizard in dev studio and app studio? From dev studio the classes created are abstract and from App studio its concrete.
2) In general simulations are required only when the service is not available , so for these kind of requirements simulations are enabled . When a simulation is enabled Pega creates a database table and update the class key with the OOTB pyGUID. So when I have to disable the simulation does Pega remove the key for the class , if the answer is NO , what is impact when I have to move the code to higher environments. I don't want to move the simulations table to higher environments as there is no need.
And regarding the warning if its mapped to pr_other is in Pega 7.4 and lower versions.
Thanks,
Suman