Setting up the Pega Offline Sync JMeter Framework
We need assistance with setting up the Pega Offline Sync JMeter Framework - https://community.pega.com/marketplace/integrations/pega-offline-sync-jmeter-framework.
We have several questions regarding variables extraction and steps to run the script.
1. Following instructions, we reached Step 4, where is saying that OAUTHCLIENTNAME variable is posted as part of the pzGetMobileAppConfiguration POST transaction when not configured to use OAuth2 and that this value should be extracted from a Charles or Fiddler trace of the initial sync.
Could you please give us more information about which transaction it should be extracted from?
2. Could you please clarify the need of setting up Decomposed Actions (which process is described in Step 3). Which transactions are affected by using decomposed actions?
By searching in JMeter we found only "Populate Work Start/End" jsr223 samplers, but we didn't fiind any transactions where Decomposed Actions variables would be used.
***Edited by Moderator Marije to change type from General to Product, added Product details and Capability tags****
Updated: 10 Feb 2023 9:43 EST
Pegasystems Inc.
US
Hi @DaniilL0 ,
Would be good to understand which release of Pega Infinity server you are using. This JMeter framework was created for version 7.4 and adapted to work with 8.1, but I'm uncertain if more recent updates to the protocol may require additional refinements to this Jmeter file that is at the core of the framework.
Here are answers to your queries:
1) If you setup the mobile device with the mobile pega app to route all transactions through a proxy (so that they might be captured and analyzed), there is an initial transaction that is a POST transaction to ?Activity=Data-Portal.pzGetMobileAppConfigurations and there are various parameters that are part of the POST payload. In the JMX file it is the transaction with label "Login and get mobile app configuration" and a pega_client_name parameter was seen and this OAUTHCLIENTNAME param is there to mimic that. I don't think it should have an adverse effect to just leave the default value there (but not 100% certain). If you don't. find that parameter in your captured traces, you might remove that parameter from the corresponding .jmx transaction as well. I don't believe it is so critical to get this to work.
Hi @DaniilL0 ,
Would be good to understand which release of Pega Infinity server you are using. This JMeter framework was created for version 7.4 and adapted to work with 8.1, but I'm uncertain if more recent updates to the protocol may require additional refinements to this Jmeter file that is at the core of the framework.
Here are answers to your queries:
1) If you setup the mobile device with the mobile pega app to route all transactions through a proxy (so that they might be captured and analyzed), there is an initial transaction that is a POST transaction to ?Activity=Data-Portal.pzGetMobileAppConfigurations and there are various parameters that are part of the POST payload. In the JMX file it is the transaction with label "Login and get mobile app configuration" and a pega_client_name parameter was seen and this OAUTHCLIENTNAME param is there to mimic that. I don't think it should have an adverse effect to just leave the default value there (but not 100% certain). If you don't. find that parameter in your captured traces, you might remove that parameter from the corresponding .jmx transaction as well. I don't believe it is so critical to get this to work.
2) The Decomposed Actions are related to the payload sent on each synch transaction from the device to the server. The synch protocol allows for configuring some parameters around how many actions to include with each transaction, and by setting up this decomposed actions. The script can then simulate different # of minimum actions and this might be used to run different load tests to find the optimal settings for the application in question.
3) Search and find the "Case Actions bundler ${dispCaseInfo}" JSR233 Sampler. Also search on "DA" and you will find where it accesses such DA* vars.
I hope this is helpful.
Thanks
- Vinod Seraphin
EPAM Systems Inc
BY
Hi,@serav, thanks for your answer! The Decomposed Actions moment became much clearer.
The reason we asked about OAUTHCLIENTNAME param is that "Login and get mobile app configuration" request (which contains this param) throws 307 response code and empty response data (screenshot is attached). To run script we only changed password, UserIdentifier and serverdomain variables, and we tried different settings intended for 7.4 and 8.1. After all interactions we still get same result. Would be grateful if you would advise us on what else we should pay attention to.