Expand

title	MENU

Table of Contents

style	none

1. Purpose

This tool ensures reliable and efficient testing for conformance to the Ozone Connect implementation within the API Hub. It simplifies testing, enforces standards, and enhances quality and interoperability.

This guide provides step-by-step instructions to set up and use the test automation framework, including initializing configurations, running tests, and validating setups. It supports testing on OzoneAPI's mock server or custom servers with ease.

2. Scope

This manual covers the essential aspects of the Testing Tool, including its installation, usage, and testing capabilities. It provides detailed instructions and guidelines to help users effectively utilise the tool within their development and testing environments. The scope includes:

Installation and setup	Provides instructions for installing and setting up the Testing Tool using Docker, including prerequisites and initial configuration. This tool has been successfully tested on Ubuntu Linux and on MacOS.
Usage instructions	Details the commands and options available in the Testing Tool CLI tool, with examples for effective usage.
Testing	Explains the testing procedures and conformance checks, including how to run tests and interpret the results.3. Audience

3. Audience

The primary audience for this manual includes developers, QA engineers, and technical implementers who are involved in the integration and testing of the Ozone Connect implementation for the API Hub.

This manual assumes that the audience has a basic understanding of CLI tools, Docker, CBUAE Open Finance Standards and Ozone Connect specifications.

4. Overview

The Testing Tool is a command-line interface (CLI) based testing tool designed to assist implementers in verifying their conformance to the Ozone Connect implementation. Developed specifically for the API Hub, the Testing Tool provides a comprehensive suite of tests that validate various aspects of the implementation against the predefined standard. The tool runs within a Docker container, ensuring a consistent and isolated testing environment. By using the Testing Tool, implementers can efficiently identify and rectify issues, ensuring that their implementations meet the required conformance criteria.

5. Setup Requirements

Before You Start:

Familiarise yourself with the Ozone Connect specifications.
Ensure you have https://www.docker.com/ installed locally on your machine to run Docker containers.

6. Usage

The instructions below are based on using the Testing Tool to test against the latest Ozone Connect Specification.

6.1 Running the Testing Tool

To test the LFI’s implementation of Ozone Connect, execute the following commands. These commands allow you to add a custom configuration file and SSL certificates to connect the tool to the LFI’s server.

The basic command for this testing tool is shown below. Running it without any options will display a list of available options.

6.1.1 Constructing the command for the test tool

6.1.1.1 Base Command:

Code Block
docker run --user root --rm -it \ -v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \ -v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \ public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.610.1

6.1.1.2 Help Command

To view the available Options, run:

Code Block

docker run --user root --rm -it \
-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \
-v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \
public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.610.1 help

6.1.1.3 Available Options:

init-config: Initialize the configuration folder if not already present.
setup-config: Run the interactive configuration setup.
validate-config: Validate the configuration file.
yarn : Run the framework with Yarn and specified arguments.
help: Show the help message.

The Base Command and the Help Command display the same output.

6.1.2 Initializing Configuration

To get started, the framework provides a default configuration setup.
Start by initializing the configuration on your host machine using the init-config command.

Code Block

docker run --user root --rm -it \
-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \
-v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \
public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.610.1 init-config
config

Output if the config artefacts are not present :

Code Block
Initializing Configuration... Configuration file missing. Copying default config file... Certificates folder missing. Copying default certs folder...

Output if the config artefacts are already present from the previous version of the testing tool :

Code Block
Initializing Configuration... Configuration file exists. Skipping file copy. Certificates folder exists. Skipping folder copy.

This command copies the required configuration files and certificates to the config folder inside the container, which is mapped to a newly created config folder in the host's current working directory (pwd). Additionally, a logs folder is created in the host's current working directory to store JSON logs and HTML reports generated after the tests.

6.1.2.1 Upgrading from a previous version of this testing tool

6.1.2.1.1 Using JWT Authorization

Release 2025.3.1 introduces JWT authorization support for Ozone-connect APIs, requiring configuration changes in certs section in the config.yaml.

Previous certs section

Code Block
certs: transport: ca: certificate.pem certFileName: cert_fullpath.pem keyFileName: key_fullpath.key

The updated configuration introduces JWT authorization settings and reorganizes existing certificate configurations. Set authorization_type to JWT to enable JWT authorization or none to disable it (Authorization header will not be included in API requests). The signing certificate, private key, and key identifier (kid) are required components in the new certs section. ReferJWT Authorization document to know more about JWT authorization.

Updated certs section

Code Block

authorization_type: JWT
server:
  aud: RTCBUAE
  request_object_signing_alg: PS256
  expiry_in_sec: 30
  certs:
    signing:
      pemFileName: signing_fullpath.pem
      keyFileName: signing_fullpath.key
      kid: kid_value
    transport:
      ca: certificate.pem
      certFileName: cert_fullpath.pem
      keyFileName: key_fullpath.key

Migration Notes

Transport certificate configurations must be moved from certs.transport to server.certs.transport
JWT signing certificate configuration is only required when using JWT authorization. Let it remain as it is if JWT authorization is not being used.

6.1.2.1.2 Using Client Credentials Grant Authorization

Release 2025.6.1 introduces CCG (Client Credential Grant) authorization support for Ozone-connect APIs, requiring configuration changes in the config.yaml.
New section is added in config.yaml file.

Code Block

authorization_type: CCG
ccgDetails:
  authorisationServerTokenUrl: https://mock.rt-cbuae.rt.dev.apihub.openfinance.uk/token
  ccgClientAssertionType: clientCredentials
  clientId: 6ag503edb-d2332-5dfdf-99aa-345325f34234
  clientSecret: JHbv24jhb2jjI3G45U3I2GlNbfew3weFSSAfdsfdsg

authorization_type should be CCG if 'Client Credential Grant' needs to be use.

The ccgClientAssertionType value can be among private_key_jwt or clientCredentials .

While using private_key_jwt the details of JWT as mentioned in the above server section can be utilized.

6.1.2.2 Adding Multiple Users

Since the version 2025.6.1 we also provide the facility to have multiple users to hit the APIs.

In the users section in the config.yaml file, add the details of a user. Then use the name of the user in the dynamic fields accountTypes or paymentTypes. The details of the user information can be found in the chart https://openfinanceuae.atlassian.net/wiki/spaces/APIHubDocsv6/pages/244253962/Testing+Tool+User+Guide#7.1.2-Configuration-Fields

6.1

.2.3 Running a Sample TestAfter initializing the default configuration, you can run the following command. It will execute tests against the same OzoneAPI mock server as described in section 6.1, but now explicitly uses the default configuration as input.
Line number 2 below

.3 Updating Configuration

6.1.3.1 Editing `config.yaml`

To run tests on your own server, update the config.yaml file located in the newly created config folder on the host machine. Open the file and edit the necessary fields.

6.1.3.2 Using the Interactive Setup Tool

Alternatively, you can update the configuration using the interactive setup tool:
The setup tool will back up config.yaml as backup-config.yaml in the same folder.

Code Block

docker run --user root --rm -it \
-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \
-v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \
public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.610.1 \
yarn tr-ozone-connect \
--formatter terse \
--loglevel-runner info \
--config ./config/config.yaml \
--outsetup-config

Output :

Code Block

Starting Config Manager: Setup Configuration...
Welcome to the Config Manager!
Note: Pressing enter will keep the current value.
Backup created: /usr/o3/tr-ozone-connect/logs/test_logs.json \
-s 'Id:[GET /accounts]' -r Id:'[AIS_A001]'

6.1.3 Updating Configuration

6.1.3.1 Editing `config.yaml`

To run tests on your own server, update the config.yaml file located in the newly created config folder on the host machine. Open the file and edit the necessary fields.

6.1.3.2 Using the Interactive Setup Tool

Alternatively, you can update the configuration using the interactive setup tool:
The setup tool will back up config.yaml as backup-config.yaml in the same folder

config/backup-config.yaml
Enter the section to update (e.g., baseUrl, certs, accounts.accountTypes, payments.paymentTypes):

Refer to Section 7.1.2 for a comprehensive list of configurable options. After entering the required details, config.yaml file is updated with the new values.

6.1.4 Validating Configuration

To validate the configuration file, use the validate-config command: This command ensures the configuration file is properly formatted and that all required certificate files are present.

Code Block

docker run --user root --rm -it \
-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \
-v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \
public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.610.1 setupvalidate-config

Output :

Code Block

Starting Config Manager: SetupValidate Configuration...
WelcomeValidating to the Config Manager!
Note: Pressing enter will keep the current value.
Backup created: /usr/o3/tr-ozone-connect/config/backup-config.yaml
Enter the section to update (e.g., baseUrl, certs, accounts.accountTypes, payments.paymentTypes):

Refer to Section 7.1.2 for a comprehensive list of configurable options. After entering the required details, config.yaml file is updated with the new values.

6.1.4 Validating Configuration

To validate the configuration file, use the validate-config command: This command ensures the configuration file is properly formatted and that all required certificate files are present

configuration file...
All cert files are present.
Configuration validation passed.

6.1.5 Running the Testing Tool with custom configuration

The command to run the testing tool against the customer server is similar to the command in section 61. above, with the addition of updating the configuration file for the testing tool.
The only difference being the addition of line 3 which is the argument to mount the custom config folder.

Sample command WITH the client configuration being provided.

Code Block

docker run --user root --rm -it \
-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \
-v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \
public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.610.1 validate-config
Starting Config Manager: Validate Configuration...
Validating configuration file...
All cert files are present.
Configuration validation passed.

6.1.5 Running the Testing Tool with custom configuration

The command to run the testing tool against the customer server is similar to the command in section 61. above, with the addition of updating the configuration file for the testing tool.
The only difference being the addition of line 3 which is the argument to mount the custom config folder.

Code Block

#Sample command WITH the client configuration being provided
docker run --user root --rm -it \
-v \
yarn tr-ozone-connect \
--formatter terse \
--loglevel-runner info \
--config ./config/config.yaml \
--out ./test_logs.json \
-s 'Id:[GET /accounts]' -r Id:'[AIS_A001]'

6.1.6 Components of the command

The command provided above docker run --user root --rm -it can has the following 3 parts.

Running the Docker Container: The first part runs the Testing Tool Docker container, mounting the necessary directories and setting up the environment:

Option	Description
`-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config"`

\ -v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \ public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.6.1 \ yarn tr-ozone-connect \ --formatter terse \ --loglevel-runner info \ --config ./config/config.yaml \ --out ./test_logs.json \ -s 'Id:[GET /accounts]' -r Id:'[AIS_A001]'6.1.6 Components of the command

The command provided above docker run --user root --rm -it can has the following 3 parts.

Running the Docker Container: The first part runs the Testing Tool Docker container, mounting the necessary directories and setting up the environment:

Option

Description

-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config"

If the LFI configuration is not provided, the tool will attempt to connect to a the Ozone Connect mock server deployed by Ozone in the cloud. For detailed information on the configuration file format, please refer to the configuration file section: 7.1.2

SSL certificates are necessary for secure mTLS connection between the Testing Tool and LFI’s implementation of Ozone Connect. The method to generate these certificates is documented in the Certificates Generation section: 7.2

After generating the certificates, copy them into a folder named config/certs on the host machine from where the test command will be executed. These copied files are then passed to the Docker container using the configuration options mentioned earlier.

-v "$(pwd)/logs:/

If the LFI configuration is not provided, the tool will attempt to connect to a the Ozone Connect mock server deployed by Ozone in the cloud. For detailed information on the configuration file format, please refer to the configuration file section: 7.1.2

SSL certificates are necessary for secure mTLS connection between the Testing Tool and LFI’s implementation of Ozone Connect. The method to generate these certificates is documented in the Certificates Generation section: 7.2

After generating the certificates, copy them into a folder named config/certs on the host machine from where the test command will be executed. These copied files are then passed to the Docker container using the configuration options mentioned earlier.

-v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs"

This option is mandatory and must be provided to access the logs after the program runs. Both the logs and the HTML output report will be available in this folder once the tests are complete.

Acquiring the latest docker image:

Option	Description
`public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.6.1 \`	This is the location of the publicly available Test Tool Docker image.

Executing the Ozone Testing Tool: This 3rd part executes the Ozone Testing Tool within the container with a set of specified options:
Code Block
yarn tr-ozone-connect \ --formatter terse \ --loglevel-runner info \ --config /usr/o3/tr-ozone-connect/

logs"

This option is mandatory and must be provided to access the logs after the program runs. Both the logs and the HTML output report will be available in this folder once the tests are complete.

Acquiring the latest docker image:

Option

Description

public.ecr.aws/g5c5c6i0/tr-image

config/config.yaml \
--out /usr/o3/tr-ozone-connect

:2025.6.1 \

This is the location of the publicly available Test Tool Docker image.

Executing the Ozone Testing Tool: This 3rd part executes the Ozone Testing Tool within the container with a set of specified options:

Code Block

yarn tr-ozone-connect \
--formatter terse \
--loglevel-runner info \
--config /usr/o3/tr-ozone-connect/config/config.yaml \
--out /usr/o3/tr-ozone-connect/logs/test_logs.json \
-s 'Id:[GET /accounts]' -r Id:'[AIS_A001]'

6.1.7 Options to the tr-ozone-connect command

The available command line options for the yarn tr-ozone-connect command are listed in the table below.

Option

Description

Possible Values

-h, --help

Show help (boolean)

-c, --config

Input test configuration files in .yaml or .json format
(Format : string, required)

config.yaml, config.json, ./config/config.yaml

-f, --folder

Preconfigured path to the folders with the test files
(Format : string, required)

src/tests, tests, ./src/tests

-o, --out

Output file name
(Format : string, optional)
A log file and an HTML output report are generated with the name specified in this option.

results.json, output.json, ./test_output.json

-e, --formatter

Use a standard formatter for the output

/logs/test_logs.json \
-s 'Id:[GET /accounts]' -r Id:'[AIS_A001]'

6.1.7 Options to the tr-ozone-connect command

The available command line options for the yarn tr-ozone-connect command are listed in the table below.

Option	Description	Possible Values
-h, --help	Show help (boolean)
-c, --config	Input test configuration files in .yaml or .json format (Format : string, required)	config.yaml, config.json, ./config/config.yaml
-f, --folder	Preconfigured path to the folders with the test files (Format : string, required)	src/tests, tests, ./src/tests
-o, --out	Output file name (Format : string, optional) A log file and an HTML output report are generated with the name specified in this option.	results.json, output.json, ./test_output.json
-e, --formatter	Use a standard formatter for the output (Format : string, optional)	full, terse, medium, errors
-s, --regex_for_test_suite	Provide the full name of the test suite from the list. comma separated list if multiple SuiteId needs to be tested. (No leading and trailing whitespace) To exclude specific test suite just add '!' before test suite. To run all the suites, use `.*` (Format : comma separated string, optional)	The full list of test suites currently available are : SuiteIds If this flag is absent then all suites will get execute. ‘Id:[GET /accounts/{accountId}/customer]’, ‘Id:[GET /accounts/{accountId}/customer,GET /accounts/{accountId}]’ ‘Id:[!GET /accounts/{accountId}/customer]’ → this will exclude test suite ‘GET /accounts/{accountId}/customer’ and execute remaining others.
-r, --regex_for_test_case	Provide a regular expression for running selected tests. (Format : string, required)	The list of the test case names can be found in the Ozone Connect Test Cases If this flag is absent then all test cases will get execute. Example regex values are mentioned in this document : Regular Expression for Ozone Connect Testing Tool
-v, --loglevel-runner	Log level for the test runner (Format : string, optional)	fulldebug, terse, medium, errors
-s, --regex_for_test_suite	Provide the full name of the test suite from the list. comma separated list if multiple SuiteId needs to be tested. (No leading and trailing whitespace) To exclude specific test suite just add '!' before test suite. To run all the suites, use `.*` (Format : comma separated string, optional)	The full list of test suites currently available are : SuiteIds If this flag is absent then all suites will get execute. ‘Id:[GET /accounts/{accountId}/customer]’, ‘Id:[GET /accounts/{accountId}/customer,GET /accounts/{accountId}]’ ‘Id:[!GET /accounts/{accountId}/customer]’ → this will exclude test suite ‘GET /accounts/{accountId}/customer’ and execute remaining others.
-r, --regex_for_test_case	Provide a regular expression for running selected tests. (Format : string, required)	The list of the test case names can be found in the Ozone Connect Test Cases If this flag is absent then all test cases will get execute. Example regex values are mentioned in this document : Regular Expression for Ozone Connect Testing Tool
-v, --loglevel-runner	Log level for the test runner (Format : string, optional)	debug, info, silent (In the order of precedence)
-l, --loglevel-suite	Log level for the test suite (Format : string, optional)	debug, info, error (In the order of precedence)
--version	Show version number (boolean)

7. Common Config Files Options

In order to run the above docker command against LFI’s implementation of Ozone Connect, the LFI needs to:

Create an input configuration file.
Provide the certificate files if required.

7.1 Configuration File

The configuration file can be created manually or generated using the init-config command. It should be placed in the ./config folder within the same directory where the docker run command will be executed.

7.1.1 Sample config.yaml file

Code BlockbaseUrl: https://mock.rt-cbuae.rt.dev.ozoneapi.co.uk accounts-schema-file: der-cbuae-ozone-connect-data-sharing-openapi.json payments-schema-file: der-cbuae-ozone-connect-service-initiation-openapi.json event-action-schema-file: der-cbuae-ozone-connect-consent-events-actions-openapi.json insurance-schema-file: der-cbuae-ozone-connect-insurance-data-sharing-openapi.json products-schema-file: der-cbuae-ozone-connect-products-data-openapi.json authorization_type: none ccgDetails: authorisationServerTokenUrl: https://as1.altareq1.sandbox.apihub.openfinance.ae/token ccgClientAssertionType: clientCredentials clientId: 2fwefwdsfgsdgsdgsdgsdg clientSecret: dfewfewfwefwefwefewfwefewfewfasfcascascv server: aud: RTCBUAE request_object_signing_alg: PS256 expiry_in_sec: 30 certs: signing: pemFileName: /usr/o3/tr-ozone-connect/config/certs/signing/signing.pem keyFileName: /usr/o3/tr-ozone-connect/config/certs/signing/signing.key kid: suvAuFTM6F4xzZKbudVO1oGGDnY transport: ca: /usr/o3/tr-ozone-connect/config/certs/transport/certificate.pem certFileName: /usr/o3/tr-ozone-connect/config/certs/transport/transport.pem keyFileName: /usr/o3/tr-ozone-connect/config/certs/transport/transport.key aisBasePath: openbanking/v1/ais pisBasePath: openbanking/v1/pis validateBasePath: openbanking/v1 productsBasePath: openbanking/v1/products productsLeadBasePath: openbanking/v1/leads users: invalid-psu-identifier

info, silent (In the order of precedence)
-l, --loglevel-suite	Log level for the test suite (Format : string, optional)	debug, info, error (In the order of precedence)
--version	Show version number (boolean)

7. Common Config Files Options

In order to run the above docker command against LFI’s implementation of Ozone Connect, the LFI needs to:

Create an input configuration file.
Provide the certificate files if required.

7.1 Configuration File

The configuration file can be created manually or generated using the init-config command. It should be placed in the ./config folder within the same directory where the docker run command will be executed.

7.1.1 Sample config.yaml file

Code Block

baseUrl: https://mock.rt-cbuae.rt.dev.ozoneapi.co.uk
accounts-schema-file: der-cbuae-ozone-connect-data-sharing-openapi.json
payments-schema-file: der-cbuae-ozone-connect-service-initiation-openapi.json
event-action-schema-file: der-cbuae-ozone-connect-consent-events-actions-openapi.json
insurance-schema-file: der-cbuae-ozone-connect-insurance-data-sharing-openapi.json
products-schema-file: der-cbuae-ozone-connect-products-data-openapi.json
authorization_type: none
ccgDetails:
  authorisationServerTokenUrl: https://as1.altareq1.sandbox.apihub.openfinance.ae/token
  ccgClientAssertionType: clientCredentials
  clientId: 2fwefwdsfgsdgsdgsdgsdg
  clientSecret: dfewfewfwefwefwefewfwefewfewfasfcascascv
server:
  aud: RTCBUAE
  request_object_signing_alg: PS256
  expiry_in_sec: 30
  certs:
    signing:
      pemFileName: /usr/o3/tr-ozone-connect/config/certs/signing/signing.pem
      keyFileName: /usr/o3/tr-ozone-connect/config/certs/signing/signing.key
      kid: suvAuFTM6F4xzZKbudVO1oGGDnY
    transport:
      ca: /usr/o3/tr-ozone-connect/config/certs/transport/certificate.pem
      certFileName: /usr/o3/tr-ozone-connect/config/certs/transport/transport.pem
      keyFileName: /usr/o3/tr-ozone-connect/config/certs/transport/transport.key
aisBasePath: openbanking/v1/ais
pisBasePath: openbanking/v1/pis
validateBasePath: openbanking/v1
productsBasePath: openbanking/v1/products
productsLeadBasePath: openbanking/v1/leads
users:
  invalid-psu-identifier:
    userId: '1238123081039'
    jwt: ThisISATemporaryPsu==
  saving_user:
    userId: '10000100000000000000002'
    jwt: eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==
  default_user:
    userId: '10000100000000000000002'
    jwt: eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==
  user_not_base64:
    userId: '10000100000000000000003'
    jwt: invalidJWTString
  user_not_json:
    userId: '10000100000000000000004'
    jwt: dGhpcyBpcyBub3QganNvbg==
  user_no_userId:
    userId: '123812308103910000100000000000000005'
    jwt: ThisISATemporaryPsueyJmb28iOiJiYXIifQ==
  savinguserId_usernull:
    userId: '1000010000000000000000210000100000000000000006'
    jwt: eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==eyJ1c2VySWQiOm51bGx9
  defaultuserId_not_userstring:
    userId: '1000010000000000000000210000100000000000000008'
    jwt: eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==eyJ1c2VySWQiOnRydWV9
headers:
  o3-provider-id: RTCBUAE
  o3-aspsp-id: RTCBUAE
  o3-caller-org-id: '000015000000000000000001'
  o3-caller-client-id: 65e64982-f080-4785-a887-816f5274ea7e
  o3-caller-software-statement-id: '000016000000000000000004'
  o3-api-uri: open-finance/product/v1.2/leads
  o3-api-operation: GET
  o3-consent-id: aac-6359d9-ab01458-c45a358cbf3230733
  o3-caller-interaction-id: bf630602-b0a5-467e-abe8-5e350f11f092
  o3-ozone-interaction-id: e2ff21ca-dd11-4c05-98ef-403dcc8e588d
accounts:
  accountTypes:
    SampleAccount:
      accountIds: ['100004000000000000000002']
      userId: saving_user
    Corporate_Savings_NotActive:
      accountIds:
        - '100004000000000000000002'
      accountType: Corporate
      accountSubType: Savings
      status: NotActive
payments:
  paymentTypes:
    simple-cbuae-payment:
      paymentType: cbuae-payment
      ConsentId: 1a6d828f-ee97-467f-8626-b5db31f5b887
      Amount: 100
      currency: AED
      PaymentSequenceNumber: 4082668482
      PersonalIdentifiableInformation: eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ....
      PaymentPurposeCode: JEC
      paymentId: b04d4f92e75f4d7f93c0190aa9e4ee71

7.1.2 Configuration Fields

This section provides a detailed explanation of the configuration file fields used in the Testing Tool for Open Banking APIs.

Configuration

Description

baseUrl

Description: The base URL for the API endpoints.
Type: String
Example Value: https://<Some URL>

accounts-schema-file

Description: Path to the dereferenced swagger file for the data-sharing apis
Type: String
Default and only value : der-cbuae-ozone-connect-data-sharing-openapi.json
This field is required for validating the response with the schemas.

payments-schema-file

Description: Path to the dereferenced swagger file for the service-initiation apis
Type: String
Default and only value : der-cbuae-ozone-connect-service-initiation-openapi.json
This field is required for validating the response with the schemas.

event-action-schema-file

Description: Path to the dereferenced swagger file for the consent event action apis
Type: String
Default and only value : der-cbuae-ozone-connect-consent-events-actions-openapi.json
This field is required for validating the response with the schemas.

insurance-schema-file

Description: Path to the dereferenced swagger file for the insurance apis
Type: String
Default and only value : cbuae-ozone-connect-insurance-data-sharing-openapi.json
This field is required for validating the response with the schemas.

products-schema-file

Description: Path to the dereferenced swagger file for the product apis
Type: String
Default and only value : der-cbuae-ozone-connect-products-data-openapi.json
This field is required for validating the response with the schemas.

authorization_type

Description: The type of authorization.
Type: String
Currently we support only JWT, CCG and none.
If CCG is selected, the following 4 fields (ccgDetails) are required to be updated.
If CCG is selected, and the ccgClientAssertionType is selected as private_key_jwt then, the (server) fields are required to be updated.
If JWT is selected, the (server) fields are required to be updated.

ccgDetails

authorisationServerTokenUrl

Description: The complete path for the authorization server end point.
Type: String
Example Value: authUrl/token

ccgDetails

ccgClientAssertionType

Description: Type of client credential grant
Type: String
Example Value: clientCredentials, private_key_jwt

ccgDetails

clientId

Description: Client Id for client credential grant
Type: String

ccgDetails

clientSecret

Description: Client Secret for client credential grant
Type: String

server

aud

Identifier for the party receiving the JWT. This must be set to the PROVIDER_ID specified by Ozone during configuration.

server

request_object_signing_alg

PS256

server

expiry_in_sec

We recommend an expiry time of 10-30s.

When validating the JWT, allow for a 10s clock skew.

server

certs

signing
- kid

The key ID of key-pair used to sign the message as published on the JWKS. The specification does not support the use of other means of identifying the key as they are not considered to be secure enough (e.g. x5c and x5u are not supported).

server

certs

signing
- certFileName

Path to the public certificate file containing the X.509 certificate used for JWT signature verification

server

certs

signing
- keyFileName

Path to the private key file used for signing JWTs with PS256 algorithm

server

certs

transport
- ca

Description: Path to the CA certificate for transport layer security.
Type: String
Example Value: /usr/o3/tr-ozone-connect/config/dev-ca.pem

server

certs

transport
- certFileName

Description: Path to the transport layer certificate file.
Type: String
Example Value: /usr/o3/tr-ozone-connect/config/dev-ca-issued-transport.pem

server

certs

transport
- keyFileName

Description: Path to the private key file for the transport layer certificate.
Type: String
Example Value: /usr/o3/tr-ozone-connect/config/dev-ca-issued-transport.key

aisBasePath

Description: The base path for the Bank Data Sharing endpoints.
Type: String
Example Value: openbanking/v1/ais

pisBasePath

Description: The base path for some Bank Service Initiation endpoints.
Type: String
Example Value: openbanking/v1/pis

validateBasePath

Description: The base path for some endpoints.
Type: String
Example Value: openbanking/v1

productsBasePath

Description: The base path for the Products endpoints.
Type: String
Example Value: openbanking/v1/products

productsLeadBasePath

Description: The base path for the Leads endpoints.
Type: String
Example Value: openbanking/v1/leads

users

<user-name>:
- userId : <user identifier>
- jwt : <base 64 format json object of the above userId>
test-user:
- userId : 10000100000000000000002
- jwt : eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==

The list of users among which a user can be used in any APIs.

We can add the list of users as follows :
For <user-name> : if the userId is "10000100000000000000002", then convert this string : {"userId": "10000100000000000000002"} into Base64 format json object to get eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==.

Then we use the user-name in any of the dynamic fields

accountTypes
paymentTypes

For example :

Code Block
accounts: accountTypes: Retail_CurrentAccount_Active: accountIds: - '100004000000000000000002' accountType: Retail accountSubType: CurrentAccount status: Active userId: test-user

headers

o3-ozone-interaction-id

Description: A unique identifier for tracking interactions. Each request should have a new uuid
Type: String
Example Value: 1c7ee40a-3fa4-406f-a7d5-d935e3910742

headers

o3-api-operation

Description: The HTTP method used for the API operation.
Type: String
Example Value: GET

headers

o3-aspsp-id

Description: The identifier of the LFI.
Type: String
Example Value: RTCBUAE

headers

o3-api-uri

Description: The URI for the specific API endpoint.
Type: String
Example Value: open-banking/account-information/v1/accounts

headers

o3-caller-org-id

Description: The organization ID of the API caller.
Type: String
Example Value: 000015000000000000000001

headers

o3-caller-client-id

Description: The client ID of the API caller.
Type: String
Example Value: 0b196be9-d515-4052-88ac-69585d073030

headers

o3-caller-software-statement-id

Description: The software statement ID of the API caller.
Type: String
Example Value: 000016000000000000000004

headers

o3-consent-id

Description: The consent ID provided by the PSU.
Type: String
Example Value: 17ac7372-2b42-4856-8724-664c256dbba0

headers

o3-provider-id

Description: The identifier for the service provider.
Type: String
Example Value: RTCBUAE

headers

o3-caller-interaction-id

Description: A unique identifier for tracking caller interactions.
Type: String
Example Value: e4180e49-e895-4d6f-80d0-7f5c8f01ee4d

accounts

accountTypes

Description: A list of accountToTest key-value pairs which are internally used in the tests.
Type: Array
Example :
- Retail_CurrentAccount_Active
- AccountIdWithInValidBalanceType
- AccountIdWithCreditIndicatorRetail_CustomerType
- Corporate_CustomerType
- SME_CustomerType
All the accountToTest are a crucial part of the test framework. To modify the parameters of any data-sharing related test we should know the accountToTest value of that test.
Then add that accountToTest in the config.yaml file.

A list of all the accountToTest values can be found in the document : Customizable Fields for Ozone Connect Testing Tool

payments

paymentTypes

Description : A list of paymentToTest key-value pairs which are internally used in the tests.
Type : Array
Example :
- single-instant-payment-for-SME
- AcceptedSettlementCompleted
- simple-cbuae-payment
- single-instant-payment-for-retail
All the paymentToTest are a crucial part of the test framework. To modify the parameters of any service-initiation related tests we should know the paymentToTest value of the test.
Then add that paymentToTestin the config.yaml file.
A list of all the paymentToTest values can be found in from line number 350 onwards in the document : Customizable Fields for Ozone Connect Testing Tool

7.2 Generating the SSL certificates.

Note

The API Hub uses certificates from the OFTF when calling the LFI Ozone Connect service. The procedures below are included as a reference if developers want to do local testing.

It is not recommended to deploy self signed certificates to Preprod or Production environments.

Acquire or generate the SSL certificates to connect to the Ozone Connect server. Put the certificates in a ./config/certs folder.

The certificates in the certs folder are critical for securing communications between the LFI and the OFP using mTLS.

Below you can find a brief explanation of how you can generate test certificates in order to run the testing tool against your implementation.

Please keep in mind that you can also use certificates provided by OFTF. In this case please skip certificate generation step.

7.2.1 Steps to Generate Test Certificates:

Create a Certificate Authority (CA)
- A CA is responsible for signing certificates. If you do not have an existing CA, you can create one.
- Generate the private key for your CA:
  openssl genpkey -algorithm RSA -out dev-ca.key -aes256
- Create a self-signed root certificate:
  openssl req -x509 -new -nodes -key dev-ca.key -sha256 -days 365 -out dev-ca.pem
Generate a Private Key for the Server
- Generate the private key for your server:
  openssl genpkey -algorithm RSA -out dev-ca-issued-transport.key -aes256
Create a Certificate Signing Request (CSR)
- Generate a CSR using the server's private key:
  openssl req -new -key dev-ca-issued-transport.key -out dev-ca-issued-transport.csr
Sign the CSR with Your CA
- Use your CA to sign the CSR, creating the server certificate:
  openssl x509 -req -in dev-ca-issued-transport.csr -CA dev-ca.pem -CAkey dev-ca.key -CAcreateserial -out dev-ca-issued-transport.pem -days 365 -sha256
Verify the Certificate
- Ensure the certificate is correctly generated and can be verified against the CA:
  openssl verify -CAfile dev-ca.pem dev-ca-issued-transport.pem

7.2.2 Summary of Files

CA Certificate (dev-ca.pem)
- The root certificate used to sign other certificates.
Server Private Key (dev-ca-issued-transport.key)
- The private key for the server, kept secure and not shared.
Server Certificate (dev-ca-issued-transport.pem)
- The public certificate signed by the CA, used for secure communications.

8. Detailed Steps to run the Testing Tool

Follow the instructions below to run the Testing Tool:

#Sample

Sample command

WITH

the

client

configuration

and

custom

tests

being

provided :

provided

Step 1

Create an input test configuration file and set up it in /config folder.

Refer section 6.1.2 and section 6.1.3

Step 2

Acquire/Generate the SSL certificates and put them in a /config/certs folder.

Please follow the Test Certificates section in case you need to generate test certificates: 7.2.1

Otherwise please use OFTF Certificates.

Step 3

Execute the testing tool command.

Code Block

docker run --user root --rm -it \
-v "$(pwd)/config:/usr/o3/tr-ozone-connect/config" \
-v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \
public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.610.1 \
yarn tr-ozone-connect \
--formatter terse \
--loglevel-runner info \
--config ./config/config.yaml \
--out ./test_logs.json \
-s 'Id:[GET /accounts]' -r Id:'[AIS_A001]'

Step 4

The final section of the sample output, after all tests have been run and logs have been printed, will appear as follows.

The output will look similar but the Pass-Fail status might be different in the actual output.

Step 5

Review the Testing Tool output log file for the test case results. The log file's name is defined in the last part of the command from step 1. You can modify this name with each run. If unchanged, subsequent runs will overwrite the same file.

Use any text editor to view the file :
$(pwd)/logs/test_logs.json

Step 6

The test run results are also available in an HTML file with a similar name to the test_logs.json file. This file is located in the same folder as the JSON log file.

Use any browser to open the html report file :
$(pwd)/logs/test_logs.html

8.1 Sample Output Report

A sample html report file can be found in : Sample Html Report of the Testing Tool

9. Test Cases

The list of referred tests is available in the following document: Ozone Connect Test Cases

10. Recorded Demonstration of using this tool

The following video demonstration showcases how to customize an existing test case, enabling anyone to run it in their own environment.

Testing-Tool-2024.46.0.mp4

11. New Khvafar HTML Report Demo Recording

Khvafar Report Demo.mov

Version	Old Version 9	New Version 10
Changes made by	Isla Humphreys	Rajeev Walia
Saved on	13 Feb 2025	27 Feb 2025

QA engineers	Professionals responsible for ensuring the quality and reliability of the Ozone Connect implementation by conducting thorough testing and identifying defects.
Integration Specialists	Experts focused on integrating and aligning the Ozone Connect implementation with the API Hub to ensure seamless interoperability and conformance.

Content Comparison

Versions Compared

Key

1. Purpose

2. Scope

3. Audience

4. Overview

5. Setup Requirements

6. Usage

6.1 Running the Testing Tool

6.1.1 Constructing the command for the test tool

6.1.1.1 Base Command:

6.1.1.2 Help Command

6.1.1.3 Available Options:

6.1.2 Initializing Configuration

6.1.2.1 Upgrading from a previous version of this testing tool

6.1.2.1.1 Using JWT Authorization

Previous certs section

Updated certs section

Migration Notes

6.1.2.1.2 Using Client Credentials Grant Authorization

6.1.2.2 Adding Multiple Users

6.1

.3 Updating Configuration

6.1.3.1 Editing config.yaml

6.1.3.2 Using the Interactive Setup Tool

6.1.3 Updating Configuration

6.1.3.1 Editing config.yaml

6.1.3.2 Using the Interactive Setup Tool

6.1.4 Validating Configuration

6.1.4 Validating Configuration

6.1.5 Running the Testing Tool with custom configuration

6.1.5 Running the Testing Tool with custom configuration

6.1.6 Components of the command

6.1.7 Options to the tr-ozone-connect command

7. Common Config Files Options

7.1 Configuration File

7.1.1 Sample config.yaml file

7. Common Config Files Options

7.1 Configuration File

7.1.1 Sample config.yaml file

7.1.2 Configuration Fields

7.2 Generating the SSL certificates.

7.2.1 Steps to Generate Test Certificates:

7.2.2 Summary of Files

8. Detailed Steps to run the Testing Tool

8.1 Sample Output Report

9. Test Cases

10. Recorded Demonstration of using this tool

11. New Khvafar HTML Report Demo Recording

6.1.3.1 Editing `config.yaml`

6.1.3.1 Editing `config.yaml`