BizTalk360 is a single platform to have total control over your BizTalk environment. It has the three main modules namely Operations, Monitoring and Analytics. Monitoring is considered as the main feature of BizTalk360 because it provides rock solid monitoring for the BizTalk environment and informs us via email alerts when the BizTalk server is suffering from problems and downtimes.
As per the below quotes,
“Listening to our customer’s feedback makes them feel appreciated and part of the value creation process”
We always listen to their valuable suggestions and feedback and add them to BizTalk360 in every upcoming release. We also make enhancements to the existing features based on the customer feedback. This blog explains about one such enhancement on actions performed on the suspended instances.
MessageBox Queries Monitoring:
Data Monitoring was one such feature included in BizTalk360, from the customers’ feedback. Data monitoring helps to monitor the send/receive ports, service instances and exception data from different data sources in BizTalk server. Message Box Queries monitoring is a part of Data Monitoring which is used to monitor the service instances. The service instances may be running or may get suspended in BizTalk servers due to various reasons.
The messaging service instance is the service instance that’s created for your receive and send port at the run time. A receive port/send port is a combination of various things. Ex: An adapter (File, WCF, SQL etc.), a receive pipeline (and a send pipeline if two-way), and Maps. They get instantiated like the objects for the classes and have different states in their lifetime namely,
- Ready to Run
- Suspended (Resumable)
- Suspended (Non-Resumable)
- In Breakpoint
Here in monitoring, we can monitor the count of these instances at various stages and the alerts will be triggered based on the filters and threshold value configured. It is important to monitor the number of service instances, to keep the BizTalk environment healthy. Having many instances will make the MessageBox database bloated which in turn will affect the performance of the environment. The service instance count can be retrieved from BizTalk Administrator group hub page which displays only the count and does not tell you if it’s the expected count or not. A person seeing this information needs to be a BizTalk expert to understand the various states. Here comes our MBQ monitoring which alerts users according to the threshold limit configured. A non-BizTalk person can now easily understand the alert message and act accordingly.
Actioning on the suspended service instances:
Based on the state of the service instances, the administrator can decide on whether to resume or terminate the instances. For example, when a message is sent through the send port and if it’s stopped, then the instance gets suspended. Once the send port is up, the message can be resumed and processed. Instead of going to the BizTalk admin console and checking it, BizTalk360 has the feature to terminate/resume the instances from the monitoring itself. We can also configure the time when we want to perform the action, either every time or during Error/Warning condition.
So, what happens when Action Required is ticked?
There may be scenarios wherein, the customer wants to monitor any suspended messages that by the end of the day are no longer relevant and should be terminated. So, in this case, BizTalk360 can automatically terminate the instances as per the alarm configuration. This can avoid the excess workload to the BizTalk user as he needs to go and manually run the query to find the instances and action it. We also have the option to bulk terminate the suspended instances altogether instead of doing one by one. There is also an archiving option and to download the instances.
Can non-super users terminate/resume suspended instances?
We have two kinds of users in BizTalk360, namely Super users and normal users. Super users enjoy the admin privileges and have access to all modules. They can define the authorization for the different level of users. They restrict the access permissions for the normal users. The normal users will have minimal access permissions.
The normal users can be anyone from the organization, may be supported engineers, other non-BizTalk group members who are just monitoring BizTalk servers. They would not be aware of the conditions of the service instances. Hence, they cannot decide upon the action to be performed on the suspended instances as it’s a sensitive area like terminating/resuming the instances. This may lead to security and auditing problems also. When normal users configure Data Monitoring and try to resume a suspended instance, they may get an exception message as follows-
System.Exception: User does not have enough rights to access the BizTalkQueryService(service) and ExecuteServiceInstanceOperation(operation).
The administrator alone can know the state of the instances and decide upon the action on them. For this reason, BizTalk360 has provided the restriction that only superusers can perform the resume/terminate action for them.
An in-depth analysis on the super user access to terminate instances:
Let’s have an in-depth look into this limitation and how it must be handled. The user logged into BizTalk360 may be a super user. But still, that user will not be able to perform any action on the service instances. Do you know why? Let’s move forward to know the reason.
When we install BizTalk360, we provide the service account credentials. This service account will be the user who is running the App Pool and monitoring service. The logged in user running the MSI to install BizTalk360 may be different from the service account. When the application is installed, the logged in user will be created as a superuser in BizTalk360 by default.
So, what happens to the service account if it’s different from the logged in user?
The service account running the IIS App pool and the monitoring service must be created as the “Super User” in BizTalk360. Only then this user can perform the resume/terminate actions on the service instances. Otherwise, the above exception will be thrown.
Since these are sensitive operations on the instances, only the super user/ administrator should be able to perform such tasks. Therefore, BizTalk360 has imposed this restriction that only when the service account is added as the super user, he can perform the operations on the suspended service instances.