Child renewal strategy

[Belenchusky]

We are having problems with some universities, using MoveOn e.g., that want to renew their agreements mobility by mobility. They have decided to use a “child” renewal strategy over the “parent” one. We think that this “child over parent” decision could have a negative impact on the working environment of EWP and the whole philosophy behind the digitalization of the Erasmus+ program.

Allow me to elaborate: Using a "parent" relationship means to use a common ground agreement containing all the “child” agreements in the same lot. That was the de-facto way of working with the physical IIAs for the last decades. For example, a parent agreement could look like this: Agreement 1

Type of Mobility IN (partner to UAL) or OUT (UAL to partner) Study Cycle Area code (ISCED) § Area name Number of mobilities Period Total Language requirement

SMS IN 1st Cycle/Undergraduate 0511 Biology 2 10 Months 20 Spanish B1 English B1 SMS OUT 1st Cycle/Undergraduate 0511 Biology 2 10 Months 20 German B2 STA IN N/A No ISCED code, see note 1 7 Days 7 Spanish B2 English B2 STA OUT N/A No ISCED code, see note 1 7 Days 7 French B2

Using the “child” option means that agreements are defined individually by the type of mobility (SMS, STT or STA), the direction (incoming/outgoing) and the discipline (the ISCED code). Applying this strategy to the previous example, the result would be this:

Agreement 1 SMS IN 1st Cycle/Undergraduate 0511 Biology 2 10 Months 20 Spanish B1 English B1 Agreement 2 SMS OUT 1st Cycle/Undergraduate 0511 Biology 2 10 Months 20 German B2 Agreement 3 STA IN N/A No ISCED code, see note 1 7 Days 7 Spanish B2 English B2 Agreement 4 STA OUT N/A No ISCED code, see note 1 7 Days 7 French B2

In this example, a rather small IIA is transformed into 4 IIAs.

To put things into perspective, if we at UAL (a medium size university) used a “child” strategy for SMS and SMA mobilities, our partners and us would have to sign over 2000 agreements, compared to the 373 we would use with a “parent” one. In addiction, some forms developed previously to EWP to manage agreements lose their functionality.

While we understand that a middle ground is sometimes necessary (for example, universities where agreements are signed at faculty level should use a child strategy within those units), this situation provokes a scenario where the management of information is done unnecessarily more complex and time-consuming, which partially defeats the purpose of EWP.

We therefore propose that some kind of logic limitation is implemented on the “child” strategy, at the same time as

Therefore, we propose that some kind of logical limitation be implemented in the “child” strategy, which will allow us to have a standard because some universities refuse to renew agreements with more than one mobility per agreement.

We understand that the API should be used with the same criteria with which paper agreements are signed.

[sascoms]

As well as I remember from a meeting with an HEI using MobilityOnline, they had to send incoming and outgoing mobilities as separate IIAs. As this issue would be a good place to confirm this, @georgschermann is it the case with MobilityOnline or is it just the HEI preference?

[umesh-qs]

Not sure how this forum can help here. Each university has the flexibility to decide their own agreement structure. This has to be sorted out between the universities in partnership.

[Belenchusky]

@umesh-qs Maybe taking away some flexibility from the API so that it does not allow doing things that detract from what is an agreement and its correspondence with the template.

I think the flexibility that you mention that each university has is not such. It is rather the Information System that they use that forces them to do that because those same universities previously EWP renewed their agreements with parents strategy. However now they cant´t because each agreement has to be categorized as IN or OUT and STA or SMS, so when I send them an agreement with more than one mobility , they can't approve it because their system can´t. So what do we do now? The renewal of an agreement is blocked due to this problem and that is why I report it.

[jiripetrzelka]

In case our IIA can be represented by multiple partner IIAs then I suggest to change the maxOccurs attribute of the iia-id and iia-code parameters to unbounded so that we can keep track of all the partner IIAs that correspond to our copy of the IIA: https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/stable-v6/endpoints/get-response.xsd#L99

I understand that we too have the flexibility to not divide our copy into multiple agreements and that if the partner does it then their system will still offer their end users the option to approve our copy as a whole and that partner coordinators will not exert pressure on our coordinators with the demand that our copy should be divided too because their system cannot otherwise handle the approval of our copy.

[umesh-qs]

@Belenchusky .. Not sure if you are referring to MoveOn or some other system. In MoveOn there is no such restriction. Our clients can choose to create IIA as per their requirement. They can choose to have one or many cooperation conditions in the same agreement. Also, if at all there is an issue as you mentioned, it cannot be solved at this level. Please have your partner approach their service provider.

I have not understood in what sort of flexibility can be taken away in the API. Rather I would second the suggestion given by @jiripetrzelka to give more flexibility in terms of linking one IIA to multiple partner IIA in the API.

[Belenchusky]

@umesh-qs Thanks for the clarification. It must be a misunderstanding on my part.

[Belenchusky]

@umesh-qs I have just to receive new information from collegues from de University of Cadiz. They are having the same problem as me. This is as extract from Universities Pázmány Péter Katolikus Egyetem de Budapest y la Freie Universität de Berlin respectively:

"Please note that the systems, unfortunately, all work different. In Moveon we need to create one iiA for each flow, so e.g. SMS in, SMS out, STA in, STA out. Do you have a way to work on the drafts I send and finish them?"

"Since we are using Mobility Online for the purpose of renewing the IIAs, we need to upload the agreements by ISCED codes, and we manage them separately regarding ISCED code, mobility type and direction. Unfortunately, we cannot merge this agreements into one, since in that case we could not handle them. "

Finally it seems that the problem is in how some Information System are using the APIs.

I thought it was important to share it in this forum. However, both universities have reported the problem to the Digital Officer of Spain to bring it to the attention of DG EAC and EUF.

Thank you.

[sascoms]

I think this last comment and messages confirm the workflow on MobilityOnline that I mentioned in my previous comment.

[gig2kor]

Well there is some elements of how each system works affects the usage and data share. In MoveON, it is ensured that users can have multiple options at the same ensure the normal current processes within MoveONfollowed by users are still available.

MoveON allows sharing each cooperation conditions as IIAs (multiple IIAs) or all combined (single IIA) with partners. It is upto the users and their partners how they would like to manage it. I suppose Universität de Berlin is not yet aware of it.

[jiripetrzelka]

We experienced the above mentioned issue with Mobility Online too. It seems that their system divides each IIA of ours to up to 8 IIAs (SMS/SMP/STA/STT, IN/OUT). And what is more, each of these 1 to 8 IIAs contain the entire contents of the original IIA. Some of these 1-8 IIAs have identical hashes, while some have different hashes because they have a different order of the mobility specifications (but otherwise the contents is the same). As for the partner iia-id value, each if these 1-8 IIAs contain our IID ID so a N:1 relation is established, which I think is against current specification, which assumes that there should always be a 1:1 relation.

[umesh-qs]

We experienced the above mentioned issue with Mobility Online too. It seems that their system divides each IIA of ours to up to 8 IIAs (SMS/SMP/STA/STT, IN/OUT). And what is more, each of these 1 to 8 IIAs contain the entire contents of the original IIA. Some of these 1-8 IIAs have identical hashes, while some have different hashes because they have a different order of the mobility specifications (but otherwise the contents is the same). As for the partner iia-id value, each if these 1-8 IIAs contain our IID ID so a N:1 relation is established, which I think is against current specification, which assumes that there should always be a 1:1 relation.

Current specification does not mandate 1:1 mapping, not sure how this conclusion was made. As I mentioned earlier each university is free to decide their own IIA structure and there will be situations where 1:N or N:1 case will arise due to the approval hierarchy followed by each institution.

[jiripetrzelka]

I made the conclusion based on the current maxOccurs attribute of the iia-id element:

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/cdecc5eae6233335646d13efae158e3a22cf4ce9/endpoints/get-response.xsd#L99

If N:1 and 1:N were allowed, then maxOccurs would have been set to unbounded. Otherwise we cannot comply with this requirement: "If this server is aware of the IDs used by the other partners, then it MUST output it here". We are aware that our IIA is represented by multiple IIA IDs of partner, yet we cannot "output them here" without breaking the XML schema.

In the case of universities with which I tested the division of IIAs was not a result of their organisational structure nor their decision but the result of Mobility Online not allowing anything else.

And to be clear, I'm speaking about Mobility Online importing our IIA - this causes the duplicates. In case partner initiates the process then the IIAs are divided too but each IIA correctly contains just one part of the specification (e.g. SMS OUT, SMS IN, etc.)

[umesh-qs]

Well you might argue on implementation point of view. But the point your are referring from the spec does not say that I cannot pass same partner IIA for N IIAs generated by me. All it says that if I know related IIA, I should pass it. We already had mentioned earlier is that allowing unbounded will make this easier.

Also, is your concern pertains to handling of IIA by "Mobility Online" or handling of 1:N mapping in general? Please separate these 2 so that we can provide inputs accordingly. It would not be right for us to comment on how things work at "Mobility Online"

[jiripetrzelka]

The specification says MUST, not SHOULD pass it - that is a difference.

I’m primarily interested in the generic problem. I mention specific issues with Mobility Online to illustrate it on a specific example.

[umesh-qs]

ok, it is MUST, but the point remains the same. It doesn't restricts 1:1 mapping. You can still pass the same partner IIA ID.

From your comments it looked like you were focused on only allowing 1:1 mapping. But I guess you agree that there can be scenarios for 1:N mapping. As I have mentioned earlier it can only be solved by allowing more than 1 IIA ID in the second partner section.

[jiripetrzelka]

No, I can't. If my IIA 123 is divided into IIAs 456 and 789 by partner then their GET endpoint is ok because they just list: For IIA 456: first partner/iia-id: 456, second partner/iia-id: 123 For IIA 789: first partner/iia-id: 789, second partner/iia-id: 123

But I have to list: For IIA 123: first partner/iia-id: 123, second partner/iia-id: 456 AND 789 , which means:

<iia-id>456</iia-id>
<iia-id>789</iia-id>

So my GET response is invalid because I have exceeded the maxOccurs attribute for iia-id.

And at the same time I MUST NOT omit the iia-id if I'm aware of partner's IIA IDs. I therefore cannot fulfill the schema requirements because it asks me to do two mutually exclusive things. Therefore the initial assumption that 1:N and N:1 relations are allowed by the schema is falsified and therefore only 1:1 relations are allowed by the schema.

To remove the logical contradiction, it is necessary to:

• Either change the word MUST to SHOULD OR
• Change the maxOccurs to unbounded.

The first approach would mean that 1:N/N:1 relations are implicitly tolerated, while the second approach would say explicitly that it is a valid use case. I'm for the second change. I understand that business processes require that the schema accommodate 1:N/N:1 relations. But I think we should also ask whether this approach is ok legally. Who can decide this? The designers of the API?

[Belenchusky]

I fully agree with @jiripetrzelka that the current specification only allows 1:1 relations in IIAS. Futhermore, I don't understand why APIs have been used differently to make signatures in EWP different from how they were done on paper.

[umesh-qs]

No, I can't. If my IIA 123 is divided into IIAs 456 and 789 by partner then their GET endpoint is ok because they just list: For IIA 456: first partner/iia-id: 456, second partner/iia-id: 123 For IIA 789: first partner/iia-id: 789, second partner/iia-id: 123

But I have to list: For IIA 123: first partner/iia-id: 123, second partner/iia-id: 456 AND 789 , which means:

<iia-id>456</iia-id>
<iia-id>789</iia-id>

So my GET response is invalid because I have exceeded the maxOccurs attribute for iia-id.

And at the same time I MUST NOT omit the iia-id if I'm aware of partner's IIA IDs. I therefore cannot fulfill the schema requirements because it asks me to do two mutually exclusive things. Therefore the initial assumption that 1:N and N:1 relations are allowed by the schema is falsified and therefore only 1:1 relations are allowed by the schema.

To remove the logical contradiction, it is necessary to:

• Either change the word MUST to SHOULD OR
• Change the maxOccurs to unbounded.

The first approach would mean that 1:N/N:1 relations are implicitly tolerated, while the second approach would say explicitly that it is a valid use case. I'm for the second change. I understand that business processes require that the schema accommodate 1:N/N:1 relations. But I think we should also ask whether this approach is ok legally. Who can decide this? The designers of the API?

Your partner would already have tied your 1 IIA internally to the 2 IIAs they have. So passing any 1 should be sufficient for your partner to connect the IIAs. Your partner will have to deal with this. There is no violation of the specs. But as I said earlier, having maxOccurs would be ideal.

[kamil-olszewski-uw]

Please allow me to provide a "historical perspective" on the issues discussed here.

At the very beginning of the EWP project, when the electronic exchange of IIAs was not mandatory and the previous edition of the Erasmus+ was functioning, the Interinstitutional Agreements API was designed to reflect IIAs written on paper based on an official template. These were only agreements 1:1, and how they were later modeled in the systems of individual universities, did not matter for their partners.

In a similar vein, the Interinstitutional Agreements Approval API was developed, which at the time of its creation was not yet used as equivalent of "electronic signing" of IIAs, but for mutual confirmation that the systems of both universities contain what was signed on the (then mandatory) paper.

However, a new edition of Erasmus+ has started, the use of the IIAs API has become mandatory and the paper is not to be used. There were some voices from European universities (including important partners of subsequent projects) that such a classic way of formulating IIAs, i.e. 1:1, is inconvenient, because each university may have its own IIAs granulation, resulting from system limitations or business habits.

I have always found the 1:1 model to be the most convenient, readable and the least error-prone. And I still think that it would be best to hide the IIAs granulation in each university system from partners and to generate agreements 1:1 at the EWP level, and then, if necessary, arrange the data in our system according to our preferences, but with the possibility of immediate indication of which data in the system correspond to the data in the agreement bilaterally signed via EWP. Please take it as my personal opinion though :-)

At some point, the option was passed that the IIAs data for each partner may have different granulation, e.g. a 1:N relationship will be acceptable (e.g. there are universities that want to have one IIA for each partner, or universities that want to have one IIA for all cooperation conditions). Of course, this makes data exchange difficult, and indeed the phrase "If this server is aware of the IDs used by the other partners, then it MUST output it here" should perhaps be more mild.

Changing maxOccurs of iia-id to unbounded might not be that easy. Perhaps this would work well if we were dealing with 1:N or N:1 relationships (but I wouldn't want to be in the position of an IRO worker who needs to download and identify N IIAs and assign them to his/her one IIA). But there can also be N:N relationships (e.g. when one university divides its IIAs by ISCED codes and another university divides its IIAs by faculties). In that case, some (but not all) of the cooperation conditions of our IIAs will match some (but not all) of the cooperation conditions of partner's IIAs.

All of this makes the two-sided approval of IIAs very difficult (and even makes it impossible in the current form of API). Therefore, the idea was born that it would be possible to approve IIAs one-side only - that is, the university that first entered the IIA into its system could automatically be considered one that approved this IIA.

[jiripetrzelka]

Can you please elaborate on the last paragraph and provide a step by step workflow for the negotiation/signing process for a new agreement similar to https://github.com/erasmus-without-paper/ewp-specs-api-iias/tree/stable-v6/example-scenario ?

[kamil-olszewski-uw]

Both partners may agree that having the signature date(s) from both sides is enough to complete the IIA and end the data exchange (no steps 7 and 8).

@pleys, you were in favor of IIAs being asymmetrical. How are you dealing with your partners now?

[martincharlier]

At Lund University we have also been facing some of the issues described in this thread, ie that we are receiving multiple IIAs from the same partners (MoveON or Mobility-Online users) in our information system SoleMove, even though those "IIAs" are just different cooperation conditions for the same IIA.

I am strongly in favor of having flexibility with the cooperation conditions within one IIA, our version does not need to completely match our partner's version. However, I am unsure of the benefits of splitting one IIA into several IIAs for SMS in, SMS out, STA and so forth... At least at Lund University, we have always reasoned according to the 1:1 principle. What would an HEI gain in creating and signing 4-6 IIAs instead of a single one?

Example where flexibility is needed: one IIA with Partner B has three ISCED: 0222, 0233 and 0288. We do not wish to divide the number of available exchange spots/months per subject area, but our Partner does. So their version of the IIA looks slightly different than ours.

We currently have 10 IIAs with Utrecht University (from the previous E+ period). If Utrecht uses MoveON or Mobility-Online, it means that we will have to deal with 40-60 IIAs coming from the same partner. Different IROs will have to identify "their" IIAs and sign each cooperation agreement with that partner. It will create a lot of confusion. The higher the complexity, the higher the workload and the risk of signing an IIA containing errors.

All of this makes the two-sided approval of IIAs very difficult (and even makes it impossible in the current form of API). Therefore, the idea was born that it would be possible to approve IIAs one-side only - that is, the university that first entered the IIA into its system could automatically be considered one that approved this IIA.

@kamil-olszewski-uw I am not sure that I agree with this idea. Since there are distributed versions of one IIA, it is crucial for an IRO to be able to trust that the partner will have a similar (but not necessarily identical) version of the IIA signed and stored in its information system. It is therefore essential that IROs are able to send IIA CNR notifications to partners (and vice versa) in order to make sure that what has been agreed upon via mail/elsewhere is reflected in both parts' information systems. In other words, both parts need to compare and control both versions before sending their approval and signing the IIA.

[jpbacelar]

Thank you all for the comments and discussion on the parent-child issue. This discussion went well beyond the scope of the IIA template and corresponding API, so we felt it was necessary to look into detail of what was being proposed, as well as to give careful consideration to the feedback of the business process owners.   The current specification only foresee IIA exchanges taking place in a 1:1 logic, and the analysis that was carried does not recommend adding support for parent and child agreements; the business process risks this would engender clearly outweigh possible benefits.   Two useful considerations that may help you in the design of your systems:   a) Please bear in mind that each HEI/IRO should be able to choose whether they submit an IIA with one or many cooperation conditions to their partners, who in turn will be able to accept/reject them. Systems who do not support multiple CC are strongly encouraged to do so, to avoid an explosion/fragmentation of the number of agreements in circulation; having to approve many more agreements than what would normally be required does not constitute an efficiency gain but a big step backwards, as pointed out by Martin.    b) each SIS is free to process received IIA data as they see fit. The manner in which data is processed is beyond the purview of EWP, but it’s important that such processing does not eventually compromise interoperability. Accordingly, IIA needs to remain structurally consistent and properly identified during the exchange process, regardless of how systems process and handle information internally.

In the future we would propose to distinguish more clearly between discussions where existing specification might not be clear to all, from discussions about supporting new processes or ways to improve existing APIs. In the case of parent-child topic this clearly goes beyond what the API can/should specify, but these precisions will nonetheless be added to the API descriptions. As always, developers are kindly invited to read the latest specification and ensure their implementations adhere to them as closely as possible.

[georgschermann]

I just want to add a few clarifications on the Mobility-Online way of (currently) handling IIAs.

@sascoms assumption is mostly correct. The limitation to separate IN / OUT agreements was recently added in the context of EWP to prevent some issues which sometimes needed to be manually resolved. When creating EWP agreements they are currently 1:1 matched from local agreements and not summarized. Imported EWP agreements can still contain all sorts of coop conditions an are transparently mapped to local agreements. So the same agreement would be represented in e.g. 10 iias when created in Mobility-Online but maybe only 1 iia when created in another system and maybe e.g. 4 iias in yet another system.

The issue @jiripetrzelka mentions, that there are 8 iias representing the same 1 iia on their side is correct, but only one of these iia-ids should have been exposed via the cnr / index endpoints, if there were all 8 exposed then this is an error in the respective system we are currently not aware of (if so please contact me with more information to resolve this). If the system works correctly, only one iia-id is exposed matching the partners agreement and consistent coop-condition order/hash, changes to any of these 8 agreements result in a cnr, signing/approval is only possible for all 8 at once.

Generally there are several levels of parent - child relations in agreements which can be freely configuered in the system, some of them are relevant in the EWP context.

"Agreement groups" (like super agreements) can contain all kinds of agreements between two partners - several IN/OUT, ISCED Codes, SMS/SMT/SMP/++, Years, etc. EWP IIAs which can contain as many local agreements as needed to represent all coop-conditions. Local agreements which correspond to 1-2 coop conditions (only 1 if created in the context of EWP - IN/OUT splitted)

The 1:1 IIA relation was agreed on during specification, with the 1:N mapping (if needed) to be done in the local systems, as it is the case for us. We don't think that a 1:N relation would be beneficial in the specification. A colleague suggested to add coop-condition-ids to be able to easier match them internally if needed (especially if several coop-conditions are changed at once and keeping track of them is not automatically possible). This would ease the mapping process for 1:N relations, but we currently went for another solution internally to solve some partner specific issues in this context.

Some of the IIA processes / user interactions are currently worked on to allow HEIs e.g. to release multiple local agreements as one IIA and generally allow for a bit more freedom in their processes like signatures vs. approval, non-mapped agreements, ...

[umesh-qs]

I just want to add a few clarifications on the Mobility-Online way of (currently) handling IIAs.

@sascoms assumption is mostly correct. The limitation to separate IN / OUT agreements was recently added in the context of EWP to prevent some issues which sometimes needed to be manually resolved. When creating EWP agreements they are currently 1:1 matched from local agreements and not summarized. Imported EWP agreements can still contain all sorts of coop conditions an are transparemently mapped to local agreements. So the same agreement would be represented in e.g. 10 iias when created in Mobility-Online but maybe only 1 iia when created in another system and maybe e.g. 4 iias in yet another system.

The issue @jiripetrzelka mentions, that there are 8 iias representing the same 1 iia on their side is correct, but only one of these iia-ids should have been exposed via the cnr / index endpoints, if there were all 8 exposed then this is an error in the respective system we are currently not aware of (if so please contact me with more information to resolve this). If the system works correctly, only one iia-id is exposed matching the partners agreement and consistent coop-condition order/hash, changes to any of these 8 agreements result in a cnr, signing/approval is only possible for all 8 at once.

Generally there are several levels of parent - child relations in agreements which can be freely configuered in the system, some of them are relevant in the EWP context.

"Agreement groups" (like super agreements) can contain all kinds of agreements between two partners - several IN/OUT, ISCED Codes, SMS/SMT/SMP/++, Years, etc. EWP IIAs which can contain as many local agreements as needed to represent all coop-conditions. Local agreements which correspond to 1-2 coop conditions (only 1 if created in the context of EWP - IN/OUT splitted)

The 1:1 IIA relation was agreed on during specification, with the 1:N mapping (if needed) to be done in the local systems, as it is the case for us. We don't think that a 1:N relation would be beneficial in the specification. A colleague suggested to add coop-condition-ids to be able to easier match them internally if needed (especially if several coop-conditions are changed at once and keeping track of them is not automatically possible). This would ease the mapping process for 1:N relations, but we currently went for another solution internally to solve some partner specific issues in this context.

Some of the IIA processes / user interactions are currently worked on to allow HEIs e.g. to release multiple local agreements as one IIA and generally allow for a bit more freedom in their processes like signatures vs. approval, non-mapped agreements, ...

On a separate note having unique id at cooperation condition level will also help in tying total seats available to each cooperation condition (internal child relation) as asked earlier in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/29

[janinamincer-daszkiewicz]

This issue has been discussed during the Infrastructure Forum on 2022-04-06. Participants voted for the 1:1 logic and matching identifiers.

This is the proposal of description which would be added to the IIA specification:

1. Electronic versions of IIAs should model their former paper equivalents in a straightforward manner.
2. Two HEIs sign one or several IIAs with one or several cooperation conditions.
3. Specifications support IIAs with many cooperation conditions and each node in the network must be able to handle such IIAs to achieve this goal.
4. Both copies of the same IIA stored in both partners' systems must be presented to each other as exactly one IIA having the same number of corresponding cooperation conditions.
5. Partners should exchange identifiers of their copies of the IIA to match these copies respectively in their systems.
6. Regardless of whether or not a field is mandatory in the API, if it is present in the IIA of one HEI it should also be present in the matched IIA of the partner HEI.
7. Providers are free to implement their local solutions to best support the needs of their customers but under the condition that the general principle expressed in the points above is maintained.
8. It may happen that in time the signed IIA needs to be terminated, extended or modified for good reasons. Future changes in specifications will support such needs.

[janinamincer-daszkiewicz]

Done

[demilatof]

We still stuck on this point, as I wrote here: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/94 Have you finally solved the problem? Are you adopting the 1:1 logic or what else?