Work with mock data

Mock data is the response an adapter returns when running in stub mode. Instead of making a live call to the external system, the adapter runs through its full processing pipeline and returns the stored mock data at the point where the real call would occur. This allows you to test the complete data flow through the adapter — including schema translation — without integrating with a live system.

Stub mode is also useful for buildingItential Platform workflows when the external system is not yet available.

Mock data file format

Mock data is the raw response body from the external system. It should match the responseDatatype defined in action.json — typically JSON.

Simple format — the file contains only the response body:

1
{
2
  "data": {
3
    "authentication": {
4
      "authentication-method": [
5
        {
6
          "priority": 1,
7
          "scope": "remote",
8
          "statistics": {
9
            "called": 2,
10
            "failure": 3,
11
            "skipped": 10,
12
            "success": 10
13
          },
14
          "type": "tacacs"
15
        }
16
      ]
17
    }
18
  }
19
}

Status/response format — an older format that wraps the response body in a response object and adds a status field. Use this format when you need to simulate specific HTTP status codes, such as error responses, since mock data files do not contain real HTTP headers.

1
{
2
  "status": 200,
3
  "response": {
4
    "allowDelete": true,
5
    "alternateName": "string",
6
    "dateAdded": 0,
7
    "description": "TESTING",
8
    "id": 1245,
9
    "ipAddress": "10.10.10.1",
10
    "name": "Michael1"
11
  }
12
}

Define mock data files in action.json

Each action in action.json has a responseObjects array that tells the adapter which mock data file to return when running in stub mode. The mockFile path is relative to the entity directory — keep mock data files in a mockdatafiles/ subdirectory to avoid cluttering the entity root.

1
{
2
  "name": "getIP",
3
  "protocol": "REST",
4
  "method": "GET",
5
  "entitypath": "{base_path}/{version}/addresses/{pathv1}",
6
  "schema": "schema.json",
7
  "timeout": 3000,
8
  "datatype": "PLAIN",
9
  "sendEmpty": true,
10
  "headers": {},
11
  "responseObjects": [
12
    {
13
      "type": "default",
14
      "key": "",
15
      "mockFile": "mockdatafiles/getIP-default.json"
16
    }
17
  ]
18
}

Use multiple mock data files per action

An action can define multiple entries in responseObjects, each pointing to a different mock file. The adapter selects which file to return based on the incoming request, using the following hierarchy:

1. Match data in the request body
2. Match data in a path variable
3. Match data in a query or option parameter
4. Request has a body (withBody)
5. Request has a path variable (withPathv#)
6. Request has a query parameter (withQuery)
7. Request has an option parameter (withOption)
8. Default

Example: match-based selection. The type field in each responseObject entry specifies the match value. In this example, a request with { name: 'abc123' } in the body returns a.json, a request with path variable error returns b.json, and a request with query name=happy returns c.json:

1
{
2
  "name": "getIP",
3
  "entitypath": "{base_path}/{version}/addresses/{pathv1}?{query}",
4
  "responseObjects": [
5
    { "type": "name-abc123", "key": "", "mockFile": "a.json" },
6
    { "type": "error",       "key": "", "mockFile": "b.json" },
7
    { "type": "name=happy",  "key": "", "mockFile": "c.json" }
8
  ]
9
}

Example: structural selection. Use withPathv#, withQuery, or default as the type to select based on whether the request includes a path variable, a query parameter, or neither:

1
{
2
  "name": "getIP",
3
  "entitypath": "{base_path}/{version}/addresses/{pathv1}?{query}",
4
  "responseObjects": [
5
    { "type": "default",    "key": "", "mockFile": "x.json" },
6
    { "type": "withPathv1", "key": "", "mockFile": "y.json" },
7
    { "type": "withQuery",  "key": "", "mockFile": "z.json" }
8
  ]
9
}

Capture mock data

From Postman

Run the API call in Postman, then copy the response body from the response panel and save it as a JSON file in the mockdatafiles/ directory of the appropriate entity. Reference the file in the corresponding action.json responseObjects entry.

From integration tests

Set isSaveMockData to true and stub to false in adapterTestIntegration.js, then run the integration tests. The adapter makes live calls to the external system, saves each response as a mock data file, and updates the corresponding action.json entries automatically.

1
const isSaveMockData = true;
2
const stub = false;
3
4
// ...
5
6
describe('#createDeployment', () => {
7
  it('should work if integrated or standalone with mockdata', (done) => {
8
    try {
9
      a.createDeployment(apisApiId, apisCreateDeploymentBodyParam, null, (data, error) => {
10
        try {
11
          runCommonAsserts(data, error);
12
          if (stub) {
13
            assert.equal('string', data.response.CreatedDate);
14
            assert.equal('string', data.response.DeploymentId);
15
          } else {
16
            assert.equal('string', data.response.CreatedDate);
17
          }
18
          saveMockData('Apis', 'createDeployment', 'default', data);
19
          done();
20
        } catch (err) {
21
          log.error(`Test Failure: ${err}`);
22
          done(err);
23
        }
24
      });
25
    } catch (error) {
26
      log.error(`Adapter Exception: ${error}`);
27
      done(error);
28
    }
29
  }).timeout(attemptTimeout);
30
});

By default, saveMockData saves the translated response. If you want to save the raw, pre-translation response instead, set return_raw: true in the request properties. When return_raw is enabled, saveMockData uses the raw response data, so you do not need to manually revert the translation.

From adapter logs

Enable debug-level logging on the adapter, then run the call. Two log entries contain the response data:

CALL RETURN — the full response body before JSON parsing. Use this for mock data when you want the raw response.

debug: Test-eai-connectorRest-makeRequest: CALL RETURN:
{"status":"success","code":201,"response":"{\n\"type\":\"oci/card\",\n\"id\":308,...}"}

CALL RESPONSE — the response after JSON parsing. Use this when you want the parsed object.

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

Copy the relevant value and save it as a JSON file in the mockdatafiles/ directory of the appropriate entity.