For this integration we can use any Twitter account you can get access to. If you do not have an account yet, or want to have an extra account for testing purposes, go to https://twitter.com/signup and follow the instructions.

To allow ICS to interact with your Twitter account, we need to create an application and set its permissions. Go to https://apps.twitter.com/ and click the Create New App button.

Complete the form with following information:

Once the application is created, you can go to the Settings page and update the settings if you want. You can also set an application icon and info about your organization.

Finally, we need to create our access token and obtain the API credentials. Go to the Keys and Access Tokens page. On this page, you find the Consumer Key and Consumer Secret.

Obtain the values and save them somewhere you can retrieve when we create the connection. At the bottom of the page, click Create my access token to obtain your token and save the values of Access Token and the Access Token Secret.

We start with the request mapping. Click the mapping icon, and then on the plus sign to create a new mapping. Notice that the target message contains nine parameters we can assign, but the most important one is status. We will assign one of four different messages to the status node depending on the request message, but first assign the optional source's latitude and longitude to the target's lat and long nodes.

As we said, we want to send out a dynamic tweet. In total, we want to send out four different messages. The four message types will be similar to this:

In the mapper, click on the status node to create these dynamic messages. First, drag and drop the choose element to the status node statement, which can be found under Mapping Components | XSL Elements. The reason we are doing this is because we want to determine whether a flight is en route, at its origin, or is in flight to destination.

Notice that a choose statement is built and a when element is added as a child. The when element has a test attribute we need to configure with an expression. The result of the expression should be a Boolean.

Instead of creating the expression from scratch by dragging and dropping the different parts, it is also possible to enter the expression itself. To check if a flight has departed, we can use the following expression:

xsd:duration(fn:current-dateTime() - xsd:dateTime(/nssrcmpr:ScheduleUpdate/nssrcmpr:departureTime)) > xsd:duration('PT0S') 

We check whether the duration between the current-dateTime and departureTime, which is also a dateTime, is greater than zero seconds. If this is true, then it means the flight has arrived; otherwise, the flight is en route. Click Type here... for 'test' and enter the preceding expression.

Next, we create the otherwise clause. We can do this by creating a new Sibling After the xsl:when element using the right-click contextual menu. Drag the element otherwise from the Mapping components | XSL Elements to the new created sibling. The statement should now look similar to the following screenshot:

Now that the main XSL construction is in place, we add a child to both the xsl:when and xsl:otherwise elements. Right-click the element and select Insert Child. Each child is a concatenated string of source nodes and literal text phrases.

For our own convenience, we will not drag and drop with functions and source nodes. We are going to use the value-of XSL element. Using this element, we can add an expression that represents the same outcome as when we would have used the mapper UI in the same way we have demonstrated in past chapters.

Drag the value-of element from Mapping components | XSL Elements to the child of xsl:when. This will create a value-of element with a select attribute. Click Type here... for 'select' and enter the following expression. This expression concatenates source nodes to create the message that will be tweeted if an airplane is on its way. We use the double slashes, which is a wildcard, to shorten the expression.

concat('Flight #', //nssrcmpr:ident, ' arrival to #', //nssrcmpr:destination, ' from #', //nssrcmpr:origin, ' is ', //nssrcmpr:durationString, ' ', //nssrcmpr:updateType) 

Save your progress and do the same process for the otherwise, but instead use the following expression:

concat('Flight #', //nssrcmpr:ident, ' en route from #', //nssrcmpr:origin, ' to #', //nssrcmpr:destination, ' is ', //nssrcmpr:durationString, ' ', //nssrcmpr:updateType) 

Again, save your progress, and we should now have a complete mapping for the target's status node. The statement should now look similar to the following screenshot:

Close the mapping of the status node to return to the mapper. Notice that all the used elements we mapped using the wildcard expression are visually mapped in the UI:

To test our mapping, we can click the Test button below the Save button. This will open the Test Mapper. Generate inputs and execute the test to see the result. Play around with destinationTime to the see different messages. Close the Test Mapper and subsequently click Save and Exit Mapper to return to our integration.

For the response mapping, we are mapping the result from Twitter to the result of our SOAP service. Create the response mapping and map the nodes as follows:

Save the mapping and click on Exit Mapper.

For the fault mapping, we are mapping APIInvocationError from Twitter to the BusinessFault of our SOAP service. Create the fault mapping and map the nodes as follows:

Save the mapping and click on Exit Mapper.

When an identical message is sent within a period of time, Twitter can reject the message because it is categorized as a duplicate message. This can easily be reproduced by sending the requests twice, immediately after each other.

This will result in the following exception visible at the client, that is, SoapUI:

{"errors": [ 
 { 
  "code":187, 
  "message":"Status is a duplicate." 
 }] 
}  

Try not to send multiple source events with the same values so that the call to Twitter will have different messages and prevent this error.

If one of the authentication settings, such as consumer key/secret and access token/secret, is invalid, Twitter will reject the message because it can not authenticate the caller. This can be reproduced by editing the security settings in ICS or by revoking the access token of the Twitter application.

When invoking the integration, the following exception will result:

{"errors": [ 
 { 
  "code":32, 
  "message":"Could not authenticate you." 
 }] 
}  

The owner of the Twitter account can set the access the Twitter application requires. To post a tweet, the application needs read and write access at a minimum. This can be reproduced by changing the access token to read only within the Twitter configuration.

When invoking the integration, the following exception will result:

{ 
 "request":"/1.1/statuses/update.json", 
 "error":"Read-only application cannot POST." 
}