Posted: 3 Apr 2018 10:51 EDT Last activity: 26 Jun 2018 7:29 EDT
Common Web Service across multiple Pega Applications
We are using Pega 7 and have multiple Pega applications on the same instance which are logically separated through the class structure. I want to build a common inbound web service which will be used to create/update/inactivate an operator record. Depending on the application the user belongs to (defined in the payload) custom business logic needs to be invoked depending on the application eg. superuser needs to be notified.
As I am a newbie I was wondering how we can design a Pega Inbound Web service to notify all Pega applications which use the service when a payload is received from an external system?
A Service Package is associated to one Access Group, hence can only perform tasks allowed by the Access Group's Application.
An Agents rule is associated to a ruleset. The same ruleset can be added to every Application that performs Business Logic processing. Let's name this ruleset "OperatorChangeHandling".
The create/update/inactivate-an-operator-record Service's Application should notperform Business Logic processing, hence would notinclude the above-mentioned OperatorChangeHandling ruleset.
Instead that Service should create/update/inactivate the indicated operator record as instructed then create a Data-Operator-Change record stating what action was performed on what Operator record.
An Agents rules defined in the OperatorChangeHandling ruleset would periodically check for newly added Data-Operator-Change records. The Activity that the OperatorChangeHandling Agent calls would implement the Template Pattern. Each Application would override the allowed extensions points according its specific requirements.
All code common to operator change handling would be included in the OperatorChangeHandling ruleset. Ideally the OperatorChangeHandling ruleset would be included in a Component.
Can you please expain this a bit more? are you suggesting to have multiple agent rules? Otherwise how would this solve the problem. In agent rule we have to mention the Access group which will be used for generate agent requestors. So the application is always same and there is no customization based on the operators access group.
An alternative exists to having each application poll a queue populated by a Service. A more efficient implementation is having the Service "impersonate" an application temporarily and safely within a Template Pattern-permitted override.
The Access Group of the PegaUnit Service Package is PRPC:Administrators yet that Service is able to switch access groups as-needed to execute test cases and suites. java step 15 in the Code-Pega-List pzValidateInputs Activity is shown below. Note how the current pxThread's Access Group is can be changed to the AG specified by an "AccessGroup" parameter.
You can do a content search for "setActiveAccessGroup". This function is conditionally called in the System-Queue-ServiceLevel agent's EstablishContent activity.
The only example that comes close to being a "pattern" AFAIK is what occurs in pzGetTestsAndExecute but exactly what each Application overrides is not clear. Any Application can define Test Cases; pzGetTestsAndExecute can execute any test case given its pxInsName and Access Group.
If you are running 7.2.2 or greater you can develop an application that the service calls and that every other application adds as a built-on application. The other applications would override a stubbed-out / templated rule to implement their specific Business Logic.
An example of the above app structure, minus any template rule to override, is the Deployment Manager application that you can download from Pega Exchange. The "DevOps Orchestration" Manager application is built on an application named "PegaDevOpsFoundation" which "Candidate" applications are required to be built on as well.