Joining in short
As a first step you will have to agree to the provisions of the Collaboration Agreement (for HEIs) and sign it. You can send it to us as a signed PDF. On the EWP side Joao Bacelar (Executive Director of the European University Foundation - EUF) signs it for the EWP consortium as representative of the coordinating institution.
You will also have to supply contact details for your institution as soon as you become operational in EWP. We need two names and email addresses from each HEI, one from a policy maker/responsible person who is connected to the student data services used and one on a technical level in case there are operational problems).
Detailed admission procedure
As a first step an interested institution will consult the information in the EWP Knowledge Base.
The EWP team will require a formal Collaboration Agreement signed by the Legal Representative of the applying institution.
- As a first step the EWP team will assure that the applying institution is an Erasmus charter holder that actively participates in the Erasmus programme;
- The EWP team will check if the SCHAC code belongs to the applying HEI;
- The EWP team checks if the proposed domain for hosting the manifest file is owned by the applying institution.
To enter the Development environment, no special requirements have to be fulfilled except for providing the URL of the manifest file that will be added to the Development registry.
b. Technical admission
You will need to involve you technical team for being added to EWP. The first step for the technical admission is that your technical team provides us with the URL of your manifest file.
For each of the APIs supported, the server implementation should work properly to assure the data exchange.
The technical admission procedure consists of four steps:
- The URL to the manifest file is added to the development registry (DEV):
As a first step of the technical admission, upon approval of the EWP team (see a. Authentication), the institution will be added to the development registry. Therefore a manifest file and its corresponding URL will be needed. The manifest file contains information about the supported APIs and hosts. The URL will be added to the development registry and as a first step the ECHO API needs to be developed.
- The applicant institution performs some automated self-tests;
- The applicant institution performs testing with three partner institutions.
Newcomers will need to demonstrate their technical ability to exchange real data in the development environment. Therefore they will need to develop at least one of the APIs (apart from ECHO) that facilitate real exchange of data between HEIs. Before an applicant institution can become part of the production registry, the institution needs to prove successful testing.
- The EWP technical team performs some ultimate technical testing before adding the institution to the production registry (PROD).
The final step of the technical admission consists of an ultimate series of tests by the EWP technical team. Each of the APIs supported by the applicant will undergo this testing.
Entry in the production registry
Once both admission processes have a positive outcome, the EWP Technical Support Team will add the URL of the manifest file of the applicant HEI to the production registry. By doing so the applicant becomes part of the EWP network and agrees to the EWP rules and obligations. In case of a serious violation or complaints by other EWP users a revocation procedure can be installed by contacting us via the Knowledge Base (see below). As part of the obligations, institutions agree not to add additional APIs to their production manifest file before it has released and tested these new APIs in the development environment.
We should keep in mind that things can go wrong. When institutions violate the use of EWP there should be an exit strategy. The contact section in the Knowledge Base will be the central point where institutions can report incidents and complain about the quality of APIs of any particular institution, the unavailability of a server, partners that are not trustworthy. The EWP Governance structure will try to settle disputes and has the ability to decide to exclude a certain institution from the production registry. The institution will need to prove its ability and trustworthiness again in the development environment. In cases of extreme violation the EWP governance structure has the competence to temporally exclude an institution from EWP.