Learning Agreements (LA)

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

MEDIUM

Clients should use some locking mechanism to prevent duplicate requests from happening. Servers should send CNR notifications after all changes.

Monitoring system

In PROD at least 8 providers returned 409, but it's hard to tell how many actually had a problem.

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

Critical

Enforce absolute compliance with the specification

Monitoring system

At least 2 providers in PROD, at least 1 provider in DEV

Also shared in email correspondence with providers

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.

MEDIUM

Enforce absolute compliance with the specification

Monitoring system

At least 3 providers in PROD, at least 3 providers in DEV

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.

Critical

Enforce absolute compliance with the specification

From the experience of UW (3 partners)

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. 

LOW

Enforce absolute compliance with the specification

Reported by a customer of the provider