Spring Boot uses two main YAML configuration files:

• bootstrap.yml
  • Loaded before application.yml during the startup process.
  • Used for early-stage configuration that is required before the main application context is loaded.
• application.yml
  • Loaded after bootstrap.yml, within the main application context.

Some properties may want to be put in environment-specific configuration files with the naming convention bootstrap-ENV.yml and application-ENV.yml. For example, there may be bootstrap-dev.yml and bootstrap-prod.yml. At deployment-time, you can specify an environment variable SPRING_PROFILES_ACTIVE to indicate whether to load dev or prod on top of the default configurations.

To convert a property name in the canonical-form to an environment variable name you can follow these rules:

• Replace dots (.) with underscores (_).
• Remove any dashes (-).
• Convert to uppercase.

For example, the configuration property spring.main.log-startup-info would be an environment variable named SPRING_MAIN_LOGSTARTUPINFO.

Environment variables can also be used when binding to object lists. To bind to a List, the element number should be surrounded with underscores in the variable name.

For example, the configuration property my.service[0].other would use an environment variable named MY_SERVICE_0_OTHER.

Examples of environment variable naming conventions:

Note: Official guidance is to remove dashes (-) entirely from the environment variable. For example: label-filter becomes LABELFILTER. However, both LABEL-FILTER and LABELFILTER work interchangeably.

Overriding Default Configs

Any of the properties for serivce configuration can be provided either via environment variables, through a custom application.yml file, or via properties set in java using -D<propertyName>=<value> passed as an argument to the JVM during startup.

Azure App Config and Key Vault

Default key-filter and label-filter properties are specified for each service, so that at deployment time only the connection to the Azure App Config or Key Vault services needs to be configured/specified in environment variables.

Authentication

Java Azure libraries have difficult using different authentication mechanisms between App Config (AAC) and Key Vault (AKV). If you specify AZURE_CLIENT_ID, it will attempt to use managed identity for both AAC and AKV.

If using managed identity authentication for one, it is suggested to use managed identity for both; not a connectionString with a token/secret embedded in it for AAC and MI for AKV.

Specifying all three AZURE_CLIENT_ID, AZURE_CLIENT_SECRET and AZURE_TENANT_ID is only necessary when using a service principal for authentication. Only AZURE_CLIENT_ID is necessary to authenticate using managed identity.

If using a service principal for authentication, the AZURE_TENANT_ID is not the same as the subscription ID.

Blob Storage

Telemetry

Swagger

Databases

Mongo DB

SQL Server

Auto Update/Migrate DBs

Kafka

Service Authentication

HAPI FHIR Server Configuration

The HAPI module supports rate-limiting configuration to control the number of requests allowed within a specified time period. When rate-limiting is enabled, clients that exceed the configured limits will receive HTTP 429 (Too Many Requests) responses.

Environment Variable Examples:

• HAPI_FHIR_RATELIMITING_COUNT=100 - Allow 100 requests per time window
• HAPI_FHIR_RATELIMITING_DURATION=PT5M - Set time window to 5 minutes

Note: Rate-limiting is applied per client IP address. When count is set to -1 (default), no rate-limiting is applied.

Service Information

The service-information configuration allows exposing build, version and deployment information through the /api/XXX/info (i.e. /api/validation/info) endpoint of each service. This information is automatically populated from assembly metadata and git information during build time.

Relationships

flowchart LR
njava_C251860["Design: Configuring Java Services"]