Versions Compared

Old Version 33

changes.mady.by.user Paul Leys

Saved on

compared with

New Version 34

changes.mady.by.user Paul Leys

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
This page explains how HEIs higher education institutions that hold an Erasmus Charter for Higher Education (ECHE) can join the EWP Erasmus Without Paper network. Organisational units of a given HEI given higher education institutions (faculties, departments) or consortia are not allowed to connect to the network separately.

In case you are using a 3rd party mobility management software, chances are that their there is a big change that this software is already connected to the Erasmus Without Paper Network to provide . When connected it provides you with the functionality to send and receive mobility data via their softwarebetween partners. Please get in touch with your respective mobility management software provider to learn more about their involvement in Erasmus Without Paper. 

An overview of the current 3rd party mobility software providers that are present in the network after successful technical testing can be found here.

If you use a 3rd party provider that is not mentioned in the overview above, please let us know or pass on our contact info to your software provider. Each third party provider is responsible for its own software and EWP Erasmus Without Paper implementation, so we the EWP+ Consortium can only act as an intermediary. 

Procedure

If you are using software from a third party provider, you will join EWP via your provider. Your provider will need to upload information on the registration portal where the institution (the so-called EWP-administrator) will need to confirm they are supported by this provider for using EWP:


Expand
titleStep 1: Preparation by the 3rd-party provider
  1. The third party provider needs to undergo a technical admission procedure:
    1. The third party provider needs to register as a new provider in the registration portal staging environment (a copy of the production environment linked to the EWP development network);
    2. In this portal the provider will need to upload a signed Collaboration Agreement determining the terms of use of  the EWP Development Network and setting the conditions to link the Provider’s external software to the EWP Development Network as well as the right to use the name and logo of EWP in its documentation;
    3. Upon the countersigning of the MoU by the EWP Consortium, an account will be created in the staging registration portal;
    4. The provider will upload a link to the manifest file(s) for its testing instance(s);
    5. The provider performs some automated self-tests;
    6. The 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 IIAs and/or LAs as described in GitHub.
  2. Upon technical admission, the third party provider needs to register as a new provider in the registration portal;
  3. In this portal the provider will need to upload the signed Collaboration Agreement determining the terms of use of  the EWP Network and setting the conditions to link the provider’s external software to the EWP Network, as well as the right to use the name and logo of EWP in its documentation;
  4. The EWP team will verify if the third party provider underwent the technical admission. If that’s the case the signed Collaboration Agreement will be uploaded and an account will be created in the registration portal;
  5. The provider can now deliver the manifest file for each of their customers. This manifest file contains amongst other things information on which APIs the provider supports for the higher education institution in question. Only APIs that were tested during 1.g. can be included in the manifest files. When the provider would like to declare endpoints for new processes, they need to undergo the 1.g. testing with the reference implementation.


Expand
titleStep 2: Confirmation by the Higher Educaton Institution

The EWP-admin from the higher education institution needs to log in to the registration portal as HEI and confirm their institution is represented by the provider for the given APIs (this step only works for EWP-admins).

For the time being, this step is taken care of by the EWP technical support team until a majority of HEIs support the EWP admin entitlement. This is to ensure higher education institutions can keep using EWP services in this transitional period.


Start exchanging via EWP

Once the steps above are completed, higher education institutions can start exchanging data via EWP in their productive environment. They need to use the functionalities provided by their provider who is responsible for accurate training and support for using EWP-related functionalities. 

As part of their obligations, software providers agree not to add additional APIs to their production manifest file before they have released these new APIs in the development environment and tested them with the reference implementation.

Revocation

One should keep in mind that things can go wrong. When institutions violate the use of the EWP network there should be an exit strategy. Institutions can report implementation issues of any particular node via the ESCI Service Desk. The EWP management will try to settle disputes and has the authority to exclude any institution from the production registry if it is in violation of the terms of usage. The institution will need to prove its ability and trustworthiness again in the development environment.