Like in the previous chapter, we need to create SOAP connectors; this time we will create two: one that will be called by SoapUI, and a second to call Mockable.io.

As before, navigate into the Connections part of the Designer and create a SOAP connection with the following details:

Once the fields are complete, use the Test button at the top of the page to validate the connection configuration; the percentage complete should reach 100% at this point. Click the Save and Exit Connection button.

Now we repeat this to create the second connector with the following details:

We should now have two connections successfully created. So now we can navigate to the Integrations part of the Designer and create the integration. This process is very similar to the integration created in Chapter 2, Integrating Our First Two Applications, with one key difference-as we have defined both SOAP connections in the WSDL to be one-way (so no return result or fault definition), we will only see a one-directional flow. Click the Create New Integration button, and select the Basic Map Data pattern. Now we can complete the creation of the integration with the following details:

With the basic details for the integration completed, we can now drag and drop our connections from the connector palette. For the Source side, we want to drop the FlightSitRep_Ch3 connector. With the icon displayed, we can then proceed to edit the details of the connector to use. The Source and Trigger spots are as you may remember tabbed panels, and can be navigated through using the Next and Back buttons. But we need to complete the following information:

We can now define the other end of the integration by dropping the connector ReceiveFlightStatus_Ch3 onto the Invoke target. The resultant dialog can be completed with the following information:

Now we need to complete the mapping. This will be a little more complex than in the previous chapter. But we start in the same way by selecting the mapping icon in the middle of the flow. Then we link the source and target elements by clicking and dragging the dot symbol using the following table to define the mapping:

You will note we have deliberately mapped a source element to a destination element twice, as illustrated in the following screenshot, so the outbound data will have the same value in both elements:

The diagram and table also show that we can map a single element of the source to more than one element on the target. To help differentiate the multiple integrations without bound endpoints, we are going to illustrate how to hardwire a target value.

The first step is to open up the specific mapping by clicking on ident in the target, which will show us the Build Mappings screen:

To do this, we are going to modify the ident target field to have a prefixed string. You may recognize the expression in the statement; this shows the selected element from the source by providing an XSLT (XSL Transform). We are going to extend this to have a prefix of Direct-; to do this, select the edit statement (pencil) icon on the right. We will now be able to edit the schema.

On the right-hand side is the Source, and so on. Select the Mapping Components menu and open the String option in the collapsed tree. Scroll through the list until you see concat, then select this and drag and drop it onto the editor icon on the right-hand side.

Doing this will trigger a popup called Select Parameter. Now select the string1 field and click on OK. This will set the path into the position for the string1 field. To set the literal value, simply double-click on the string2 parameter and then change the value to the literal Direct-. Your statement should look like the following screenshot:

As you can see, the expression inside the select clause looks vaguely Excel-like. Once done, select the Save button and close the dialog with the Close button. Back at the main mapper page, you want to press the Save button to be safe.

You may also note that some of the elements are prefixed with an asterisk. This denotes whether the element is declared as mandatory or not (indicated in the schemas within our WSDL files by the minimum number of occurrences attribute on an element definition) as you can see here:

<xs:element maxOccurs="1" minOccurs="0" name="heading" type="xs:int"/> 

We can confirm the mapping is as expected using the test option which can be accessed by the Test button. When you open the Test Mapper screen, you are presented with two large fields representing the input and output. As we have a WSDL and a schema, we can have some test values generated for us, by selecting the Generate Inputs button, which will populate the Inputs field. Alternatively, it is possible to paste in some input XML. Then by selecting the Execute button, the mapping process is performed and the Outputs field is populated. When you do this, you should notice the ident output is the input combined with the literal string. The following screenshot shows the outcome of generating and testing a mapping:

If the input is not suitable, then you will see an error message in the output panel, such as:

There has been an error executing this map:  
<Line 10, Column 1>: XML-20210: (Fatal Error) Unexpected EOF. 

With the mapping complete, we can exit the mapper and set the Tracking. For this test case we would recommend tracking the Id element of the source.

Having saved and tested the integration within the editor, we can make it Active using the button on the Integrations page. Once this process has completed, then we can get the URL for the service via the information icon. It will include the endpoint URL along the lines of https://icssandbox-xxxx.integration.us2.oraclecloud.com:443/integration/flowsvc/soap/TEST_SOAP_CH3/v01/?wsdl.

If you paste the URL into the toolbar of your browser, you will see the actual WSDL rather than invoke the service. To actually trigger the service you will need to remove ?wsdl from the URL (as this parameter is a common way to ask for the WSDL description to be returned). This path can be added to Mockable. Before running, also ensure that SoapUI includes the appropriate credentials, as you will have seen in the previous chapter. Once the service has been triggered, we can check the Monitoring page is showing when the service was triggered. But, most importantly, we can examine what has been received in Mockable. By selecting Request Inspector at the top of the screen, we will be presented with a screen showing what events have occurred, as follows:

Within the Request Inspector , we can open up any of the requests and examine the content, which will show us the XML payload, as can be seen here:

To see the XML payload, you will need to use the scroll bars, but you should be able observe their information.