Within the integrations menu we can look at all the integrations and use the menus to filter them down, initiated by a scheduler or via push, that is to say, the integrations are triggered by something calling the integration, such as an external application.

All of these views present a list of appropriate integrations showing:

You may have also noticed that, like most other views, you can filter down the list of integrations by name in the same way as you can in the designer. In addition to this, the data displayed is filtered by what has occurred in the selected time period as previously mentioned. An example can be seen in the following screenshot:

As you can see in the preceding screenshot, we have filtered the list of Push Integrations down to those related to Chapter 7, Routing and Filtering (by setting the filter field to Ch7) and one of the integration has experienced an error.

To see the views, we will look at the test scenario for the FilteredFlightStatusEnquiry service that we produced in Chapter 7, Routing and Filtering, which will need to be run a number of times. The service was tracked using the attribute faFlightID, and we have added the ident and prefix to this now (Refer to Chapter 2, Integrating Our First Two Applications, if you need to see how this is setup). The filter worked on whether the suffix element had a value of BA. Most of the executions should have that value set to BA. Each time you trigger the integration, make sure that at least the faFlightID is different. So that errors can be seen, log into Mockable and stop the appropriate mock and then trigger the integration again (with the suffix set to BA) and we will be able to see an instance of the integration reporting an error. Having run SoapUI several times, you should be able to navigate to the monitoring part of ICS and click on the Push Integrations sub menu. We have chosen FilteredFlightStatusEnquiry_Ch7 so we can illustrate what happens when a filter eliminates an event.

We can focus on the instances of the integration that have run by clicking on the different measures, as it will filter the list of instances displayed accordingly (for example showing everything that was received, succeeded, or caused an error). To best illustrate things, click on Received. With this we get a view like as follows:

This list is in time series with the latest instance at the top. In this case, the last instance that was executed had failed as we had disabled the Mockable.io on that occasion. Note how the heading for each instance reflects both the faFlightID but also a unique Instance ID. The Instance ID is provided by ICS to each instance of the integration that is run, and is unique across all the integrations on this instance of the ICS service.

We can examine more detail and see visually what has happened with each instance of the service by clicking on the instance name (For example, faFlightID: 130). This will present a variation of the editor view, as you can see in the following screenshot:

As you can see in the preceding screenshot, the arrows showing the direction of flow are green to show the successful route taken. We can also display all the business identifiers being tracked with each instance, if we click on the Business Identifiers button. If we click on Exit Instance to return to the instance list and then click on the failed instance name (faFlightID: 150), we would see something like as follows:

Note that in this screenshot we have clicked on the View Error button in this instance to see the error details. In the background integration image, we can see at what stage things failed. In this case, the mapping process completed, but the invocation of our Mockable.io endpoint failed as we had disabled it.

This does leave us with the question of what is the outcome of the situation where the integration can run properly (that is the Mockable endpoint is running and ready), but our filter has prevented the integration from continuing to invoke the endpoint. This situation is shown in the following screenshot:

As you can see in the screenshot diagram, the filter in the upper part of the diagram is shown in red, as this is where the integration effectively stopped. As a result, the flow to the transformation did not work, as reflected in the lower part of the diagram. However, as the integration behaved as it should do, the integration counts as a success.