So, in the integrations view we can select Create New Integration; however, when the pattern popup is presented, this time we want to select Publish To ICS.

The following table, as before, will guide you through setting up the integration description:

With the basic integration stuff defined we can now apply the connector. As with the original source, locate the FlightSitRep_Ch3 connector, apply it to the source, and complete the source configuration with the following information:

As the target is the ICS Message service, we do not need to do any configuration for this end of the integration as the section of the pattern has told ICS how the target should work and it can derive all the necessary information from the rest of the integration. The last step to configure the tracking is to test and save the integration, which also follows same the values for the source in our FlightStatusUpdateDirect_Ch3 integration.

Having created the publication service it is now possible to implement the subscription. So we go through the Create New Integration process, but this time select the Subscribe To ICS pattern.

The following table, as before, will guide you through setting up the integration description:

To start with, we need to drag the ICS Messaging Service onto the Invoke part of the template. When this is done, a list of possible publish services to connect to will be displayed. For example:

We can select our PublishFlightStatusUpdate_Ch3 service and click on the Use button. Note that the version information is available, so if going forward we have two versions of the same interface, you can choose between the versions to pick up a subscription.

With the basic integration stuff defined, we can now apply the connector that will send the SOAP event to Mockable. Locate the ReceiveFlightStatusUpdate_Ch3 connector and drop it onto the target. Complete the wizard using the following information:

So at this stage, we have a service looking like this:

Having created these new integrations, we need to get them activated. Once activated, use the info icon to get the target URI for the service. The new URI can be inserted into the destination address of the original SoapUI test. Before you trigger the SoapUI test again, you probably want to refresh the user credentials to ensure the username and password are still correct, to avoid problems from the timestamp element of the security details having expired.

When you fire the trigger service now you should be able to see in the Monitoring view (more on this in Chapter 12, Are My Integrations Running Fine, and What if They Are Not?) that the publish and subscribe integrations have been triggered. We can see the monitoring information by navigating to the integration list page and clicking on the Monitoring tab, then on the monitoring dashboard by clicking on Activity Stream, which will list integrations that have been executed. We can also go to Mockable and look at the events list again. As before, Mockable should show the service being invoked.