When you activate the option “Send ESB Detail In Notification”, you are getting the data show below with the number of faults per Fault Code. This data is grouped by Fault Code which is the default grouping. I need the option to be able to choose the “group by” setting on one of the three fields: Fault Code (the default grouping now), Error Type or Exception Message. In the case below you need to group the errors on the Exception Message because this can be different for the same errorcode.

ESB Fault Details in the application: Company.BizTalk.Application

Fault Code: ESB0002, Number of Faults by Fault Code:2
Error Type: ApplicationException

Exception Message: Group 1234 is deleted.

In application monitoring I'd like to have the option to show all receive locations, all send ports or all orchestrations in one overview.

This would make it much faster and easier to add all items in your monitoring.
And this would also make it much easier to add new items in your existing monitoring or to do a weekly or monthly check whether all new items are added in your application.
Now we have to click and reclick thousands of items if we want to check we have all items in our application monitoring. Especially when you have a lot of applications this is very devious and circuitous.

This could be similar to the monitoring of for instance all NT Services

Hello BizTalk360 team,

I am helping TF1 test your monitoring solution and after my first presentation to different users, I have some remarks from them which I think might interest you :
· User management : possibility to create management profiles, and attach those profiles to users. I am aware that we can achieve something similar through AD groups, but they don’t seem to be very enthusiastic about it – mainly because the process of requesting membership to a specific AD group is slow…
· Graphical flow tracking and Message Box Queries (In particular, but this suggestion may apply to all functionalities) : automatically filter the data according to the applications the user is allowed to monitor
· Graphical flow tracking and Message Box Queries saved queries : right now all saved queries are available to any user (provided this user is granted the right to access Message Box Queries or tracking data). It would be nice to be able to grant / deny access per query and per user (profile?)

By Simon Rivas

Suspended messages are routed to ESB and for some reason doesn't reach ESB, in this case user wants a notification
but problem is if you search in suspended messages there are too many and the suspended message application name does not reflect the application from which the message came - the application name of the suspended message is All.Expcetions
You need to go into the message context of suspended message & read the application name there.
Currently a powershell script is used to filter the applications in message context.
Basically can BizTalk360 go thru the message context and read the message application name as the suspended message application name is different

Currently there is no place to see, at the same time, all artefacts that are set to autocorrect.

In BizTalk360 there needs to be one single view showing a live view of all artefacts that will autocorrect if they are down.

In this view, at least the following should show:
- Current retries and other per artefact settings related to autocorrect.
- Each artefact should have a link to the alarm view of the application.
- Each artefact should have a link to the operations view of the application.
- It should be possible to group artefacts in the view; for ex. Currently retrying, Per application, Per artefact type, etc.

We have quite a lot of servers, and thus quite a few artifacts we monitor. However, we have way more artifacts (NTServices, SQL jobs, etc.) that we do not monitor. But I notice these artifacts still add rows to the table b360alertMonitor_LogStateCheck (with ExpectedState 2). This gives us a lot of useless rows in this table for things we don't want to monitor anyway. Is there a way to turn this off? We now have 17 million rows in this table, and we only keep this data for a week (the cleanup job works fine).
I can write a job myself to delete these rows with ExpectedState 2 at a higher frequency than 7 days (more like every hour), but I was hoping there was an option to actually indeed 'do not monitor' them at all

By Marc van de Klashorst