What’s new for April 2024?

[Service Virtualization]: Prioritizing transactions (unique priorities) 

Once transactions are assigned to a Virtual Service, the priority for each transaction can be defined uniquely. Matching of transactions is based primarily on the Request Matchers defined. If multiple transactions could be matched, then the new functionality of Unique Priorities can be used to assign unique priorities for those transactions. For example, transaction A has a priority of 4 and transaction B has a priority of 9. Since transaction A has a lower priority of 4, it will be matched and returned. However, you need transaction B to be the matched transaction. In that case, utilize the “Unique Priorities” feature to change the priorities and assign transaction B to be a lower priority than transaction A. In this case, you could move the transaction B such that its priority is lower priority than transaction A and thereby is matched first. 



 

[Service Virtualization]: Support for certs/keystore per environment 

A single transaction can be used across multiple Virtual Services. Every transaction can be configured with certs and/or keystores in processing actions like HTTP call and Webhooks. However, when that transaction is a part of multiple Virtual Services, if a different cert/keystore needs to be configured then that affects all the Virtual Services that have that transaction. So, rather than hardcoding the certs/keystore at the transaction level, this can be configured at the Environment level. Since parameters defined in the Environment level can be used with the syntax of $config.<paramname> inside transactions, that resolves the issue of hardcoding the certs/keystore into the transactions.  

Env2 has a parameter called mycert with dummy.jks, this parameter can be referenced in your Virtual Services with the Env2 selected as the current Environment as $config.mycert 


 

Env1 has a parameter called mycert with multiple-clients.jks, this parameter can be referenced in your Virtual Services with the Env1 selected as the current Environment as $config.mycert 

 


 

[Service Virtualization]: Revamped intuitive keystore and certs management 

All Keystore and Certs can now be uploaded, managed and deleted from the Certificates area of the Asset Catalog. See below 


 

Certificates can be opened, viewed and downloaded using this screen with the Actions column. 

Keystores can be viewed, edited, managed and deleted from the Actions column. Passwords for keystore assets can be added/updated in this section as well.  

Once a keystore and or cert is uploaded into the Asset Catalog ---> Certificates section, it can be used in the Virtual Services, transactions (processing actions) and the Environments. 

[Correlation Recorder]: JSON correlation rules 

In today's web environment, JSON is frequently used in both request and response data.  

Until now, when confronted with JSON scenarios, plugin users had to rely on complex regular expressions that sometimes weren’t precise for the correlation.  

The new version of the Correlation Recorder plugin introduces JSON-type correlation rules: JSON extractor and JSON replacement, using JSONPath. 

With the new version of Correlation Recorder, users can create JSON-type correlation rules instead of using Regex or manually creating a JSON post processor, save and use templates with JSON rules and have more control over correlation when JSON format is present in the recording.