In Chapter 1, Introducing the Concepts and Terminology when we looked at some of the broader integration concepts, we introduced the idea of publish and subscribe (or pub-sub for short) such as enabling a single event to be sent to multiple interested parties. In this chapter, we are going to bring the idea alive by creating an integration that represents a flight update being received and then sent onto one then multiple destinations (which could range from websites to other aviation-related systems). The services we are going to build don not directly map to what is offered by websites such as FlightAware. But we will talk about the steps to connect sites such as FlightAware to our integrations. We will also build on the ideas around pub-sub to explain some advanced design patterns.
In this chapter, we are going to make use of Mockable.io (often just referred to as Mockable); like Apiary it can be used to define and create mocked web services. Where Apiary focuses on supporting REST and its service definition standards, Mockable focuses on the just the testing aspect of web services and provides good support for WSDL/SOAP-defined services. As this is the first time we make use of Mockable in the book we will devote some attention to it. Note that Mockable does provide its own documentation within the tool as well.
To show how we can reuse connectors, we will start with a normal integration and then convert to a pub-sub reusing the connectors, as shown in the following diagram:
We can then extend our service so we can have multiple subscribers, like this:
Before we start building the services, let's take a look at the WSDLs for the inbound and outbound calls for our first inbound and outbound definitions. Let's start with the inbound or source definition, as shown in the following illustration:
The service payload is defined by a schema within the file and is structured as follows:
The inbound WSDL is available in the downloads as ICSBook-Ch3-FlightProgress-Source.WSDL.
As you can see, the idea of the message is to describe the status of a flight, including its destination and where it is. The first thing of note is that ICS has to offer the implementation URL of the service to be called, so the SOAP:Address location attribute is missing.
However, if you look at the destination WSDL, it has to contain the concrete target address (shown as http://XXXX.mockable.io/FlightServices) so that ICS knows where to call out to. When we set up Mockable, we will need to change this address to our unique account identified mock of the target web service. This target WSDL is available in the downloads as ICSBook-Ch3-FlightProgress-Target.WSDL:
The following illustration shows the structure of the FlightProgress WSDL:
You should also note the wsdl:service provided, as we will need this for the mock interface (along with the targetName space attribute).
So before we start on the integrations, let's get set up with the tools needed to send and receive web service calls. This is always a good development practice. Upon visiting Mockable.io (https://mockable.io) you will get several options to quickly establish a mock, or to log in to an account. You can work with the quick-start approach, but the mock will only remain for a limited period, so you may want to consider creating a login.
Once you are into Mockable, you will see a dashboard like that in the next screenshot, showing the number of mocks created and how many are active. At this stage, of course, you will not have any.
The preceding screenshot shows the main page of Mockable.io with a single tab and a button for + Add Domain. As we are using the free version of the solution you will only be able to work with the single provided domain. It is possible to create targets against domain names, but this is a licensed feature and is not needed for our purposes.
At this stage, we need to manage our Mockable subdomain and establish our mock service, so click the MANAGE button. This will present us with the primary screen for controlling mocks, as shown here:
The left-hand tabs (REST and SOAP) allow you to switch between the types of mock you have. In this case, we want to create a SOAP service. Select the SOAP tab, and then click the + SOAP Mock button. This brings us into the final screen, where we can define the mock, as you can see here:
To complete our mock, we need to provide the following information on this screen:
|
Property |
Description |
|
Endpoint |
This forms part of the URI we need to wire into the outbound WSDL. You will probably want to use either a test name or the service name.
To keep things simple, we have used the service name. In our case, we have used |
|
SoapAction |
This defines the action that should be called when the WSDL URL is addressed. This is made up of our namespace plus the service name defined.
So our WSDL means this needs to be |
|
Headers |
If we wish to pass any security tokens or special attributes, then this is where we would define what is expected. However, in this chapter we are going to keep things simple, so this can be left unmodified with no values. |
|
Response status |
As we are using the HTTP protocol to carry the SOAP object, we need to tell Mockable how to respond at the HTTP level. To start with, we want to keep this simple, which means returning a success result, that is, code 200. The full set of error codes is published as part of the standard definition. For more information on HTTP response codes, go to https://www.w3.org/Protocols/HTTP/HTRESP.html. |
|
Content-encoding |
When passing information around using HTTP, there should be a description of the type of content in the header elements. This provides the opportunity to define the encoding of the response. For our use cases, the default value is sufficient. For more information about header content encoding, go to https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. |
|
Response Body |
Mockable offers the ability to incorporate some intelligence into the response through the use of Jinja2, a Python based templating tool, or Mustache, which has its own notation. Presently we have no need to have a dynamic response, so the option can be left unset. More information on these tools can be seen at:
If the service was a request and response (bidirectional) communication, then we would provide the HTTP body content to return here. As we are actually performing a one-way call, we only need to worry about the HTTP response code, and this field can be cleared. |
|
Display Name |
When looking at the mock dashboard, this is the name that will be used for this mock. The best thing to do here is to align it to the endpoint name for simplicity, for example, |
|
Enable Request Logger |
When requests are received, you can control whether the information is logged. For our benefit, we want to see what has been received. So you want to click on the icon so it turns green. |
|
Set response delay |
You might want to simulate the effect of a delay in responding, to reflect the typical real execution time. This is good if you need to manage the risk of timeouts on target systems, or you want to prove the integration will time out a connection rather than leaving things hanging. For basic testing we can leave this unchanged. |
With all this information provided, we then can save the configuration with the Save button. Note that, having provided the details, you will now have a banner at the top of the page showing what the URLs are for invoking the mock service. The HTTP URL needs to be incorporated into the outbound schema's SOAP Address Location attribute, as mentioned before.
The last step is to enable the mock. We can use the URL path indication near the top of the page to navigate back to the test domain level, for example, http://xxxx.mockable.io/. The mock needs to be enabled to capture the calls. This can be done with the button on the left of the line for each mock, which will toggle between Stopped and Started, as shown here:
The alternative is via the Actions dropdown and the Stop and Start options, as you can see in the following screenshot:
With the mock ready, the next step is to prepare the part in SoapUI that will simulate the source of the web service call. As we have already used SoapUI in the previous chapter, we will not go into too much depth here. But the steps needed are as follows: open SoapUI, load the WSDL file that defines the integration trigger, and use SoapUI to help generate some test values to send to the integration.
Note we will need to revisit SoapUI to apply a couple of revisions when we are ready to test, specifically:
- Set the URL for the service once it has been created, so SoapUI knows where to make the invocation
- Set the credentials and the time to live for that information with respect to the connection to ICS, as we did in the previous setup for SoapUI