Question
AI4Process
GB
Last activity: 31 Aug 2020 19:46 EDT
How parameterized Datapage follows Interface segregation principle?
As per LSA course in pega Academy- it is mentioned that -
" Examples of ISP in the Pega platform include Service Packages and parametrized Data Pages. Data Propagation would also meet the definition of ISP if a single Data instance is passed as opposed to multiple, individual scalar Properties."
Can any one please help me understand this above statement?
or in other words - how "Service Packages", "Parameterized DataPage" and "Data Propagation" satisfy ISP?
Pegasystems Inc.
US
Pega Rule-Obj-Class definitions do not support the notion of a Java Interface, which is a mechanism for declaring that Java class supports certain methods. A Java Interface resembles an abstract class with the exception that an Interface does not possess attributes (properties in Pega).
In Pega the word "Interface" is used to refer to APIs (Application Programming Interfaces) such as the Pega API.
A Service declares what it supports for input and how it responds to that input.
With Data Propagation there is no mechanism for declaring what is required for input, but you pretend that an API exists.
When you issue a REST POST request, as when using the "cases" form the Pega API, it is up to you to decide what to populate inside the POST request body's "content" page.
For simplicity you can propagate a single Page / Field Group as the "payload". This is referred to as the "Transfer Object Pattern".
It doesn't matter what mechanism is used, a REST POST or PUT, or Data Propagation.
In either case, you define the recipient's API as the structure of the Data object that is transferred.
In the 8.3 LSA course's sample Booking application, all three mechanisms are used.
The Booking application propagates an FSG-Data-Hotel-RoomsRequest page to RoomsRequest cases (cases that were created by import from the built-on Hotel application.
The Hotel and HotelProxy applications communicate using POST and PUT requests.
Pega Rule-Obj-Class definitions do not support the notion of a Java Interface, which is a mechanism for declaring that Java class supports certain methods. A Java Interface resembles an abstract class with the exception that an Interface does not possess attributes (properties in Pega).
In Pega the word "Interface" is used to refer to APIs (Application Programming Interfaces) such as the Pega API.
A Service declares what it supports for input and how it responds to that input.
With Data Propagation there is no mechanism for declaring what is required for input, but you pretend that an API exists.
When you issue a REST POST request, as when using the "cases" form the Pega API, it is up to you to decide what to populate inside the POST request body's "content" page.
For simplicity you can propagate a single Page / Field Group as the "payload". This is referred to as the "Transfer Object Pattern".
It doesn't matter what mechanism is used, a REST POST or PUT, or Data Propagation.
In either case, you define the recipient's API as the structure of the Data object that is transferred.
In the 8.3 LSA course's sample Booking application, all three mechanisms are used.
The Booking application propagates an FSG-Data-Hotel-RoomsRequest page to RoomsRequest cases (cases that were created by import from the built-on Hotel application.
The Hotel and HotelProxy applications communicate using POST and PUT requests.
The FSG-Data-Hotel-RoomsRequest class is defined in a "HotelShared_" ruleset. That ruleset and the ruleset that contains FSG-Int-Hotel-RoomsRequestAPI classes are included in a Component shared by the Hotel and HotelProxy applications.
By using a shared Component, a warning about an Application Validation Mode ruleset being used in two differently named applications is avoided.