Exchanging data between different software applications may seem to be something fairly simple and straightforward, but this is generally not true. First of all, software applications use identifiers that are usually not compatible. For example, using the DNI as a key to identify people, we could establish a correspondence between their data in the different applications. But if the keys are not the same, for example, if each application creates its own codes, matching becomes impossible without hard and laborious manual work. Another obvious reason is that the relationships between the data and their internal structures are also application-specific.
Integrating data between different applications requires well-designed and documented interfaces through which data can be exposed and software can interact. There is no other way. But this condition, while necessary, is not enough. In addition to an interface, it must be possible to establish a correspondence between the codes used in the two applications to identify their data elements.
In the case of an application that makes a service request to another application, the first one must provide its keys so that it can interpret the result once it has been resolved. In other words, if an application requests a task to be solved, it must provide, through the common interface, in besides the information of the request itself, the necessary keys to understand the result it receives. Let us suppose an application that requests another application for a service to resolve an academic timetable. In this case, the resolved timetable should be expressed using keys so that the requesting application can recognise it. In this way it will be able to identify teachers, subjects, etc. in the solution. The agreement of formats and keys between the two applications must be precise for it to work and both parties must necessarily collaborate in this.
There are some applications that expose their own exchange interfaces without being fully operational, with design weaknesses that prevent the output from being received correctly. It is therefore necessary to implement well-defined and documented open interfaces for inter-application communication. In fact, there are standardisation organisms that establish them. Alternatively, open interfaces associated with consolidated products published for this purpose could be adopted as standards.
Peñalara Software has published the internal GHC storage format to be used as an exchange interface. The XML-GHC format is complete. Everything that is configured with the planner, as well as the results that GHC creates, can be expressed with this model.
In addition, along with the development of a new engine that we hope to offer soon as a remote service, we have open JSON interfaces that can be consulted through the public GitHub repository and are associated with development libraries also available, in this case, in Apache Maven. With this project we intend to offer services for the creation of timetables to the academic management application ecosystem, and thus ultimately facilitate the work of users.