...
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
...
In the Registration Portal the manifests which are Confirmed, Verified, Enabled, and Valid are shown as Active, otherwise as Inactive.
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 gets the Invalid status.
...
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. This is why hybrid manifests were introduced. Registration of such a manifest proceeds in the following steps:
The 3rd-party provider authorises HEI to register manifests with the name of this provider.
HEI registers the manifest providing its location (URL).
When a hybrid manifest is registered, the system checks:
Whether the provider with the name given in the manifest has authorised HEI for using their software.
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.
The Update operation performs the same validations that are carried 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 or during periodical check and sets the status of the manifest according to the validation resultssystem 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).
...