With the point-to-point integration proven to be working, we can now create a version of the same integration using the pub-sub pattern provided by ICS. We can re-use the existing connectors, and we can jump straight into creating the integrations.
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:
Property |
Value |
Integration Name |
|
Identifier |
Take default |
Version |
01.00.0000 |
Package Name |
|
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
To keep it simple, call it |
What does this end point do? |
Add the description: | |
Operations |
Selected Port Type |
As we only have a single operation in the WSDL, this tab will not offer any options. |
Selected Operation | ||
Request Object | ||
Summary |
WSDL URL |
As we only have a single operation in the WSDL, this tab will not offer any options. But should reflect the selected connector information. |
Selected Port Type | ||
Cloud Operation | ||
Message Exchange Pattern |
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:
Property |
Value |
Integration Name |
|
Identifier |
Go with the proposed value. |
Version |
01.00.0000 |
Package Name |
|
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
To keep it simple, call it |
What does this end point do? |
Passes | |
Preview updated SOAP adaptor runtime |
This should be set to No | |
Operations |
Selected Port Type |
As we only have a single operation in the WSDL, this tab will not offer any options. |
Selected Operation | ||
Request Object | ||
Summary |
WSDL URL |
As we only have a single operation in the WSDL, this tab will not offer any options. But should reflect the selected connector information. |
Selected Port Type | ||
Cloud Operation | ||
Message Exchange Pattern |
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.