🚧 This project is currently being built and is not yet ready for use. 🚧
This Application exports important data from Munichs "kita finder +" and makes it available for further use.
"kita finder +" is an instance of "kita-planer" by netgo.
This project is built by it@M in cooperation with netgo based on the following technologies/frameworks:
- Java
- Spring Boot
- Maven
- Docker
- PostgreSQL
- Flyway
- ...
To start and test kitafinder-datenservice, you can simply download and run one of the pre-built packages. When running with Docker, first start the required infrastructure by running the docker-compose.yml.
When running from source the default spring profile 'local' uses Docker to start required infrastructure. This includes a postgres-database and sso instance. The configuration can be viewed in the stack directory.
Tries to connect to a kita-planer instance, queries it's data and persist it in the configured DB for further use. Without configured a kita-planer instance this module does not work!
The mimimum configuration to run this module are following properties:
- app.kitafinder.base-url: API-URL of the kita-planer instance to connect to.
- app.kitafinder.username: Username of the kita-planer API
- app.kitafinder.password: Password of the kita-planer API
Provides REST-endpoints serving the stored data. A local deployment of this module doesn't require additional configuration.
The batch-module performs its loading process in 3 steps:
- Load all Kindmappe ids
- Load all Kindmappe entities and generate events
- Clean up old data
The configuration for the kita-planer connection is defined under 'app.kitafinder.*'.
The first step is used to allow subsequent batching of calls made against netgos kita-planer. The IDs are persisted into the database. The ID-retrieval is batched and can be confugured using 'id-batch-size'.
The second step is also batched with an independent batch size configured in 'data-batch-size'. Kindmappen are loaded, events calculated and both stored in the database batch by batch. For detecting newly occured events, the last saved state of each domain object is used for reference.
In the third and last step old batch data is removed from the database as configured with 'cleanup-keep-age' and 'cleanup-keep-number'. Events are persisted forever and not affected by this step.
Domain-events are detected after exporting the kita-planer data and persisted into an outbox.
The outbox uses JSONB to store the full payload for events. This ensures we can retroactivaly check sent events, even after database schema changes.
🚧 Handling of events part is not part of it@Ms initial scope and not yet implemented. 🚧
🚧 This module is not part of it@Ms initial scope and only implemented rudimentarily. 🚧
The web-module provides a REST-service with endpoints to list and display child data. The OAuth2 security can be configured using the 'app.security' properties.
Contributions are what make the open source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated.
If you have a suggestion that would make this better, please open an issue with the tag "enhancement", fork the repo and create a pull request. You can also simply open an issue with the tag "enhancement". Don't forget to give the project a star! Thanks again!
- Open an issue with the tag "enhancement"
- Fork the Project
- Create your Feature Branch (
git checkout -b feature/AmazingFeature
) - Commit your Changes (
git commit -m 'Add some AmazingFeature'
) - Push to the Branch (
git push origin feature/AmazingFeature
) - Open a Pull Request
More about this in the CODE_OF_CONDUCT file.
Distributed under the MIT License. See LICENSE file for more information.
it@M - opensource@muenchen.de