How to Support Service versioning in Pega
Hi All,
We are on Pega 8.1 and we have been requested to support multiple versions for our REST service simultaneously . The service is authenticated using OAuth2.0 . We could think of 2 approaches
1) Same Access Group / Application :- Using this approach , we would have the same access group and application but different activities with different code for each version of the service . This is how Pega Marketing application did it for "Container" service. They had 2 different activities Handlecontainer and HandleContainer_v2 for 2 service versions .
Pros :-
Easy to maintain and easy to understand for the developers .
Multiple access groups and applications creation not necessary which has impact on the application score.
Cons:-
Becomes a little challenging for some logic i.e if there are decision tables used in the logic ,we have to end up maintaining multiple rules like DecisionTable_v1 , DecisionTable_v2 .
2) Different Access Group / Application :- Using this approach, we create multiple access groups and applications . This
Pros :-
Rule Resolution takes care of executing the code as per the application definition.
Cons:-
Defect fixing / enhancements will be challenging as we have to leave gap between the rsv versions to support multiple service versions .
Hi All,
We are on Pega 8.1 and we have been requested to support multiple versions for our REST service simultaneously . The service is authenticated using OAuth2.0 . We could think of 2 approaches
1) Same Access Group / Application :- Using this approach , we would have the same access group and application but different activities with different code for each version of the service . This is how Pega Marketing application did it for "Container" service. They had 2 different activities Handlecontainer and HandleContainer_v2 for 2 service versions .
Pros :-
Easy to maintain and easy to understand for the developers .
Multiple access groups and applications creation not necessary which has impact on the application score.
Cons:-
Becomes a little challenging for some logic i.e if there are decision tables used in the logic ,we have to end up maintaining multiple rules like DecisionTable_v1 , DecisionTable_v2 .
2) Different Access Group / Application :- Using this approach, we create multiple access groups and applications . This
Pros :-
Rule Resolution takes care of executing the code as per the application definition.
Cons:-
Defect fixing / enhancements will be challenging as we have to leave gap between the rsv versions to support multiple service versions .
My understanding is that when we do OAuth2.0 we are providing access to a resource . Does it make sense to use Approach 1 if our service just does a BRE logic and nothing related to case processing ? Also i would like to know best practices from Pega standpoint to handle various scenario's like Case Creations / Headless Engine etc .
Appreciate your responses.
Thanks
Dinesh
Booking Holdings
IN
Could you share the context as why we need to support multiple versions of the service? Is it temporary in nature; e.g. for testing? Or there are reasons that it is a permanent setup; if so then what's the background?
We can go further into design based on the overall context.
JP Morgan Chase
IN
Hi Anupam ,
This may be a transient setup ( do not know the time line though ) . There are multiple consumers for this services and each have different timelines to production .One of the consumer is already leveraging this service in production and the other consumers want to have updated business logic and hence a need for new version of the service . Do let me know if you need any other information .
Booking Holdings
IN
Hi Dinesh
Since it is temporary in nature...
a. If in a single environment (say, QA or UAT) we need to host 2 different versions of the service which will be consumed by 2 different customers, then we need to go with approach 1. Else you need to create 2 service packages pointing to 2 different access groups/applications. This will result in 2 endpoint urls and you need to provide customers the url corresponding to them.
b. If there is only one version of service to be run on a single environment, then we can go with approach 2 which will only need creation of a new access group/application or update the existing application with the new ruleset version.