Date: Fri, 29 Mar 2024 06:42:10 +0000 (UTC) Message-ID: <228954257.111.1711694530095@debian.example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_110_500239952.1711694530094" ------=_Part_110_500239952.1711694530094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Erasmus Without Paper (EWP) initiative promises Higher Educati= on Institutions (HEIs) to exchange information in the context of student mo= bility swiftly and securely. To do this, it uses digital technology to pave= the way to manage mobilities more efficiently. But what does this mean? An= d how does it work? Let's look under the hood of the EWP Network at o= ne of the core components, the so-called Application Programming Interfaces= , shortly referred to as APIs.
APIs are mechanisms that enable two software components to communi= cate with each other. Compare it with how you order in a restaurant. To ord= er food from the kitchen, you rely on the restaurant staff. They provide th= e menu (with the available food and beverages), you use them to request you= r order from the chef and they deliver your order at the table. Behind the = scenes =E2=80=9Cdata=E2=80=9D is exchanged between you and the chef.=
This is similar to how APIs collect and provide data between two s= ystems. You request data from the EWP network, or use the API to send data = in the form of an interinstitutional agreement (IIA) or learning agreement = (LA) to another HEI / user that is connected to the network. In this case, = all systems can communicate with each other via the EWP network. Developers= implementing your mobility software need to connect their system to the sy= stem of your partners using APIs.
For this to work, it is crucial to share the information in a =E2= =80=9Ccommon data structure=E2=80=9D. This is because it allows sharing dat= a that all systems can recognise and translate it back to their own data st= ructure. Imagine a mobility that starts on the first of May 2023. One syste= m may use the dd/mm/yyyy format for dates while the partner is using mm/dd/= yyyy. The difference in format entails a difference of 5 months for the sta= rt of this mobility: 01/05/2023 vs 05/01/2023. How is this done? APIs use a= set of definitions and protocols to make sure they =E2=80=9Cspeak the same= language=E2=80=9D and share information in the same format.
The EWP Consortium provides the API specifications, which describe= what data should be exchanged and what actions are required from the partn= er to be able to work with a specific data set (for example, the API specif= ications are different for the IIAs and LAs API). It is up to the organizat= ion managing the local software (this can be a third-party provider or your= university's IT department) to develop the business processes on what shou= ld happen with the data retrieved via the EWP network. This is part of what= is called =E2=80=98the local implementation'. To make sure the processes a= re tailored to the needs of its end users, development teams providing the = mobility software should cooperate closely with the International Relations= Office (at a central or faculty level).
To optimize the exchange of data, some important decisions are mad= e at network level. For example, in case of the learning agreement (LA) it = was decided that the student and the sending HEI should first approve an LA= before the receiving HEI can either approve the LA or reject it with comme= nts. These decisions impact which data is exchanged and what actions are re= quired from the partner for that specific process (IIAs, or LAs).
The impact of such decisions taken at the level of EWP cannot be u=
nderestimated. That is why there is a chain of actors involved in the desig=
n of APIs. First, there is the development team of the University of Warsaw=
who are responsible for the API specification. They rely on DG Education a=
nd Culture for the main programme document templates (determining what info=
rmation is required). Secondly, there is the Business Process Owner forum w=
ho are specialists when it comes to mobility processes. A third important a=
ctor is the Infrastructure Forum where developers discuss several design op=
tions. Many discussions are also happening online via the GitHub forum for =
developers. In all these discussions the European Commission takes part as =
well.
Changes to existing APIs that are already implemented by many HEIs= and software providers, are to be avoided as much as possible. For each ch= ange in the API everyone using these APIs need to modify their implementati= on, resulting in a lot of work and potentially new errors. Changes are only= considered to add new essential functionalities and improve the mobility p= rocess. An example of an idea that is currently under discussion, has to do= with the possibility to change an existing IIA (which is not possible now)= . To make that possible, developers are examining the best technical soluti= ons to modify approved agreements. In the near future, such functionality w= ill be rolled out, both at the level of the network and at the level of the= local implementation.
Now how can you participate in these discussions? First of all you= can join the Business User Groups= and share your suggestions via this channel. Secondly you can suggest a ch= ange or improvement via <= /span>the ESCI Service Desk. And finally, you can al= so get in touch with your development team who can bring up issues via GitH= ub or at the Infrastructure Forum.
Join the business user groups and follow us on LinkedI=
n and Twitter=
for regular updates.