Page History
Setup configuration in the cloud
Out of the box blueriq the runtime uses an embedded cloudconfig cloud config server to retrieve the values of property files.
This server reads all property files it finds in the assigned folder, and blueriq in order the runtime asks the server for the value of the property it wants.
Creating documents
To generate a document we use an IBEX renderer.
This renderer requires some adjustments by the customer before being usable.
For starters, the folder containing the xsl files (required to generate documents) must be in the WAR, since we cannot use the physical paths any more.
To do this you must unpack the war and add the folder to the src/main/resources folder of the application server used.
When doing so the property blueriq.documents.base-folder must be given the value "classpath:/", using this value Blueriq will use the documents folders inside the WAR.
This renderer also uses windows fonts when creating a pdf-A file.
We cannot include these fonts due to copyright infringement so it's required for customers to add them to the WAR.
To do this you must unpack the war and add the windows fonts to the src/main/resources folder of the application server.
When using the spring cloud config server embedded, all the exports can be placed in the exports folder in the aquima.home folder.
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=D:\exports\example.zip, D:\exports\example2.zip, etc.
These exports must be on the same server as the runtime is running on.
Possible changes:
Git
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).
Code Block | ||
---|---|---|
| ||
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 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, some change these changes have to be made:bootstrap.properties - for using the file-system
spring:
profiles:
active: native
cloud:
config:
server:
native:
searchLocations: file:D:/local-properties
bootstrap.properties - for using GIT - basic authentication
spring:
cloud:
config:
server:
git:
uri:
Code Block | ||
---|---|---|
| ||
spring.cloud.config.server.git.uri: https://git.blueriq.com/config-repo.git |
basedir: target/config
username: <git_username>
password: <git_password>
However, using git does result in not being able to use the development plugin the same way as it does without GIT.
This is because it can only read from git, but cannot write. So while it does show all the settings, you cannot change them and save them.
They will run during your session, but when it reloads (manually, or new session) all the original settings are being read from GIT again, and be back to original.
spring.cloud.config.server.git.basedir=target/config
spring.cloud.config.server.git.username=<git_username>
spring.cloud.config.server.git.password=<git_password> |
UI Text Box | ||
---|---|---|
| ||
Please note that when using GIT the development plugin has limited functionality. As properties can only be read from GIT and not written, the development plugin can only read values and not write them. Any changes made with the development toolbar work during your session, but starting a new session or reloading the application will read the original values from GIT again. This is only an issue for development or test environments, as the development plugin is not present on production environments. |
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.
Code Block |
---|
@Configuration
@EnableAutoConfiguration
@EnableConfigServer
public class Application {
public static void main(String[] args) {
SpringApplication |
Standalone instead of embedded
If you wish to run the cloud config server on it's own, that's also possible.
To accomplish this, some changes must be made:
In the bootstrap.properties you must place the url to reach the server
(example:spring.cloud.config.uri=http://ipadress:portnumber)
Add the following annotation on the standalone config server:
@Configuration
@EnableAutoConfiguration
@EnableConfigServer
public class Application {
SpringApplication
.run(ConfigServerApplication.class, args); |
}
}
}
} |
UI Text Box | ||
---|---|---|
| ||
Connecting the Blueriq Runtime to a standalone Config Server requires you to exclude the spring-cloud-config-server.jar from your webapplication. If you do not exclude it, then the embedded server is still used. |
Excluding the embedded server can be achieved by adding the following dependency with exclusion to your custom pom.xml.
Code Block | ||
---|---|---|
| ||
<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
When creating documents with the runtime in the cloud, you can not rely on a absolute path to refer to the necessary documents, because the runtime will then search for the documents on the hard drive where the runtime is running.
This means that the documents folder used by the documents renderer cannot be located in the spring.config.location, instead the property blueriq.documents.base-folder
needs to be used.
We advice to package the documents folder inside the WAR. When doing so the property blueriq.documents.base-folder
must be given the value classpath:/
. With this value the runtime uses the documents folders inside the WAR.
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.
For the following changes we have no realease date, but they are expected to be made.
The development plugin cannot write in property files that are read out of GIT. This is something we want to keep.
However this results in the fact that the development plugin can only read properties, and this changes it usage.
Either the development plugin, or the compatibilty with GIT based property storing, will be changed.
Currently static resources are not managed by the spring cloud config server(for example frontend sources and exports).
When we make the spring cloud config server manage those aswell, they can be versioned when using GIT.