Configuration

There are two applications that we will need to provide an application.properties file to configure.

General information about usage of application.properties file with Spring

To run the application in "dev" mode, there is already an application-dev.properties file in the project. You can modify it as you wish. Another option is to copy the file as "application.properties" to the same resources folder. Note that this is by git as we don't want to have a global configuration file in the application.

If you want to use the jar file provided in the release part, as there is no application.properties file included in the jar file itself, you will need to put "application.properties" file to the same folder that your jar file is.

For more information about this, you can visit Running using Maven page.

Scenario generator (server)

For the scenario generator's main application (called server), as currently, we did not need to have an auto-discovery mechanism, we will need to tell the applications which agents exist.

agents.easyTravel.name=easyTravel
agents.easyTravel.description=EasyTravel helps you travel the world
agents.easyTravel.url=https://127.0.01:9008

agents.badges.name=myApp
agents.badges.description=My beautiful application
agents.badges.url=http://localhost:9010

For each agent, you will need to have a unique key under agents key. Name also should be unique. Url is used to access to the agents, so it has to be a valid one.

Scenario generator agent

As an agent can run one application at the same time, and there can more than one supported application in the agent itself, we will need to tell the application to run for which application. Let's say agent will work with the easyTravel application. (Supported by default)

scenario.application=easyTravel

This config is to tell the application to start for which application. Related service will be registered accordingly. You can see ScenarioServiceConfig.java file to understand more about this.

---

easyTravel.apiUrl=http://localhost:8091

In easyTravel's case, we will need some additional configs. So, we have EasyTravelConfigurationProperties.java file to access easyTravel related configs. If you need something like this for your own application, you can create one and use it in the same way.

---

easyTravel.availableScenarios[0].id=CPULoad
easyTravel.availableScenarios[0].name=Long response times for searching/booking activities
easyTravel.availableScenarios[0].description=Long response times for searching/booking activities problem that consumer faces is caused by high CPU usage in the backend process that provokes an unhealthy host state. The additional CPU time is triggered in 8 separate threads independent of any searching/booking activity.
easyTravel.availableScenarios[0].minTime=20
easyTravel.availableScenarios[0].maxTime=200

easyTravel.availableScenarios[1].id=GarbageCollectionEvery10Seconds
easyTravel.availableScenarios[1].name=Periodic application freeze
easyTravel.availableScenarios[1].description=Application is frozen for a moment because of a manual full garbage collection on the Business Backend process when searching for journeys. The GC is triggered every 10 seconds.
easyTravel.availableScenarios[2].id=CreditCardCheckError500
easyTravel.availableScenarios[2].name=Credit card check error
easyTravel.availableScenarios[2].description=Simulates an exception while communicating with the native application. This is triggered when the credit card is validated as part of booking a journey in the customer web frontend.

Scenarios need some basic configurations. In easyTravel's case, we decided to restrict the available error patterns so we have the availableScenarios config. This config is an array and you can define as many error patterns as you want. You need to be careful about giving the exact name of the error pattern in easyTravel to the id field. You can define your own name and description for easyTravel error patterns by filling name and description fields in the config.

We also have a config that specifies the minimum and maximum time allowed for a scenario. In easyTravel's case, we decide this through config (may be different for other apps). If you don't specify min and max time for a scenario, it is set as min=60 and max=180 seconds by default.