Registration Portal

The EWP Registration Portal (RP) is an online service that plays a pivotal role in supporting the deployment of the EWP Network. In the RP, Higher Education Institutions (HEIs) can enter or change their EWP settings, having full control as to how they are represented in the EWP Network. Mobility software providers may register manifest files of their customers enabling them to have easy access to technical data.

Goals of the Registration Portal

Actions performed in the Registration Portal

In this section, we shortly explain what actions providers and HEI representatives should perform to properly register their manifests in the EWP network. The only way to place the manifest on the Internet is for the provider to enter it into the Registration portal, verify the correctness of the manifest (including the APIs it contains) and have the manifest confirmed by the HEI for which it is intended.

Important functionalities of the Registration Portal

Activating the provider’s account

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. 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

  <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).

If the manifest does not validate, the provider has to correct errors and try again.

Read also about hybrid manifests.

Confirmation of the manifests by HEIs

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 can be exported to the EWP Network.

In special cases, the 3rd-party provider can ask the RP administrator to confirm manifests on behalf of the institution. The system delivers a functionality which allows the provider to select the manifests and mark them as Admin confirmation requested. An email is sent to the RP administrator, who can confirm the manifests or reject the request.

Manifests registered by in-house system providers by default get the status Confirmed.

Verification status of the provider’s APIs

The system keeps track of the major versions of the APIs which can be present in the EWP Network. Currently (October 2023) the following major versions are acceptable in the DEV and PROD networks.

The RP administrator in 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 manually by the RP administrator who can, for some reason, temporarily disable the manifest.

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.

Hybrid manifests

There are possible situations where a 3rd-party provider produces software that is installed by HEI in a local installation. In this case, the provider may not know the address of this installation, so it should not register the manifest. On the other hand, he created the software and is responsible for its quality, conducting tests and obtaining positive API verification. It is also possible

This is why hybrid manifests were introduced. Registration of such a manifest proceeds in the following steps:

1. The 3rd-party provider authorises HEI to register manifests with the name of this provider.

2. HEI registers the manifest providing its location (URL).

When a hybrid manifest is registered, the system checks:

• Whether the provider selected on the webpage has authorised this HEI.

• Whether the name of the provider selected on the webpage maches the name from the manifest.

• Is the SCHAC given in the manifest the same as the SCHAC of this HEI. If this condition is not met, the manifest is tagged as auxiliary and must be approved by the admin (HEI may use the Admin confirmation requested option for such a manifest).

Hybrid manifests with the attribute auxiliary were introduced so that HEIs could introduce (in the DEV network) test manifests with SCHAC codes outside the domain provided by MyAcademicID. For example, the HEI hei.edu.pl can enter the test1.hei.edu.pl and test2.hei.edu.pl manifests on the DEV, available in two local installations, in order to exchange data between these installations. In the PROD network, it will install one manifest with the SCHAC code hei.edu.pl.

Manifests with the attribute auxiliary are displayed on the webpage as SCHAC1 (SCHAC2), where SCHAC1 is the code of the HEI registering the manifest and SCHAC2 is the code of the HEI specified in the manifest. Only the SCHAC1 HEI can see and manage this hybrid manifest.

The auxiliary attribute may appear in the context of hybrid manifests, but also for manifests introduced in the DEV network by in-house providers.

Hybrid manifests are similar to in-house manifests in the sense that in both cases the manifest is uploaded by HEI. The difference is that the provider is:

• the in-house system provider (HEI) – in the case of in-house manifests,

• the 3rd-party provider who authorised the HEI – in the case of hybrid manifests.

When HEI registers a manifest, the system checks:

• The name of the provider and, for a hybrid manifest, whether the provider with the name given in the manifest has authorised HEI for using their software.

• SCHAC, and if the SCHAC specified in the manifest is different from the SCHAC of this HEI, the manifest receives the attribute auxiliary and must be approved by the admin (HEI may use the Admin confirmation requested option for such a manifest).

Granting permissions

For the entered SCHAC, data is retrieved from the HEI API, therefore the HEI must exist in the HEI API. A notification is sent to HEI.

Removing permission

Hybrid manifests based on this permission are deleted. A notification is sent to HEI.

Updating manifest’s status on demand

The Update operation is available on the Manifests webpage. You must click the checkbox next to one or more manifests. A set of operations will appear above the list. Among them is Update.

If the manifest fails to download, the status changes to Invalid and the system does not update the manifest data.
If the manifest is successfully downloaded, the date is updated, validation is performed as when registering the manifest and the system updates the fields accordingly. In particular, the status may change from Invalid to Valid or vice versa.

Periodical check of the manifests' status

The system validates and verifies manifests when they are registered, and also periodically:

• If the manifest is not reachable for a long time, or it does not parse according to XSD, or the name is not correct, it may get the Invalid status (depending on the system parameters).

• If the manifest contains unverified APIs, it gets the Unverified status.

A change to Invalid status is controlled by the parameters:

• MANIFEST_FETCH_WARNING_LIMIT = # days – after how many days to start warning that the manifest could not be downloaded (set to 7 on the network).

• MANIFEST_FETCH_INVALID_LIMIT = # days – after how many days to switch to Invalid (in the network it is set to None – never).