Configuration

The EPR loads configuration data from a file (typically backed by a Kubernetes config map). If the service is unable to retrieve the configuration data, it will not start. Refer to the configuration for details.

Service configuration structure

The recommended configuration format is YAML. The below sections describe the officially supported configuration options that influence various aspects of the service functionality. The service may support options other than the ones listed below, but those are not a part of the public API and may be changed or deleted at any time.

General service configuration

EPR uses a standard Spring Boot server.port property to configure the port to expose the REST API at.

server:
  port: <unsigned short integer>  # Server port used to expose the REST API at

Kaa applications

Many Kaa services can be configured for different behavior depending on the application version of the endpoint the processed data relates to. This is called appversion-specific behavior and is handled in service configurations under kaa.applications. Despite EPR currently does not support any appversion-specific configurations, it uses the application and appversion names to validate the API calls and the protocol data.

kaa:
  applications:
    <application 1 name>:                # Kaa application name
      versions:
        <application 1 version 1 name>:  # Kaa application version name

Data persistence interface

EPR uses Spring Data MongoDB configuration. Refer to the corresponding documentation for the list of supported configuration options.

NOTE For security reasons, username and password must be sourced from the environment variables.

NATS

The below parameters configure EPR’s connection to NATS. Note that for security reasons NATS username and password are sourced from the environment variables.

nats:
  urls: <comma separated list of URL>  # NATS connection URLs

Communication service interface

kaa:
  epr:
    communication-service:
      service-instance:
        name: <service instance name>  # Instance name of the communication service

Authentication and authorization

EPR REST API security is implemented according to the OAuth2 protocol with the UMA profile.

The protection is controlled with the following configuration options:

security:
  ignored: <value>           # Controls authentication and authorization on REST API endpoints. 
                             # Possible values: '/**' to disable security or 'none' to enable.
  oauth2:
    client:
      clientId: <clientId>   # Client ID on whose behalf the requests will be made.
      clientSecret: <secret> # Client secret on whose behalf the requests will be made.
      accessTokenUri: <URI>  # An OAuth2-compliant Token Endpoint for obtaining tokens via the 'Implicit Flow', 
                             # 'Direct Grants', or 'Client Grants'. 
                             # E.g. "https://your-url-to-auth-server/auth/realms/realm-a/protocol/openid-connect/token"
      resourceUri: <URI>     # An UMA-compliant Resource Registration Endpoint which resource servers can use
                             # to manage their protected resources and scopes. 
                             # E.g. "https://your-url-to-auth-server/auth/realms/realm-a/authz/protection/resource_set"
    resource:
      userInfoUri: <URI>     # URL endpoint for the User Info service described in the OIDC specification.
                             # E.g. "https://your-url-to-auth-server/auth/realms/realm-a/protocol/openid-connect/userinfo"

Management

EPR monitoring and management implementation is based on the Spring Boot Actuator. Refer to the corresponding documentation for the list of supported configuration options.

Logging

By default, EPR uses Spring Boot logging configuration with logback for logging. Refer to the corresponding documentation for the list of supported configuration options.

Built-in configuration profiles

For your convenience, EPR comes with a default built-in configuration profile.

Built-in profiles are optimized for a Kubernetes-based production deployment. They do not define any Kaa applications—you have to configure them for a specific Kaa-based solution.

Default

server:
  port: 80
  compression:
    enabled: true
    mime-types: application/json

nats:
  urls: nats://nats:4222

kaa:
  epr:
    cm:
      base-url: http://cm
    communication-service:
      service-instance:
        name: kpc

spring.data.mongodb:
  database: epr
  uri: mongodb://mongodb:27017/epr
  threads-allowed-to-block-for-connection-multiplier: 5
  connections-per-host: 100
  max-wait-time: 120000
  connection-timeout: 5000
  socket-timeout: 0

management:
  server:
    port: 8080
  endpoint:
    health:
      enabled: true
      show-details: always
      status:
        http-mapping:
          UNKNOWN: SERVICE_UNAVAILABLE
    shutdown:
      enabled: true
    metrics:
      enabled: false
    prometheus:
      enabled: false
  metrics:
    export:
      prometheus:
        enabled: false
  endpoints:
    web:
      base-path: /
      exposure:
        include: info,health,metrics

security:
  ignored: /**