This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Trigger Event"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) m (→Notes: typo) |
|||
| Line 4: | Line 4: | ||
The Trigger Event may be caused by one of the following: | The Trigger Event may be caused by one of the following: | ||
| − | * | + | *Environmental - For example, the trigger event that prompts a system to send all accumulated data to a tracking system every 12 hours is considered Environmental. Similarly a user pressing a button in a user-interface would be considered environmental |
*[[State Transition]] - resulting from a state transition as depicted in the State Transition Model for a particular message interaction. The trigger for canceling a document, for example, may be considered a State Transition Based trigger event | *[[State Transition]] - resulting from a state transition as depicted in the State Transition Model for a particular message interaction. The trigger for canceling a document, for example, may be considered a State Transition Based trigger event | ||
| − | *Interaction Based - based on another interaction. For example, the response to a query (which is an interaction) is an Interaction Based trigger event. | + | *Interaction Based - based on the receipt of another interaction. For example, the response to a query (which is an interaction) is an Interaction Based trigger event. |
Most trigger events are State-Transition based and will be encountered when reading the dynamic message model information defined to support a particular message interaction. Some trigger events may be based on more than one state transition, which are assumed to occur simultaneously. | Most trigger events are State-Transition based and will be encountered when reading the dynamic message model information defined to support a particular message interaction. Some trigger events may be based on more than one state transition, which are assumed to occur simultaneously. | ||
| + | |||
| + | Trigger events which are either invoked by a state transition or which are associated with a state transition (as a request, fulfillment request or refusal) should include a link to the D-MIM definition of the class to be transitioned as well as the transition to occur (or which has occurred or was refused) for each associated transition. | ||
=== Notes === | === Notes === | ||
| Line 14: | Line 16: | ||
#A Trigger Event (within a sending application) represents an event which happened at the sender's side of the communication link. The behaviour of a Receiver is exclusively linked to the interaction (in the form of its [[Receiver Responsibilities]]) or to attribute values within the message itself. Example: the Trigger Event "creation of a new Prescription" may result in a "fulfillment request interaction" as well as a "notification of the creation of a request interaction". The trigger event doesn't distinguish between the notification or the fulfillment request; this is accomplished at the interaction level. | #A Trigger Event (within a sending application) represents an event which happened at the sender's side of the communication link. The behaviour of a Receiver is exclusively linked to the interaction (in the form of its [[Receiver Responsibilities]]) or to attribute values within the message itself. Example: the Trigger Event "creation of a new Prescription" may result in a "fulfillment request interaction" as well as a "notification of the creation of a request interaction". The trigger event doesn't distinguish between the notification or the fulfillment request; this is accomplished at the interaction level. | ||
#When defining a Trigger Event, it can't be used to negate or otherwise significantly alter the semantics of the static model being communicated. Example: if the focal act of the [[Domain Payload]] is in EVN mood, the Trigger Event (when used as a [[Receiver Responsibilities|Receiver Responsibility]]) can't redefine the message to be an Order. | #When defining a Trigger Event, it can't be used to negate or otherwise significantly alter the semantics of the static model being communicated. Example: if the focal act of the [[Domain Payload]] is in EVN mood, the Trigger Event (when used as a [[Receiver Responsibilities|Receiver Responsibility]]) can't redefine the message to be an Order. | ||
| + | #Environmental trigger events may still be associated with a state transition. For example, a request to 'suspend' an Act would be triggered by an environmental trigger (e.g. a user clicking a button saying 'suspend'. | ||
Revision as of 16:17, 14 December 2005
An Event which, when recorded or recognized by an application, indicates the need for an information flow to one or more other applications, resulting in one or more Interactions.
A trigger event is an explicit set of conditions that initiate the transfer of information between system components (Application Roles). The trigger event represents the “real-world” event such as the placing of a laboratory order or drug order. The trigger event must be systematically recognizable by an automated system.
The Trigger Event may be caused by one of the following:
- Environmental - For example, the trigger event that prompts a system to send all accumulated data to a tracking system every 12 hours is considered Environmental. Similarly a user pressing a button in a user-interface would be considered environmental
- State Transition - resulting from a state transition as depicted in the State Transition Model for a particular message interaction. The trigger for canceling a document, for example, may be considered a State Transition Based trigger event
- Interaction Based - based on the receipt of another interaction. For example, the response to a query (which is an interaction) is an Interaction Based trigger event.
Most trigger events are State-Transition based and will be encountered when reading the dynamic message model information defined to support a particular message interaction. Some trigger events may be based on more than one state transition, which are assumed to occur simultaneously.
Trigger events which are either invoked by a state transition or which are associated with a state transition (as a request, fulfillment request or refusal) should include a link to the D-MIM definition of the class to be transitioned as well as the transition to occur (or which has occurred or was refused) for each associated transition.
Notes
- A Trigger Event (within a sending application) represents an event which happened at the sender's side of the communication link. The behaviour of a Receiver is exclusively linked to the interaction (in the form of its Receiver Responsibilities) or to attribute values within the message itself. Example: the Trigger Event "creation of a new Prescription" may result in a "fulfillment request interaction" as well as a "notification of the creation of a request interaction". The trigger event doesn't distinguish between the notification or the fulfillment request; this is accomplished at the interaction level.
- When defining a Trigger Event, it can't be used to negate or otherwise significantly alter the semantics of the static model being communicated. Example: if the focal act of the Domain Payload is in EVN mood, the Trigger Event (when used as a Receiver Responsibility) can't redefine the message to be an Order.
- Environmental trigger events may still be associated with a state transition. For example, a request to 'suspend' an Act would be triggered by an environmental trigger (e.g. a user clicking a button saying 'suspend'.
