VIDIZMO V8 is an Event-Driven system that utilizes Azure Service Bus as the broker service for inter-communication between component services. Data is transferred between different applications and services using messages.

A message is a container decorated with metadata and contains data. The data can be any kind of information, including structured data encoded with the common formats such as JSON (JavaScript Object Notation), XML, Apache Avro, Plain Text, etc.


The messaging entities that form the core of the messaging capabilities in Azure Service Bus are queues, topics, subscriptions, and rules/actions.

VIDIZMO uses Azure Service Bus to create Topics for messaging between different component services.


This messaging model contains several Subscriptions underneath it. These are called Topic Subscriptions. 

You can opt for this model if there is a need to send incoming messages to multiple users or systems. The maximum limit for subscribers in a Topic is 2000. A subscriber to a topic can receive a copy of each message sent to that topic. 

In this model, you can have multiple receivers (subscribers) to receive the messages. The message copy can be sent to any number of subscribers associated with the Topic. 

VIDIZMO uses Topics to send and receive messages between different component services. The below illustration explains this messaging model. 



There are times when you would want to scale Azure Service Bus Topic processing, but nodes may not be powerful enough to handle thousands of requests per second. Creating multiple message factories; sending and receiving asynchronously, doing batch send/receive, and effective ways to scale Azure Service Bus, but they are helpful only for publisher and subscriber mode. 

They will not have much effect on a low-power Topic Node. So, how would you scale your Azure Service Bus to handle more than 10,000 transactions/second? HERE are a few tips to help you achieve a vast number of transactions and low latency. 

Deploy Azure Service Bus 

Premium and Standard Messaging Tiers 

Azure offers Service Bus in Standard and Premium tiers. You can choose a service tier for each Service Bus service namespace that you create, and this tier selection applies across all queues, topics and subscriptions, relays, and Event Hubs created within that namespace.

Shared Access Authorization Policies 

Azure Service Bus namespace has a Shared Access Authorization policy made up of rules. The policy at the namespace level applies to all entities inside the namespace, irrespective of their individual policy configuration.

When you create a Service Bus namespace, a policy rule named RootManageSharedAccessKey is automatically created for the namespace. You would need to use the connection string associated with this policy rule to configure Azure Service Bus as the broker service in VIDIZMO. 

Configure Azure Service Bus as Broker in VIDIZMO 

As mentioned above, a broker service is needed to exchange data and messages between different VIDIZMO services for the application to function. To configure broker service in the VIDIZMO application, please follow the instructions given below: 

Note: You will need the Administrator role to change Application Configuration in the VIDIZMO app.

Step-1. Login VIDIZMO application with Administrator user.

Step-2. Go to Navigation Menu > Control Panel > Application Configuration > VIDIZMO Runtime Configuration and click ‘Edit’ to change/update existing config.

Step-3. Select your ‘Event System’ as Azure Service Bus and use the connection string associated with ‘RootManageSharedAccessKey’ shared access policy rule in your Azure Service Bus resource to configure all services under Distributed Runtime Config. See the below screenshot


Step-4. Click ‘Update’ to add the latest changes in the system. 


Please consider the following key factors and recommendations for utilizing Azure Service Bus with VIDIZMO application: 


As with any technical resourcing, prudent planning is key in ensuring that Azure Service Bus is providing adequate performance that your application expects. The right configuration or topology for your Service Bus namespaces depends on a host of factors involving your application architecture and how each of the Service Bus features is used. 

Service Bus offers various pricing tiers. It is recommended to pick the appropriate tier for your application requirements. 

Standard Tier - Suited for developer/test environments or low throughput scenarios where the applications are not sensitive to throttling.

Premium Tier (Recommended) - Suited for production environments with varied throughput requirements where predictable latency and throughput are required. Additionally, Service Bus premium namespaces can be auto-scaled and can be enabled to accommodate spikes in throughput.

Premium Messaging: How fast is it? - Microsoft Tech Community 

Network Protocols

Service Bus enables clients to send and receive messages via one of three protocols: 

  • Advanced Message Queuing Protocol (AMQP) 
  • Service Bus Messaging Protocol (SBMP) 
  • Hypertext Transfer Protocol (HTTP)
AMQP is the most efficient because it maintains the connection to Service Bus. It also implements batching and prefetching. Unless explicitly mentioned, all content in this article assumes the use of AMQP or SBMP.

Message Sequencing

Sequencing and timestamping are two features that are always enabled on all Service Bus entities and surface through the Sequence Number and EnqueuedTimeUtc properties of received or browsed messages. 

For those cases in which the absolute order of messages is significant and/or in which a consumer needs a trustworthy unique identifier for messages, the broker stamps messages with a gap-free, increasing sequence number relative to the queue or topic. For partitioned entities, the sequence number is issued relative to the partition. 

The Sequence Number value is a unique 64-bit integer assigned to a message as it is accepted and stored by the broker and functions as its internal identifier. For partitioned entities, the topmost 16 bits reflect the partition identifier. Sequence numbers roll over to zero when the 48/64-bit range is exhausted. 

The sequence number can be trusted as a unique identifier since it is assigned by a central and neutral authority and not by clients. It also represents the true order of arrival and is more precise than a timestamp as an order criterion because timestamps may not have a high enough resolution at extreme message rates and may be subject to (however minimal) clock skew in situations where the broker ownership transitions between nodes. 

The absolute arrival order matters, for example, in business scenarios in which a limited number of goods offered are served on a first-come-first-served basis while supplies last; concert ticket sales are an example. 

The time-stamping capability acts as a neutral and trustworthy authority that accurately captures the UTC time of arrival of a message, reflected in the EnqueuedTimeUtc property. The value is useful if a business scenario depends on deadlines, such as whether a work item was submitted on a certain date before midnight, but the processing is far behind the queue backlog. 


You can submit messages to a queue or topic for delayed processing; for example, to schedule a job to become available for processing by a system at a certain time. This capability creates a reliable distributed time-based scheduler.

Scheduled messages do not materialize in the queue until the defined en queue time. Before that time, scheduled messages can be canceled. Cancellation deletes the message.

You can schedule messages using any of our clients in two ways: 

  1. Use the regular send API (Application Programming Interface) but set the ScheduledEnqueueTimeUtc property on the message before sending.

  2. Use the schedule message API, pass both the normal message and the scheduled time. This will return the scheduled message's Sequence Number, which you can later use to cancel the scheduled message if needed.

Scheduled messages and their sequence numbers can also be discovered using message browsing.

The Sequence Number for a scheduled message is only valid while the message is in this state. As the message transitions to the active state, the message is appended to the queue as if it had been enqueued at the current instant, which includes assigning a new Sequence Number.

Because the feature is anchored on individual messages and messages can only be enqueued once, Service Bus does not support recurring schedules for messages.

Message Removal 

It is the processing of a locked message, and how to delete it from the queue or subscription. This operation should only be called after successfully processing a previously locked message, to maintain at-least-once delivery assurances. 

For further information regarding how the Message removal is done, follow the Microsoft documentation HERE. 


When you have critical applications and business processes relying on Azure resources, you want to monitor those resources for their availability, performance, and operation. Here is the article that describes the monitoring data generated by Azure Service Bus and how to analyze and receive alerts from this data with Azure Monitor. 

What is Azure Monitor? 

Azure Monitor collects monitoring telemetry from a variety of on-premises and Azure sources.

Management tools, such as those in Azure Security Center and Azure Automation, also push log data to Azure Monitor. The service aggregates and stores this telemetry in a log data store that is optimized for cost and performance.

Azure Service Bus creates monitoring data using Azure Monitor, which is a full-stack monitoring service in Azure. Azure Monitor provides a complete set of features to monitor your Azure resources. It can also monitor resources in other clouds and on-premises.

For further details, you can visit the Microsoft documentation HERE. 


This section provides troubleshooting tips and recommendations for a few issues that you may see when using Azure Service Bus as the broker service in the VIDIZMO app. 

Connectivity, or Timeout Issues

If you have intermittent connectivity issues, slow network performance, or a network security appliance operating at the edge of your network, you may experience slow application performance, and/or application not functioning at all. Please consider looking into the below areas to determine the root cause of the issue and resolution as needed:

Before configuring Azure Service Bus as the broker service in VIDIZMO, it is recommended to make sure the Service Bus namespace is accessible from the VIDIZMO application server.

You can browse to or WGET ‘https://<yournamespace>’. It helps with checking whether you have IP (Internet Protocol) filtering or virtual network or Firewall related issues, which are common in a secure network environment. You can download WGET HERE.


An example of a successful message: 



An example of a failure error message: 




Your organization network may be locked, and the necessary ports might be blocked which are needed to access the Azure Service bus. Ports used are: 

  • 443 (HTTPS)
  • 5671 (AMQP)
  • 9354 (Net Messaging/SBMP)

You can use MS TELNET to check if any port is blocked on the security system. Here is the sample command to check whether the 5671 port is open for transmission.
When there are intermittent connectivity issues, run the following command to check if there are any dropped packets. This command will try to establish 25 different TCP connections every 1 second with the service. Then, you can check how many of them succeeded/failed and see TCP connection latency. You can download the PSPING tool from HERE. 


Issues that may occur with service upgrades/restarts

You may experience the following issues with your VIDIZMO app when there are any Service_Bus-related upgrades or service restarts.

  • Requests may be momentarily throttled 
  • There may be a drop in incoming messages/requests 
  • The log file may contain error messages 
  • The application may be disconnected for a few seconds

Backend service upgrades and restarts may cause these issues in your VIDIZMO application. 

For resolution, the retry policy is already built-in Azure Service Bus and it is always active. The VIDIZMO application will reconnect without significant impact on the application/workflow.

Application Configuration and Component Services 

This section provides information about VIDIZMO related configurations that you may need to investigate in case of issues. 

Distributed Run-Time Config 

The ‘Application Configuration’ portion in your VIDIZMO app includes the ‘Distributed Run Time Config’ section where you would configure Endpoints needed to establish a connection with the broker service. The application may run into unexpected issues if the Endpoints are not specified correctly. Make sure the correct Connection String is added with all VIDIZMO services in the ‘Distributed Run Time Config’ section. The example is shown below: 




VIDIZMO Component Services

VIDIZMO uses different component services that run in the background to allow the application to function. The VIDIZMO application may run into issues when one or more services are in a stopped state.

When one or more VIDIZMO services are in a stopped state, it can cause the broker service to stop relaying messages between component services. At this point, you will see the Service Bus message queue being piled up (see the count). To see the message queue under your Azure Service Bus resource, log in to your Azure portal account > go to your Service Bus resource > select the Overview section and here you can view the message queue.

Please make sure the VIDIZMO services are in running state on the application server. See the below example: 




For information about issues related to Azure Service Bus, please see Microsoft documentation HERE. 

For issues related to VIDIZMO, please contact the VIDIZMO support team and one of us will get back to you accordingly. To contact the VIDIZMO support team, please send an email to