This section outlines the approach to onboarding the iHub services to client forces. Client forces must follow the appropriate process to engage with the onboarding mechanism and, once engaged, will need to allocate appropriate resource funding, access, and support onboarding.
The following information is taken from sections 9.2, 9.3, and 9.5 of the iHub Offering Description Document. The role of this document is to support client forces and their system providers in the adoption and use of the iHub service. For further information on these topics, please consult the relevant section of the above documentation.
To implement Standard API, endpoints will need to be exposed over the internet to receive POST requests from the iHub. These endpoints must support TLS 1.2 or above.
To implement Standard API, client information needs to be transmitted between the iHub and the client force. Client IDs and Secrets will be leveraged as the method of authentication. Client forces will need to provide a useable set of credentials that iHub can authenticate against the Standard API with. APIs must support mutual TLS.
When onboarding to the Standard Data Model, each client force will be assigned a "force identifier" and a "brand". This takes the form of an integer that will be used to ensure payloads are routed to the correct client force(s).
The iHub provides four different environments:
| Environment | Description |
|---|---|
| Developers | For developers to use for code updates and testing |
| Test | Test environment for functional and integration testing |
| Pre-Production | Test environment used for user-acceptance testing and performance testing |
| Production | Live environment |
Client forces are required to ensure that relevant resources are provided for testing and feedback is given in a timely manner to support the delivery dates of the iHub work.
Further testing information can be found in section 9.5 of the iHub ODD document.
Client forces must be aware of the role of the Change Approval Board (CAB) and change release as a critical requirement for change and service onboarding. Client forces will be responsible for the co-ordination and sign-off of the internal processes within their own organisation.
Further information can be found in section 9.5 of the iHub ODD documentation.
Client forces must follow the appropriate process to engage with the change mechanism and once engaged, will need to ensure access to NDT/DPC and allocate appropriate internal resource funding, access and support the change delivery processes.
Client forces and system suppliers must provide information about changes to relevant elements which could affect the API, XML and future integration/interface services, three months before any transformation or alteration is considered.
Please note: should emergency change be required this would follow the emergency change route outlined in the change management process.
Further information can be found in section 9.5 of the iHub ODD documentation.
Client forces will be notified three months in advance of any breaking changes to the iHub. Recognition and response of these changes will need to be received and confirmed by client forces within two weeks of this information being made available.
All forces are expected to maintain a modern digital lifecycle which supports the iHub versioning strategy.
Further information can be found in section 9.5 of the iHub ODD documentation.