Traffic Parrot 5.48.0 released, what's new?

We have just released version 5.48.0. Here is a list of the changes that came with the release:

Features

• New Thrift API to send a request by mapping id:

  curl -v http://localhost:8080/thrift/management/sendThriftMessage -d send-mapping-id=fc7ee4ad-e247-49a8-8528-af20845adde9 -d send-to-host-port=localhost:5562

• Thrift message recordings are now in JSON format
• New {{ executeProcess '/bin/bash' '-c' 'echo hello' }} helper to execute external processes

Fixes

• Fixed a Thrift issue when the same method name is defined in super and subclass
• Fixed a Thrift issue with methods that are prefixes/suffixes of other methods

Changes

• Thrift compiler binary must be version 0.10.0 for backwards compatibility reasons

The Executive's Guide to Shift-Left Testing: Beyond the Buzzword

What is Shift-Left Testing?

At its core, shift-left testing means moving quality assurance activities earlier in the software development lifecycle. Rather than waiting until development is complete to begin testing, quality becomes integrated from day one. But the actual value goes far beyond just testing earlier.

The Business Case

According to our data, organizations implementing shift-left testing are seeing remarkable results:

• At least 43% faster software releases
• At least 38% fewer customer-facing issues

In this example, we calculated the ROI for one of our clients. For their typical release, they would get $800,000 in net return and a 15-day speed-up in release schedules for a modest developer's time investment.

These benefits come from three key areas:

1. Reduced rework and context-switching costs

2. Faster time to market through parallelized development

3. Higher quality through early defect detection

Beyond Testing: A Requirements-First Approach

The most successful implementations treat shift-left testing as more than moving QA earlier. It becomes a requirements-first approach where business needs are captured as automated tests before development begins.

When business stakeholders are asked, "How will you know if this feature works as intended?" Their answers become the acceptance criteria and automated tests. This ensures alignment between business needs and technical implementation from the start.

Implementation Framework

Here's how our clients are successfully implementing shift-left testing:

Phase 1: Pilot Program (1-2 months)

- Select 1-3 teams for initial implementation

- Focus on high-visibility, moderate-risk initiatives

- Provide tools and training for API-first development and test automation

- Measure baseline metrics for comparison

Phase 2: Scale Success (3-6 months) 

- Document learnings and patterns from pilot teams

- Create an internal community of practice

- Roll out to additional teams in waves

Phase 3: Enterprise Transformation (6-24 months)

- Integrate shift-left practices into standard methodologies

- Update governance and funding models

- Implement cross-team metrics and reporting

- Continue optimization based on data

Key Success Factors

1. Executive Sponsorship: Position quality as a business driver, not just a technical concern
2. Tool Selection: Provide teams with the right tools for test automation, API mocking, and continuous testing
3. Skills Development: Invest in upskilling developers and QA professionals in new practices
4. Metrics Focus: Track both technical and business metrics to demonstrate value:
• Decrease in production issues
• Faster time to market
• Time to recover from a production incident

Conclusion

Shift-left testing, when implemented properly, drives significant business value through faster delivery, higher quality, and lower costs. Success requires executive commitment, the right tools and practices, and a focus on business outcomes rather than just technical metrics.

By starting small, measuring results, and scaling success, organizations can transform their software delivery capabilities while maintaining stability and managing risk.

Traffic Parrot 5.47.1 released, what's new?

We have just released version 5.47.1. Here is a list of the changes that came with the release:

Features

• Improved support for sending one or more JMS messages after an HTTP or gRPC response
  • Messages can now be in proto format
  • Message delay can now be dynamic

Fixes

• Fixed an {{ objectStore }} bug where a deadlock could occur with multiple usages in the same response
• Fixed an issue with startup logging

Troubleshooting Nested Handlebars Each Loops in Traffic Parrot

When working with nested data structures in Traffic Parrot mock responses, you may encounter unexpected behaviour with nested {{#each}} loops, mainly when using the @index variable. Here's how to handle this common issue.

The Problem

Consider a request containing nested arrays, such as a list of customers, each with multiple contact methods:

{
  "customerId": "ABC123XYZ",
  "details": [
    {
      "name": { "first": "John" },
      "contacts": [
        {
          "region": "123",
          "identifier": "5551234567",
          "category": "PRIMARY"
        },
        {
          "region": "123",
          "identifier": "5551234568",
          "category": "SECONDARY"
        }
      ]
    }
  ]
}

When using nested {{#each}} loops without named loop variables, the @index variable may reference the outer loop's index instead of the intended inner loop's index.

The Solution

To correctly handle nested loops, always use named loop variables in your {{#each}} statements:

{{#each (jsonPath request.body '$.details') as |details| }}
{
  "customerId": "{{ jsonPath request.body '$.customerId' }}",
  "status": "SUCCESS",
  "statusDescription": "Customer record created",
  "details": [
    {{#each details.contacts as |contact| }}
    {
      "region": "{{ contact.region }}",
      "identifier": "{{ contact.identifier }}",
      "category": "{{ contact.category }}"
    }{{#unless @last}},{{/unless}}
    {{/each}}
  ]
}{{#unless @last}},{{/unless}}
{{/each}}

Best Practices

1. Always name your loop variables in {{#each}} statements
2. Use descriptive variable names that reflect the data being iterated
3. Remember to handle comma separators using {{#unless @last}},{{/unless}}

How should data pipeline teams test their products?

Our client is looking to expand the usage of our tooling at their enterprise, and among many teams, we talked to a data pipeline team.

The advice we have given them was to:
1. Write automated tests for their data pipelines
2. Consider shift-left testing of their data pipelines
3. Use an API design-first approach when integrating with other teams

Thoughtworks has two great articles with an introduction to testing data pipelines and ML quality:

• https://www.thoughtworks.com/en-gb/insights/blog/testing/testing-data-pipelines 
• https://www.thoughtworks.com/insights/blog/machine-learning-and-ai/effective-ml-part-II 

We recommended to this team that they use an API design-first approach as described in the article we published a while back https://www.infoq.com/articles/api-mocking-break-dependencies/ 

API-first and API-mocks will allow their consumer teams to start working on their critical features before the data pipeline and ML code are ready, reducing the time to market for the new critical functionality, which will make the product managers and users very happy!

Contact us for a free-of-charge, no-obligation 30-minute call if you would like to discuss how design-first APIs can help accelerate critical deliverables at your organization.

Traffic Parrot 5.46.7 released, what's new?

We have just released version 5.46.7. Here is a list of the changes that came with the release:

Features

• Added support for sending one or more JMS text messages after an HTTP or gRPC response, configured via mapping JSON:

  "postServeActions" : [ {
      "name" : "send-jms-message",
      "parameters" : {
        "jmsConnectionId" : "(connection id from jms-connections.json)",
        "destination" : {
          "name" : "queue-name",
          "type" : "QUEUE"
        },
        "variables" : {
          "id" : "{{randomValue length=24 type='ALPHANUMERIC'}}"
        },
        "properties" : {
          "id" : "{{variables.id}}"
        },
        "jsonBody" : {
          "id" : "{{variables.id}}",
          "fieldFromRequest" : "{{originalRequest.jsonBody.requestField}}",
          "fieldFromResponse" : "{{originalResponse.jsonBody.responseField}}"
        },
        "delayDistribution" : {
          "type" : "fixed",
          "milliseconds" : 500
        }
      }
  } ]

• Added additional Okta JWT access token verification
• Added gRPC native transport for Apple ARM based processors

Fixes

• Fixed desktop issue where the start and stop scripts would steal focus on launch
• Fixed logging issue where HTTP and HTTPS GUI ports would be printed in the logs even if a port is disabled
• Fixed a DNS resolution failure issue on Mac
• Improved OpenAPI parser compatibility
• Improved error message when script runtime is missing

Changes

• Upgraded bundled JRE from 8u392 to 8u402
• Upgraded gRPC from 1.60.0 to 1.63.0
• This release is compatible with the MQ com.ibm.mq.allclient JAR up to version 9.3.4.1
• When using IBM MQ Advanced for Developers Docker icr.io/ibm-messaging/mq:9.3.4.0-r1 and above, MQ_APP_PASSWORD must be set for the app user, the default lack of password is no longer supported by the container
• IBM MQ username and password are now interpreted as null if set to "" or "null" in the connection JSON configuration
  • To configure a "" value use "<empty>"
  • To configure a "null" value use "<null>"
• Improved JMS message logging for null property values
• Library upgrades to fix OWASP issues

Large Enterprise Service Virtualization

Large enterprises use a wide variety of software architectures (Monolith running on VMs 

Microservices running in ephemeral containers, Cloud-native serverless).

Tools that fit one paradigm do not fit well with other paradigms. For example, teams use different tech stacks specialized in monolithic architectures or microservice architectures.

Enterprise Archiecture teams must provide solutions to product teams to support all use cases.

Traffic Parrot 5.45.0 released, what's new?

We have just released version 5.45.0. Here is a list of the changes that came with the release:

Features

• Added support for default HTTP OPTIONS response based on the current HTTP mappings, enabled by:

  trafficparrot.http.optionsResponse.enabled=true

• Added support for accessing HTTP VS using the UI port, enabled by:

  trafficparrot.gui.forwardToVirtualService.enabled=true

• Added support for Okta SSO integration, enabled by:

  trafficparrot.okta.enabled=false
  trafficparrot.okta.clientId=some_client_id
  trafficparrot.okta.clientSecret=some_client_secret
  trafficparrot.okta.oktaAuthorizeUri=https://${yourOktaDomain}/oauth2/default/v1/authorize
  trafficparrot.okta.oktaTokenUri=https://${yourOktaDomain}/oauth2/default/v1/token
  trafficparrot.okta.oktaIssuerUri=https://${yourOktaDomain}/oauth2/default
  trafficparrot.okta.oktaAudience=api://default
  trafficparrot.okta.oktaRedirectUri=https://some-TP-deployment-uri

Traffic Parrot 5.44.0 released, what's new?

We have just released version 5.44.0. Here is a list of the changes that came with the release:

Features

• Added support for zero response messages in server streaming record/replay gRPC

Fixes

• Library upgrades to fix OWASP issues
• Exposed properties to allow changing maximum HTTP header size:

  trafficparrot.virtualservice.jettyHeaderRequestSize=8192
  trafficparrot.virtualservice.jettyHeaderResponseSize=8192

Changes

• Reduced default HTTP container threads from 500 to 100:

  trafficparrot.virtualservice.containerThreads=100

Traffic Parrot 5.43.2 released, what's new?

We have just released version 5.43.2. Here is a list of the changes that came with the release:

Features

• Added support for editing gRPC response delays in the UI
• Added support for editing HTTP/gRPC response delays with uniform min/max distribution in the UI
• Added support for connecting to IBM® MQ with an unspecified or null username/password

Fixes

• Library upgrades to fix OWASP issues
• Timeout shutdown if tray icon takes too long to close

Changes

• Upgraded protoc from 3.24.4 to 3.25.1
• Upgraded gRPC from 1.58.0 to 1.60.0
• Upgraded bundled JRE from 8u382 to 8u392
• Increased shutdown logging verbosity
• Windows executable metadata was updated
• The default virtual service CA certificate was renewed
• Amazon SQS HTTP plugin retired, please contact support@trafficparrot.com if you need extended support

Extension to OpenAPI specs that documents which responses to return when requests are invalid.

We have added a specification extension to OpenAPI specs that documents which responses to return when requests are invalid.

It allows your API consumers to understand in more detail what validation responses look like just by looking at the OpenAPI spec. It is handy for external APIs where talking directly to support might take time.

It also allows Traffic Parrot to generate API mocks that mimic those validation rules on the fly from just the OpenAPI spec without any need for coding. That means the API consumers have API mocks ready in milliseconds without any coding required!

For example, to validate the entire request and return a specific response object, you can add to your OpenAPI example:

x-traffic-parrot-validation:
- type: schema
  response:
  code: INVALID_REQUEST
  message: ${in} parameter ${name} has invalid value ${value} because  ${reason}

We are adding more sophisticated rules to allow embedding even more details in the OpenAPI spec.

Comment below "Keep me posted!" if you want to hear more when ready!

Traffic Parrot 5.42.2 released, what's new?

We have just released version 5.42.2. Here is a list of the changes that came with the release:

Features

• Added support for casting to a boolean value
• Added request matching and response templating examples to check for presence of an optional JSON field:

  {{#if (jsonPath request.body '$.[?(@.field)]') }}field is present{{/if}}
  {{#if (not (jsonPath request.body '$.[?(@.field)]') ) }}field is not present{{/unless}}
  {{#if (jsonPath request.body '$.[?(!(@.field))]') }}field is not present{{/unless}}
  {{#unless (jsonPath request.body '$.[?(@.field)]') }}field is not present{{/unless}}
  

• Added new Couchbase configuration options
  • Added support for executing a Couchbase warmup query on startup, which can improve performance of subsequent
  • Added support for setting Couchbase IO options enableDnsSrv and networkResolution
  • Enable in database-connections.json by setting:

    {
        "connectionId": "couchbase.db",
        "type": "COUCHBASE_CONNECTION",
        "connectionString": "couchbase://localhost:32784",
        "username": "Administrator",
        "password": "password",
        "warmupQuery": "SELECT COUNT(*) FROM bucket_a UNION SELECT COUNT(*) FROM bucket_b",
        "enableDnsSrv": true,
        "networkResolution": "auto"
    }

• Added support for OpenAPI request schema validation annotations (beta)
  • Enable in trafficparrot.properties by setting:

    # OFF will turn off validation
    # DEFAULT_VALIDATION will turn on validation and provide default responses when not annotated
    # ONLY_ANNOTATED will turn on validation only for annotated specifications
    trafficparrot.openapi.request.validation.mode=OFF

  • Place OpenAPI specifications in the openapi configuration directory
  • Requests that match the OpenAPI URL will be validated according to the schema of the parameters
  • By default, Traffic Parrot will return an HTTP 400 response with a human-readable plain text validation message of the first validation error encountered
  • You can customize which fields to validate and the error response, by annotating the OpenAPI YAML file with:

    paths:
      /items:
        get:
          parameters:
            # standard OpenAPI parameters with schema definitions
          responses:
            '400':
              content:
                application/json:
                  schema:
                    # standard OpenAPI response schema definition
              x-traffic-parrot-validation: # array of validations that trigger this response code

  • To validate the entire request and return a plain text validation message:

    x-traffic-parrot-validation:
    - type: schema
      response: ${in} parameter ${name} has invalid value ${value} because ${reason}

  • To validate the entire request and return a specific response object:

    x-traffic-parrot-validation:
    - type: schema
      response:
        code: INVALID_REQUEST
        message: ${in} parameter ${name} has invalid value ${value} because ${reason}

  • To validate particular query/path/header parameters and return a specific response object:

    x-traffic-parrot-validation:
    - type: schema
      parameters:
      - name: style
        in: query
      - name: limit
        in: query
      - name: id
        in: path
      - name: X-Request-Label
        in: header
      response:
        code: INVALID_REQUEST_PARAMETER
        message: ${in} parameter ${name} has invalid value ${value} because ${reason}

  • To validate the request body:

    x-traffic-parrot-validation:
    - type: schema
      parameters:
      - name: *
        in: requestBody
      response:
        code: REQUEST_BODY_INVALID
        message: Request body has invalid value ${value} because ${reason}

  • To perform a specific validation and fall back on a catch-all validation:

    x-traffic-parrot-validation:
    - type: schema
      parameters:
      - name: style
        in: query
      response:
        code: INVALID_QUERY
        message: query parameter ${name} has invalid value ${value} because ${reason}
    - type: schema
      response:
        code: INVALID_REQUEST
        message: ${in} parameter ${name} has invalid value ${value} because ${reason}
    

  • Multiple response codes can be annotated, but only one response code per OpenAPI path should have a catch-all validation
  • The template parameters ${name} and ${value} will be populated with the name and value of the field that failed validation
  • The template parameter ${in} will be populated with query/path/header/requestBody
  • The template parameter ${reason} will be populated with a human-readable description of why the validation failed

Fixes

• Library upgrades to fix OWASP issues
• Upgrade script now migrates any previous logback configuration
• Fixed an issue where {{ dataSource }} errors would shadow all other context variables
• Improved internal error reporting when an expected Handlebars variable is not found or of the wrong type
• Validate that mapping queue name is not empty when saving a mapping and when starting replay mode
• Improved performance when using custom request matchers for requests that do not match the standard matcher checks

Changes

• Upgraded WireMock from 2.35.0 to 2.35.1
• Upgraded protoc from 3.23.4 to 3.24.4
• Upgraded gRPC from 1.56.1 to 1.58.0
• Upgraded bundled JRE from 8u372 to 8u382

Traffic Parrot 5.41.7 released, what's new?

We have just released version 5.41.7. Here is a list of the changes that came with the release:

Fixes

• Fixed support for modifying more than one header in a Handlebars script:

  {{ modifyResponse 'headerValue' 'header-name-1' 'header-value-1' }}
  {{ modifyResponse 'headerValue' 'header-name-2' 'header-value-2' }}

• Improved system tray OS compatibility
• Fixed a bug in the stop.sh script impacting Apple ARM based M1/M2 processors
• The UI log file viewer now supports viewing .gz and .zip log files

Changes

• Logback can now be specified as a logging provider in jvm.args:

  trafficparrotserver.logging.properties.filename=trafficparrotserver.logback.xml

• For organizations that have parted ways with all versions of Log4j, we now offer a distribution with those JAR files removed entirely

Traffic Parrot 5.41.0 released, what's new?

We have just released version 5.41.0. Here is a list of the changes that came with the release:

Features

• Random mixed case strings of a fixed length can now be generated using

  {{ randomValue length=10 type='ALPHANUMERIC' mixedcase=true }}

• Header values can now be set in Handlebars scripts using

  {{ modifyResponse 'headerValue' 'header-name' 'header-value' }}

• New simplified OpenAPI mock import
  • Enable in trafficparrot.properties by setting:

    trafficparrot.openapi.import.mode=SELECT_RESPONSE_STATUS
    trafficparrot.openapi.skeletons.mode=SELECT_RESPONSE_STATUS

  • When OpenAPI response examples are present, they are used directly as mock responses
  • Otherwise, OpenAPI schema data types and field structures are used to generate a valid mock response
  • The request header x-traffic-parrot-select-response-status can be set to a numeric response code to select which response to return
  • The default response returned is the success response
  • The request body is not included in matching, to simplify the response selection
  • The request URL is used for matching, including checking for mandatory path and query parameters
• Role based UI access to allow defining some read only UI users that are allowed view permissions but not edit permissions
  • Enable in trafficparrot.properties by setting:

    trafficparrot.gui.security.mode=LOGIN_PROPERTIES

  • Define users in trafficparrot.gui.login.properties by setting:

    admin=password,traffic-parrot-gui-role,traffic-parrot-gui-edit-role
    readonly=password,traffic-parrot-gui-role

  • HTTP basic authentication popup prompts users to specify a username and password
• Allow loading gRPC existing proto set files in proto-bin with .set.bin extension (e.g. as output by gRPCurl)
• Added a UI page with instructions on how to provide the required JAR files when working with IBM® MQ

Fixes

• Library upgrades to fix OWASP issues
• {{ evaluate 'variable' }} now recognizes a variable that was set using {{#assign 'variable'}}value{{/assign}}
• Fixed an issue with the default permissions of the lib/external folder on Linux
• Fixed an issue with saving very large XML body mappings in the UI

Changes

• Upgraded protoc from 3.21.9 to 3.23.4
• Upgraded gRPC from 1.51.0 to 1.56.1

Aligning company objectives when planning a system simulation project

When planning a system simulation (service virtualization) project, aligning the project with the enterprise strategy is essential. For example, here is what I have been discussing recently with a prospect.

CIO's objective: High uptime.

Director of QA objective: Quality product (feeds into high uptime enterprise objective)

Director of QA key result: Do root cause analysis on all 2023 incidents resulting in lowering downtime of the product (allows a targeted approach to resolving uptime issues)

Director of QA key result: increase automated test coverage by 30% to be able to prevent root cause issues from happening again

Director of QA key result: Create three system simulators (virtual services) to allow for increased automated test coverage for user journeys X, Y and Z

Result: The Director of QA can communicate to the CIO that selected categories of issues causing uptime downgrade will be mitigated going forward, and the expected uptime is increased by X.

If you want to learn about options your specific situation, please contact us https://trafficparrot.com/contact.html