...
HEIs get agency and tools to manage their connection to the Network. This goal is achieved by giving institutions the way to sign in to the Registration Portal with the credentials passed from their home authorisation system and the right to approve their manifests. |
In the Registration Portal all stakeholders – HEIs and mobility software providers – manage all network parameters of their connectivity by themselves, anytime. Registry administrators RP administrator and EWP network authorities also can handle the needed activities via the web portal. | ||||
All important documents, such as the signed EWP Collaboration Agreement, are gathered in one place which is easily accessible to all stakeholders. |
In line with the carefully crafted verification rules, the portal supports security and ownership by verifying the identifiers (such as SCHAC code) transported in the set of attributes from MyAcademicId against identifiers obtained from other sources (ECHE List API, HEI List API, manifest files). |
...
Actions performed in the Registration Portal
...
3rd-party provider |
|
In-house provider (represented by the EWP Administrator) |
|
...
When a provider creates an account in the Registration Portal, the account status is New. After the Collaboration Agreement (MoU) signed by the provider is loaded into the system, the account status changes to Pending. Once the MoU Administrator submits the countersigned MoU, the account status changes to Active. Only then, the provider can register the manifest files.
Registration of the manifests with validation
A provider registers the manifests. The system validates them and only those manifests can be uploaded which validate positively, are exported to the EWP Network. The manifest has to be reachable, have a proper certificate, have a proper XML format. Additionally, there are some restrictions concerning names:
the provider’s name in the manifest must be identical to the technical name of the provider (or a name, if no technical name is provided); be aware, that the provider’s name in the manifest does not include the part in parenthesis, eg. for an element
Code Block <admin-provider>MUCI (USOS)<admin-provider>
the name of the provider is MUCI, the name of the mobility software of the provider is USOS.
in case of the manifest registered by an in-house system provider, the SCHAC code in the manifest must be identical to the SCHAC of the HEI (delivered by MyAcademicID).
...
A manifest registered in the system by the 3rd-party provider gets the status Unconfirmed. Such manifests have to be confirmed by the HEIs for which they are intended. The HEI’s representative with a EWP Admin role should sign in to the system via MyAcademicID and confirm the manifest(s) on behalf of the institution.
Only confirmed manifests are can be exported to the EWP Network.
...
# | Name of the API | Versions acceptable in DEV | Versions acceptable in PROD |
|---|---|---|---|
1 | courses | 0.0.0 | 0.0.0 |
2 | discovery | 6.0.0 | 6.0.0 |
3 | echo | 2.0.0 | 2.0.0 |
4 | factsheet | 1.0.0 | 1.0.0 |
5 | file | 1.0.0 | 1.0.0 |
6 | iia-approval-cnr | 1.0.0, 2.0.0 | 1.0.0 |
7 | iia-cnr | 2.0.0, 3.0.0 | 2.0.0 |
8 | iias | 6.0.0, 7.0.0 | 6.0.0 |
9 | iias-approval | 1.0.0, 2.0.0 | 1.0.0 |
10 | imobilities | 1.0.0 | 1.0.0 |
11 | imobility-cnr | 1.0.0 | 1.0.0 |
12 | imobility-tor-cnr | 1.0.0 | 1.0.0 |
13 | imobility-tors | 1.0.0, 2.0.0 | 1.0.0, 2.0.0 |
14 | institutions | 2.0.0 | 2.0.0 |
15 | omobilities | 1.0.0, 2.0.0 | 1.0.0, 2.0.0 |
16 | omobility-cnr | 1.0.0 | 1.0.0 |
17 | omobility-la-cnr | 1.0.0 | 1.0.0 |
18 | omobility-las | 1.0.0 | 1.0.0 |
19 | organizational-units | 2.0.0 | 2.0.0 |
20 | simple-course-replication | 1.0.0 | 1.0.0 |
The RP administrator in theReviewer’s the Reviewer’s role verifies the mobility software of a provider and sets the status of the provider’s APIs accordingly. In the DEV Network generally all acceptable APIs are set as Verified. In PROD the status of the API depends on the results of testing - only after successful testing the APIs get the status Verified, otherwise they have the status Unverified.
The status of the manifest depends on the status of the APIs defined in it. If any of the APIs is Unverified, the manifest also gets the status Unverified.
Status of the manifests
The status of the manifest depends on the following flags:
Valid (Yes/No) - this status depends on the result of the validation performed upon registration and periodically by the system.
Confirmed (Yes/No)
Verified (Yes/No)
Enabled (Yes/No) - this flag is set manualy manually by the RP administrator who can, for some reason, temporarily disable the manifest.
Valid (Yes/No) - this status depends on the result of the validation performed upon registration and periodically by the system.
Each of these flags can change independently of the others.
Only the manifests which are Confirmed, Verified, Enabled, and Valid are exported to the EWP Registry:.
In the Registration Portal the manifests which are Confirmed, Verified, Enabled, and Valid are shown as Active, otherwise as Inactive.
...