Application Design Question about Managing Integration Versions
We have an application that supports various versions of SOAP and REST integrations depending on our clients' needs. Even within these integrations, there may be parallel versions that we need to support.
For example we might have SOAP_A_v1 and SOAP_A_v2, SOAP_B_v1, SOAP_C_v1, SOAP_C_v2, etc.
The integration needs vary from client to client. Today we manage this all via client specific applications and access groups, tying the specific integration components into their profile. We use traditional rule resolution to resolve to the appropriate integration logic based on the application/access groups.
We are exploring a design in which instead of creating and maintaining a multitude of application and access group setups to represent the specific application profile we need, we will have one "god" app that knows of all of these integration components (including the various versions within each integration).
We will then maintain client specific settings telling us which integration and integration version, and we will use application logic (e.g. a version switch statement) to call the appropriate integration and integration version based on said settings. With SOAP specifically, there are so many rules created to support the integration (Classes, Properties, parse and map xml rules).
Are there application or performance concerns with having all of these rules loaded within the same application at the same time?
We have an application that supports various versions of SOAP and REST integrations depending on our clients' needs. Even within these integrations, there may be parallel versions that we need to support.
For example we might have SOAP_A_v1 and SOAP_A_v2, SOAP_B_v1, SOAP_C_v1, SOAP_C_v2, etc.
The integration needs vary from client to client. Today we manage this all via client specific applications and access groups, tying the specific integration components into their profile. We use traditional rule resolution to resolve to the appropriate integration logic based on the application/access groups.
We are exploring a design in which instead of creating and maintaining a multitude of application and access group setups to represent the specific application profile we need, we will have one "god" app that knows of all of these integration components (including the various versions within each integration).
We will then maintain client specific settings telling us which integration and integration version, and we will use application logic (e.g. a version switch statement) to call the appropriate integration and integration version based on said settings. With SOAP specifically, there are so many rules created to support the integration (Classes, Properties, parse and map xml rules).
Are there application or performance concerns with having all of these rules loaded within the same application at the same time?
Also, are there any new features or enhancements available to simplify the underlying structure that supports SOAP integrations so that we don't need the thousands of rules generated for a simple SOAP integration?
Infosys Limited
IN
Check the decision table approach of setting the interation versions based on the kogc you have. Whatever connect rule that comes out of the decision you can execute that.
Quavo
US
@P.Siva.Praveen Thank you for the response. However my question is not about how to manage dynamically calling the connectors. My question is, are there performance concerns with having the application that knows about all of these giant integration rulesets. In the past we had application specific profiles that limited rulesets and used rule resolution depending on the specific integration needs of a client. Our proposed design is to have a god app that knows of all the various flavors of integrations with all their rulesets defined in the app and to use logic like you described to dynamically call the appropriate connector. The Soap integrations are gigantic, with thousands of rules and classes to support the integration. Are there performance concerns with having these all within one application? Additionally, are there any new integration features that allow us to support SOAP with a lighter solution that doesn't require all the classes, properties, and parse/map xml rules?
Quavo
US
@P.Siva.Praveen Still looking for guidance on my questions.