Using the UI5 Mockserver for Client-Specific Data and Testing

Using the UI5 Mockserver for Client-Specific Data and Testing
Estimated read time 10 min read

The Mockserver: An Underrated Tool in UI5 Development

The mockserver is undoubtedly an underutilized tool in UI5 development. While it is often associated with the Fiori Tools team’s UI5 middleware for the Fiori elements Mock server, its potential extends far beyond that. Don’t let the name mislead you—it can be used in various scenarios, including freestyle applications.

Many developers are familiar with the mockserver because it is included in all templates when generating a UI5 app using Fiori Tools. A configuration file called ui5-mock.yaml is preconfigured for this purpose. In the customMiddleware section of the YAML, sap-fe-mockserver is added to simulate the service. However, by default, the parameter generateMockData: true is enabled. This generates data based on metadata (e.g., date fields contain dates, integers are numbers). While helpful, this approach may not always align with the specific needs of your application.
For this reason, I want to demonstrate how to integrate and configure the mockserver to use your own data.

Setup

The best starting point is the package’s README. You’ll also find more examples in the GitHub repository that you can follow.

In summary:

Add the dependency (@sap-ux/ui5-middleware-fe-mockserver).Create a mockserver YAML configuration file.Ensure the metadata.xml file exists as described in the README.

Here’s an example of what the YAML configuration might look like:

services:
– urlPath: /orders
metadataPath: ./webapp/localService/metadata.xml
mockdataPath: ./webapp/localService/data
generateMockData: true
annotations: []

To use your own data, a new feature released today makes the setup even easier. The feature, ‘Support autoloading mockdata file for specific tenants’, has been added. A simplified setup is demonstrated in the new sample app ‘tenants’.

Steps to Configure Your Own Data

Set generateData: false in your YAML configuration.Create a data folder if it doesn’t already exist. This folder should match the path defined in the YAML file.Add your test data to this folder. Create a separate JSON file for each entity, named exactly as the entity in the metadata.xml.

For example, if your metadata contains an entity called RootEntity (link), create a JSON file named RootEntity.json (link). This is sufficient to enable the mockserver to load the data automatically.

You can repeat this process for other entities by adding additional JSON files to the same folder.

Offline Use, Testing, and Context-Based Isolation

The mockserver is invaluable when working offline, if the backend system is unavailable, or during the early stages of development. It is especially useful for testing, as it provides consistent data for test cases. However, for multiple tests, you’ll likely need different datasets. The mockserver can handle this too.

You can create additional JSON files using the naming scheme <EntityName>-<client>.json. For example, instead of using classic client numbers (e.g., 100, 200), you can use custom names like testcase1. In this case, the file would be named RootEntity-testcase1.json (link).

Open the App as a Client

With this setup, you can now easily open the app in the context of a specific client or test case, ensuring a tailored experience for each scenario.

Example Configuration for Client-Based Data Handling

There is a helpful example available in the official repository: link. You can easily modify the script in the package.json file to include the sap-client parameter in the URL. Here’s how you can do it:

‘scripts’: {
‘start’: ‘ui5 serve –open “index.html#tenants-tile”‘,
‘start:100’: ‘ui5 serve –open “index.html?sap-client=100#tenants-tile”‘,
‘start:200’: ‘ui5 serve –open “index.html?sap-client=200#tenants-tile”‘
}

With this setup, you can quickly switch between client-specific datasets by appending the appropriate sap-client parameter to the URL.

Using Fallback Mechanisms for Client Data

You don’t need to create separate JSON files for every client unless necessary. For instance:

If you have a general file RootEntity.json and two specific files Products.json and Products-100.json,When you open the browser with sap-client=100, the mockserver will load Products-100.json.If no file like RootEntity-100.json exists, it will fall back to the general RootEntity.json.

This mechanism ensures that you can maintain a combination of general and client-specific data files efficiently.

 

Offline Development Made Easy

By leveraging the sap-client parameter and fallback functionality, you can seamlessly work offline. The mockserver provides flexibility to load specific data per client while maintaining a consistent experience for testing and development.

wdi5 with Tenants Data

As already mentioned, the use of a mockserver makes sense not only when working offline but also for tests, especially E2E tests when you need an OData server. A mockserver is ideal for this because it always has the same state every time it is started and can therefore be used in pipelines for automated tests. If you build different datasets with different clients or tenants, you can also set up tests for various scenarios.

Here is an example scenario:

You have the following test files for wdi5: DefaultRoot.test.js, DefaultDialog.test.js, Customer1Root.test.js, Customer1Dialog.test.js, Customer2Dialog.test.js.

The test data files are then named, for example, Products.json, Products-customer1.json, and Products-customer2.json.

This means that we have tests for the default data, tests for customer1 with dialog and root, and tests for customer2 only for the dialog.

The wdi5 tests can then be started with the following scripts in the package.json:

‘wdi5:customer1’: ‘wdio run ./webapp/test/e2e/wdio.conf.js — –urlParameter sap-client=customer1 –spec Customer1’,
‘wdi5:customer2’: ‘wdio run ./webapp/test/e2e/wdio.conf.js — –urlParameter sap-client=customer2 –spec Customer2’,
‘wdi5:default’: ‘wdio run ./webapp/test/e2e/wdio.conf.js –spec Default’,

This way, you can set up tests for different scenarios and create special tests for them.

 

​ The Mockserver: An Underrated Tool in UI5 DevelopmentThe mockserver is undoubtedly an underutilized tool in UI5 development. While it is often associated with the Fiori Tools team’s UI5 middleware for the Fiori elements Mock server, its potential extends far beyond that. Don’t let the name mislead you—it can be used in various scenarios, including freestyle applications.Many developers are familiar with the mockserver because it is included in all templates when generating a UI5 app using Fiori Tools. A configuration file called ui5-mock.yaml is preconfigured for this purpose. In the customMiddleware section of the YAML, sap-fe-mockserver is added to simulate the service. However, by default, the parameter generateMockData: true is enabled. This generates data based on metadata (e.g., date fields contain dates, integers are numbers). While helpful, this approach may not always align with the specific needs of your application.For this reason, I want to demonstrate how to integrate and configure the mockserver to use your own data.SetupThe best starting point is the package’s README. You’ll also find more examples in the GitHub repository that you can follow.In summary:Add the dependency (@sap-ux/ui5-middleware-fe-mockserver).Create a mockserver YAML configuration file.Ensure the metadata.xml file exists as described in the README.Here’s an example of what the YAML configuration might look like:services:
– urlPath: /orders
metadataPath: ./webapp/localService/metadata.xml
mockdataPath: ./webapp/localService/data
generateMockData: true
annotations: []
To use your own data, a new feature released today makes the setup even easier. The feature, ‘Support autoloading mockdata file for specific tenants’, has been added. A simplified setup is demonstrated in the new sample app ‘tenants’.Steps to Configure Your Own DataSet generateData: false in your YAML configuration.Create a data folder if it doesn’t already exist. This folder should match the path defined in the YAML file.Add your test data to this folder. Create a separate JSON file for each entity, named exactly as the entity in the metadata.xml.For example, if your metadata contains an entity called RootEntity (link), create a JSON file named RootEntity.json (link). This is sufficient to enable the mockserver to load the data automatically.You can repeat this process for other entities by adding additional JSON files to the same folder.Offline Use, Testing, and Context-Based IsolationThe mockserver is invaluable when working offline, if the backend system is unavailable, or during the early stages of development. It is especially useful for testing, as it provides consistent data for test cases. However, for multiple tests, you’ll likely need different datasets. The mockserver can handle this too.You can create additional JSON files using the naming scheme <EntityName>-<client>.json. For example, instead of using classic client numbers (e.g., 100, 200), you can use custom names like testcase1. In this case, the file would be named RootEntity-testcase1.json (link).Open the App as a ClientWith this setup, you can now easily open the app in the context of a specific client or test case, ensuring a tailored experience for each scenario.Example Configuration for Client-Based Data HandlingThere is a helpful example available in the official repository: link. You can easily modify the script in the package.json file to include the sap-client parameter in the URL. Here’s how you can do it:’scripts’: {
‘start’: ‘ui5 serve –open “index.html#tenants-tile”‘,
‘start:100’: ‘ui5 serve –open “index.html?sap-client=100#tenants-tile”‘,
‘start:200’: ‘ui5 serve –open “index.html?sap-client=200#tenants-tile”‘
}
With this setup, you can quickly switch between client-specific datasets by appending the appropriate sap-client parameter to the URL.Using Fallback Mechanisms for Client DataYou don’t need to create separate JSON files for every client unless necessary. For instance:If you have a general file RootEntity.json and two specific files Products.json and Products-100.json,When you open the browser with sap-client=100, the mockserver will load Products-100.json.If no file like RootEntity-100.json exists, it will fall back to the general RootEntity.json.This mechanism ensures that you can maintain a combination of general and client-specific data files efficiently. Offline Development Made EasyBy leveraging the sap-client parameter and fallback functionality, you can seamlessly work offline. The mockserver provides flexibility to load specific data per client while maintaining a consistent experience for testing and development.wdi5 with Tenants DataAs already mentioned, the use of a mockserver makes sense not only when working offline but also for tests, especially E2E tests when you need an OData server. A mockserver is ideal for this because it always has the same state every time it is started and can therefore be used in pipelines for automated tests. If you build different datasets with different clients or tenants, you can also set up tests for various scenarios.Here is an example scenario:You have the following test files for wdi5: DefaultRoot.test.js, DefaultDialog.test.js, Customer1Root.test.js, Customer1Dialog.test.js, Customer2Dialog.test.js.The test data files are then named, for example, Products.json, Products-customer1.json, and Products-customer2.json.This means that we have tests for the default data, tests for customer1 with dialog and root, and tests for customer2 only for the dialog.The wdi5 tests can then be started with the following scripts in the package.json:’wdi5:customer1′: ‘wdio run ./webapp/test/e2e/wdio.conf.js — –urlParameter sap-client=customer1 –spec Customer1’,
‘wdi5:customer2’: ‘wdio run ./webapp/test/e2e/wdio.conf.js — –urlParameter sap-client=customer2 –spec Customer2’,
‘wdi5:default’: ‘wdio run ./webapp/test/e2e/wdio.conf.js –spec Default’,This way, you can set up tests for different scenarios and create special tests for them.   Read More Technology Blogs by Members articles 

#SAP

#SAPTechnologyblog

Avatar for

You May Also Like

More From Author