Sometimes we have a process which is only partially executed by Biztalk. But this process is a global integration process and need to be monitored by an integration team.
Example :
the process write a flag file in a directory. sometimes Biztalk write the file, sometimes the file is written by another system (and no Biztalk artefact is trigerred). in this last specific cas, Biztalk 360 doesn't allow me to check if the flag file is there or not.
I think it could be useful to add a feature which allow to detect a file in a specific directory (same as the behavior of a Biztalk receive location)

We have data monitoring alerts setup for a number of customers such as count > 0 in last 15/30/60 minutes etc. This obviously results in individual emails, however it would be good to be able to roll up emails. For example if I have a customer that doesn’t place an order from 10-11 and then 11-12 and then 12-1pm, can I get emails to roll up so each subsequent email shows the previous failures? Otherwise I will just have three separate emails which I have to check for each customer to see how long they have not been placing an order for.

Inspired by some of the sessions at Integrate2017, I suggest you analyse the possibilities to develop an “Assign to me” function. Let me describe a bit more…

An alert-email goes out as a Biztalk send port is down. This email goes to a group, in our case 6 recipients. Then, who’s going to fix this? Maybe there could be a button in the email and when I click it, the status in 360-db on this alert goes to “ongoing work”/”under investigation” or something like that, with my ad-name as responsible. Then, another email goes out to the group as the status has changed and everyone knows that someone in the group is working on it.

Hope I made my point understandable, otherwise, just send an email and I’ll try to describe in other words…

Best regards,

Tom Nyberg

I am needing the capability to route suspended message ‘Data Monitoring’ notifications to some IT partners, but, based upon information that is in ONLY available in the Message Context. In these cases, the BizTalk messages are suspended with an Application Name of “Microsoft.Practices.ESB”, but are not able to make it to the Exceptions Portal and only associating the root application that caused the issue in the Message Context, which is how today we manually review and manually notify the development groups that these types of Suspended Messages occur. What I need is the capability to search generically across all Context Data elements, not just one if that eases the solution, using something like a SQL “like” wildcard.

• Idea shared by Eric Abts

There is no way for setting Stopped and Disabled states – not for monitoring or auto-correct behavior.

The problem this is creating for me is that if someone inadvertently starts a secondary FTP Receive Host Instance (as someone did recently) I want BizTalk360 to:

1. alert me that this Host Instance is in an unexpected state
2. have auto-correct set it to the desired state – Disabled
3. and stop the running service – because it should never have been started and must be stopped: a. Set to disabled and left running is not what I need b. Setting ‘Desired State’ to Stopped and using auto-correct to stop it isn’t enough – it needs to be disabled to draw someone’s attention to the fact that this service should not be started if it is seen to be down. This is special behaviour required by the limitations of the FTP Receive Adapter where business needs don’t justify clustering costs and a ‘warm standby’ solution is sufficient.

So in summary, what I would like BizTalk360 to do is to:

· Allow me to set desired state monitoring to disabled (which it does)
· Allow Auto-Correct to set the status to disabled (which it does)
· To also stop the service if it is running before setting the state to disabled

• Idea shared by Simon Young

When creating a new Alarm you must enable one or more of the 3 independent alarm types:
- Threshold
- Health
- Data Monitoring

There does not seem to be any logical reason that when an alarm should monitor Thresholds that it shouldn't also be monitoring Data and vice versa.
We ran into an issue when we built some DB Query Monitors and attached them to Alarms that didn't have Threshold monitoring enabled, only Data Monitoring. We never received alerts when the DB Query was triggering a failure. Only upon detailed investigation when we noticed that we were in a failure condition but had never received an email did we track down that Threshold monitoring was not enabled and DB Queries are part of Threshold, not Data Monitoring.