Question
CYBG PLC
IN
Last activity: 4 Dec 2024 6:57 EST
Service Accessgroup for OOTB Service Package in a multi application environment
We are hosting multiple separate applications in a pega cloud stack. All these applications need to use Pega APIs in their own context.
The service package requires a service AccessGroup which can only point to one application at a time.
We can duplicate the Package instance for each application, but then we'll have to duplicate all the service rules as well. But that way reusability will be lost.
What is the recommended design approach for this instance?
Personly
NL
@ArindamD1592 Usually in pega after authentication the context shifts to the requester being logged in with authorisations that are granted to that operator. From that perspective, the pega apis will have access to data pages cases etc that the operator/requestor has access to. So you may try to create mulitiple operators, one for each application context that you want to access, each operator having a access group for the perticular aplication. (i am working from memory i might be correct) Indeed copying the service package and services is not a great solutions, especially not for the Pega API's. I may have misunderstood, if your question is about a service that is not a Pega ootb api but a custom one then its a little bit different. In that case you may have to build the api in a separate application that builds on the applications that you want to access with that sevice. Good luck! :)
CYBG PLC
IN
@Niels_U Thanks for your time in answering this.
To be specific, I was trying to use the Pega Data View API (api/v1/data) to expose few data pages for each applications. The challange is, the API is not able to find the data page unless the service package api with the application accessgroup to set the context. We can't do that for different applications unless we duplicate the structure.
As you suggested, I tried defining 'OAuth 2.0 Client Registration' and specifying the operator/AccessGroup context into that. But the api is still not taking the application context from there.
Hence I was wondering if there is any other way instead of creating multiple copy of the service package and service rule.
Personly
NL
@ArindamD1592 Hi Arnidam, thanks for the additional info. It is not desired or needed to copy the pega api service package and services. I have done a experiment on a community edition platform version 24.2. Used client credentials as grand type. For me it works with:
Each application having has its own oauth 2.0 client registration matching the accessgroup of the application (i used operator records (one for each application) have not tested the accessgroup option).
The v1 pega api service package has basic auth configured ootb, this should be changed to oauth 2.0 (in case you missed that, but i suppose you already updated it)
My observation, when i requested a data page not present in the application slected given the client secret and token the api returns resource not found error 404. With the correct credentials it would return the data requested.
Did not need to change the token urls for the different applications, just use the correct client id client credentials.
I tested it with specific data pages for specific case types present in the specific applications. My recommendation is to double check the authorizations and if the access tokens match the intended application. Hope you get it working!
Accenture
IN
@Niels_U Thanks for reconfirming.
My AccessGroup didn't have the role PegaRULES:PegaAPI added, hence the issue.
I have now tested with both the user ID and Accessgroup added to the 'OAuth 2.0 Client Credentials'.
Thanks for your help. This is now resolved.