Question
NTT Data
US
Last activity: 29 Dec 2018 12:21 EST
Identifying ECS-Enterprise Class Structure Work/Data/Int Elements
How do classify ECS elements as work , Data , Int elements after ECS creation
- Any Data Page holds Service End Point URLs – can be considered as Data Page – Is In Data correct
- Service Rule – Service Soap , Service Rest – Is considered as Int elements correct?
- Section , Report Definition can be – either in Work or Data correct?
- Service Activity – can be considered as Int element correct?
- Cache Report is coming from System - so it comes under Int element since from system other work , data elements won’t fit
- When rule can be any where it could be under work , data even Int correct?
- Flow is always under work correct?
- Property holds reference data page - is it mean Data Element?
- Property holds the data – is it means data element? Since mostly property can be defined in work or data or int element.
Pegasystems Inc.
ES
I think it is important to establish the difference between Connectors (integration that Pega consumes) and Services (integration that Pega exposes). In general, the Int layer holds all the assets that are relevant to connect Pega to downstream systems (meaning Connectors and related assets). Services, on the other hand, should be defined at Work layer (or even Data, depending on what are we going to expose). Another approach to hold Services is to use something similar to what Pega API uses - A higher layer on the structure with visibility to all your application (Pega-API...).
In other words, Int layer does not necesarily have visibility to Data and Work layers, but Data and Work layers will always have visibility to Int layer.
With that said:
1) Yes - Create something like XXX-Data-AppExtension, and use OOTB Embed classes.
2) No - See my comment above.
3) Yes
4) No - See my comment above.
5) Not sure what you are talking about here.
6) In general Yes, but try to keep the minimum logic at the Int layer - Just enough to do the mapping that is required to transform the information from the system you are integrating with.
7) Yes - There are circumstances where it can be interesting to have some flows defined at Data level, but usually it's not the case.
I think it is important to establish the difference between Connectors (integration that Pega consumes) and Services (integration that Pega exposes). In general, the Int layer holds all the assets that are relevant to connect Pega to downstream systems (meaning Connectors and related assets). Services, on the other hand, should be defined at Work layer (or even Data, depending on what are we going to expose). Another approach to hold Services is to use something similar to what Pega API uses - A higher layer on the structure with visibility to all your application (Pega-API...).
In other words, Int layer does not necesarily have visibility to Data and Work layers, but Data and Work layers will always have visibility to Int layer.
With that said:
1) Yes - Create something like XXX-Data-AppExtension, and use OOTB Embed classes.
2) No - See my comment above.
3) Yes
4) No - See my comment above.
5) Not sure what you are talking about here.
6) In general Yes, but try to keep the minimum logic at the Int layer - Just enough to do the mapping that is required to transform the information from the system you are integrating with.
7) Yes - There are circumstances where it can be interesting to have some flows defined at Data level, but usually it's not the case.
8 & 9) I don't understand these two questions - In general, properties have to be defined at the layer they are applicable.
I hope this helps.
Pegasystems Inc.
US
Regarding (1), a Connector can default its URL using Global Resource Settings syntax, e.g., =D_EnvSettings[<params>].someURL. A Data Page entirely dedicated to supplying URLs for different environments for different purposes would use a class such as XXX-Int-EnvSettings, hence be part of the Integration layer.
NTT Data
US
Thank you, but please reply back and clarify
Global Resoure Setting (GRS) is considered as Int Layer. Also GRS pyEndPointURL can get any applied to class even Embed- , Rule-, Data-
But Data Page holding the Global Resoure setting pyEndPointURL is considered in Data Layer since is a data page? question is holding all environment urls is considered in which layer Work- , Data- , Int- ?
Pegasystems Inc.
US
I prefer to use the word "partition" when referring to the loose coupling that should exist between a Application's Work/Data partition and its Int partition. The word "layer" is already used to refer to layers of built-on applications.
Nothing prevents you from defining URL values in the Work/Data partition but, in general, that partition should be used for Business Logic. An Application should not care how its data is sourced. This follows from the long-standing Separation of Concerns (SoC) principle mentioned in the 7.3/4 LSA course.
Again, a Data Page that strictly contains URLs would belong in the Int partition.