(Project) Introduce Activities

1 Aim of Project

The aim of this project should sound familiar, as we already attempted something similar under the moniker Introduction of Service Discovery / Internal API alignment. This project is a new approach to a similar aim, with a slightly changed wording. At the time of writing, ILIAS has no discernible layer where we can find "Activites" with objects and facilities in the system. The project should improve in that regard, for various benefits. What do we mean with this sentence?

Initially, ILIAS was developed as a simple "CRUD"-style application, as witnessed by the create/read/update/delete-methods of ilObject. This simplistic view was abandoned long ago, and ILIAS got components known as "Services" that offer functionality internally to other components. Nowadays many of these services offer decent and well documented APIs to other components and we are on a good route to improve in that area.

But another area, where we would expect "APIs" have not been adressed until now. This is the area, that the Introduction of Service Discovery / Internal API alignment-proposal aimed to adress. While the internal "Services" provide APIs to other components, there are Activities within the system that happen on the domain layer of our application and that cannot yet be referenced and used explicitly. An Activity is understood to be a way in which a user wants to use our system. E.g.: Create a Course. Add Members to a Group. Make a Test available.

These examples, superficially, might look as if they could be mapped onto according calls on existing objects, such as ilObjCourse::create, ilParticipants::addMember or ilObjTest::setOnline. But in reality this is not the case. When users say they want to create a course, they do no only mean to programmatically "Create a ilObjCourse"-object. The object needs to be put in the Repository somewhere. Permissions need to be checked. Same for "Add Members to a Group". This is what the "Domain" of our software is, in difference to the programming that we use to implement that domain. Currently, the code of our software does not allow to encode Activities on the domain. Instead, they are encoded in some GUI that controls these activities or they are implicitly implemented via the concrete control flow that some request of a user takes. This is also the thing, that the Introduction of Service Discovery / Internal API alignment aimed to change.

Despite the slightly changed wording ("Activity" instead of "API"), the benefits are the same as they have been. Activities will

• offer a way to present a domain level API to other developers, webservices and end users in a machine-readable way.
• offer documentation in the ILIAS GUI for end users to take advantage of the available services e.g. in webservice integrations or workflow definitions.
• move APIs as back into the maintenances of the proper maintainers in a consumer-agnostic way.

This will improve our development processes as well and allow for new possibilities:

• Maintainers have better insight into changes to activities. Cross-communications with webservice-maintainers about changes are not required. A maintainer will be responsible for a domain level API to their component being available and properly working.
• New domain level API methods that allow interaction with the core will be in the control and responsibility of the affected components maintainer, making coordination and eventual subcontracting with a webservice maintainer unnecessary.
• Newly introduced consumers may take advantage of existing APIs without a duplicate effort to recreating existing means for their specific purposes.

2 Involved Maintainers and Stakeholders

• will be usable by every maintainer with a user facing component.
• Webservices such as SOAP can be switched to use Activities

3 Timeline

4 Related Feature Requests and Status

5 Further Results

• …

6 Additional Information

…

7 General Discussion

11 DEC 2023: For the product manager, the proposal is an exciting and ambitious proposal to improve interaction with ILIAS and drive its modularisation forward. As already mentioned by the TB, all ILIAS developers should be able to familiarise themselves with the concept and its implications at an early stage. The DevConf in March or September would be a good opportunity to present and discuss the concept in detail.