Bosch RefinemySite is a cloud-based collaboration platform for the construction industry.
It involves all trades of a construction project at an early stage of the overall schedule and thereby includes all particular knowledge of all participants in an aligned schedule.
This method increases the stability of processes during execution, fostering a common understanding of all trades. The assigned work can be tracked within a continuous improvement workflow and all task can be documented.
All sources contained in this repository have been developed as part of Bosch RefinemySite project at Robert Bosch Power Tools GmbH.
RefinemySite is not being developed by Robert Bosch Power Tools GmbH any further.
⚠️ The sources are provided as is and are not actively maintained or supported in any way.⚠️
For building and deploying the sources provided here, a few (major) preparatory adjustments are necessary:
- Adjust repository references in build.gradle and settings.gradle files of all libraries and services to reflect your own packaging/artifacts solution like Azure Artifacts.
- Build and publish the backend libraries to your own packaging/artifacts solution.
- Adjust the dependency references for the libraries (name and version) as needed.
- Set up your own Identity Provider (IdP) and configure OAuth settings:
- in particular in csm.cloud.api configuration.
- in csm.cloud.common.core/src/main/resources/application-idp-bosch-dev.yml and csm.cloud.common.core/src/main/resources/application-idp-bosch-prod.yml.
- Implement your own notification endpoint integration (i.e. a web hook) in csm.cloud.project.notifications/src/main/kotlin/com/bosch/pt/csm/cloud/projectmanagement/user/facade/listener/UserEventListenerImpl.kt
- In csm.cloud.project.project and csm.cloud.user.user services, supply test image sources as needed or adjust the tests implementations instead.
- Adjust all Dockerfile files to use your own container image library or a public one instead.
- Adjust or replace all azure-pipeline.yml to suit your own build and deployment needs.
- In csm.web.app supply your own icons as SVGs in /src/assets/icons
- Set up a suitable infrastructure (with an AKS or other Kubernetes runtime and MySql and MongoDB databases as well as Azure Storage Accounts). The local deployment scripts in utilities/csm.cloud.dev/docker will give you a deeper understanding of the runtime environment needed.
The system is composed of the following parts:
- Frontends published under MIT license.
- Backend services and libraries published under Apache 2.0 license.
The architecture of the configured and deployed solution could look like this:
The diagram above depicts the coarse decomposition of the system with its backend services and most Kafka-based communication flows. All components are described below in more detail.
There are two web-based frontends. Both are built with Angular and deployable in an nginx-based container.
The Primary UI to RefinemySite for end-users. Offers all features and functionalities described above.
Administrative application to be used by support personnel to assign users as employees to companies with specific RefinemySite roles. Allows to administer users, employees and companies from vendor/support side.
The cloud backend is organized in bounded contexts inspired by DDD methodology. Each bounded context is made up of one or more backend services.
The User Management context deals with the registration of users on RefinemySite. It contains the sign-up process as well as processes around the maintenance of a user account (i.e. user profile picture) and makes sure all information about a user are in place before a user can be used in RefinemySite.
The user service deals with the registration and profile management of users and therewith implements the main functionality of the user management context.
The Company Management context deals with the registration of companies, the maintenance of their organisational structure (like users being employees in a company) and so on. This information can be used to derive authorisation information from it (i.e. to decide in the project context, which users are allowed to create projects etc.).
The company service implements all functionality that is covered by the company management context.
The Project Management context is the main context of the capability "Construction Site Management (CSM)". It contains all processes around project and task management, lean construction management etc.).
The functionality inside this context is split to the following components (each being a separate Sprint Boot backend service):
The project service contains the main processes related to project and task management and lean construction management. Since it is a "source" service, it is responsible for providing all data in the form of events (according to our event log pattern) so that downstream services can make use of them.
The project activities service transforms the stream of project events into an "activity stream". An activity is a representation of an event in a user-friendly way and provides information about a change that happened on an aggregate of the project context. Currently, only events for tasks and "sub-aggregates" of a task are recorded and provided as an activity stream for a selected task. Since events always come with a full snapshot of the corresponding aggregate, the activity service provides functionality to calculate the difference between two consecutive aggregate versions (coming with two consecutive events). Since this information is derived from the stream of events, the activities are eventual consistent.
The project news service transforms the stream of project events into news marker for each user. It knows which event is relevant for which user and marks (currently only) tasks with a user-specific news flag in case something relevant on a task happened since the user last visited the task. Since this information is derived from the stream of events, the news markers are eventually consistent.
Furthermore, the news service sends Live Update Events as messages to the Event Service in order to distribute them to currently connected users.
The project notification service transforms the stream of project events in notifications for each relevant user. It knows which event leads to which notification and determines the list of recipients. Furthermore, it persists notifications per user as a kind of inbox and keeps track of the "seen" state of a users notification list as a whole as well as of each single notification. It also sends messages to the Event Service to actively inform users about new notifications being available.
The project statistics service calculates key performance indicators according to the lean construction principles. The figures provide insights into amount of daycards completed in time etc. It uses the kafka event stream to derive statistics from events.
The project timeseries service represents the backbone of the public API of RefinemySite. It consumes all project data from Kafka topics and materializes that data in an easily accessible data structure providing bulk project information as well as timeline-based project information (based on Kafka event records the project is made up of).
The Job Context covers support for (long-running) jobs.
The job service handles (possibly) long-running asynchronous jobs.
The Storage Context covers generic interaction with file storage.
The storage event service listens to Azure Storage Queue of Azure Storage Account Container. Whenever a file is uploaded to the container an event is emitted to a Kafka topic allowing for further processing.
The Image Context covers image-specific workloads.
The image scale service listens to Kafka events provided by storage event service and scales images in specifically configured target sizes. The results (originals and scaled images) are uploaded into project and user storage accounts. The user and project services are informed via Kafka events about image scaling results.
The Feature Toggle Context provides feature toggles.
The service allows to easily create feature toggles. A feature can be enabled, disabled or enabled for whitelisted subjects with subjects being specific companies or projects. Downstream services required to implement the toggles are informed via Kafka topic on toggle states.
There are a number of services and libraries that cannot be attributed to any or just one bounded context. These are listed below.
(used in multiple services across bounded contexts):
- csm.cloud.common.avro
- csm.cloud.common.blob
- csm.cloud.common.core
- csm.cloud.common.event-consumer
- csm.cloud.common.go-app
- csm.cloud.common.kafka
- csm.cloud.common.mongodb
- csm.cloud.common.mysql
- csm.cloud.common.streamable
- csm.cloud.common.web
- csm.cloud.dependency-management
- csm.cloud.i18n-plugin
- csm.cloud.i18n-plugin
The API Service serves as entry point for all requests and forwards all requests to the appropriate backend service. It acts as an Application Gateway.
The event service is a technical component providing a Server Sent Event (SSE) endpoint to receive an event stream containing various events. Clients can establish a connection to this endpoint to receive events sent from the server to the clients. The first use case for this are so called "Live Update Events" that notify a client about a resource that was somehow changed.
The PDF converter service generates PDFs for schedules and such.
The Kafka connector is actually not a service bound to any context. It is a technical component that transfers events written to a database table inside a service (that owns data) to a Kafka topic in a reliable way (at-least-once semantics). We use this in order to solve the dual-write problem when updating a local data store and writing events in parallel (based on a transactional outbox-pattern within the service).
Since we need a deployment of this service for each primary service, we have multiple helm charts, one for each primary service.
Contains a number of scripts that help to operate the application with technologies like Kubernetes and Kafka.
This project contains third-party software components listed under Third-Party Software. These components are Open Source Software licensed under a license approved by the Open Source Initiative (www.opensource.org).
The sources in this repository are Open Source released under Apache 2.0 license.
- Axel Gauweiler
- Axel Schüssler
- Benjamin Höhensteiger
- Christian Schaible
- Corvin Schapöhler
- Edgar Pires
- Filipe Taborda
- Francisca Pimenta
- Katharina Kleiner
- Lars Dülfer
- Mareike Lowinski
- Mert Yücel
- Nicolas Steimmig
- Nicole Seifert
- Pedro Letra
- Peter Kleimann
- Rafael Franca
- Renato Cruz
- Sebastian Maximilian Jackisch
- Simon Hartmann
Missing yourself on this list? If you are a former contributor or code author of RefinemySite project you may reach out to the current maintenance team or simply create a pull request adding yourself to the list. As code-author you are entitled to be named as author of the software or to remain anonymous. If you add your name as an author of the given software, you agree that your name will be published with said software. You are fully aware that after a contribution your name cannot be removed from copies of the software in the OSS community.