An environment file may define an arbitrary number of systems to connect from Benerator via a short reference.
Currently, relational databases and Kafka clusters and topics are supported.
An environment file has the suffix .env.properties
.
As an example, you may define the development environment as dev.env.properties
.
The settings for each system are listed in the environment file in the form:
<name>.<type>.<setting>=<value>
-
<name>
must be an identifier, -
<type>
must bedb
orkafka
, -
<setting>
must be one of the settings supported by this system type. The name may contain '.' characters.
Example:
crm.db.url=jdbc:h2:mem:benerator
crm.db.driver=org.h2.Driver
Additional individual settings that depend on the environment may be declared. Such settings must not have a '.' character in their name.
Example:
id_strategy=hilo
Lines starting with a hash # are considered comments and should be used to structure and explain the file's content:
# this is a comment line
Complete environment file example: dev.env.properties
# In the dev environment, the CRM system is located in a H2 databas
crm.db.url=jdbc:h2:mem:benerator
crm.db.driver=org.h2.Driver
crm.db.schema=PUBLIC
crm.db.user=sa
crm.db.read.only=true
# The procurement is a Kafka cluster on x.de
procurement.kafka.bootstrap.servers=x.de:9092
procurement.kafka.topic=orders
procurement.kafka.format=json
# Use hilo as default id generation strategy
id_strategy=hilo
You can put the environment file in different places.
If it should be shared with other users of the same project,
it is recommended to put it in a folder named 'conf' inside the project folder
(example location myproject/conf/dev.env.properties
).
For private system and password configurations, you can put an environment file
into the folder rapiddweller
under your user home directory
(example location ~/rapiddweller/dev.env.properties
on a macos/Unix system
or C:\Users\<your_user_name/rapiddweller/dev.env.properties>
on a Windows system).
Beware: For referencing an environment, have it in the proper folder and use just the environment name to reference it (not a path!)
In order to access the system, you need to reference it in the benerator setup.
The crm
database above would be referenced by:
<database id=“custs“ environment=“dev“ system=“crm“/>
or
<kafka-importer id=“orders“ environment=“dev“ system=“procurement“/>
You will likely set up your data generation or anonymization task on a development environment, fine tune and test it and finally roll it out on a performance test, showcase or functional testing system. Consider these different stages of the Benerator project.
If you are planning and naming your environment definitions wisely, it is a trivial configuration change to switch from one stage to another:
-
Choose abstract names that describe the roles of the systems, not the names, eg.
crm
,order
,procurement
etc. -
Define an environment file for each stage, eg.
dev
,functest
,perftest
etc. -
In each environment files, assign each role identifier the physical system of that stage.
-
Create a Benerator setup in which
stage
occurs as a variable, eg. as setting, environment property or setting in an included configuration properties file -
When declaring a system, use a script expression
{stage}
to reference the stage of a system
Now switching the stage means just switching the stage
flag:
<setting name="stage" value="dev"/>
...
<database id=“custs“ environment=“{stage}“ system=“crm“/>
...
<kafka-exporter id=“orders“ environment=“{stage}“ system=“procurement“/>
The previous database-only environment format (before Benerator 3.0.0) is still supported, but will be abandoned in a future release.