Skip to content
This repository has been archived by the owner on Jul 10, 2020. It is now read-only.

Update onboarding_process.md #7

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update onboarding_process.md #7

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
18 changes: 9 additions & 9 deletions document_provider/onboarding_process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,33 +1,33 @@
# Onboarding process to become a Document Provider
![Diagram: DocProvider onboarding process](../media/docProviderOnboardingProcess.png)

## DocProvider initial request
## 1. DocProvider initial request
First you can contact [[email protected]](mailto:[email protected]) in order to explain in a high-level way what is expected with you future e-Box integration as new DocProvider, for which business/use cases, and a first idea of the volume (number of provided documents) and the expected planning.

## Agreement in principle of the NSSO
## 2. Agreement in principle of the NSSO
Before starting any integration, it is necessary to obtain a first agreement in principle from the NSSO. This agreement will be requested by the eBoxIntegration team to the NSSO e-Box managers.

## Kick-off meeting
## 3. Kick-off meeting
This step is optional but often very useful in order to answer any questions before starting the technical integration.

## Formal request & contract + certificate
## 4. Formal request & contract + certificate
In order to officially become a new DocProvider, please send the following documents to [[email protected]](mailto:[email protected]):
- e-Box DocProvider onboarding form & contract (the contract must be signed by a Legal Representative from your organization);
- The public part of your certificate;
If you need to order a [X.509 certificate](../common/x509_certificate.md) to [QuoVadis](mailto:[email protected]), please pay attention to respect the expected format.
Once completed, the form must be sent.

## Request validation & configuration (ACC)
## 5. Request validation & configuration (ACC)
The eBoxIntegration team is responsible for technically validating the received form. A formal validation of the NSSO is confirmed at this stage. The onboarding with the OAuth2 Authorization Server is managed by our technical teams, based on the information you sent.

## Implementation and tests
## 6. Implementation and tests
Here is the main step, when you are going to implement your own MessageRegistry, based on the API and the development guidelines given in the next section. Of course it is important to test your service and the security before proceeding to the next step.

## Integration of your Web Service & configuration (PRD)
## 7. Integration of your Web Service & configuration (PRD)
At this step, you can deploy a test version of your [MessageRegistry](document_provider.md#MessageRegistryService) that can be integrated into our Acceptance environment. We can then check the integration with the user interface of the federated e-Box. As soon as the verifications are conclusive, we carry out the necessary configurations directly in Production.

## Deploy in Production
## 8. Deploy in Production
You can now deploy your service in the production environment. It is recommended to proceed with the different sanity checks before ‘going live’.

## Production-ready
## 9. Production-ready
Your integration with the e-Box system can finally ‘go live’. Congratulations, you are now actually part of the e-Box galaxy!