Recently I was asked by one customer on how they can assess or check the performance of Dynamics CE as they were having some network outages and issues. I remembered that I used a tool earlier for checking my Dynamics CRM On premise engagement. So after checking for online version as well, got to know that we can use in the same way to find the performance for the online CE instance as well. You can follow as below…
To run the Diagnostics tool, you have to follow these steps.
On the user’s computer or device, start a web browser, and sign in to an organization.
The report displays a table with test and benchmark information. Of particular importance is the Latency Test row value. This value is an average of twenty individual test runs. Generally, the lower the number, the better the performance of the client.
In this way you can track your Dynamics CE performance at a given point of time to assess your network latency and bandwidth behaviors.
To start with Service Bus is fully managed messaging service which is used to connect any applications, devices, and services running in the cloud to any other applications or services. In this we can have queues which helps in the one directional communication and topics which provides two directional communication with the help of publish subscribe model.
Service bus can serve the following purposes
Used for messaging
For Decoupling producer and consumer of the message
Load balancing
For 1:N(publish and subscribe model) using Topics
Queues and Topics follow FIFO mechanism.
That said, lets see in action…
Create an Azure service bus namespace in Azure like below…
Following this, once you have created a namespace which is actually a container for all messaging components (queues and topics).
Next step is to create a queue or topic, in this case I am creating a queue….creating topic will be similar.
Fill up the details as required for the queue setup in the highlighted section…
After creating a queue or topic, you need to create an access policy for the same as below
Do note the queue URL as highlighted above….access control in service bus is achieved through Shared Access policies.
Once you have Primary connection string created, you need to go back to your Plugin registration tool and register a service end point for triggering your service bus message and provide the connection string in the below areas highlighted and click on next.
Next below appears for your review..
You can provide SAS Key or SAS Token for authentication in order to retrieve the messages from service bus and click on save. Now your end point is configured, now you can go ahead and create a step which will trigger the message to service bus from Dynamics, do note that you can only register an asynchronous operation inorder to communicate with your service bus.
You can perform the necessary operation and you can find the message being created in the service bus. If it didn’t show up immediately, please refresh and try after a few mins.
In order to consume these messages, you can use a console application for the sake of retrieval. Once the message is retrieved, it will be deleted from the queue by default.
Incase you want to use those messages for your troubleshooting purposes, you can peek command, the Peek operation on a queue or a subscription returns at most the requested number of messages. The following table shows the types of messages that are returned by the Peek operation.
Type of messages
Included?
Active messages
Yes
Dead-lettered messages
No
Locked messages
Yes
Expired messages
May be (before they are dead-lettered)
Scheduled messages
Yes for queues. No for subscriptions
I hope this provides right insights for integrating service bus with Azure and service bus is widely used when both systems were not in sync and available at the same time.
ECELLORS CRM Blog 