Datapages are very useful to fetch the data but with only one source. My Ideas is, if we can Pass the source as a parameter so that it will be useful for many scenarios and eliminates creating several datapage rules - Low-Code App development
Simply - datapage with multiple sources
Ex: DataPage - D_getDetails is a List and Requestor/Thread datapage and is having a source ReportDefinition (FetchDetails) in class A-B-C-D.
I am using this Datapage in Data transform or Property-Set or some other places and passing some parameters and source for this datapage is Report definition, similarly, if i want to use other report definition (FetchFullDetails) in the same class or ancestor class, I need to create another datapage.
If i can pass Source Name (Report definition - FetchFullDetails) as a parameter to the datapage with the same Page,Mode type, it will be very much helpful.
I know we have to think about Page structure, Mode and scope and Source.
We can keep Datapage Structure,Mode and scope as it is and pass source as a parameter then it would be much help. This way we can eliminate creating many datapages and we can re-use the same datapage with multiple sources as a parameter.
Clipboard will have same datapage multiple times with different sources and different results.
Hello Ramesh, I'm Mike Degatano, the product owner for data pages at Pega.
Data pages can have more then one source even today. You can add multiple sources to the data page and use when rules to specify which source is used based on the provided parameters. Also in 8.4 you are able to use the new "aggregate source" option to construct the data page by executing multiple sources sequentially.
Unfortunately the feature you're asking for is not one we're going to be able to provide however. Generally we try to avoid providing options that allow people to call any rule of a type where the identifier is a parameter. We do this for a number of reasons:
We cannot properly optimize that call since we don't know what rule will be used at runtime. There are optimizations we can take when we know which rules call which, that's not possible when the rule to call becomes dynamic.
We cannot determine dependencies between rules since the call is dynamic. This prevents us from doing things like building accurate rule references. It also makes it impossible for us to be certain all dependencies are included during packaging since we don't really know what rules this one depends on.
We can't guarantee a working runtime based on the designtime configuration. Validation can only go so far in these circumstances due to its dynamic nature. Whether or not the rule works without exception depends on what value is passed in via parameter. In your example it's likely the rule was tested with a few specific RDs but not every RD that could possibly be called there.
That can pose a security risk depending on where the data page is used. If that data page and its parameter became part of an API for example then you would effectively have an API that allowed the caller to execute any RD. That would not be a good idea.
In general we've also found in usability testing that what makes a good and effective low-code experience is more clear definition where the provided tools spell out exactly what they do and when. The more dynamic a tool is in terms of what it can do the more complicated it becomes and the harder it is to easily leverage in a low-code experience. People find it much easier to work with our tools when each tool has a specific and clearly-defined purpose then when the tools can each do many many things and there's lots of ways to solve any one problem.