You're viewing legacy documentation for API Fortress (deployed via an on-premises container). To view documentation for the new SaaS version of API Fortress — now known as Sauce Labs API Testing and Monitoring (with Sauce Connect tunnels) — see API Testing on the Sauce Labs Cloud.
The default Bloodhound configuration module is file driven. All configuration files are located in the
config_loader section describes which configuration loading mechanism needs to be used. Modules can be created to store and load configuration in other locations and systems, such as databases.
mime.text_content_types_contain array contains a list of substrings meant to help the system detecting which content types are meant to represent textual content.
See Fine tuning for more settings.
|describes where the logging configuration file is located|
|tells the Bloodhound web server which port it should bind to (default is |
|true if the web server needs to compress its output (default is |
|a comma-separated list of mime types that should undergo compression|
|the smallest stream of that should trigger compression|
|to configure secure connections, the key-store type (default is |
|the location of the |
|the password of the |
Certain operations may require some short lived caching. This is where that caching happens.
configsis a cache meant to store the system configuration, so that it doesn't need to be read multiple times in a short period of time.
expressionsis a cache meant to store the interpreted version of Spring SpEL scripts.
api_keysis a cache used by the default ApiKeysFilterActor to store API keys in memory.
http_routersis a cache used by the load-balancing functionality.
New caches can be introduced to support other modules if necessary.
The configuration of the logging system.
This is where all actors involved in flows get listed and configured. If an actor is going to be used in a flow, it needs to appear here.
A typical implementer is configured like this:
- id: request
idthe ID of the actor
classthe class implementing the actor
typea type among
instances(optional) the number of instances of the actor to be instantiated
thread_pool(optional) the name of the thread pool assigned to this actor
This file also defines thread pools in the
thread_pools section. Thread pools describe pools of threads to be assigned to actors. A typical thread pool looks like this:
The key of the thread pool (in this case
default) is a single word that identifies the thread pool. A
default thread pool is always required.
minis the minimum number of threads created for this thread pool.
maxis the maximum number of threads created for this thread pool (the threads exceeding
minget decommissioned when not in use)
factoris a multiplier that depends on the server Bloodhound is operating on and it works like this
factor*cpu=n_of_threads. A way to make the system more adaptive to the context.
Check out the Fine Tuning Guide for further readings on this topic.
This file connects the inbound requests to the outbound destinations.
A typical backend looks like this:
- prefix: '127.0.0.1/any'
prefixhow the inbound request will look like, without protocol and port.
upstreamwhere to send the request to. If this field is omitted, the full request URL will be used (useful in conjunction with a forward proxy)
flow_idwhich flow needs to be used.
Everything exceeding prefix on the right side will be passed over to the upstream.
In this example, a request sent to:
is then forwarded to:
headers filter can also be applied. For example:
- prefix: '\[^/\]\*/only/with/header'
- prefix: '\[^/\]\*/only/with/header'
x-my-header header is present and is equal to
anything, the first configuration will be chosen. If the given header is equal to
mastiff, the second configuration will be chosen.
It is also possible to pass extra meta-variables to the flow when a specific flow is picked up. For example:
- prefix: '\[^/\]\*/with/meta'
The meta variables can be retrieved in
evaluated fields by using the following syntax: