Recording SOAP/XML Traffic

MockMotor cannot be smart enough to recognize what parameters in the inbound payload are the account keys. Because of this, the automatic creation of mocks for SOAP/XML services generates crude mock services, typically requiring some manual updates later.

Forward and Record Response

To record a SOAP or XML traffic:

1 Create a mock service that will simulate the real backend later
2 Create a forwarding response in that service
3 Point your application to that mock service and generate a traffic

The forwarding mock response will create a new mock response for each SOAP Action or top payload element name it sees.

Forwarding Response

A forwarding response:

  • Matches any HTTP method
  • Has no match by operation
  • Has no matching script
  • Contains the base URL of the real backend service in the Forward URL field
  • Has Record & Activate on
  • When recording is set to Record and Activate, the new mock is placed above the forwarding mock and begins handling the matching traffic immediately.

    When recording is set to Just Record, the newly created mock is placed below the forwarding mock. No traffic is reaching it. When the flow is completed, you need to move the recorded mock to its proper place in the list manually.

    Recording by Operation

    By default, MockMotor records SOAP (and XML) requests based on their SOAPAction/top element name.

    That creates mock services where there is a single mock for each WSDL operation.

    Two requests are considered matching if they have the same SOAPAction or top element name.

    For example, if MockMotor receives a SOAP request with SOAPAction: getAccount, it creates a mock response that has a single match condition: SOAPAction=getAccount. Any request with such SOAPAction is handled by this new mock, even if the request body contains a different account number or other conditions.

    If SOAPAction is missing or empty, MockMotor uses the top element name - the first element that is not soap:Envelope, soap:Header or soap:Body - as the key to match. If MockMotor receives a XML request with <GETACCOUNT> top element, it creates a mock response that has a single match condition: Top Element Name=GETACCOUNT. Any request with the same top element is handled by this new mock, even if the request payload is different.

    Recording with Keys

    There is a way to hint MockMotor where the keys are in the payload. Then MockMotor creates one mock per unique key, which can help if you have multiple different responses based on say account number.

    You can specify the recording keys’ paths - i.e. the locations in the request that contain special values that identify a test account - in the Record section. For each inbound request, MockMotor will evaluate the provided expressions and add them to the recorded mock’s match script along with their evaluated value.

    For instance, if the account number is sent in the request under AccNo:


    we can add its path $input//*:AccNo to the Record section, and MockMotor extracts its value (B9404591E) and adds it to the match script as $input//*:AccNo='B9404591E'.

    When the same operation is called with a different account number (say A0000210T), another mock is created with the match script as $input//*:AccNo='A0000210T'.

    The values extracted from the request - the account number - is added to the match script to ensure each new mock handles the right account.

    This mock generation can easily create hundreds of mock responses - one per each test account.

    Performance Considerations

    Having one mock per input may not provide the required response time for load testing.

    MockMotor has to check each mock in a row to find a match. When you have hundreds of mocks, the time to find a matching mock can be bigger that the delay configured in that mock. It can be a showstopper for a load testing run.

    For LT-targeted recordings, you should consider Recording Mock Accounts.