Question
Greenfield AG
DE
Last activity: 1 Nov 2018 8:00 EDT
Need for Int classes for JSON integration?
Hello
Per my understanding Int classes serve as a middleman between external system and Pega Data class pages (which have different naming and structure). That's why ideally Pega services do not need Int class, unless you are developing something super universal.
But, as of 7.3.1 we have new data transforms with json mode that map straight from JSON to Data class and backwards. So, the question is: do we really need Int classes in this case? And are those new data transforms a first step in the path of getting rid of Int classes?
Accepted Solution
Pegasystems Inc.
US
A service dictates the data model and format that it accepts within a request and what is contained within a response. What you are referring to is whether integration classes are necessary when connecting to a service.
Suppose a table in an external database. You would use the Data Table Class Mapping Wizard to generate an Int- class. A Data- class Data Page would source a report definition that queries the external database table. The Int- response from the query would be mapped to the Data- class.
If you generate your Data- class directly from a web interface response then there is no need to use an Int- class intermediary. The risk is that the web interface may change over time.
Greenfield AG
DE
Yes, I am talking about Pega connector, Pega service is an example of case where we do not need Int classes. I understand the risk of web interface changing over time, but if we use new JSON mode data transform, ideally, we would need to change only them, so the risk is minimized unless the whole data structure is changed (in which case we might have to change Data classes even if we have Int classes additionaly).
Anyway, I've got the answer to my question.
Thank you.
Coforge Technologies (Erstwhile Incessant Technologies)
GB
Integration layer is used for connectors only, when the pega system invokes external services, to maintain all service invocation rules together, extensible and maintainable pega suggests integration layer in the application, so that all int- rules saved in integration rulesets separately for easy future maintenance without mingling with business logic. Data layer and Int layer are seperated to reduce the complexity and limiting the changes to individual layers. Yes, we can go without int layer also directly mapping to data layer, but whenever the service response structure changes, need to disturb the business or data layer. Also if we maintain integration layer seperately it can be reused as a component for other applications.
Pegasystems Inc.
US
There is such as thing as an SQL Connector. A Report Definition, while not being a Connector per se, would nonetheless be considered integration when an external database table is queried. A Report Definition that queries an external database table should be applied to an Int- class that is defined in an integration ruleset. A Data Page defined in a "data' ruleset would source that Report Definition. A response Data Transform would map the "integration" result set to the Data Page's class. This is the exact same process as when a Connector is called.
I wish there was a better word to use than "layer" when referring to "data' and "integration". I prefer to use the word "layer" when referring to things that are arranged vertically. When I think of "data' and "integration", though, I picture two "things" arranged horizontally.
The Separation of Concerns (SoC) Principle, which advocate looses coupling, comes to mind but the word "concern" is too vague.
I like the word "aspect". Definition: a particular part or feature of something.
Then again, the word "partition" does a better job of emphasizing that what is being referenced is a "part" of a whole, plus has a well-defined boundary. I like that better.