An interaction represents the exchanging of a message from one role to another role(s).

This is achieve by dragging a link between the 'originating' (or 'source') role to the 'destination' (or 'target') role. This will cause 'send' and 'receive' message events to be added to the source and target roles, with a link between drawn between them.

While the link is selected, go to the Properties view to set the relevant properties for the message.

The "Error Expected" property is a checkbox that can be used to indicate that this message is expected to be incorrect when used for simulating or testing against other artifacts.

The "Operation" field represents the name of the operation being performed. In cases where the target architecture is message oriented, this may not seem necessary, however it can be useful to clarify the purpose of the interaction.

The optional "Fault" field is used to provide a fault name for the interaction, in situations where the message exchange represents a fault response.

The "Parameters" list represents the one or more pieces of information that should be exchanged with the message. Pressing the 'Add' button will show another dialog window:

The "Type" field represents a fully qualified type name. The value within the curly braces defines the namespace, and the remaining text is the 'local part'.

The "Value" field represents a path to the file containing the example message value. The path can define a relative path, as in the image above, from the scenarios location. So this example indicates that the message value file (BuyRequest.xml) is in the same folder as the scenario file that is referencing it.

Once the parameter has been defined, it will be displayed in the parameters list as above and the text associated with the message link will be updated to summarize the information.

It is also possible to select the individual send and/or receive message events from the palette and attach them to the appropriate roles, with or without a link to connect them. For example, if a 'send message event' is placed on a Role, with the associated message information, this will indicate that the role sends a message but the intended recipient does not get it for some reason.

This is an example of where we want to represent an invalid (or negative) use case. Although this may seem counter intuitive, it can be useful to be able to specify anti use cases, as a way to document situations that we don't want to be implemented. Through the use of the 'Error Expected' field (associated with the Message Link properties) it is also possible to identify which parts of these negative scenarios should observe errors, and therefore can be used for automated testing.