Spring Boot & Apache CXF – XML validation and custom SOAP faults

What about XML? Can’t we validate our data with XML easily? Just take the XML schema and … erm. What about the reaction to the validation´s outcome? Most of the time, we have to tailor this response and build a custom SOAP fault. But how does this work with Spring Boot and Apache CXF?

Spring Boot & Apache CXF – Tutorial

Part 1: Spring Boot & Apache CXF – How to SOAP in 2016
Part 2: Spring Boot & Apache CXF – Testing SOAP web services
Part 3: Spring Boot & Apache CXF – XML validation and custom SOAP faults
Part 4: Spring Boot & Apache CXF – Logging & Monitoring with Logback, Elasticsearch, Logstash & Kibana
Part 5: Spring Boot & Apache CXF – SOAP on steroids fueled by cxf-spring-boot-starter

In the preceding parts we learned how a SOAP web service is configured and tested in detail with Spring Boot and Apache CXF. Now we want to look at a more particular case. There are some big web service specifications out there (look e.g. at the BiPro specs) that require our SOAP endpoint to react with a 100% XML schema compliant response in every situation – even when somebody sends bad XML requests which generate errors inside Apache CXF´s XML processing.

Given a request that could be processed successfully, our response will always be 100% XML schema compliant. We only have to follow this blog series first part´s guidelines and generate the Java classes from our WSDL and XSDs. As usual, there is a new GitHub project waiting in our tutorial repository – if you want to give it a try. 🙂

As a starting point we´ll use the preceding part´s project for now and fire up the SimpleBootCxfApplication with the help of a “Run as…” . Once our SOAP endpoint is up and running (check http://localhost:8080/soap-api/WeatherSoapService_1.0 ), we send a valid request against it with SoapUI :

1<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gen="http://www.codecentric.de/namespace/weatherservice/general">
2   <soapenv:Header/>
3   <soapenv:Body>
4      <gen:GetCityForecastByZIP>
5         <gen:ForecastRequest>
6            <gen:ZIP>99998</gen:ZIP>
7            <gen:flagcolor>bluewhite</gen:flagcolor>
8            <gen:productName>ForecastProfessional</gen:productName>
9            <gen:ForecastCustomer>
10            <gen:Age>30</gen:Age>
11            <gen:Contribution>5000</gen:Contribution>
12            <gen:MethodOfPayment>Paypal</gen:MethodOfPayment>
13            </gen:ForecastCustomer>
14         </gen:ForecastRequest>
15      </gen:GetCityForecastByZIP>
16   </soapenv:Body>
17</soapenv:Envelope>

Also, the reply should look like a valid SOAP response:

1<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
2   <soap:Body>
3      <GetCityForecastByZIPResponse xmlns="http://www.codecentric.de/namespace/weatherservice/general" xmlns:ns2="http://www.codecentric.de/namespace/weatherservice/datatypes" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" xmlns:ns4="http://www.codecentric.de/namespace/weatherservice/exception">
4         <GetCityForecastByZIPResult>
5            <Success>true</Success>
6            <State>Deutschland</State>
7            <City>Weimar</City>
8            <WeatherStationCity>Weimar</WeatherStationCity>
9            <ForecastResult>
10               <ns2:Forecast>
11                  <ns2:Date>2016-06-06T17:17:06.903+02:00</ns2:Date>
12                  <ns2:WeatherID>0</ns2:WeatherID>
13                  <ns2:Desciption>weather forecast Weimar</ns2:Desciption>
14                  <ns2:Temperatures>
15                     <ns2:MorningLow>0°</ns2:MorningLow>
16                     <ns2:DaytimeHigh>90°</ns2:DaytimeHigh>
17                  </ns2:Temperatures>
18                  <ns2:ProbabilityOfPrecipiation>
19                     <ns2:Nighttime>5000%</ns2:Nighttime>
20                     <ns2:Daytime>22%</ns2:Daytime>
21                  </ns2:ProbabilityOfPrecipiation>
22               </ns2:Forecast>
23            </ForecastResult>
24         </GetCityForecastByZIPResult>
25      </GetCityForecastByZIPResponse>
26   </soap:Body>
27</soap:Envelope>

Standard SOAP faults

Approaching the topic for the first time, one could google something like “configure XML schema validation Apache CXF” or the like. The results are somewhat misleading. For example, look at the Apache CXF FAQ . You´ll find thousands of different variants to activate XML schema validation in Apache CXF. And even worse, the examples provided nearly all show up with Spring XML configuration, which we left behind already . But the configuration of the XML schema validation isn´t our real problem. And funnily enough, XML schema validation is already activated in our setup with Spring Boot and CXF. Just fire a non-valid XML request against our endpoint (which we´ll do in a minute). Instead we should shift our focus to the reaction onto a validation error. All the web service specifications define not if, but the terms how to react.

In case of an error, Apache CXF reacts in form of a standard SOAP fault. We´ll try that out now. This time we´ll send a request against our endpoint that doesn´t comply to our XML schema. Actually our SOAP request´s root element has to be spelled as GetCityForecastByZIP according to the weather-general.xsd , which is imported into our WSDL. But because we want to provoke an error, we´ll change the root tag to GetCityForecastByZIPfoo and send it against our endpoint:

1<?xml version="1.0" encoding="UTF-8"?>
2<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gen="http://www.codecentric.de/namespace/weatherservice/general">
3   <soapenv:Header/>
4   <soapenv:Body>
5      <gen:GetCityForecastByZIPfoo>
6         <gen:ZIP>99425</gen:ZIP>
7      </gen:GetCityForecastByZIPfoo>
8   </soapenv:Body>
9</soapenv:Envelope>

Our (still running) endpoint should react with a SOAP response like this:

1<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
2   <soap:Body>
3      <soap:Fault>
4         <faultcode>soap:Client</faultcode>
5         <faultstring>Unexpected wrapper element {http://www.codecentric.de/namespace/weatherservice/general}GetCityForecastByZIPfoo found.   Expected {http://www.codecentric.de/namespace/weatherservice/general}GetCityForecastByZIP.</faultstring>
6      </soap:Fault>
7   </soap:Body>
8</soap:Envelope>

Now our web service specification defines its own type of exception in case of an error. It´s called WeatherException, which is also defined inside the mentioned weather-exception.xsd . This exception is appended to the SOAP operations with the wsdl:fault tag inside our WSDL . It defines the following structure:

1<s:element name="WeatherException">
2    <s:complexType>
3        <s:sequence>
4            <s:element name="Uuid" type="s:string"/>
5            <s:element name="timestamp" type="s:dateTime"/>
6            <s:element name="businessErrorId" type="s:string"/>
7            <s:element name="bigBusinessErrorCausingMoneyLoss" type="s:boolean"/>
8            <s:element name="exceptionDetails" type="s:string"/>
9        </s:sequence>
10    </s:complexType>
11</s:element>

Our specification states that the element WeatherException and its children should be put beneath the soap:Fault element, which resides inside the detail tag. Such standards are well known from “enterprise WSDLs”. So we´ll have to implement this requirement to provide a specification-compliant SOAP endpoint.

Not XML schema compliant vs. invalid XML

In case of an error, our WeatherException should be returned inside the soap:Fault/detail – whatever the error might be. So our implementation should be capable of handling not only the errors based on non schema compliant XML, but also if somebody sends XML that is per se completely incorrect. Here are some example requests with a broken XML header – starting with a missing right angle bracket:

1<?xml version="1.0" encoding="UTF-8"?

…a non-concluded tag somewhere inside the document:

1<?xml version="1.0" encoding="UTF-8"?>
2<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gen="http://www.codecentric.de/namespace/weatherservice/general">
3   <soapenv:Header/>
4   <soapenv:Body>
5      notRelevantHere />
6   </soapenv:Body>
7</soapenv:Envelope>

…a broken SOAP header:

1<?xml version="1.0" encoding="UTF-8"?>
2<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gen="http://www.codecentric.de/namespace/weatherservice/general">
3   <soapenv:Header/
4   <soapenv:Body>
5   ...

and many more.

Looking at these examples, the requirement to handle such broken requests makes a lot of sense. Especially if we follow the ideas from part 1 of this tutorial . Because then, we rely on 100% XML schema compliant messages – which also implies that those messages contain correct XML. Our framework would otherwise react with cryptic fault messages if the requests aren´t valid.

Apache CXF interceptor chains

So how do we approach this problem? As always many roads lead to Rome. In the following I´ll show a way that worked quite well and has been approved in my current projects. Let´s first have a look at Apache CXFs architecture. The docs show that CXF´s processing relies on interceptors, which are invoked sequentially, one at a time. They are arranged like pearls on a string and are organized in phases . There´s an incoming interceptor chain, where at the end our web service implementation is invoked, as well as an outgoing interceptor chain, which handles the response processing. A image says more than a thousand words, so let´s look at this one:

The incoming web service calls always run through these chains. If an error occurs inside an incoming chain interceptor, the outgoing interceptor chain is provided with the error information and run through in opposite direction. So if for example an error occurs in the phase READ, the succeeding incoming interceptor chain´s phases aren´t invoked any more. By the way: Apache CXF provides an extra outgoing fault interceptor chain specifically for handling every error. And luckily enough, we can hook our own custom interceptors into these chains, so that we are able to react on every event that might appear.

This knowledge is quite useful in our case. If an request contains incorrect XML, the incoming chain stops in the UNMARSHAL phase at the latest and the outgoing fault interceptor chain is called. So we just have to implement an Interceptor who witnesses as many errors as possible and enables us to react on them. The eye-catching phase here is org.apache.cxf.phase.Phase.PRE_STREAM. With that phase we are as far ahead in the chain as possible to not miss any error. We have to derive our Interceptor from org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor and override the method void handleMessage(T message) throws Fault. Additionally we provide the phase inside the constructor while calling the super() method:

1public class CustomSoapFaultInterceptor extends AbstractSoapInterceptor {
2 
3    private static final SoapFrameworkLogger LOG = SoapFrameworkLogger.getLogger(CustomSoapFaultInterceptor.class);
4 
5    public CustomSoapFaultInterceptor() {
6        super(Phase.PRE_STREAM);
7    }
8 
9    @Override
10    public void handleMessage(SoapMessage soapMessage) throws Fault {
11        Fault fault = (Fault) soapMessage.getContent(Exception.class);
12        Throwable faultCause = fault.getCause();
13        String faultMessage = fault.getMessage();
14 
15        if (containsFaultIndicatingNotSchemeCompliantXml(faultCause, faultMessage)) {  
16            WeatherSoapFaultHelper.buildWeatherFaultAndSet2SoapMessage(soapMessage, FaultConst.SCHEME_VALIDATION_ERROR);
17        }
18        else if (containsFaultIndicatingSyntacticallyIncorrectXml(faultCause)) {
19            WeatherSoapFaultHelper.buildWeatherFaultAndSet2SoapMessage(soapMessage, FaultConst.SYNTACTICALLY_INCORRECT_XML_ERROR);          
20        }
21    }
22 
23    ...

Detecting XML validation errors

First of all we extract the faultCause and faultMessage inside the overridden method handleMessage(SoapMessage soapMessage). Looking at the latter you could find the exact same inside the standard SOAP fault tag faultstring. Based on those two variables, we are able to detect which error occured.

Sadly the CXF API does not provide any help and we have to implement the methods containsFaultIndicatingNotSchemeCompliantXml() and containsFaultIndicatingSyntacticallyIncorrectXml() ourselves. To figure out how Apache CXF reacts to non schema compliant or incorrect XML, one could think about many test cases and send each of them against our SOAP endpoint. This could get quite sophisticated and cumbersome. Luckily there is already a bunch of test cases inside our example project that we could use. As we try every one of them out, some patterns emerge that we could use to build our detection methods:

1. non XML-schema-compliant

The faultCause contains a javax.xml.bind.UnmarshalException if the request message does contain non schema compliant XML. Besides we check if there´s a missing closing tag. In this case we have to check whether the faultMessage contains an “Unexpected wrapper element”:

1private boolean containsFaultIndicatingNotSchemeCompliantXml(Throwable faultCause, String faultMessage) {
2    if(faultCause instanceof UnmarshalException
3        || isNotNull(faultMessage) && faultMessage.contains("Unexpected wrapper element")) {
4        return true;
5    }
6    return false;
7}

2. generally incorrect XML

There are three kinds of errors indicating that the request message contains incorrect XML itself. Either the faultCause contains a com.ctc.wstx.exc.WstxException, the wrapped cause is a com.ctc.wstx.exc.WstxUnexpectedCharException or the faultCause contains an IllegalArgumentException:

1private boolean containsFaultIndicatingSyntacticallyIncorrectXml(Throwable faultCause) {
2    if(faultCause instanceof WstxException
3        // If Xml-Header is invalid, there is a wrapped Cause in the original Cause we have to check
4        || isNotNull(faultCause) && faultCause.getCause() instanceof WstxUnexpectedCharException
5        || faultCause instanceof IllegalArgumentException) {
6        return true;
7    }
8    return false;
9}

Building custom SOAP faults

OK, now ne “know” that some invalid or incorrect XML request tried to frighten our endpoint. Let´s now tailor our custom SOAP fault. The class WeatherSoapFaultHelper is able to change the SOAP fault to our needs. The method buildWeatherFaultAndSet2SoapMessage(SoapMessage message, FaultConst faultContent) extracts the org.apache.cxf.interceptor.Fault out of the org.apache.cxf.binding.soap.SoapMessage. Now we have the fault where we could set our desired message and detail:

1public static void buildWeatherFaultAndSet2SoapMessage(SoapMessage message, FaultConst faultContent) {
2    Fault exceptionFault = (Fault) message.getContent(Exception.class);
3    String originalFaultMessage = exceptionFault.getMessage();
4    exceptionFault.setMessage(faultContent.getMessage());
5    exceptionFault.setDetail(createFaultDetailWithWeatherException(originalFaultMessage, faultContent));
6    message.setContent(Exception.class, exceptionFault);
7}

It uses the other class WeatherOutError inside the package transformation to arrange the actual WeatherException. As you for sure remember, our specification states that the WeatherException has to be put into the detail tag in our soap:Fault:

1private static final de.codecentric.namespace.weatherservice.exception.ObjectFactory objectFactoryDatatypes = new de.codecentric.namespace.weatherservice.exception.ObjectFactory();
2 
3public static WeatherException createWeatherException(FaultConst faultContent, String originalFaultMessage) {
4    // Build SOAP-Fault detail <datatypes:WeatherException>
5    WeatherException weatherException = objectFactoryDatatypes.createWeatherException();        
6    weatherException.setBigBusinessErrorCausingMoneyLoss(true);
7    weatherException.setBusinessErrorId(faultContent.getId());
8    weatherException.setExceptionDetails(originalFaultMessage);
9    weatherException.setUuid("ExtremeRandomNumber");
10    return weatherException;
11}

There´s one interesting aspect about this: Apache CXF kicks out the root element of that piece of XML that one tries to set into soap:Fault/detail. Therefore we have a short look into the code of the method createFaultDetailWithWeatherException(String originalFaultMessage, FaultConst faultContent) of our WeatherSoapFaultHelper (exception handling is left out of this here for readability reasons):

1private static Element createFaultDetailWithWeatherException(String originalFaultMessage,  FaultConst faultContent) {
2    Document weatherExcecption = XmlUtils.marhallJaxbElementIntoDocument(WeatherOutError.createWeatherException(faultContent, originalFaultMessage));
3    return XmlUtils.appendAsChildElement2NewElement(weatherExcecption);
4}

With a little help of our XmlUtils we marshal the WeatherException into a org.w3c.dom.Document . Because the method Fault.setDetail() expects a org.w3c.dom.Element and kicks the root element, we prepend our WeatherException Document with a mock root element which can be thrown away by Apache CXF later on.

Is there a way to build test cases using invalid XML requests?

Now we have an implementation that is said to detect all the cryptic errors Apache CXF produces when requests are sent containing invalid or incorrect XML. Additionally we have a bunch of test cases that we could manually send to our SOAP endpoint (e.g. with SoapUI ). But do we have to believe the author? Fortunately not 🙂 Just think of all the things that could break if there´s a small incline of a version number in some used libraries or Apache CXF itself.

Here our knowledge from the preceding part Testing SOAP web services comes in handy. We just have to write some automatically executable tests. Ideally some single system integration tests that fire up our SOAP server endpoint inside the test´s execution.

And as we saw in the paragraph “How to deal with your test cases”, we could also load our test files and marshal them directly into the appropriate object. Or couldn´t we? No, sadly not. I guess you already know why. Because we want to send requests containing invalid XML, we´re not able to use the power of our JAX-B marshallers. If we try to marshal them, we would get similar errors as Apache CXF would throw in its outbound chains in case of an error triggered from invalid XML.

But we still want to be able to write some tests that we could automate. And there´s a way to do it. The core problem is just to send text messages containing our invalid XML via HTTP POST against our endpoint. All we need is a mature HTTP client and we are able to use our invalid XML test files. OK, let´s go! First of all we extend our pom by adding two new dependencies: org.apache.httpcomponents.httpclient and org.apache.httpcomponents.fluent-hcs. But before starting to use our HTTP client, we´ll have a short look at a SOAP message including its HTTP headers that is SOAP 1.1 compliant (in SoapUI just click on “Raw”):

1POST http://localhost:8080/soap-api/WeatherSoapService_1.0 HTTP/1.1
2Accept-Encoding: gzip,deflate
3Content-Type: text/xml;charset=UTF-8
4SOAPAction: "http://www.codecentric.de/namespace/weatherservice/GetCityForecastByZIP"
5Content-Length: 289
6Host: localhost:8080
7Connection: Keep-Alive
8User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
9 
10<?xml version="1.0" encoding="UTF-8"?>
11<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:gen="http://www.codecentric.de/namespace/weatherservice/general">
12   <soapenv:Header/>
13   <soapenv:Body>
14      notRelevantHere />
15   </soapenv:Body>
16</soapenv:Envelope>

Besides the content type, what´s really important here is the HTTP header field SOAPAction. It should contain the SOAP operation, according to the SOAP specification . If not present, our endpoint will complain. But what´s the exact value we have to put in there? This is defined inside the WSDL in the soap:operation´s tag attribute soapAction, which both belong to the wsdl:operation definition. So if we like to use our HTTP client – e.g. via the fashionable fluent API – we have to set the SOAPAction HTTP header correctly. And don´t forget the quotes (which you have to escape)!

1Response httpResponseContainer = Request
2            .Post("http://localhost:8090/soap-api/WeatherSoapService_1.0")
3            .bodyStream(xmlFile, ContentType.create(ContentType.TEXT_XML.getMimeType(), Consts.UTF_8))
4            .addHeader("SOAPAction", "\"http://www.codecentric.de/namespace/weatherservice/GetCityForecastByZIP\"")
5            .execute();
6 
7HttpResponse httpResponse = httpResponseContainer.returnResponse();

These few lines of code suffice so that we can torture our endpoint with weird XML requests. As a somehow enhanced version the class SoapRawClient inside our example project does exactly that. We just configure it as a Spring bean in the WebServiceSystemTestConfiguration and provide it with our generated Service Endpoint Interface (SEI). It then dynamically derives the correct SOAPAction header form the SEI. Additionally the method callSoapService(InputStream xmlFile) will give us a SoapRawClientResponse , which is really helpful while crafting our test cases.

single system integration tests with invalid XML

Now we have all the tools in place to finally write our desired test cases. Therefore we again use our knowledge from the last part of this tutorial – especially considering single system integration tests. Because they automatically fire up our SOAP endpoint for the period of the test´s execution. Besides, we know how to load our XML testcases and provide them as InputStream via Spring’s org.springframework.core.io.Resource in a really straightforward manner, without having to grapple with the file handling ourselves.

Our testcase WeatherServiceXmlErrorSystemTest is based on the same principles we know from the last part´s WeatherServiceXmlFileSystemTest . So let´s look into the details. We inject our SoapRawClient and configure the test files to load:

1@RunWith(SpringJUnit4ClassRunner.class)
2@SpringApplicationConfiguration(classes=SimpleBootCxfSystemTestApplication.class)
3@WebIntegrationTest("server.port:8090") 
4public class WeatherServiceXmlErrorSystemTest {
5 
6    @Autowired private SoapRawClient soapRawClient;
7 
8    @Value(value="classpath:requests/xmlerrors/xmlErrorNotXmlSchemeCompliantUnderRootElementTest.xml")
9    private Resource xmlErrorNotXmlSchemeCompliantUnderRootElementTestXml;
10 
11    @Value(value="classpath:requests/xmlerrors/xmlErrorSoapBodyTagMissingBracketTest.xml")
12    private Resource xmlErrorSoapBodyTagMissingBracketTestXml;
13 
14    // ... and many more

After that we provide every test file with its own test method. All these methods refer to the generalized method checkXmlError(), to which we forward the appropriate test file and the expected kind of error class. The latter are defined in FaultConst , which we already used in the paragraph “Building custom SOAP faults” to build our SOAP fault:

1@Test
2public void xmlErrorNotXmlSchemeCompliantUnderRootElementTest() throws InternalBusinessException, IOException {
3    checkXMLError(xmlErrorNotXmlSchemeCompliantUnderRootElementTestXml, FaultConst.SCHEME_VALIDATION_ERROR);
4}
5 
6@Test
7public void xmlErrorSoapBodyTagMissingBracketTest() throws InternalBusinessException, IOException {
8    checkXMLError(xmlErrorSoapBodyTagMissingBracketTestXml, FaultConst.SYNTACTICALLY_INCORRECT_XML_ERROR);
9}
10 
11// ... and many more

And finally we´ll see some asserts in action. 🙂 Inside the checkXmlError() method we check our resulting SOAP faults thoroughly. Among others we look for a HTTP status code 500 and the tag faultstring should contain a message from our FaultConst . For simplicity reasons we use the SoapRawClientResponse´s method getFaultstringValue(), which gets us the faultstring out of the HTTP message. With the help of the convenient getUnmarshalledObjectFromSoapMessage(Class jaxbClass) we also get our WeatherException out of the HTTP message. After that we can throw our assert statements:

1private void checkXmlError(Resource testFile, FaultConst faultContent) throws InternalBusinessException, IOException {
2    // When
3    SoapRawClientResponse soapRawResponse = soapRawClient.callSoapService(testFile.getInputStream());
4 
5    // Then
6    assertNotNull(soapRawResponse);
7    assertEquals("500 Internal Server Error expected", 500, soapRawResponse.getHttpStatusCode());
8    assertEquals(faultContent.getMessage(), soapRawResponse.getFaultstringValue());
9 
10    de.codecentric.namespace.weatherservice.exception.WeatherException weatherException = soapRawResponse.getUnmarshalledObjectFromSoapMessage(de.codecentric.namespace.weatherservice.exception.WeatherException.class);       
11    assertNotNull("<soap:Fault><detail> has to contain a de.codecentric.namespace.weatherservice.exception.WeatherException",  weatherException);
12 
13    assertEquals("ExtremeRandomNumber", weatherException.getUuid());
14    assertEquals("The correct BusinessId is missing in WeatherException according to XML-scheme.", faultContent.getId(), weatherException.getBusinessErrorId());
15}

One important note here: Using the fully qualified name of your exception (e.g. de.codecentric.namespace.weatherservice.exception.WeatherException) you avoid confusion with identically named classes (de.codecentric.namespace.weatherservice.WeatherException). One could argue here that this should be handled by renaming the exceptions. But sadly this is something you´ll not be able to do in real world projects, where the WSDL is a given and immutable artifact. Just have a look at big enterprisey web services like BiPro.

Now we achieved everything we wanted: Our framework validates the XML requests against the XML schemas and we decide what the SOAP faults will look like. At the same time we can test all this automatically while being able to send arbitrary strange XML requests against our SOAP endpoint. Overall this solution is rather complex from an Apache CXF user´s point of view. Configuring custom SOAP faults as a reaction to XML validation errors could be something far more easy to do. But for now it should work very well for us.

As always, there are things left to look at. Just think about the weird namespaces or the monitoring of SOAP messages with the elastic stack . We´ll have a look at these topics in the upcoming blog posts.