Skip to content

Configurations

Jump to bottom
Mike Ahlers edited this page May 27, 2019 · 34 revisions

Back to home

Configurations

Index

Introduction

This section explains how and what can be configured:

  • properties
  • xml

Properties

For Java installations there are two ways:

  • system properties
  • configuration file (requires a single system property, namely a ref (props) to the file)

For Docker installations there is only one way:

  • configuration files and Docker volume(s)

Properties overview

The table below shows a list of available properties (sorted by alphabet). Note that the property needs a prefix of -D when used as system property. Something like:

java -Dprops=/var/data/mock.properties -jar target/microservice-mock-x.y.z.jar
Property Example value Remarks
config /var/data/mock-configuration.xml Optional but recommended, the location of the configuration file of the micro service. If not provided, for demo purposes, the micro service falls back on a very simple embedded variant.
data /var/data/mock Optional but recommended, the location of the root folder for the resource files. Similar to config the jar comes with embedded resources to support the demo, i.e. the fall back variant.
log4j.configurationFile log4j2.xml Optional, use this to override the default logging configuration.
port 9999 Optional, and defaults to 9090.
props /var/data/mock.properties Optional but recommended, the location of the properties file.

XML overview

Basically this file defines the behaviour of the micro service, where the request URI is used to find a match. Based on this match, the response is generated which is defined in a text file. Note that caching is in place, meaning to say that for subsequent matches the file content is not read again but served from memory. This strategy makes the mock also ideal for performance testing.

Currently supported Http operations:

  • GET
  • POST

Regardless of operation, the resource fetching can be altered with the following attributes:

  • delay, in milli seconds (example: <resource delay="10000">mock/sample-post2.json</resource>)
  • error-code with error-rate, as in HTTP return code and error percentage (example: <resource error-code="500" error-rate="50">mock/sample-post2.json</resource>)
  • content-type, which is similar to the mime-type, it defines the data type of the response. This defaults to application/json.

If a request is made which does not match any url's (mappings) a 404 is returned.

The resource files, associated with the responses, are relative from the data folder specified with the data property.

Configuration of GET requests

Note that the configured values for the url attributes should be unique to avoid problems. Currently this is not enforced and it means the last one wins (as it overwrites the previous in memory). Example:

   ...
    <configuration type="GET" url="/mock/get">
        <resource>mock/sample-get.json</resource>
    </configuration>
    <configuration type="GET" url="/mock/*/get">
        <resource>mock/sample-get.json</resource>
    </configuration>
    <configuration type="GET" url="/mock/1/get">
        <resource>mock/sample-get.json</resource>
    </configuration>
    ...

Configuration of POST requests

Since version 1.6.0 the post requests can be made in XML as well as JSON.

XML

This is more complex as underwater xpath expressions are used in order to find out what matches. Note that namespaces are supported. Example:

   ...
   <configuration type="POST" url="/mock/post">
        <namespaces>
            <namespace prefix="technolords">urn:some:reference:1.0</namespace>
        </namespaces>
        <resource-groups>
            <resource-group>
                <xpath>/technolords:sample/technolords:message[@id = '1']</xpath>
                <resource>mock/sample-post1.json</resource>
            </resource-group>
            <resource-group>
                <xpath>/technolords:sample/technolords:message[@id = '2']</xpath>
                <resource delay="10000">mock/sample-post2.json</resource>
            </resource-group>
            <resource-group>
                <xpath>/technolords:sample/technolords:message[@id = '3']</xpath>
                <resource error-code="206" error-rate="50">mock/sample-post3.json</resource>
            </resource-group>
            <resource-group>
                <xpath>/technolords:sample/technolords:message[@id = '4']</xpath>
                <resource content-type="text/plain">mock/sample-post4.txt</resource>
            </resource-group>
        </resource-groups>
    </configuration>
   ...

... with for example the following posted message:

<sample xmlns="urn:some:reference:1.0">
    <message id="1"/>
</sample>

When the message above is posted, the content of the file 'sample-post1.json' is cached and then returned.

JSON

This is more complex as underwater jsonpath expressions are used in order to find out what matches. Example:

    ...
    <configuration type="POST" url="/json/1/get">
        <resource-groups>
            <resource-group>
                <jsonpath><![CDATA[ $.sample.message[?(@.id == '1')] ]]></jsonpath>
                <resource>mock/json/sample-post1.json</resource>
            </resource-group>
            <resource-group>
                <jsonpath><![CDATA[ $.sample.message[?(@.id == '2')] ]]></jsonpath>
                <resource>mock/json/sample-post2.json</resource>
            </resource-group>
        </resource-groups>
    </configuration>
    ...

... with for example the following posted message:

{
    "sample": {
        "message": {
            "id":"2"
        }
    }
}

When the message above is posted, the content of the file 'sample-post2.json' is cached and then returned.

Note that the microservice does not check whether the syntax of the jsonpath expression is correct. Best practise is to use the online validator for that first: https://jsonpath.herokuapp.com/

Configuration of service discoveries

This is optional, and basically means that the micro service will register itself automatically at the service discovery service.

Currently supported:

  • Consul
  • Eureka

It is possible to register at multiple service discoveries, for example:

<configurations xmlns="http://xsd.technolords.net">

    <!--+
        | Service registration (Registration and Eureka)
        +-->
    <service-registrations>
        <registration registrar="CONSUL" address="192.168.10.14" port="8500">
            <service address="192.168.10.10" port="9090" id="mock-1" name="mock-service" >
                <health-check enabled="true" interval="60s" deregister-after="90m"/>
            </service>
        </registration>
        <registration registrar="CONSUL" address="192.168.10.15" port="8500">
            <service address="192.168.10.11" port="9090" id="mock-2" name="mock-service" >
                <health-check enabled="true" interval="60s" deregister-after="90m"/>
            </service>
        </registration>
        <registration registrar="EUREKA" address="localhost" port="8080">
            <service address="192.168.10.10" port="9090" id="mock-1" name="mock-service" >
                <!-- Health check ignored, as it renews automatically -->
            </service>
        </registration>
    </service-registrations>

    ...

See also:

XSD

The XML will be validated against a schema, which is embedded in the jar file. For details, see here:

Clone this wiki locally