Setup configuration in the cloud

Out of the box the runtime uses an embedded cloud config server to retrieve the values of property files.
This server reads all property files it finds in the assigned folder, and the runtime asks the server for the value of the property it needs.

If you wish to run the cloud config server on its own, that is also possible. In a cloud environment you want to be sure that all nodes run under the same configuration so that the all show the same behavior. Having a local configuration on each node is difficult to maintain as any change to the configuration should be made to the configuration of each node at the same time. Therefore it is better to lead each node read the configuration from one central position. This is what the spring cloudconfig server can do.

Embedded spring cloud config reading from file system

The spring cloud config server reads its values from the file system (possibly on one central location).

spring.profiles.active=native
spring.cloud.config.server.native.searchLocations= file:D:/local-properties

Also see: Reading properties from file system

Embedded spring cloud config reading from Git

 It is possible to stop using files on the filesystem, and read property files out of git. This has advantages also the properties are version managed using a standard approach.

To be able to do this, these changes have to be made:

spring.cloud.config.server.git.uri: https://git.blueriq.com/config-repo.git
spring.cloud.config.server.git.basedir=target/config
spring.cloud.config.server.git.username=<git_username>
spring.cloud.config.server.git.password=<git_password>

Also read: Reading properties from Git

Creating your own standalone spring cloud config server

To run your own server use the spring-cloud-config-server dependency and @EnableConfigServer. If you set spring.config.name=configserver the app will run on port 8888 and serve data from a sample repository.

You need to have the property spring.cloud.config.server.native.searchLocations to point to the searchlocation, and you need the property:  spring.profiles.active=native to tell the server to not use GIT.

@Configuration
@EnableAutoConfiguration
@EnableConfigServer
public class Application {

public static void main(String[] args) {
         SpringApplication.run(ConfigServerApplication.class, args);
         }
}

Excluding the embedded server can be achieved by adding the following dependency with exclusion to your custom pom.xml.

<dependency>
    <groupId>com.blueriq</groupId>
    <artifactId>blueriq-runtime</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Creating documents

To generate a document the runtime uses an IBEX renderer. This renderer requires two adjustments by the customer before being usable.

(1) No physical paths can be used in a cloud environment. Therefore, the folder containing the xsl files (required to generate documents) must be inside the WAR. To do this you must unpack the WAR and add the folder with the xsl files to the WEB-INF/classes/ folder inside the unpacked WAR.
When doing so, the property blueriq.documents.base-folder must be given the value "classpath:/", using this value the runtime uses the documents folders inside the WAR.

(2) The IBEX renderer also uses windows fonts when creating a pdf-A file. It is not possible for us to include these fonts due to copyright limitations. Therefore, it is required for customers to add them to the WAR themselves. To do this the WAR has to be unpacked and the windows fonts should be added to the WEB-INF/classes/ folder inside the unpacked WAR.

(3) Finally repack the WAR.

Usage of exports

When using the spring cloud config server embedded, all the exports can be placed in the exports folder in the spring.config.location.
However if config server is running standalone, these exports must be explicitly named with the full path to each file in the application.properties file.
Resulting in a line like: blueriq.exports.files=file:///d/exports/example.zip, file:///d/exports/example2.zip, etc.
These exports must be on the same server as the runtime is running on.