Learning Agreements (LA)

Levels of estimated error severity.

If an error is present in the context of an API (or endpoint), it applies only to that API (or endpoint).

Critical	This severity level implies that the process always/usually works badly.
MAJOR	This severity level implies that the process works badly in some cases.
MEDIUM	This flaw results in unfavorable behavior but the system remains functioning.
LOW	This type of flaw won’t cause any major breakdown in the system.

List of identified issues in this category (click on the title to show details)

Description	This error doesn't always mean that there is a problem, it might be that users on both sides just tried to change something simultaneously. But if it happens often, there might be some issue that needs to be fixed. A typical problem on the client side is sending duplicate requests. A user might submit the form used to send the update request twice, either by mistake, or because the server was not responding and they were getting impatient. But only the first request may succeed, all other requests will fail with a 409 error. If the client's system is not prepared for that, the failure could overwrite the success and in the end the user will believe that the server didn't accept their update request. On the other hand, a typical issue on the server side is not sending CNR notifications after receiving successful update requests. This might be a problem if, for example, the server took a long time to process the request and the client timed out before receiving the response, assuming failure. The specification says: "Please note, that the sending institution SHOULD send this notification to you even when it is you who actually initiated the update (e.g. via the update endpoint of Outgoing Mobility Learning Agreements API)."
Estimated severity	MEDIUM
Examples
Suggested action	Clients should use some locking mechanism to prevent duplicate requests from happening. Servers should send CNR notifications after all changes.
How communicated	Monitoring system In PROD at least 8 providers returned 409, but it's hard to tell how many actually had a problem.

Description	The ESI field is required. This is what the specification says about the student's data: "Note: All fields are optional only inside `changes-proposal` element and required otherwise!".
Estimated severity	Critical
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system At least 2 providers in PROD, at least 1 provider in DEV Also shared in email correspondence with providers

Description	The problem occurs if a server sends a CNR notification about a new LA to the partner, but they are unable to download it, since the LA get response is empty as if the LA didn't exist. Servers should not send CNR notifications about an LA before it is accessible by the partner.
Estimated severity	MEDIUM
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system At least 3 providers in PROD, at least 3 providers in DEV

Description	The specification says: "The request SHOULD also contain a matching Content-Type header (such as text/xml).". It doesn't say that text/xml is the only acceptable option.
Estimated severity	Critical
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	From the experience of UW (3 partners)

Description	The provider reported incorrect number of LAs shared in the EWP network (“TOTAL” column) wrongly assuming that when LA is modified after approval its new version should be considered a new LA. A student can have only one LA per mobility, changes to this LA are considered different versions of this LA, not different LAs. For a given mobility identified by one omobility-id there should be only one LA, a number of mobilities should be equal to a number of LAs. According to Mandatory Business Requirements "Only one LA per mobility can be exchanged via EWP. This LA can have many versions". Mobility_id cannot change within one nomination/mobility. This is clearly stated in the word "immutable" in the description of the element. Also in the case of LA we have the word "immutable" in the omobility_id description, which in this case means that one LA cannot be shared by several mobilities.
Estimated severity	LOW
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Reported by a customer of the provider