This section defines the protocols to be applied to the notifications and recipients.

Usually it is expected that each notification will be processed within the Recipient. When this fails it will be automatically retried by the queue by way of the IsReadyToSend property.

To support fully asynchronous processes, i.e. where the notification causes an action that may complete at some point in the future the notification used will have to be modified to record the status as asynchronous, the current identification or state information, and the recipient will check this during the next invocation to and set the completed property accordingly.

Transmission, timeouts and retries

The notification is responsible for handling the status of the request. Typically the processing element will set the status of the notification according to what it knows. The base class QueueNotification supports the the date and time element of the creation of the request and also the expiryDate of the request. These are used to define when the Notification has expired.

complete property

When this is true the notification has completed. To be set only by the object processing or actioning the request.

public bool complete { get; set; }

IsReadyToSend property readonly

Used to control the sending of notifications. If this returns false then the Transmitter should not send this notification. This is used to control the frequency of operations. Typically uses elapsed or current time to decide if the notification needs to be sent (or resent)

public bool IsReadyToSend

TimedOut property

Used to control the timeout. If this notification has timed out. This is to be set by the processing recipient

public bool TimedOut

IsComplete property

When this notification has completed the processing recipient must set this to true. The processing recipient is responsible for follow on notifications. A notification can remain as complete until the transmit queue decides to remove it from the queue, there is no requirement that elements are removed immediately upon completion merely that once complete the transmitter should not notify any more elements.

public bool IsComplete

Notify Return codes

The return codes are defined as enum ReceiptStatus. Any Notification Receive method message can have one the return states from NotifyAll:
  • OK – successful
  • Fail – not successful
  • Abort – this Notification has failed and the transmitter will consider the entire operation as Fail
  • Finished – Definitive success. The recipient warrants that this event has definitively been processed and the transmitter does not need to notify any other recipeint of this notificaiton.
  • NotProcessed - Recipient didn't recognise this event – standard / default return code when not procesed.
  • Pending - Not yet processed only supported by QueuedNotifcations and QueuedTransmitters. Upon return of Pending the message is considered to have been processed successfully. NotifyAll will return a code of OK for requests that are pending – because the request has been accepted.

Return codes for Queued elements

When processing the Queued Notification the QueuedTransmitter follows the following protocol:

Messages of type Abort, Fail are considered failures and will result in a retry next time the notification is ready. If the transmission fails and the TimedOut method of the Notification is true Notification being removed from the Queue
OK & Finish are considered successful and will result in the notification being removed from the queue.
All other return codes will result in the message remaining in the queue.

Last edited Nov 3, 2011 at 7:32 AM by RichardHarrison, version 1

Comments

No comments yet.