Enhancing testing efficiency with DX API and setting user context while invoking DX API

General
, ,
1

Hello Pega Community,

We’re currently running an application in production that is built on Constellation + Customer Service. While we’ve already implemented Selenium automation scripts for UI testing, the process is time-consuming when covering the entire test suite. To accelerate testing, we’re exploring the DX API for running through workflows via API-based testing tools such as Postman or Bruno.

What We’re Looking For:

The goal is to reduce the overall testing time and speed up our release process by leveraging the DX API. However, we’ve run into a challenge where, when triggering the DX API from Postman, it returns response based on the admin user’s context. We have various other roles, such as Dealers, that have different permissions and can perform distinct actions compared to Admins.

Our Challenge:

We want to set up different user contexts (i.e., various access groups or personas) while calling the DX API to cover all test scenarios. One key thing to note is that we want to avoid creating users in our SSO Identity Management (IDM) system. We need the flexibility to test various operator roles without having to add new users every time.

What We’ve Tried:

  • We currently use Selenium for UI automation, but it’s taking too long.
  • We’re planning to shift to API-based testing using Postman or similar tools.
  • However, we’re stuck on how to set the operator or user context dynamically in the DX API without involving our SSO setup.

What We’re Hoping to Learn:

  • Has anyone implemented a similar approach where you can set the user context dynamically for different personas using the DX API?
  • Are there best practices for setting up operators for testing without touching the SSO?
  • Any tools, workarounds, or insights into speeding up the testing process using DX APIs would be greatly appreciated.

Looking forward to hearing your thoughts and solutions

Thanks in advance,

Maynak Dubey

2

Changing roles via an external facing API opens numerous security issues. Alternatives for achieving desired result:

  • Multiple users with different roles (easiest solution) - Per comment above the desire is to avoid multiple operators in SSO IDP

  • Give access group(s) used by test operator update rights to the Data-Admin-Operartor-ID class to facilitate changing access group used by the operator. Use standard Infinity password protection to lock down the test operator. Postman would use the Infinity password during authentication. For additional security program network infrastructure to limit access by test operator to internal domain, existing sub-domain or dedicated Postman internal sub-domain

  • Note, Code-Security.pxUpdateOperatorContext updates the requestor context after changing to the desired access group on the Operator ID page.