As a first step it is important to understand the basics (different scenario's for joining Erasmus Without Paper, the mobility process cut into pieces) of the Erasmus Without Paper infrastructure and apply it to the management of mobility processes at your own institution.

The implementation of Erasmus Without Paper in your inhouse software needs to be done by your IT team. We encourage you to involve them in the process right from the beginning. They will be responsible for developing the APIs that connect your own system to the system of your partner via the Erasmus Without Paper network using the communication protocols.

Your IT team will have two important tasks:

1. They have to connect your in-house software to the Erasmus Without Paper Network. This is a mainly technical task and there is a lot of documentation available on how to connect. You can redirect them to the EWP developers page and a special Github repository;

2. The existing business processes will need to be redesigned once data can be directly exchanged with the partners. This is a task where both the IT-team and the IRO (as business process owners) should be involved (also see step 5).

1. As a first step some basic APIs should be implemented by your IT team (the so-called Primary Network APIs: Echo, Institutions, Organizational Units).

2. As a second step it is important to align the developments with the targets from the European Commission and the National Agencies. Contact your National Agency for more information.
   

The full entry procedure is described below.

Although your IT team will be responsible for connecting your system to Erasmus Without Paper, you will need to rethink existing business processes because you will need functionality to send data to your partner institutions or handle data that you receive from your partner. We strongly advise that the IRO as a business process owner is directly involved in the rethinking of these processes.

As a first step the higher education institution needs to undergo a technical admission procedure:

1. The EWP admin of the applicant higher education institution needs to login as a higher education institution in the registration portal staging environment, a copy of the production environment linked to the Erasmus Without Paper development network (please note that if you are not an EWP admin at your institution or your institution does not release this attribute for you (you can test this here), this step will fail, please contact the ESCI Service Desk);

2. In this portal the higher education institution will need to upload a signed Collaboration Agreement determining the terms of use of the Erasmus Without Paper (development) network and setting the conditions to link the in-house software to the Erasmus Without Paper (development) network;

3. Upon the countersigning of the Collaboration Agreement by the EWP+ Consortium, the EWP admin will be informed;

4. The EWP admin will upload a link to the manifest file (this manifest file contains amongst other things information on which APIs the provider supports for the higher education institution in question) for its testing instance;

5. The in-house provider performs some automated self-tests;

6. The in-house provider contacts the ESCI Service Desk with a request for information or guidance (non-student issues) asking to test their APIs with the reference implementation;

7. The EWP technical team will go through the testing scenarios for inter-institutional agreements and/or learning agreements as described in GitHub.

Upon successful testing, the EWP admin needs to login as HEI in the registration portal. In the registration portal the EWP admin will need to upload the signed Collaboration Agreement (also see step 1.2.).

The EWP team will verify if the higher education institution has technical admission. If that’s the case the Collaboration Agreement signed by both parties will be uploaded and the EWP admin will be informed.

The EWP admin can now upload the link to its manifest file. Only APIs that were tested during step 1 can be included in the manifest file. When the provider would like to declare endpoints for new processes, they need to undergo the step 1 testing with the reference implementation.