---
category: [Platform and Product Extensions/Workday Extend, Platform and Product Extensions, Administration & Integrations, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions/Integration]
keyword: [Extend, Presentation Components, UI components]
nav: wcp_docs
parent_url: /wcp_docs/
title: Mock Data
layout: subsection
---

## Mock Data with App Preview

Using mock data with App Preview, you can test inbound and outbound data on a page without connecting to a tenant. If you don't want to connect to a tenant while testing, you can configure mock data responses in the <b>Testing</b> section of App Builder and map them to each endpoint in the PMD.

Mock data enables you to:

-   Quickly test logic and verify dynamic scenarios using realistic sample JSON responses without having to change the source code.
-   Protect against changing data in your tenant or in external systems.


Mock data is required for endpoints that have an `authType` of OAuth2 because tenant connection doesn't support that `authType`.

These types of endpoints support mock data responses:

-   PMD inbound endpoints.
-   PMD `outboundDataUri` endpoints.
-   Pod endpoints.


<b>Note:</b> `outboundVariable`, `image`, and `imageCard` tags don't support mock data responses.

## <a id="section_yk3_nzk_rvb"></a>Configuring Mock Data

To configure mock data, you need these components:

-   Mock data response - Contains a `MockResponse` object that simulates a JSON response.
-   Mock data configuration - Contains mappings of endpoints to mock responses. For each endpoint in your app, App Preview returns the mock response for that endpoint instead of executing the endpoint.


Refer to this diagram for how mock data configuration files map endpoints in PMDs to mock data response files.

![](GUID-91d3370b-8ee6-489a-80e4-353e1a59fef5-enHYPHENus.png)

An app can have multiple mock data configuration files. You could have a single configuration file that includes all your mappings, but the file will likely be difficult to keep organized. We recommend creating a separate configuration file for either each page or each functional area. Examples:

-   `pmdA.mock_config` is a configuration file that contains all the mappings for endpoints in `pmdA.pmd`.
-   `workers.mock_config` is a configuration file that contains the mappings for all endpoints related to workers.


## <a id="section_zt3_ptr_rvb"></a>Example Mock Data and PMD

Example PMD:

```
{
"id" : "home",
"endPoints" : [ {
   "baseUrlType": "workday-staffing",
   "name": "supervisoryOrganizations",
   "authType": "sso",
   "url": "/supervisoryOrganizations"
 }
],
"presentation" : {
 "body" : {
   "type" : "section",
   "horizontal" : false,
   "children" : [{
       "type": "instanceList",
       "id": "supOrgsList",
       "label": "Supervisory Organizations",
       "values": "<% supervisoryOrganizations.data %>"
     }
   ]
 }
}
}
```

Example mock data configuration:

```
{
"mappings": [
 {
   "location": {
     "pmdId": "home",
     "endPointName": "supervisoryOrganizations"
   },
   "mockId": "supOrgsMock"
 }
]
}
```

This mock data configuration maps the `supOrgsMock` mock data response to the `supervisoryOrganizations` endpoint in `home.pmd`.

Example mock data response:

```
{
"id": "supOrgsMock",
"responseCode": 200,
"responseBody": {
 "data": [
   {
     "descriptor": "Human Resources",
     "id": "e02485f863ec48d39a082bb95cc4abe4"
   },
   {
     "descriptor": "Finance & Administration",
     "id": "1ad7d37487904a989b2db1bfa6fed57d"
   },
   ...
 ]
}
}
```

When you open App Preview for `home.pmd`, the data from the mock data response displays instead of the actual endpoint response.

Example `dataProviders` in the AMD:

```
"dataProviders" : [
{
 "key" : "workday-staffing",
 "value" : "https://api.workday.com/staffing/v4"
}
]
```

## <a id="section_sqw_j5r_rvb"></a>Endpoint Matching

For each endpoint in your app, App Preview searches the mock data configuration files for the most specific match.

<b>Example:</b>

Mapping 1:

```
{
"mappings": [
 {
   "location": {
     "endPointName": "myEP"
   },
   "mockId": "mockA"
 }
]
}
```

Mapping 2:

```
{
"mappings": [
 {
   "location": {
     "pmdId": "myPmd",
     "endPointName": "myEP"
   },
   "mockId": "mockB"
 }
]
}
```

Matching behavior:

<table><thead><tr><th>PMD ID and Endpoint Name</th><th>Matching Behavior</th></tr></thead><tbody><tr><td>PMD ID: <code>pmdX</code> <p>Endpoint name: <code>myEP</code></p></td><td>Matches the location in mapping 1 and returns <code>mockA</code>. <p>Doesn't match the location in mapping 2 because the <code>pmdId</code> doesn't match.</p></td></tr><tr><td>PMD ID: <code>myPMD</code> <p>Endpoint name: <code>myEP</code></p></td><td>Matches both mapping 1 and mapping 2, but returns <code>mockB</code> because the location in mapping 2 is more specific.</td></tr></tbody></table><br/>

## <a id="section_1"></a>Configuring Untenanted App Attributes

App attributes enable you to configure app-level, tenant-specific variables that your pages can access during runtime. If you've configured the attribute values in the tenant (using App Manager) and you've deployed your app to the tenant, App Preview shows the tenant attribute values. However, if you haven't configured the attributes on the tenant, App Preview displays blank values.

If you want to test untenanted app attributes in App Preview or you want to see them in App Preview without connecting to the tenant, you can configure the attributes in a mock data configuration. To configure untenanted attribute values:

1.  In the App Components panel in App Builder, open <b>Testing</b> &gt; <b>Mock Data Configuration</b>.
2.  If your app doesn't have a mock configuration yet, add one. If you already have mock configurations, select one where you'd like to configure the app attributes.

    <b>Note:</b> We recommend creating a separate mock configuration for either each page or each functional area. You can decide whether you want to configure your app attributes with the mappings by page or by functional area. Alternatively, you can have a mock configuration that contains all app attributes.

3.  At the root level of a mock data configuration, add the `attributes` map containing the attribute name/value pairs.

    A sample mock configuration with the attributes for the <i>viewWorkersPage</i>:

    ```
    {
    "mappings": [
    {
       "location": {
         "pmdId": "viewWorkersPage",
         "endPointName": "workers"
       },  
       "mockId": "mockA"
    }],
    "attributes" : {
       "supervisoryOrg" : "Test Org",
       "orgCount" : 123
    }  
    }
    ```

    Here's another sample mock data configuration containing only app attributes:

    ```
    {
    "attributes" : {
       "currentOrg" : "Test Org",
       "currentOrgCount" : 123,
       "orgTest" : true
    }  
    }
    ```

    <b>Notes:</b>

    -   All attribute names must be unique across all mock data configurations.
    -   You can add attributes in the mock data configuration even if you haven’t defined them yet in the Attributes section of the app. However, when you deploy the app to the tenant or connect App Preview to the tenant, ensure that the app attributes you reference in the PMD have been created. See [Create Extend App Attributes](/wcp_docs/ddn1633979003074.html).

4.  In a PMD, reference an app attribute using the `attrstore` predefined variable.

    Example:

    ```
    {
    "type": "text",
    "label": "Current Org:",
    "value": "<% attrstore.currentOrg %>"
    }
    ```



### Related Information

[Reference: Mock Data Configuration](/wcp_docs/pqp1669673626830.html)

[Reference: Mock Data Responses](/wcp_docs/rtn1669749530217.html)