diff --git a/README.md b/README.md
index b1fabf74..c9bf800d 100644
--- a/README.md
+++ b/README.md
@@ -1,21 +1,23 @@
# mod-camunda
-Copyright (C) 2018-2022 The Open Library Foundation
+Copyright (C) 2018-2025 The Open Library Foundation.
This software is distributed under the terms of the Apache License, Version 2.0.
See the file ["LICENSE"](LICENSE) for more information.
+
# Table of Contents
+
1. [Docker deployment](#docker-deployment)
- 1. [Publish docker image](#publish-docker-image)
-2. [Camunda Module Dependencies](#camunda-module-dependencies)
-3. [Workflow Project Structure](#workflow-project-structure)
-4. [App Deployment](#deploy-and-run-the-application)
-5. [Camunda APIs](#camunda-apis)
-6. [Kafka Message Broker](#kafka-message-broker)
-7. [FOLIO Integration](#folio-integration)
-8. [Additional Information](#additional-information)
-9. [Issue Tracker](#issue-tracker)
+ 1. [Publish docker image](#publish-docker-image)
+2. [Manual Build and Run](#manual-build-and-run)
+3. [Camunda Module Dependencies](#camunda-module-dependencies)
+4. [Workflow Project Structure](#workflow-project-structure)
+5. [App Deployment](#deploy-and-run-the-application)
+6. [Camunda APIs](#camunda-apis)
+7. [Kafka Message Broker](#kafka-message-broker)
+8. [Issue Tracker](#issue-tracker)
+
## Docker deployment
@@ -27,9 +29,10 @@ mvn clean install
cd mod-camunda
docker build -t folio/mod-camunda .
-docker run -d -p 9000:8081 folio/mod-camunda
+docker run -d -p 8081:8081 folio/mod-camunda
```
+
### Publish docker image
```
@@ -38,227 +41,205 @@ docker build -t [docker repo]/folio/mod-camunda:[version] .
docker push [docker repo]/folio/mod-camunda:[version]
```
-## Camunda Module Dependencies
-This module extends spring-module-core and brings in Camunda BPM to enable workflow capabilities. Camunda is an open-source BPM platform that is embedded in this module via the following dependencies.
-```
-# --- VERSIONS ---
-7.9.0
-3.0.0
-
-# --- DEPENDENCY MANAGEMENT ---
-
-
- org.camunda.bpm
- camunda-bom
- ${camunda.version}
- import
- pom
-
-
-# --- DEPENDENCIES ---
-
- org.camunda.bpm.springboot
- camunda-bpm-spring-boot-starter
- ${camunda.spring.boot.version}
-
-
-
- org.camunda.bpm.springboot
- camunda-bpm-spring-boot-starter-webapp
- ${camunda.spring.boot.version}
-
-
-
- org.camunda.bpm.springboot
- camunda-bpm-spring-boot-starter-rest
- ${camunda.spring.boot.version}
-
+
+## Manual Build and Run
+
+The `mod-camunda` project may also be built and run directly on a local machine.
+There are external services that are still needed and it is recommended that a remote OKAPI and a remote Kafka are used.
+This example describes the local build and run process using an already configured local Postgresql server with already configured remote OKAPI, remote Kafka servers, and a remote (or local) `mod-workflow`.
+This example uses environment variables to configure the `mod-camunda` service, however these configurations may be directly applied to the `application.yml`.
+
+```shell
+DB_USERNAME=folio \
+DB_PASSWORD=folio \
+DB_PORT=5432 \
+SERVER_PORT=9000 \
+OKAPI_URL=http://remote_okapi:9130 \
+SPRING_JPA_HIBERNATE_DDLAUTO="update" \
+CAMUNDA_BPM_DATABASE_SCHEMAUPDATE=true \
+TENANT_INITIALIZEDEFAULTENANT=true \
+TENANT_RECREATEDEFAULTTENANT=true \
+SPRING_MAIL_PROPERTIES_MAIL_SMTP_SSL_CHECKSERVERIDENTITY=false \
+TENANT_DEFAULTTENANT=diku \
+KAFKA_HOST=https://remote_kafka \
+KAFKA_PORT=9092 \
+APPLICATION_KAFKA_LISTENER_EVENTS_TOPIC_PATTERN='folio.(.*\.)?camunda_local.events' \
+APPLICATION_KAFKA_LISTENER_EVENTS_GROUPID=folio-mod-camunda_local-events-group \
+mvn clean spring-boot:run
```
-* camunda-bpm-spring-boot-starter
- * Adds the Camunda engine (v7.9)
- * [https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/)
- * [https://github.com/camunda/camunda-bpm-spring-boot-starter](https://github.com/camunda/camunda-bpm-spring-boot-starter)
- * The Camunda engine requires a database schema to be configured on startup
- * Work is in progress to allow the module to start without any database creation and have the tenant creation perform the necessary table creation and initial data import
- * Details on the process engine database schema configuration can be foune [here](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/configuration/)
-* camunda-bpm-spring-boot-starter-webapp
- * Enables Web Applications such as Camunda Cockpit and Tasklist
- * [https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/webapps/](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/webapps/)
-* camunda-bpm-spring-boot-starter-rest
- * Enables the Camunda REST API
- * [https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/rest-api/](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/rest-api/)
- * [https://docs.camunda.org/manual/7.9/reference/rest/](https://docs.camunda.org/manual/7.9/reference/rest/)
- * The Camunda REST API uses Jersey so we use spring boot's common application properties to configure the path to be /camunda in the application.yml file
- * `spring.jersey.application-path=camunda`
-## Workflow Project Structure
-Business Process Models and Decision Models are built using the [Camunda Modeler](https://camunda.com/products/modeler/) which impelements BPMN 2.0 and DMN 1.1 specifications.
+The above example explicitly defines the Postgresql database settings.
+The `SPRING_JPA_HIBERNATE_DDLAUTO`, `CAMUNDA_BPM_DATABASE_SCHEMAUPDATE`, `TENANT_INITIALIZEDEFAULTENANT`, and `TENANT_RECREATEDEFAULTTENANT` environment variables are defined this way so that the database is deleted and re-created on each run. If this is not desired, then they should be set to `false`.
+Note that the `SPRING_JPA_HIBERNATE_DDLAUTO` could be set to `None`, but `update` is still safe when preserving the database between runs.
-* .bpmn files are stored in `/src/main/java/resources/workflows`
-* .dmn files are stored in `/src/main/java/resources/decisions`
+The `SPRING_MAIL_PROPERTIES_MAIL_SMTP_SSL_CHECKSERVERIDENTITY` is only needed on a local machine because there might not be a valid mail server certificate for the local machine.
+This probably should not be set to `false` on a production system.
-Any Java code that is executed in the context of a process is usually written in a Java Delegate. These classes are stored in `/src/main/java/org/folio/rest/delegate/`
+The `TENANT_DEFAULTTENANT` is added to show that the tenant can be changed, but the default of `diku` is likely fine.
-## Deploy and run the application
-1. Run the application `mvn clean spring-boot:run`
-2. Deploy all the processes by running scripts/deploy.sh file
-3. Navigate to Camunda Portal `localhost:9000/app/welcome/default/#/welcome`
-4. Log in as admin user: `admin`, password: `admin`
+The `APPLICATION_KAFKA_LISTENER_EVENTS_TOPIC_PATTERN` and `APPLICATION_KAFKA_LISTENER_EVENTS_GROUPID` are provided to separate the normal Kafka messages from the local instance.
+This helps ensure isolation between different systems.
+It is recommended to use a unique topic pattern and group id for each local instance (as in for each developer machine running this locally).
-## Camunda APIs
-* Process/Decision Deployment
- * [https://docs.camunda.org/manual/7.9/reference/rest/deployment/](https://docs.camunda.org/manual/7.9/reference/rest/deployment/)
- * GET
- * /camunda/deployment
- * /camunda/deployment/{id}
- * POST
- * /camunda/deployment/create
- * DELETE
- * /camunda/deployment/{id}
-* Process Definition
- * [https://docs.camunda.org/manual/7.9/reference/rest/process-definition/](https://docs.camunda.org/manual/7.9/reference/rest/process-definition/)
- * GET
- * /camunda/process-definition
- * /camunda/process-definition/{id}
- * POST
- * /camunda/process-definition/{id}/start
- * /camunda/process-definition/key/{key}/tenant-id/{tenant-id}/start
-* Decision Definition
- * [https://docs.camunda.org/manual/7.9/reference/rest/decision-definition/](https://docs.camunda.org/manual/7.9/reference/rest/decision-definition/)
- * GET
- * /camunda/decision-definition
- * /camunda/decision-definition/{id}
-* Tasks
- * [https://docs.camunda.org/manual/7.9/reference/rest/task/](https://docs.camunda.org/manual/7.9/reference/rest/task/)
- * GET
- * /camunda/task
- * /camunda/task/{id}
- * POST
- * /camunda/task/{id}/claim
- * /camunda/task/{id}/unclaim
- * /camunda/task/{id}/complete
-* Message Events
- * [https://docs.camunda.org/manual/7.9/reference/rest/message/](https://docs.camunda.org/manual/7.9/reference/rest/message/)
- * POST
- * /camunda/message
+The `OKAPI_URL`, `KAFKA_HOST`, and `KAFKA_PORT` are standard server configuration variables for the remote systems.
+The values assigned to these are for example purposes and likely will not work without being changed to a proper address.
-## Kafka Message Broker
-We are using Kafka as the message broker.
+The `SERVER_PORT` is provided because the `mod-workflow` might be run on the same local machine.
+They both default to port `8081` and that could be changed to something like `9000` to prevent conflicts.
-## FOLIO Integration
-For detailed information to bring up a FOLIO instance refer to [https://github.com/folio-org/folio-ansible](https://github.com/folio-org/folio-ansible).
+The `OKAPI_URL` may be changed to point directly to a local `mod-workflow` to bypass OKAPI.
+This can help make development easier in certain situations.
+In such a case, this could be set to the local `mod-workflow` instance, such as `OKAPI_URL=http://localhost:9001`.
-The following requires [Vagrant](https://www.vagrantup.com/) 1.9.6 or above.
-```
-vagrant up
-# wait
-```
+## Camunda Module Dependencies
-When finished Okapi will be running with mod-workflow and mod-camunda deployed under the diku tenant. mod-camunda will have its port forwarded for access to the Camunda webapps. FOLIO UI will be accessible at `http://localhost:3000`; `username`: `diku_admin`, `password`: `admin`.
+This module depends on spring-module-core and brings in Camunda BPM to enable workflow capabilities.
+Camunda is an open-source BPM platform that is embedded in this module.
+The [pom.xml](pom.xml) described these versions and dependencies.
+
+- `camunda-bpm-spring-boot-starter`
+ - Adds the Camunda engine.
+ - [https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/)
+ - [https://github.com/camunda/camunda-bpm-spring-boot-starter](https://github.com/camunda/camunda-bpm-spring-boot-starter)
+ - The Camunda engine requires a database schema to be configured on startup.
+ - Details on the process engine database schema configuration can be found in the [spring boot integration configuration](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/configuration/).
+- `camunda-bpm-spring-boot-starter-webapp`
+ - Enables Web Applications such as Camunda Cockpit and Tasklist.
+ - [https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/webapps/](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/webapps/)
+- `camunda-bpm-spring-boot-starter-rest`
+ - Enables the Camunda REST API.
+ - [https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/rest-api/](https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/rest-api/)
+ - [https://docs.camunda.org/manual/latest/reference/rest/](https://docs.camunda.org/manual/latest/reference/rest/)
+ - The Camunda REST API uses Jersey so we use spring boot's common application properties to configure the path to be /camunda in the application.yml file.
+ - `spring.jersey.application-path=camunda`
-> Okapi is being built and redeployed from within this vagrant. Eventually this will not need to happen. If a specific branch of either mod-camunda or mod-workflow is desired to be deployed, modify the Vagrantfile `git checkout main` to the desired branch and restart vagrant. `vagrant destroy`, `vagrant up`
-### Development
+## Workflow Project Structure
-In order to facilitate development on mod-camunda in the context of Okapi, there is a sync directory from the host machine to the guest machine. The host directory is at `.vagrant/sync` and it will contain `okapi`, `mod-camunda`, and `mod-workflow`. The development and git branch management can be done on the host machine. The guest directory is at `/sync`. The redeployment of a module must be done from the guest machine.
+Business Process Models and Decision Models are built using the [Camunda Modeler](https://camunda.com/products/modeler/) which impelements BPMN 2.0 and DMN 1.1 specifications.
-```
-vagrant ssh
-sudo su
-cd /sync
-# kill mod-camunda running on port 9000
-kill $(lsof -t -i :9000)
-cd mod-camunda
-mvn clean install
-nohup java -jar target/mod-camunda-1.1.0.jar &
-```
+The UI module [ui-workflow](https://github.com/folio-org/ui-workflow) provides a way to facilitate building, activating, and running individual workflows.
-### Login
+There are also local resources that can be used to manually perform this process.
-```
-curl -v -H "Content-Type: application/json" -H "X-Okapi-Tenant: diku" http://localhost:9130/authn/login -d '{"username": "diku_admin", "password": "admin"}'
-```
+- The local resources for `.bpmn` files are stored in `src/main/resources/workflows`
+- The local resources for `.dmn` files are stored in `src/main/resources/decisions`
-The response headers of interest are `X-Okapi-Token` and `refreshToken`.
+Any Java code that is executed in the context of a process is usually written in a Java Delegate.
+These classes are stored in `src/main/java/org/folio/rest/camunda/delegate`.
-### Refresh Token
-```
-curl -v -H "X-Okapi-Tenant: diku" -H "Content-Type: application/json" http://localhost:9130/refresh -d '{"refreshToken": "`[refresh token goes here]`"}'
-```
+## Accessing the Application
-The body of this response will contain the new `X-Okapi-Token`.
+1. Start `mod-camunda` either through the Docker interface or through the manual `mvn clean spring-boot:run` command.
+2. Deploy all the processes, such as by running `scripts/deploy.sh` file.
+3. Navigate to Camunda Portal, such as `https://localhost:9000/ui/welcome/default/#/welcome` for a local execution.
+4. Log in as admin user: `admin`, password: `admin` (which can be changed using environment variables or by tweaking the `application.yml` file).
-### Workflow Module Triggers
-The Trigger entity from mod-workflow is used to select which request-response events from Okapi are to be published to the `${ENV:folio}.workflow.events` topic that mod-camunda can subscribe to. In order to create the Triggers we have to provide the correct permissions to the `diku_admin`. The vagrant will create an example trigger for when a user is created.
+## Camunda APIs
+The [module descriptor template](descriptors/ModuleDescriptor-template.json) describes the available end points provided by `mod-camunda`.
+This template is used to build the module descriptor when building the package or starting the local server.
+This end point described by this template can be found via appropriate FOLIO interfaces, such what [Stripes UI](https://github.com/folio-org/stripes-ui) may provide.
+
+The following are example end points:
+- Process/Decision Deployment
+ - [https://docs.camunda.org/manual/latest/reference/rest/deployment/](https://docs.camunda.org/manual/latest/reference/rest/deployment/)
+ - `GET`
+ - `/camunda/deployment`
+ - `/camunda/deployment/{id}`
+ - `POST`
+ - `/camunda/deployment/create`
+ - `DELETE`
+ - `/camunda/deployment/{id}`
+- Process Definition
+ - [https://docs.camunda.org/manual/latest/reference/rest/process-definition/](https://docs.camunda.org/manual/latest/reference/rest/process-definition/)
+ - `GET`
+ - `/camunda/process-definition`
+ - `/camunda/process-definition/{id}`
+ - `POST`
+ - `/camunda/process-definition/{id}/start`
+ - `/camunda/process-definition/key/{key}/tenant-id/{tenant-id}/start`
+- Decision Definition
+ - [https://docs.camunda.org/manual/latest/reference/rest/decision-definition/](https://docs.camunda.org/manual/latest/reference/rest/decision-definition/)
+ - `GET`
+ - `/camunda/decision-definition`
+ - `/camunda/decision-definition/{id}`
+- Tasks
+ - [https://docs.camunda.org/manual/latest/reference/rest/task/](https://docs.camunda.org/manual/latest/reference/rest/task/)
+ - `GET`
+ - `/camunda/task`
+ - `/camunda/task/{id}`
+ - `POST`
+ - `/camunda/task/{id}/claim`
+ - `/camunda/task/{id}/unclaim`
+ - `/camunda/task/{id}/complete`
+- Message Events
+ - [https://docs.camunda.org/manual/latest/reference/rest/message/](https://docs.camunda.org/manual/latest/reference/rest/message/)
+ - `POST`
+ - `/camunda/message`
-### Permissions
-In order to call mod-camunda and mod-workflow through the Okapi gateway a user will need the appropriate permissions. In order to accommodate this the Vagrantfile runs a shell script in which updates permissions for `diku_admin`. Providing him with all permissions to all interfaces of mod-camunda and mod-workflow.
+## Kafka Message Broker
-### Cleanup
+The message broker being used is the standard FOLIO message broker called [Apache Kafka](https://kafka.apache.org/), which is called Kafka for brevity.
-When finished it will be desired to cleanup as the FOLIO vagrant uses a lot of resources.
-```
-vagrant destroy
-rm -rf .vagrant/sync
-```
+### Workflow Module Triggers
-> Removing the synced directory, `.vagrant/sync`, on the host will remove any changes during development that have not been pushed.
+The trigger entity from `mod-workflow` is used to select which request-response events from Okapi are to be published to the `${ENV:folio}.workflow.events` topic that mod-camunda can subscribe to. In order to create the Triggers we have to provide the correct permissions to the `diku_admin`. The vagrant will create an example trigger for when a user is created.
-### Environment variables:
-The environment variables most notable to deployment are described in the [Module Descriptor](https://github.com/folio-org/mod-camunda/blob/master/descriptors/ModuleDescriptor-template.json).
+### Common Environment Variables:
+
+The most notable environment variables for deployment are described in the [Module Descriptor](descriptors/ModuleDescriptor-template.json) template.
The following is a summary of many of them.
-| Name | Default value | Description |
-|:----------------------------------|:---------------------------:|:-----------------------------------------------------------------------------------------------------------------------------------------------------------|
-| CAMUNDA_BPM_ADMINUSER_EMAIL | `admin@localhost` | The e-mail address of the Camunda administration user. |
-| CAMUNDA_BPM_ADMINUSER_ID | admin | The account name of the Camunda administration user. |
-| CAMUNDA_BPM_ADMINUSER_PASSWORD | admin | The password of the Camunda administration user. |
-| CAMUNDA_BPM_DATABASE_SCHEMAUPDATE | true | If Camunda should auto-update the BPM database schema. |
-| CAMUNDA_BPM_METRICS | false | Enable or disable Camunda metrics by default. |
-| DB_CHARSET | UTF-8 | Database charset. |
-| DB_DATABASE | okapi_modules | Postgres database name. |
-| DB_HOST | postgres | Postgres host name. |
-| DB_MAXPOOLSIZE | 5 | Database max pool size. |
-| DB_PASSWORD | - | Postgres user password. |
-| DB_PORT | 5432 | Postgres port. |
-| DB_QUERYTIMEOUT | 60000 | Database query timeout. |
-| DB_USERNAME | folio_admin | Postgres user name. |
-| JAVA_OPTIONS | `-XX:MaxRAMPercentage=75.0` | Java options. |
-| KAFKA_HOST | kafka | Kafka broker host name. |
-| KAFKA_PORT | 9092 | Kafka broker port. |
-| KAFKA_SECURITY_PROTOCOL | PLAINTEXT | Kafka security protocol used to communicate with brokers (SSL or PLAINTEXT). |
-| KAFKA_SSL_KEYSTORE_LOCATION | - | The location of the Kafka key store file. This is optional for client and can be used for two-way authentication for client. |
-| KAFKA_SSL_KEYSTORE_PASSWORD | - | The store password for the Kafka key store file. This is optional for client and only needed if `ssl.keystore.location` is configured. |
-| KAFKA_SSL_TRUSTSTORE_LOCATION | - | The location of the Kafka trust store file. |
-| KAFKA_SSL_TRUSTSTORE_PASSWORD | - | The password for the Kafka trust store file. If a password is not set, trust store file configured will still be used, but integrity checking is disabled. |
-| OKAPI_URL | `http://okapi:9130` | OKAPI URL used to login system user, required |
-| SERVER_PORT | 8081 | The port to listen on that must match the `PortBindings`. |
-| SERVER_SERVLET_CONTEXTPATH | `/` | The context path, or base path, to host at. |
-| SPRING_FLYWAY_ENABLED | false | Database migration support via Spring Flyway. |
-| SPRING_JPA_HIBERNATE_DDLAUTO | update | Auto-configure database on startup. |
-| TENANT_DEFAULTTENANT | diku | The name of the default tenant to use. |
-| TENANT_FORCETENANT | false | Forcibly add or overwrite the tenant name using the default tenant. |
-| TENANT_INITIALIZEDEFAULTTENANT | true | Perform initial auto-creation of tenant in the database (schema, tables, etc..). |
-| TENANT_RECREATEDEFAULTTENANT | false | When `TENANT_INITIALIZEDEFAULTTENANT` is true and the database already exists, then drop and re-create. |
+| Name | Default value | Description
+|:----------------------------------|:---------------------------:|:-------------------------------------------------------
+| CAMUNDA_BPM_ADMINUSER_EMAIL | `admin@localhost` | The e-mail address of the Camunda administration user.
+| CAMUNDA_BPM_ADMINUSER_ID | admin | The account name of the Camunda administration user.
+| CAMUNDA_BPM_ADMINUSER_PASSWORD | admin | The password of the Camunda administration user.
+| CAMUNDA_BPM_DATABASE_SCHEMAUPDATE | true | If Camunda should auto-update the BPM database schema (may result in dropping existing data).
+| CAMUNDA_BPM_METRICS | false | Enable or disable Camunda metrics by default.
+| DB_CHARSET | UTF-8 | Database charset.
+| DB_DATABASE | okapi_modules | Postgres database name.
+| DB_HOST | postgres | Postgres host name.
+| DB_MAXPOOLSIZE | 5 | Database max pool size.
+| DB_PASSWORD | folio_admin | Postgres user password (be sure to change this).
+| DB_PORT | 5432 | Postgres port.
+| DB_QUERYTIMEOUT | 60000 | Database query timeout.
+| DB_USERNAME | folio_admin | Postgres user name.
+| JAVA_OPTIONS | `-XX:MaxRAMPercentage=75.0` | Java options.
+| KAFKA_HOST | kafka | Kafka broker host name.
+| KAFKA_PORT | 9092 | Kafka broker port.
+| KAFKA_SECURITY_PROTOCOL | PLAINTEXT | Kafka security protocol used to communicate with brokers (SSL or PLAINTEXT).
+| KAFKA_SSL_KEYSTORE_LOCATION | - | The location of the Kafka key store file. This is optional for client and can be used for two-way authentication for client.
+| KAFKA_SSL_KEYSTORE_PASSWORD | - | The store password for the Kafka key store file. This is optional for client and only needed if `ssl.keystore.location` is configured.
+| KAFKA_SSL_TRUSTSTORE_LOCATION | - | The location of the Kafka trust store file.
+| KAFKA_SSL_TRUSTSTORE_PASSWORD | - | The password for the Kafka trust store file. If a password is not set, trust store file configured will still be used, but integrity checking is disabled.
+| OKAPI_URL | `http://okapi:9130` | OKAPI URL used to login system user, required (can be used to point directly to `mod-workflow`).
+| SERVER_PORT | 8081 | The port the `mod-camunda` service listens on.
+| SERVER_SERVLET_CONTEXTPATH | `/` | The context path, or base path, to host at.
+| SPRING_FLYWAY_ENABLED | false | Database migration support via Spring Flyway.
+| SPRING_JPA_HIBERNATE_DDLAUTO | update | Auto-configure database on startup.
+| TENANT_DEFAULTTENANT | diku | The name of the default tenant to use.
+| TENANT_FORCETENANT | false | Forcibly add or overwrite the tenant name using the default tenant.
+| TENANT_INITIALIZEDEFAULTENANT | true | Perform initial auto-creation of tenant in the database (schema, tables, etc..).
+| TENANT_RECREATEDEFAULTTENANT | false | When `TENANT_INITIALIZEDEFAULTTENANT` is true and the database already exists, then drop and re-create the database on start.
+
### Permissions
The permissions provided by this module are described in the [Module Descriptor](https://github.com/folio-org/mod-camunda/blob/master/descriptors/ModuleDescriptor-template.json) under `permissionSets`.
-The permissions defined are here are specific to the module and are usually not directly added to any user.
-Instead, permissions available for assignment to users or accounts are found in the [ui-workflow Module Permission Sets](https://github.com/folio-org/ui-workflow/blob/main/package.json).
-These [ui-workflow](https://github.com/folio-org/ui-workflow) permissions are automatically exposed via the appropriate [stripe-ui](https://github.com/folio-org/stripes-ui) administration interface.
+The permissions defined here are specific to this module and are usually not directly applied to any specific user.
+Instead, permissions available for assignment to users (or accounts) are found in the [ui-workflow Module Permission Sets](https://github.com/folio-org/ui-workflow/blob/main/package.json).
+These [ui-workflow](https://github.com/folio-org/ui-workflow) permissions are automatically exposed via the appropriate [Stripes UI](https://github.com/folio-org/stripes-ui) administration interface.
-## Additional information
### Issue tracker
-See project [FOLIO](https://issues.folio.org/browse/FOLIO)
-at the [FOLIO issue tracker](https://dev.folio.org/guidelines/issue-tracker/).
+See project [FOLIO](https://issues.folio.org/browse/FOLIO) and the [FOLIO issue tracker](https://dev.folio.org/guidelines/issue-tracker/).