You can easily add Transactions that describe the behavior of a Service using a supported file format. The Transaction Repository supports HTTP(s) stateless transactions. SOAP over HTTP(s) Transactions are supported as long as you provide the required headers. You can also manually edit or add Transactions that may not be represented in a file anywhere.
The following file formats are supported:
- Swagger 2.0 (JSON and YAML)
- Swagger 3.0/Open API (JSON and YAML)
Note: You can import multiple Swagger files in a zip file, as long as the main file in the zip is called index.json or index.yaml. - HAR files
- RR Pairs
Note: Upload RR pairs as a zip file with one or more pairs. File formats must follow the name-req and name-rsp format, where the name string is the same across pairs. For example: login-req.txt and login-rsp.txt. - WSDL (WSDL or zip for multiple files)
Note: You can import multiple WSDL files in a zip format, as long as the main file in the zip is called index.wsdl. - JSON file created from the Blazemeter Proxy Recorder.
- WireMock and Mocklab definitions in JSON format
- CodeSV definitions in JSON format
In a Transaction, you provide criteria by which a request would match the Transaction, and a response that the Mock Service returns when a match is detected. The Request criteria can be a fully formed request, like a valid GET call, or a regular expression that would return a match for multiple potential requests. For more information about matching and strategies for creating requests, see Request Matching Examples.
In addition to creating Mock Service out of transactions, you can also create Mock Services out of MAR files. MAR files are portable versions of virtual services hosted in Broadcom's enterprise Service Virtualization product. They are treated differently than raw transaction data. For more information about MAR files, see Adding MAR Files.
Adding Transactions from a File
You can add Transactions from a variety of sources. You can edit those Transactions after you import them to tune the matching criteria. See Adding Transactions Manually for more information about the Request and Response fields.
- Click the Mock Services tab.
- Click Asset Catalog at the top of the page.
- Drag your file into the upload area, or click the area to browse for the file you want. This file should contain all of the Transactions that you want to use for your Mock Service.
Note: If you want to upload multiple Swagger files using a zip file, the main file in the zip file must be named index.json or index.yaml for the upload to work.
The Import Transactions dialog opens.
- Select the Service that you want to add these Transactions to.
To create a new Service:- Click Select Service.
- Enter the name for your new Service and click Add Service.
- If you want to assign one or more tags to these Transactions, type the tag name(s) in the Tags field and press Enter.
- Tags make Transactions easier to identify, especially within a large Service. You can provide tag definitions here to apply the defined tags to all imported Transactions. Or you can define tags at the Transaction level after import.
- To enter multiple tags, press Enter after each tag name.
- Click Import.
The Transactions are added to the transaction repository as part of the selected service.
Editing and Cloning Transactions
When you import files into the transaction repository, the Transactions in the file are imported exactly as they appear in the file. You will often want or need to make those Transactions more useful by updating the URL to broaden the matching criteria, or duplicate the Transaction to add a similar Transaction that was not available in the file.
- Expand a Transaction on the Transactions page.
- (Optional) If you want to preserve the existing Transaction, click the Clone icon at the top right.
A duplicate of the Transaction is created. You can expand the new Transaction and make any required edits there. - Update Name, Service, and Description as needed.
- If you want to assign one or more tags to these transactions, type the tag name(s) in the Tags field and press Enter.
- To enter multiple tags, press Enter after each tag name.
- In the Request Matcher tab, make changes to the existing request data.
For example, you can change a direct URL into a regular expression that will match multiple similar requests. Or you can add parameters or other additional matching criteria to a request.
See Request Matching Examples for more information about modifying request data. - Click Save.
The updated Transaction is saved and available for adding into a Mock Service or Template.
Adding Transactions Manually
You can manually add Transactions to the repository to account for Transactions that might not be represented in a file or specification. Cloning a similar Transaction is the simplest way to add a new Transaction without importing, but you can create a Transaction from scratch if a good reference point is not available.
- Click the Mock Services tab.
- Click Asset Catalog at the top of the page.
- Click Add Transaction.
The Transaction details page opens.
- Enter a name for the Transaction in the Name field.
- Select the Service you want to add this Transaction to from the Service drop-down.
To create a new Service:- Click Select Service.
- Enter the name for your new Service and click Add Service.
- If you want to assign one or more tags to these transactions, type the tag name(s) in the Tags field and press Enter.
- To enter multiple tags, press Enter after each tag name.
- Enter a description for the Transaction.
- In the Request Matcher tab, select the type of Transaction you want to add.
The following transaction types are supported:- GET
- POST
- PUT
- DELETE
- PATCH
- OPTIONS
- TRACE
- HEAD
- CONNECT
- ANY
- Select the proper option on the right of the URL field:
- Select Equals if you are entering a specific URL in the field that you only want to match when that specific request URL is received.
- Select Matches regex if you are entering a URL with regular expression elements that you want to match when the request URL fulfills the regex matching criteria.
- Enter the URL or regular expression in the Enter URL field.
If you are editing an imported Transaction, you can change the URL to a regular expression to make the Transaction match against a broader set of requests.
For help with URL matching, see Request Matching Examples. - Click Add in each of the following tabs to add the details for your Transaction if you want to match against any of these entities in your request:
For detailed help and examples, see Request Matching Examples.
- Headers
Note: As a best practice, avoid using the "host" header in any request matching criteria, as it can adversely affect transaction matching. - Query Parameters
- Cookies
- Credentials
- Body
- Headers
- In the Response tab, select the Status Code to return with the response when a match occurs.
- Enter the full response body in the Body field, and add Response Headers and Proxy URL values as necessary.
Remember that while the matching values can be expressions, the response data is the exact response that you want the Mock Service to return when it detects a match against the Transaction matching criteria. - Click Save.
The Transaction is added to the transaction repository.
Request Matching Examples
Adding or editing the requests in your Transactions to match against the appropriate range of potential requests that you might use for testing helps make your Mock Services powerful and efficient.
This topic includes guidance and examples for entering matching criteria for each one of the request matcher inputs:
URL
The URL is the primary request URL. You can format the URL in a variety of ways for matching purposes, including:
- A complete request URL that will only match when the Mock Service receives that exact request. Use the Equals setting for this type of request. Any parameters must be entered in the Query Parameters section.
- A partial request URL with regular expression text that will return a match for any request that matches the expression criteria. Use the Matches regex setting for this type of request.
- A complete request URL that serves as the root of a request with parameters or other information that you include in the other matching fields. For example, you can include a root URL, and then enter parameter matching criteria in the Query Parameters section that uses regular expressions.
Examples:
This URL returns a direct match of the AWS S3 GET request for an object named report.json.
This URL returns a match for a petstore GET request that includes the string 'dog' in its path.
Matches:
- https://petstore.blazemeter.com/api/pets/dogs
- https://petstore.blazemeter.com/api/pets/animals/dog
- https://petstore.blazemeter.com/api/pets/animals/dogs/small
Does Not Match:
https://petstore.blazemeter.com/api/pets/cats
Headers
Use the Headers field to include any headers that must be present to return a match. The header value can be an exact value or a regular expression.
Example:
This URL returns a match for a petstore GET request when an Accept header is included with the exact value of application/json.
Note: As a best practice, avoid using the Host header in any request matching criteria, as it can adversely affect transaction matching.
Query Parameters
Use query parameters to define a range of parameters that will result in a match. You can include multiple parameters, and the parameters can be exact values or regular expressions. When you define multiple parameters, all parameters much be present for the request to match.
When you use an equals matcher with query parameters, the incoming value is decoded before the comparison is made. Therefore, if you are trying to match on a value that is encoded within a URL, like "http://notreal/?status=25%25%20full", use the decoded value in the matcher ("25% full") instead of the encoded value in the URL.
Example:
This request matches any time when the URL matches the URL and the search_criteria query parameter is present with any value, including an empty value.
Matches:
https://petstore.blazemeter.com/api/pets?search_criteria=brown
https://petstore.blazemeter.com/api/pets?search_criteria=white
https://petstore.blazemeter.com/api/pets?search_criteria
Does Not Match:
https://petstore.blazemeter.com/api/pets
https://petstore.blazemeter.com/api/pets?page=1
This request matches any time when the URL matches the URL and the search_criteria parameter contains the values white or black.
Matches:
https://petstore.blazemeter.com/api/pets?search_criteria=black
https://petstore.blazemeter.com/api/pets?search_criteria=white
Does Not Match:
https://petstore.blazemeter.com/api/pets?search_criteria=brown
https://petstore.blazemeter.com/api/pets
The one matches a request that contains the values white or black in the search_criteria query parameter (defined as regular expression matching) and does NOT contain the query parameter store.
Matches:
https://petstore.blazemeter.com/api/pets?search_criteria=black
https://petstore.blazemeter.com/api/pets?search_criteria=white&page=1
Does Not Match:
https://petstore.blazemeter.com/api/pets?search_criteria=white&store=london
https://petstore.blazemeter.com/api/pets?store=london
https://petstore.blazemeter.com/api/pets?page=1
Cookies
Include cookies if the request needs to pass certain cookies to return a match.
Credentials
Include credentials if the request needs to include specific credentials to return a match.
Body
Include body text in the Body section if the request needs to include specific text in the request body to return a match. You can include multiple match conditions that are important to you without having to define the entire request body. For example, you might include a match condition looking for an XPATH state, and a second match condition looking for a status code in the body. In this scenario, the entire request body doesn't have to match - only the XPATH state and status code that you specified. This is a more efficient method for defining the criteria that matter to you, because if you simply included the entire request body instead, any small deviation in the body content would cause the transaction to not match.
Testing 20 Virtual Users
0 Comments