Purpose of Integration ruleset and Data layer
Hi,
I am creating a REST connector using a wizard. Since I am new to this I have a couple of questions.
#1. I find wizard created a separate new ruleset than what I already have. Why would we need this ruleset? Every time we create service or connector, if we get more and more rulesets, isn't that complex? Pega creates a Int ruleset when we create a new application, why wouldn't we use it?
Hi,
I am creating a REST connector using a wizard. Since I am new to this I have a couple of questions.
#1. I find wizard created a separate new ruleset than what I already have. Why would we need this ruleset? Every time we create service or connector, if we get more and more rulesets, isn't that complex? Pega creates a Int ruleset when we create a new application, why wouldn't we use it?
#2. I find wizard also creates "Data layer" on top of "Int layer". In my understanding, Int class works as an intermediate page to put request and response. That temporary page is removed right after we map the response to properties in Work class. So, we only need Int class and that should be enough. On what purpose do we need this Data class? Having Int and Data make things complicated, I think.
#3. If we use wizard, it creates a bunch of rules like Int class, ruleset, properties, etc but I think I can create Connect REST rule by just right click manually. Still things should work and it is very simple. What is pros and cons between using wizard and doing manually?
Thanks,
EPAM Systems, Inc.
ES
EPAM Systems, Inc.
ES
#1
A. The wizards provide ruleset options for exporting and reusing the integration across your application.
In case, you want to delete/revert the integration rules associated with REST/SOAP or any integration due to some business requirement. You could directly perform it by using OOTB "Undo-Generation"
You could leverage OOTB features and also, withdraw the rules.
I will update more pointers if I find.
EPAM Systems, Inc.
ES
#2
A. As per knowledge, its best practice and advisable to have segregated layer for reusability and other features.
And it would help in exception handling or reverting the data. Though, I am not confident that its just used for temporarily storing the data for mapping.
Hope it gives some idea, though I'll try to find more concepts related to it and update here.
Pegasystems Inc.
IN
1) Because each service should be treated differently integration wizard will create connectors in different rulesets ,however the creation of lot of rulesets shouldn’t be an issue as only the required rules will be picked up by rule resolution algorithm in runtime .
2)When you use the wizards to create data sources, the system generates all the records that are required to use the data sources. These data sources include classes, properties, authentication profiles, connectors, and so on. The wizards provide ruleset options for exporting and reusing the integration across your application.
It's always a good practice to separate the service related rules from data to support loose coupling .
http://en.wikipedia.org/wiki/Service_loose_coupling_principle
3) Integration wizards simplify the process of using data from external services in your application. The wizards walk you through the process of getting the details of the services, defining a data model from a WSDL document, example XML document, or JSON document, testing your configuration, and creating data sources in your application.
You can degenerate the code if you want from the wizard however manually it’s a tedious job to search for all dependent rules and delete it .
In case of manual process you should create all the necessary data mappings and service mappings where the chance of mistakes are high .
1) Because each service should be treated differently integration wizard will create connectors in different rulesets ,however the creation of lot of rulesets shouldn’t be an issue as only the required rules will be picked up by rule resolution algorithm in runtime .
2)When you use the wizards to create data sources, the system generates all the records that are required to use the data sources. These data sources include classes, properties, authentication profiles, connectors, and so on. The wizards provide ruleset options for exporting and reusing the integration across your application.
It's always a good practice to separate the service related rules from data to support loose coupling .
http://en.wikipedia.org/wiki/Service_loose_coupling_principle
3) Integration wizards simplify the process of using data from external services in your application. The wizards walk you through the process of getting the details of the services, defining a data model from a WSDL document, example XML document, or JSON document, testing your configuration, and creating data sources in your application.
You can degenerate the code if you want from the wizard however manually it’s a tedious job to search for all dependent rules and delete it .
In case of manual process you should create all the necessary data mappings and service mappings where the chance of mistakes are high .
Let us know if you have any further questions .
Thanks,
Arun
#3
When you use the New SOAP Integration wizard to create data sources, the system generates the records that are required to use the data source. These records include classes, properties, mapping rules, an authentication profile, and a connector.
You need to explicitly create all the properties, mapping rules and other rules manually which is overhead. While wizard does easily for you and it creates the basic structure for the integration.
- It helps in avoiding manual error as well.
Integration wizards simplify the process of using data from external services in your application. The wizards walk you through the process of getting the details of the services, defining a data model from a WSDL document, the example XML document, or JSON document, testing your configuration, and creating data sources in your application.