BizTalk360 has many features that BizTalk Operators and BizTalk Administrators can take advantage to manage their BizTalk Environments. BizTalk360 is constantly improving the existing features based on the customer’s feedback in every release of the product. Similarly, in version 8.9.5 the existing features are improved based on the customer votes for the feature request. In this article, we can see the three different feature improvements like Filter Improvements, ESB Fault Delete Operation, Notification channel reconfiguration that has been implemented.
The Filter Component is an important tool to get query results from BizTalk databases like BizTalkMsgBox, BizTalkDTADb and BAMPrimaryImport. In Message Box Queries and Tracking Queries (Graphical Message Flow), there were few filter operators missed in the previous version of BizTalk360. Due this missing filter operators’ customers faced challenges to filter data they expected get results out of it. To overcome this situation, BizTalk360 planned to implement the filter operators to match with BizTalk Admin Console. Please find the consolidated list of filter operators that are implemented in the latest version of BizTalk360.
Message Box Queries:
In Message Box Queries, to the filters Instance Status and Service Class “Not Equals” Operator are implemented in Operation and Data Monitoring Section
- All In-Progress Service Instances
- Running Service Instances
Similarly, other operators like IS Null, IS NOT NULL and Does Not Contains are implemented. While choosing the filter operators “IS NULL and Is NOT NULL“ there is no need of filter inputs.
Graphical Message Flow:
In the ESB Module, “Machine Name and Scope” are implemented in Operation (ESB Exception Data) and Data Monitoring Section (ESB Data) Machine Name filter has operators:
- Not Equals
Scope filter has operators:
- Not Equals
- Does Not Contains
Custom Notification Channel Reconfiguration
Custom Notification channel is a powerful mechanism to notify BizTalk360 monitoring alerts to various channels like Slack, Service Now, Microsoft Teams etc. There is even a possibility that a customer can write their own custom notification channel.
A customer has written their own custom notification channel like PowerShell notification to execute the PowerShell scripts to restart the Windows service when an Error or a Warning occurred. Based on the business case, they want to enhance the custom notification channel implementation.
In this situation, the customer must remove the configured notification channel from the alarms to which it is associated. Then reconfigure custom notification channel to the alarms. If the number of alarms is large, then it is tedious process to remove and reconfigure the notification channel from all the alarms. To Overcome this challenge, in this version 8.9.5 Custom Notification Channel Reconfigure capability has been introduced. By this feature, users don’t need to remove the configured channels from the alarms. Instead the user can click on Reconfigure button and choose the latest DLL to update the existing channel object stream in the database.
The automatically reconfigured notification channel will affect from the next monitoring cycle. The users must reconfigure the notification channel properties value, if they introduce a new alarm or global properties in the updated notification channel. The user can view the list of alarms to which a custom notification channel is associated. This will give insight in the number of alarms the notification channel is associated with.
ESB Fault Delete Operation
From the Feedback portal we understood that customers are interested to have Delete Operation on ESB Fault Exceptions.
A Send Port that you are using in an application fails unexpectedly, therefore both the service instance and the message become suspended and the fault information is written into the ESB exception database. Once the exception is corrected and resubmitted for further go, there may be two scenarios which will come into picture:
- Messages which are submitted successfully are residing in the ESB Exception database but are of no further use
- Messages are rerouted to the ESB Exception database due to recurrent failure. In this specific case, the original message is also available in the ESB portal
ESB Fault Deletion is introduced in the ESB Exception Management section. The user has the option to select multiple faults, which can be deleted in the one go. The delete operation will remove the data from the following tables in the ESB Exception database.
The Delete operation will delete Multi-Part message or multiple messages and context properties related to the faults from the corresponding tables.
BizTalk360 will capture the governance audit about the message delete operation. It will audit the user who performs the delete operation and message Id’s are displayed in governance audit section. Similarly, these operations are notified in Live Feed section.
We hope that the enhanced features will give you more control over the filters, Custom notification channels and ESB Faults. We always keep track of our Feedback Portal and take up the valid suggestions and feedback. If you would like to know more about how BizTalk360 can help your organization to manage your BizTalk Server middle ware platform, feel free to contact us.