Skip to content
Pensions dashboards programme logo
  1. Home
  2. Testing

Reporting standards integration test pack

Overview

This document covers the mandatory integration testing phase for reporting standards, to be performed by every organisation connecting in the Money and Pensions Service (MaPS) pre-production environment.

The reporting standards integration test pack gives an overview of the activity performed in the integration testing phase.

Directly connecting organisations (DCOs) must demonstrate that they have successfully completed their own internal system testing and submitted their results through the connection portal. They will then be given permission to begin integration testing within the MaPS pre-production environment.

Back to top

Downloads

Download reporting integration test pack materials.

Back to top

Context

The reporting standards API enables DCOs to submit reporting data to MaPS on a daily basis. The API is hosted within the central digital architecture (CDA) by MaPS. DCOs submit their reporting data to 6 endpoints by sending HTTP POST requests.

The 6 reporting endpoints are:

  • POST /service-availability/find
  • POST /service-availability/view
  • POST /view-response/request-number
  • POST /view-response/response-time
  • POST /view-response/calculations
  • POST /view-response/unavailable

Integration testing uses a set of requests to validate event generation for each Reporting API endpoint. This confirms that each connecting organisation is successfully integrated with CDA and is compliant with PDP reporting standards v2.2 and that schema compliant requests are successfully processed through the reporting pipeline.

This testing phase is not intended to be a comprehensive test of all required functionality. It is designed to assure that API requests successfully flow through the reporting architecture

Integration testing will confirm that:

  • request to each endpoint is successfully processed
  • events are generated and delivered via the reporting pipeline

This phase will not:

  • validate business rules (such as timing, resubmissions, correctness)
  • assess correctness of business data attributes
  • test retry logic, error handling or negative scenarios

The connecting organisation should have already tested their solution to assure its functional and non-functional completeness and its compliance with reporting standards v2.2 prior to entering integration testing.

DCOs must perform checks before reporting integration testing can start. See ‘Checks to be performed by DCOs before integration testing connection proving’.

Back to top

Reference documents

You can find these on the PDP standards page.

Back to top

Setup environment

The integration testing will start by configuring the MaPS pre-production environment for the DCOs under test.

Back to top

Checks to be performed by DCOs before integration testing connection proving

  1. A valid, non-expired test mTLS certificate is in place to enable connectivity with the pre-production environment.
  2. The DCO’s mechanism for triggering requests to the endpoints is in place, whether through a scheduled batch process or a manual trigger.
  3. The DCO has requested the endpoint URLs by raising a support ticket.
Back to top

Business process

The high-level process is as follows:

  1. Following the approval of the system testing submission, the DCO downloads and deploys test cryptographic materials and updates the connection portal, which sends a notification to PDP.
  2. The PDP implementation manager contacts the DCO test manager and primary technical contact via a support ticket to confirm that the checks have been performed; and to confirm that reporting data can be submitted.
  3. The DCO submits schema-compliant reporting data to all 6 endpoints once they are ready and updates the support ticket.
  4. Once the DCO has confirmed the submission via the support ticket, PDP test team triggers the automated pipeline to execute the integration tests in the pre-production environment.
  5. The pipeline processes only current day submissions (UTC calendar day) and validates the results. It then generates a PDF test report indicating overall pass or fail status. Note: The pipeline does not process submissions from previous days. To allow sufficient time for validation and processing on the same day, DCOs should avoid submitting reporting data between 16:00 UTC and 00:00 UTC (midnight). If a submission cannot be processed on the day it is received, the DCO must resubmit the data on the following day.
  6. Any issues identified during execution are logged and communicated via the support ticket, and if necessary, a support call will be arranged.
  7. Once fixes are implemented, the pipeline is re-triggered to rerun the test.
  8. The PDP implementation manager shares the test report with the DCO via the support ticket.
  9. The DCO’s test manager uploads it to the connection portal when prompted as part of the connection process. The PDP test manager approves the test report.
Back to top

Planning and scheduling of the tests

Providers are allocated an integration testing slot on a first come, first served basis when they reach this stage. If a provider cannot utilise their window, the next organisation in the queue will be contacted to make use of the slot.

Multiple DCOs may submit requests concurrently. However, the number of DCOs undergoing testing at any one time will be limited

Back to top

Test scripts

Integration test cases are detailed in the reporting integration test cases document, which is included in this test pack. See ‘Downloads’.

Back to top

Test evidence

The test report will be supplied by the PDP implementation manager in PDF format. It will specify:

  • pass or fail for each test
  • time and date of completion
  • the account code

The report will be sent to the provider who must then upload it into the connection portal.

Back to top

Support

During the testing process, support will be available through the support hub. In the technical support area of the site, users will be able to report issues they are experiencing with PDP test and operational services that include:

  • issues completing test requirements
  • bugs and defects
  • unexpected behaviours
  • error messages
  • other test related issues that you're unsure about

If users need to speak to a member of the PDP team to help resolve their issues, they should submit their issue through the support hub.

Back to top