*Generalizations

Issue 8197 -replace ‘AcceptEventAction’ with ‘Action’

•

Action (from BasicActions ) on page 247

*Description

ReplyAction is an action that accepts a set of return values and a value containing return information produced by a previous accept call action. The reply action returns the values to the caller of the previous call, completing execution of the call.

*Attributes

No additional attributes

*Associations

• replyToCall : Trigger [1..1] The trigger specifying the operation whose call is being replied to.

Issue 8197 - add subsets constraints to ‘replyValue’ and ‘returnInformation’ entries

• replyValue : OutputPin [0..*] A list of pins containing the reply values of the operation. These values are returned to the caller. {Subsets Action::input}

• returnInformation : InputPin [1..1] A pin containing the return information value produced by an earlier AcceptCallAction . {Subsets Action::input}

*Constraints

[1] The reply value pins must match the return, out, and inout parameters of the operation on the event on the trigger in number, type, and order.

[2] The event on replyToCall trigger must be a CallEvent .

replyToCallEvent .oclIsKindOf(CallEvent )

*Semantics

The execution of a reply action completes the execution of a call that was initiated by a previous AcceptCallAction . The two are connected by the returnInformation value, which is produced by the AcceptCallAction and consumed by the ReplyAction . The information in this value is used by the execution engine to return the reply values to the caller and to complete execution of the original call. The details of transmitting call requests, encoding return information, and transmitting replies are opaque and unavailable to models, therefore they need not be and are not specified in this document.

Return information may be copied, stored in objects, and passed around, but it may only be used in a reply action once. If the same return information value is supplied to a second ReplyAction , the execution is in error and the behavior of the system is unspecified. It is not intended that any profile give any other meaning the return information. The operation specified by the call event on the trigger must be consistent with the information returned at runtime.

If the return information is lost to the execution or if a reply is never made, the caller will never receive a reply and therefore will never complete execution. This is not inherently illegal but it represents an unusual situation at the very least.