Should Omobility LA CNR be mandatory?

[janinamincer-daszkiewicz]

Continuation of the discussion on the families of APIs carried during the Infrastructure Forum.

Omobility LA CNR

Comments

1. Omobility LAs MUST be implemented by the sending HEI.
2. Sending HEI gets the answer to Omobility LAs from the receiving HEI by update, not CNR.
3. Omobility LA CNR MUST be implemented by the receiving HEI.
4. Receiving HEI gets the Omobility LA from the sending HEI by Omobility LA get.
5. Statistics

• https://stats.erasmuswithoutpaper.eu/filter/?discovery=implemented&omobility-las=implemented&omobility-la-cnr=not_implemented
• https://stats.erasmuswithoutpaper.eu/filter/?discovery=implemented&omobility-las=not_implemented&omobility-la-cnr=implemented

7. See also Families of APIs general-issues#46

Question

• Do we want to require CNR for LAs from the sending HEI even when we already have update?
• Do we want to require from each HEI to be ready at the same time to enter the network as the sending partner and as the receiving partner?

[AlesHal]

Situation is a bit different than nominations (Omobility/Imobility API - erasmus-without-paper/ewp-specs-api-omobility-cnr#4 (comment)) that there is no Imobility LA API. This functionality is ensured by the update endpoint.
So implementing Omobility LA CNR API should be mandatory for the receiving HEI only, so it can be notified that there is a new LA for it. Sending HEI should implement Omobility LA API update endpoint (as well as other endpoints) to be "notified" about the approval/rejection of LA. Receiving HEI should only be able to send update endpoint requests (and receive update responses).

If there are institutions that only send students abroad and don't accept any incoming students (and this is considered as a valid and accepted behaviour) then there is no need for them to implement Omobility LA CNR API. But if an institution wants to accept incoming students via EWP, it should implement OM LA CNR API.

This is again how it makes sense to us so no manual human work (e-mailing, phone calling etc.) is needed to start a mobility process without a need of a checking partners periodically via index endpoint.

[lsanchezpe]

In my opinion, it doesn't make sense to have an api without having its CNR. The only way to work without CNR is by periodically checking partners index endpoint and this is somthening we need to get rid of it.
Moreover, if you work with index API checking, you can go to cnr by doing practically the same you are doing rigth now and adding a couple of adjustments.

There have past years since CNR become higly recommendend and i think its time to make it a must in order to make the network smooth,

[janinamincer-daszkiewicz]

In this particular case we have update, do we still need CNR? Let me reformulate this requirement in the following way:

1. Sending HEI MUST implement Omobility LAs (index, get, update).
2. Sending HEI gets the answer to Omobility LAs from the Receiving HEI by update, not CNR.
3. Receiving HEI MUST implement Omobility LA CNR.
4. Receiving HEI gets the Omobility LA from the Sending HEI by Omobility LA get.

Questions

1. Do we want to implement CNR at Sendning HEI for LAs even when we already have update?
2. Do we want to require from each HEI to be ready at the same time to enter the network as the Sending partner and as the Receiving partner?

[lsanchezpe]

Short answer, in my opinion yes to both questions.

Explanation:
I think we must ditinguish between answering a LA and detecting new o changed LAs.

As i understand, the update give us the capability of answer an LA, but the CNR is still needed to receive the LA or its changes in an operational way (and no with index scanning of the network).

I will go further, acording to specification, when i receive an update i should make a CNR in order to notify you i have a change in my LA. And this is also a solution for a comunication problem during the approving/rejecting process as described in erasmus-without-paper/ewp-specs-api-omobility-las#51

[janinamincer-daszkiewicz]

As i understand, the update give us the capability of answer an LA, but the CNR is still needed to receive the LA or its changes in an operational way (and no with index scanning of the network).

No scanning is needed. Receiving HEI of course implements CNR, but Sending HEI relies on update.

I will go further, acording to specification, when i receive an update i should make a CNR in order to notify you i have a change in my LA.

This is already covered by CNR on the side of the receiving HEI.