Configuration properties

The tSM system is built on top of Spring Boot, which allows it to leverage Spring’s powerful externalized configuration capabilities. In tSM, configuration is primarily managed through the application.yml file, which defines common properties that apply to all microservices. These configurations can be easily customized for different environments such as development, testing, and production.

tSM also supports optional usage of Spring Cloud Config to centralize configuration across multiple microservices. This setup ensures consistency and easier management of shared properties like data sources, messaging services (Kafka), and environment-specific settings.

Please consult Spring Externalized Configuration for more info.

Common Configuration for tSM Microservices

In tSM, every microservice shares some common configuration properties, which can be centrally managed. This is especially useful when using Spring Cloud Config, where you can maintain one application.yml for all services. Here’s an example of a minimal common configuration:

# ----------------------------------------------------------------------------
# Common configuration
# ----------------------------------------------------------------------------
tsm:
  prefix: projectX
  datasource:
    host: my.postgres.database:5401
    database: tsm
    username: tsm_admin
    password: myPass
  elastic:
    address: tsm-elastic
    username: elastic
    password: elasticdata
  kafka:
    address: my.kafka.cluster:9092
    autocreate:
      partitions: 2
  elk:
    enabled: true
    logstash:
      url: tsm-log-server:5044
  locale:
    locale: cs-CZ
    timezone: "Europe/Prague"

Explanation of Common Properties:

• tsm.prefix: A unique identifier for the project, which is used to distinguish between different projects in the same environment. It is used as a prefix for all Kafka topics, elasticsearch indexes, and other project-specific settings.
• tsm.datasource: Defines the database connection details for tSM microservices.
• tsm.elastic: Specifies the ElasticSearch configuration for logging and searching within tSM.
• tsm.kafka: Configures Kafka settings, including the address of the Kafka broker and partition settings.
• tsm.elk: Controls ELK stack logging, including connection to Logstash.
• tsm.locale: Sets locale and timezone settings for tSM microservices.

These properties are common across all tSM microservices and ensure consistency in the way services connect to databases, messaging queues, and logging systems.

Deployment Options

When deploying tSM microservices, you have multiple options to manage configurations. The most common approach is using Spring Cloud Config for cloud environments, such as Kubernetes (K8s), where configurations are managed centrally and shared across all microservices. For on-premise deployments, configurations are typically managed locally via application.yml files.

Cloud Config Deployment

In cloud-based deployments, such as Kubernetes, Spring Cloud Config can be used to manage configuration files centrally. This enables easy scaling and maintenance of configurations across all microservices.

To use Spring Cloud Config, you need to specify the configuration source using the spring.config.import environment variable. This can be done directly in the Kubernetes deployment spec.

Example: Kubernetes Deployment with Spring Cloud Config

spec:
  containers:
    - env:
        - name: spring.config.import
          value: 'configserver:http://tsm-config-server'
      image: 'registry.datalite.cz/tsm/tsm-calendar:2.2'

In this example:

• spring.config.import points to the Spring Cloud Config server URL, which provides the configurations for the microservice.
• The tsm-calendar microservice image is pulled from the registry and uses the configurations provided by the config server.

To deploy the Spring Cloud Config server, you need to ensure that it is configured to pull configurations from a Git repository or other storage. Here's an example Kubernetes configuration for deploying the config server:

spec:
  containers:
    - env:
        - name: JAVA_TOOL_OPTIONS
          value: '-Xms150m -Xmx150m'
        - name: spring.cloud.config.server.git.uri
          value: https://gitlab.datalite.cz/tsm/config.git
        - name: spring.cloud.config.server.git.username
          value: user
        - name: spring.cloud.config.server.git.password
          value: pass
        - name: encrypt.key
          value: myPass
      image: 'registry.datalite.cz/tsm/tsm-config-server:2.2'

Make sure you have the Spring Cloud Config Server up and running and pointing to the correct repository where your application.yml files are stored.

On-Premise Deployment

For on-premise deployments, configurations are typically managed locally by placing the application.yml file directly in the classpath of the microservice. No external configuration server is required, and each microservice will load its configuration from the local file system.

Built in Configuration Properties

The following properties are common to all profiles, environments, and customizations.

They are included to all microservices and can be overridden by the environment or profile.

server:
  port: ${tsm.port}
  max-http-request-header-size: 64KB

spring:
  application:
    name: ${tsm.name}
  kafka:
    bootstrap-servers: ${tsm.kafka.address}
    consumer:
      group-id: ${tsm.kafka.consumerGroupId}
      auto-offset-reset: earliest # If the group does not have an offset available, it will start from the beginning.
      key-deserializer: org.springframework.kafka.support.serializer.ErrorHandlingDeserializer
      value-deserializer: org.springframework.kafka.support.serializer.ErrorHandlingDeserializer
      properties:
        spring.deserializer.key.delegate.class: org.apache.kafka.common.serialization.StringDeserializer
        spring.deserializer.value.delegate.class: org.apache.kafka.common.serialization.StringDeserializer
        max.poll.interval.ms: 3600000
        max.poll.records: 20
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
  datasource:
    url: jdbc:postgresql://${tsm.datasource.host}/${tsm.datasource.database:tsm}?currentSchema=${tsm.datasource.schema}${tsm.datasource.params:}
    username: ${tsm.datasource.username}
    password: ${tsm.datasource.password}
    hikari:
      maximum-pool-size: 30
      minimum-idle: 2
  jpa:
    properties:
      hibernate:
        type.json_format_mapper: cz.datalite.tsm.db.KotlinJacksonFormatMapper
        jdbc:
          lob:
            non_contextual_creation: true # https://github.com/pgjdbc/pgjdbc/issues/1102
          batch_size: 100
    hibernate:
      ddl-auto: none
    open-in-view: true
  jackson:
    mapper:
      DEFAULT_VIEW_INCLUSION: true # Properties without @JsonView are added by default
  freemarker:
    template-loader-path: classpath:/templates
    suffix: .ftl
  flyway:
    default-schema: ${tsm.datasource.schema}
    schemas: ${tsm.datasource.schema}
    locations: classpath:db/release-*/**/{vendor}
    group: true
    placeholder-prefix: $$FLYWAY$${
    validate-migration-naming: true
    baseline-on-migrate: true
    baseline-version: 10.01.0.001
    baseline-description: TSM Init
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.data.elasticsearch.ReactiveElasticsearchRepositoriesAutoConfiguration
      - org.springframework.boot.autoconfigure.elasticsearch.ReactiveElasticsearchClientAutoConfiguration
      - org.springframework.boot.autoconfigure.security.servlet.UserDetailsServiceAutoConfiguration

  cloud:
    openfeign:
      httpclient:
        enabled: true # Support for PATCH
      lazy-attributes-resolution: true #  of type [org.springframework.cloud.openfeign.FeignClientFactoryBean] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
      cache:
        enabled: false # Fix error in FeignCachingInvocationHandlerFactory
      client:
        config: # Extend connection timeout
          default:
            exception-propagation-policy: UNWRAP
            logger-level: FULL
            connectTimeout: 30000
            readTimeout: 30000

feign:
  httpclient:
    enabled: true

javers:
  auditable-aspect-enabled: false
  packages-to-scan: cz.datalite.tsm
  sqlSchemaManagementEnabled: false

# Defualt settings for camunda
camunda:
  bpm:
    database:
      # Use standard tSM installation instead
      # if you need generate the schema, you need to change for tsm_admin user and grant privileges
      schema-update: false 
    auto-deployment-enabled: false # Deployment is done from tSM Process Definition component
    application:
      scan-for-process-definitions: false
    # Not all scripts are transactional, so we need to handle retries carefully. 
    # Retries can be configured per process using the tSM Process Designer
    defaultNumberOfRetries: 1 
    defaultSerializationFormat: application/json # object are serialized as JSON
    generic-properties:
      properties:
        historyTimeToLive: P365D # default history for 1 year
        loggingContextActivityId: tsm.camunda.activityId
        loggingContextBusinessKey: tsm.camunda.businessKey
        loggingContextProcessDefinitionId: tsm.camunda.processDefinitionId
        loggingContextProcessInstanceId: tsm.camunda.processInstanceId
        loggingContextApplicationName:
        loggingContextTenantId:

# Publish management endpoints
management:
  endpoint:
    health:
      show-details: always
      probes:
        enabled: true
  endpoints:
    web:
      exposure:
        include: flyway,loggers,logfile,env,info,health,configprops,metrics,scheduledtasks,threaddump,heapdump,prometheus
  health:
    camunda:
      enabled: false # Check using tSM Management service instead