Expand | ||||
---|---|---|---|---|
| ||||
|
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 v2024.46Specification.00
6.1 Running the Testing Tool
on OzoneAPI Mock Server with Default SettingsThis command runs the Testing Tool Docker container with the default settings. It executes predefined tests against a cloud-based mock Ozone Connect server. Use it to explore the tool's functionality. The output HTML report will be available in the logs folder.
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)/logsconfig:/usr/o3/tr-ozone-connect/logsconfig" \ public.ecr.aws/g5c5c6i0/tr- -v "$(pwd)/logs:/usr/o3/tr-ozone-connect/logs" \ public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2024.46.0 \ yarn tr-ozone-connect \ --formatter terse \ --loglevel-runner info \ --config ./config/config.yaml \ --out /2025.3.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/test_logs.json" \ -s 'Id:[get-accounts]' -r Id:'[AIS_A001]' |
6.2 Running the Testing Tool on a custom Server
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.2.1 Constructing the command for the test tool
6.2.1.1 Base Command:public.ecr.aws/g5c5c6i0/tr-image/tr-ozone-connect:2025.3.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:20242025.46.0 |
6.2.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:2024.46.0 help |
6.2.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.2.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:2024.46.0 init-config
Initializing Configuration...
Configuration file missing. Copying default config file...
Certificates folder missing. Copying default certs folder... |
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.2.2.1 Running a Sample Test
After 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.
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:2024.46.0 \
yarn tr-ozone-connect \
--formatter terse \
--loglevel-runner info \
--config ./config/config.yaml \
--out /usr/o3/tr-ozone-connect/logs/test_logs.json \
-s 'Id:[get-accounts]' -r Id:'[AIS_A001]' |
6.2.3 Updating Configuration
6.2.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.2.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 folder3.1 init-config
Initializing Configuration...
Configuration file missing. Copying default config file...
Certificates folder missing. Copying default certs folder... |
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
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
toserver.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 Running a Sample Test
After 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.
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:20242025.463.01 setup-config\ yarn Starting Config Manager: Setup Configuration... Welcome to the Config Manager! Note: Pressing enter will keep the current value. Backup created: tr-ozone-connect \ --formatter terse \ --loglevel-runner info \ --config ./config/config.yaml \ --out /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.2.4 Validating Configuration
To validate the configuration file, use thevalidate-config
command: This command ensures the configuration file is properly formatted and that all required certificate files are presentlogs/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.
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:20242025.463.01 validatesetup-config Starting Config Manager: ValidateSetup Configuration... ValidatingWelcome configuration file... All cert files are present. Configuration validation passed. |
6.2.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 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.
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:20242025.463.0 \ 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]' |
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:/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 |
---|---|
| 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:
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 "$(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.3.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.
2.7 Options to the tr-ozone-connect 1.6 Components of the command
The available command line options for the yarn tr-ozone-connect
command are listed in the table below. 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 |
---|
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 a regular expression for running selected test suites.
(Format : string, required)
The full list of test suites currently available are :
get-accounts
get-balances
get-beneficiaries
get-customer
get-direct-debits
get-products
get-scheduled-payments
get-standing-orders
get-transactions
future-dated-payments
get-report-file-payments
single-instant-payments
-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 Sample HTML Report of the Testing Tool -
View file | ||
---|---|---|
|
Example regex values are :
‘Id:[AIS_A001]'
'Id:[AIS_A001,AIS_A002]'
'Id:[AIS_A.*]'
'Id:[AIS_A.*,AIS_B.*]'
'Id:[AIS_A009,AIS_A001,AIS_A005]'
Note there is no space after the comma which separates the regex.
Also note that the complete expression is inside single quotes.
-v, --loglevel-runner
Log level for the test runner (Format : string, optional)
debug, info, silent
-l, --loglevel-suite
Log level for the test suite (Format : string, optional)
info
--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
certs:
transport:
ca: /usr/o3/tr-ozone-connect/config/certs/ozone2021-ca.pem
certFileName: /usr/o3/tr-ozone-connect/config/certs/ozone-issued-transport-HQuZPIt3ipkh33Uxytox1E.pem
keyFileName: /usr/o3/tr-ozone-connect/config/certs/ozone-issued-transport-HQuZPIt3ipkh33Uxytox1E.key
aisBasePath: openbanking/v1/ais
pisBasePath: openbanking/v1/pis
validateBasePath: openbanking/v1
psuIdentifier:
userId: '10000100000000000000002'
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-banking/account-information/v1/accounts
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
o3-psu-identifier: eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==
accounts:
accountTypes:
SampleAccount:
accountIds: ['100004000000000000000002']
Corporate_ChargeCard_Active:
accountIds:
- '100004000000000000000008'
accountType: Corporate
accountSubType: ChargeCard
status: Active
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>
psuIdentifier
userId
Description: The user identifier (PSU ID) used in the context of AIS.
Type: String
Example Value:
10000100000000000000002
aisBasePath
Description: The base path for the Bank Data Sharing endpoints.
Type: String
Example Value:
openbanking/v1/ais
pisBasePath
Description: The base path for the Bank Service Initiation endpoints.
Type: String
Example Value:
openbanking/v1/pis
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-psu-identifier
Description: The identifier for the PSU, typically a base64-encoded JSON object.
Type: String
Example Value:
YmFzZTY0IGVuY29kZWQgSnNvbiBzdHJpbmc=
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
certs
transport
ca
| 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 |
| 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 |
---|---|
| 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 | config.yaml, config.json, ./config/config.yaml |
-f, --folder | Preconfigured path to the folders with the test files | src/tests, tests, ./src/tests |
-o, --out | Output file name | results.json, output.json, ./test_output.json |
-e, --formatter | Use a standard formatter for the output | full, terse, medium, errors |
-s, --regex_for_test_suite | Provide the full name of the test suite from the list. (Format : comma separated string, required) | The full list of test suites currently available are : Examples: ‘Id:[GET /accounts/{accountId}/customer,GET /accounts/{accountId}]’ |
-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 Sample Html Report of the Testing Tool Example regex values are :
Note there is no space after the comma which separates the regex. |
-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 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
authorization_type: JWT
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: h6ay_wf6UJQ-h9qE1KR5X2kWkPPjOUmLRZG2AHtbCk0
transport:
ca: /usr/o3/tr-ozone-connect/config/certs/transport/cerrtificate.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
psuIdentifier:
userId: '10000100000000000000002'
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-banking/account-information/v1/accounts
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
o3-psu-identifier: eyJ1c2VySWQiOiIxMDAwMDEwMDAwMDAwMDAwMDAwMDAwMDIifQ==
accounts:
accountTypes:
SampleAccount:
accountIds: ['100004000000000000000002']
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 |
|
psuIdentifier
|
|
aisBasePath |
|
pisBasePath |
|
authorization_type |
|
server
| Identifier for the party receiving the |
server
|
|
server
| We recommend an expiry time of 10-30s. When validating the JWT, allow for a 10s clock skew. |
server certs
|
|
server certs
|
|
server certs
|
|
|
|
|
server certs |
transport
keyFileName
Description: Path to the private key file for the transport layer certificate.
| 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. |
server certs
| Path to the public certificate file containing the X.509 certificate used for JWT signature verification
|
server certs
| Path to the private key file used for signing JWTs with PS256 algorithm |
headers
|
|
/usr/o3/tr-ozone-connect/config/dev-ca-issued-transport.key
accounts-schema-file
| |
headers
|
|
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
| |
headers
|
|
Default and only value : der-cbuae-ozone-connect-service-initiation-openapi.json
This field is required for validating the response with the schemas.
accounts
accountTypes
Description: A list of
accountToTest
key-value pairs which are internally used in the tests.Type: Array
Example :
Corporate_ChargeCard_Active
Corporate_CreditCard_Dormant
Retail_CurrentAccount_Active
Retail_EMoney_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 theaccountToTest
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 thepaymentToTest
value of the test.Then add that
paymentToTest
in 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:
Step 1
Create an input test configuration file and set up it in /config
folder.
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 |
---|
#Sample command WITH the client configuration and custom tests being provided :
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:2024.46.0 \
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 :
View file | ||
---|---|---|
|
9. Test-Suite and Test-Case Regex Combinations for Running a Subset of Tests
Please note : The -s and the -r both the command line arguments are mandatory.
A wide variety of selection of test cases is possible. An example usage of the regex is listed below.
Sr.
Regex Pattern
Outcome
1
-s 'Id:[get-account]' -r Id:'[.*]'
Execute all test cases from the get-account test suite only.
Test cases from other suites will not be attempted for execution.
2
-s 'Id:[get-account]' -r Id:'[AIS_A001]'
Execute only the test case AIS_A001 from the get-account test suite.
All other test cases from the get-account test suite will be skipped.
Test cases from other suites will not be attempted for execution.
3
-s 'Id:[.*]' -r Id:'[AIS_A001]'
Execute only the test case AIS_A001.
Test cases from other suites will be attempted for execution. But will be skipped.
4
-s 'Id:[.*payments.*]' -r Id:'[.*]'
Execute all the tests from the suites whose suiteId has the word ‘payments’ in it.
Test cases from other suites will not be attempted for execution.
5
-s 'Id:[get-account]' -r Id:'[00.]'
Execute all the tests from the get-account test suite which have the testId among one of 000, 001, 002, 003, 004, 005, 006, 007, 008, 009.
Test cases from other suites will not be attempted for execution.
6
| |
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
headers
|
|
accounts-schema-file |
|
payments-schema-file |
|
event-action-schema-file |
|
insurance-schema-file |
|
accounts
|
A list of all the
|
payments
|
|
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:
Step 1 | Create an input test configuration file and set up it in | |||
Step 2 | Acquire/Generate the SSL certificates and put them in a | 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. |
| ||
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 : | ||
Step 6 | The test run results are also available in an HTML file with a similar name to the | Use any browser to open the html report file : |
8.1 Sample Output Report
A sample html report file can be found in : Sample Html Report of the Testing Tool
9. Test-Suite and Test-Case Regex Combinations for Running a Subset of Tests
Please note : The -s and the -r both the command line arguments are mandatory.
A wide variety of selection of test cases is possible. An example usage of the regex is listed below.
Sr. | Regex Pattern | Outcome |
---|
Sr. | Regex Pattern | Outcome |
---|---|---|
1 | -s 'Id:[GET /accounts]' -r Id:'[.*]' | Execute all test cases from the GET /accounts test suite only. |
2 | -s 'Id:[GET /accounts]' -r Id:'[AIS_A001]' | Execute only the test case AIS_A001 from the GET /accounts test suite. |
3 | -s 'Id:[GET /accounts]' -r Id:'[00.]' | Execute all the tests from the GET /accounts test suite which have the testId among one of 000, 001, 002, 003, 004, 005, 006, 007, 008, 009. Test cases from other suites will not be attempted for execution. |
4 | -s 'Id:[GET /accounts,GET /accounts/{accountId}/direct-debits,GET /customers]' -r Id:'[.*]' | Execute all the test case from the 3 test-suites.
Test cases from other suites will not be attempted for execution. |
5 | -s 'Id:[GET /accounts/{accountId}/customer,GET /accounts/{accountId},GET /accounts,GET /accounts/{accountId}/balances,GET /accounts/{accountId}/beneficiaries,GET /customer,GET /accounts/{accountId}/direct-debits,GET /accounts/{accountId}/products,GET /accounts/{accountId}/scheduled-payments,GET /accounts/{accountId}/standing-orders,GET /accounts/{accountId}/transactions,POST /customers/action/cop-query,Combined Future Dated Payment with Fixed Defined Schedule,Combined Future Dated Payments with Fixed On Demand,Combined Future Dated Payments with Fixed Periodic Schedule,Combined Future Dated Payment with Variable Defined Schedule,Combined Future Dated Payments with Variable On Demand,Combined Future Dated Payments with Variable Periodic Schedule,Combined Single Instant Payments with Fixed Defined Schedule,Combined Single Instant Payments with Fixed On Demand,Combined Single Instant Payments with Fixed Periodic Schedule,Combined Single Instant Payments with Variable Defined Schedule,Combined Single Instant Payments with Variable On Demand,Combined Single Instant Payments with Variable Periodic Schedule,Payment consent and file payments,Fixed Defined Schedule,Fixed On Demand,Fixed Periodic Schedule,future-dated-payments,get-report-file-payments,header-validations-tests,International Payments,Payment Consent Refund,single-instant-payments,Variable Defined Schedule,Variable On Demand,Variable Periodic Schedule,Consent/action/augment post request,Consent/action/validate post request,Insurance]' -r Id:'[.*]' | Run all the test cases in all the test suites. |
10. Test Cases
The list of referred tests is available in the following document: Ozone Connect Test CasesThe list of implemented test cases in the current version of the test framework are as follows : Implemented Test Cases
11. 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.