Service Bus Trigger

Service Bus triggers are similar to Queue Triggers, in that they allow you to trigger Processes on messages received from a message queue, in this case an Azure Service Bus or Service Bus for Windows Server queue or subscription. 

NOTE: The service bus trigger cannot accept message sessions, so it cannot listen to queues or subscriptions requiring sessions. It can, however, send replies to session queues, as described below.

Configuring Service Bus Triggers

• Queue (required)
  Name of the queue or subscription to listen to

• Connection string (required; if not set, will default to system Service bus namespace)
  The full Service Bus connection string

• Max concurrent connections
  Limit on how many messages will be processed at a time. Essentially will limit the number of Processes running at the same time on a single Agent.

• Message prefetch count  
  If set, will enable message prefetching for the receiver. If you are receiving a lot of messages from the queue, it is recommended to turn prefetching on. Note that the prefetch count should still be low enough so the messages can be processed in time.

• Consume message immediately
  If set, the message will be consumed from the queue immediately on receive. If not set, the listener will use the PeekLock receive mode, and acknowledge the message only if it was processed successfully.
  The lock will be refreshed according to the lock duration defined for the queue, however if the connection string does not have management access to the Service Bus, the lock duration cannot be read and the lock is assumed to have a duration of one minute. If the lock is shorter than a minute, the lock might get released before the Process has finished executing.
  If e.g. the agent crashes before the Process finishes, the message will be returned to the queue, and will be processed again. In this case, the trigger will retry processing the message after the lock expires, until the max delivery count on the queue or subscription is reached.

• Retry message processing if exception is thrown  (from 5.1.1)
  If 'Consume message immediately' option is set, it will not by default return messages to the queue if the Process execution ends in an exception. This is to reduce problems with messages being processed again inadvertently.
  If you turn this option on, and the Process ends in an exception, e.g. due to a query timeout in a Task, the message lock will be released immediately, so the message will be returned to the queue and will be processed again by a new Process instance. If the next Process instance also fails, the lock will not be released, but it is let to expire. This means the message will be processed again after the lock interval (1-5 minutes) has passed. If the message processing fails for the fifth time, the message will be put to the deadletter queue, and will not be processed again automatically.
  

• Reply  
  If set, the Process response will be sent to a reply queue, usually defined by the ReplyTo Property in the request message. See Reply messages below for more information.

• Reply errors
  If set and the Process fails with an exception, the exception message will be serialized and sent to the reply queue. See Reply messages below for more information.

• Default reply queue
  Needed if the 'Reply' option is set. The default queue or topic where the reply message will be sent if the request did not specify it with the ReplyTo property in the request. See Reply messages below for more information.

Trigger data for the Process

The trigger will pass the message content serialized as string to the Process. It can be accessed via the #trigger.data.body reference.

The trigger will also set the #trigger.data.properties dictionary from the message properties. Any custom properties will be included in the list by name and value. The built-in message properties are also accessible; they are prefixed with the "BrokerProperties." prefix. Following properties are available: 

• #trigger.data.properties["BrokerProperties.CorrelationId"]  Correlation ID

• #trigger.data.properties["BrokerProperties.SessionId"]  Session ID

• #trigger.data.properties["BrokerProperties.DeliveryCount"]  Delivery count, i.e. how many times the messagehas been received from the queue

• #trigger.data.properties["BrokerProperties.LockedUntilUtc"]  Message lock timeout if not consuming messageimmediately

• #trigger.data.properties["BrokerProperties.LockToken"]  Message lock token if not consuming messageimmediately

• #trigger.data.properties["BrokerProperties.MessageId"]  Message ID

• #trigger.data.properties["BrokerProperties.Label"]  Label given to the message

• #trigger.data.properties["BrokerProperties.ReplyTo"]  Queue name where to send replies to. See Reply messages below for more.

• #trigger.data.properties["BrokerProperties.ReplyToSessionId"]  Session ID to set in the reply so the callercan identify it. See Reply messages below for more.

• #trigger.data.properties["BrokerProperties.ContentType"]  Body content type 

Reply messages

Sometimes you need to get a reply back to the sender of the request, e.g. when the caller needs to wait for the triggered Process to finish, or needs the results. In this case, you can turn on replies on the Service Bus trigger. This will then return the result of the process in a message that is put to the given reply queue.

The request-reply process usually goes as follows:

• The caller will decide on a session ID and queue for receiving the reply. It will set these to the ReplyToSessionId and ReplyTo  properties in the request message, and send the message to the queue listened to by the trigger. The caller will then start listening on the reply queue, accepting only the message session with the given session ID. This means the caller will only get the response that was meant for it, even from a shared queue.

• The trigger will receive the request and start a new Process instance, passing the message body and properties as trigger properties to the Process. 

• Once the Process has finished, if the 'Reply' option is set, the trigger will create the response message. The response message will have the serialized result in the message body, with the SessionId  set to the given ReplyToSessionId  value from the request and CorrelationId set to the CorrelationId  value from the request. The response is then sent to the queue or topic given in the ReplyTo  property, or if the request did not define one, in the default queue for replies, configured in the trigger.

• The caller will receive the reply message in the session.

If the Process fails and 'Reply Errors' was selected, the exception that caused the failure will be written to the reply message. The message will also have the SessionId and CorrelationId set if required.