Defined in Action.Json

  • For each action there is an array of responseObjects. These tell the adapter the various responses that are available for the action.
    • The adapter has a hierarchy for determining which response to use for a request.
  • responseObjects
    • mockFile: This is used by the adapter libraries when running in stub mode (not integrated) to tell the adapter where the mock data that should be returned is located. It should be a file within the entity (generally all mock data files are in the mockdatafiles directory to prevent clutter in the base entity directory).

ACTION.JSON

{
  "name": "getIP",
  "protocol": "REST",
  "method": "GET",
  "entitypath": "{base_path}/{version}/addresses/{pathv1}",
  "schema": "schema.json",
  "timeout": 3000,
  "datatype": "PLAIN",
  "sendEmpty": true,
  "headers": {},
  "responseObjects": [
    {
      "type": "default",
      "key": "",
      "mockFile": "mockdatafiles/getIP-default.json"
    }
  ]
},

Mock Data Files

  • Mock data files should be in a place defined in the action.json.
  • In the above example, a file should exist in: mockdatafiles/getIP-default.json.

Multiple Mock Data Files

The adapter has a hierarchy for determining which response to use for a request.

Mock data hierarchy:

  1. Match data in the body.
  2. Match data in a path variable.
  3. Match data in a query or option.
  4. If there is a body (withBody).
  5. If there is a path variable (withPathv#).
  6. If there is a query (withQuery).
  7. If there is an option (withOption).
  8. Otherwise default.

Note: The old mock data format will still work since #5-8 are effectively the old way.

  • On a call with a body { name: ‘abc123’ } the a.json would be returned.
  • On a call with a path variable – http://system:80/path/ver/addresses/error the b.json would be returned.
  • On a call with a query variable – http://system:80/path/ver/addresses?name=happy the c.json would be returned.

ACTION.JSON

    {
      "name": "getIP",
      "entitypath": "{base_path}/{version}/addresses/{pathv1}?{query}",
	….
      "responseObjects": [
        {
          "type": "name-abc123",
          "key": "",
          "mockFile": "a.json"
        },
        {
          "type": "error",
          "key": "",
          "mockFile": "b.json"
        },
        {
          "type": "name=happy",
          "key": "",
          "mockFile": "c.json"
        }
      ]
    },
  • Can still support different mock data based on the URI structure:
    • path variables (withPathv#)
    • query (withQuery)
  • On a call with a path variable – http://system:80/path/ver/addresses/abc123 the y.json is returned
  • On a call with a query variable – http://system:80/path/ver/addresses?name=abc123 the z.json is returned.
  • Otherwise the x.json is returned.

ACTION.JSON

    {
      "name": "getIP",
      "entitypath": "{base_path}/{version}/addresses/{pathv1}?{query}",
	….
      "responseObjects": [
        {
          "type": "default",
          "key": "",
          "mockFile": "x.json"
        },
        {
          "type": "withPathv1",
          "key": "",
          "mockFile": "y.json"
        },
        {
          "type": "withQuery",
          "key": "",
          "mockFile": "z.json"
        }
      ]
    },

Capture Mock Data from Postman

This image illustrates the response body when mock data is captured using Postman.

Capture Mock Data from Test

  • When the isSaveMockData flag is set to true (default is false) and the stub flag is set to false (default is true) in the adapterTestIntegration.js file, and you run a true integration test, it will make all API calls to the other system and save the responses into mock data files. It will also edit the appropriate action.json file so that the next time a call is made in standalone mode, it will return the new mock data.
  • The saveMockData method is already in the individual calls built by the Adapter Builder. This method does not do anything unless the two flags are set properly.

ADAPTERTESTINTEGRATION.JS

const isSaveMockData = true;
const stub = false;
...

describe ('#createDeployment-errors', () => {
  it('should work if integrated or standalone with mockdata', (done) => {
    try {
      a.createDeployment(apisApiId, apisCreateDeploymentBodyParam, null, 
(data, error) => {
        try {
          runCommonAsserts(data, error);
          if (stub) {
            assert.equal('string', data.response.CreatedDate);
            assert.equal('string', data.response.DeploymentId);
            ...
          } else {
            assert.equal('string', data.response.CreatedDate);
          }
          saveMockData('Apis', 'createDeployment', 'default', data);
          done();
        } catch (err) {
          log.error(`Test Failure: ${err}`);
          done(err);
        }
      });
    } catch (error) {
      log.error(`Adapter Exception: ${error}`);
      done(error);
    }
  }).timeout(attemptTimeout);
});
  • There is another property that is also in the request section – return_raw. This property makes the raw response from the other system available in the result that was returned. The saveMockData method will use this data if it is available since it has not been translated. In contrast, if you are using translation, saveMockData will save the translated response, and you will then need to edit the data and revert the translation.

ADAPTERTESTINTEGRATION.JS

return_raw: true,
...

describe ('#createDeployment-errors', () => {
  it('should work if integrated or standalone with mockdata', (done) => {
    try {
      a.createDeployment(apisApiId, apisCreateDeploymentBodyParam, null, 
(data, error) => {
        try {
          runCommonAsserts(data, error);
          if (stub) {
            assert.equal('string', data.response.CreatedDate);
            assert.equal('string', data.response.DeploymentId);
            ...
          } else {
            assert.equal('string', data.response.CreatedDate);
          }
          saveMockData('Apis', 'createDeployment', 'default', data);
          done();
        } catch (err) {
          log.error(`Test Failure: ${err}`);
          done(err);
        }
      });
    } catch (error) {
      log.error(`Adapter Exception: ${error}`);
      done(error);
    }
  }).timeout(attemptTimeout);
});

Capture Mock Data from Adapter Log

You need to have the adapter in debug mode in order to capture these logs. Then you can use these logs for mock data for future testing by storing the response part of the log into the mock data file for the specific call.

CALL RETURN – This is the full response prior to any JSON parsing.


ADAPTER LOGS

debug: Test-eai-connectorRest-makeRequest: CALL RETURN:  
{"status":"success","code":201,"response":"{\n\"type\" : 
\"oci/card\",\n\"id\" : 308,\n\"href\" : 
\"oci/card/308\",\n\"transientAttributes\"  : { },\n\"key\" :
{\n\"type\" : \"oci/cardKey\",\n\"keyValue\"  : 308\n}\n}","redirects":0,"tripTime":"197ms"}

CALL RESPONSE –This is the response or a partial response after JSON parsing.


ADAPTER LOGS

debug: Test-eai-restHandler-handleRestRequest: RESPONSE: 
{"type":"oci/card","id":308,"href":"oci/card/308","transientAttributes"
:{},"key" :{"type":"oci/cardKey","keyValue":308}}