All about Microsoft Integration Technologies | BizTalk360 Blogs

Monitoring MLLP Adapter Port Availability with BizTalk360 PowerShell Automated Tasks

Mekala — Sat, 26 Sep 2026 10:32:16 +0000

Ensuring Reliable MLLP Connectivity in BizTalk Server

Healthcare Integrations often depend on HL7 messages exchanged over the Minimal Lower Layer Protocol (MLLP). In a BizTalk Server environment, the MLLP Receive Location acts as an important entry point for these messages. When the underlying MLLP listener becomes unavailable, inbound messages can no longer reach BizTalk Server, potentially disrupting critical integration workflows.

One of the challenges in monitoring MLLP integrations is that the Receive Location status alone may not provide sufficient visibility into the availability of the underlying TCP endpoint.

For example, a Receive Location can appear as Enabled in the BizTalk Administration console, while the corresponding MLLP TCP port may not actually be listening because the associated BizTalk Host Instance is stopped or the listener is otherwise unavailable.

This raises an important operational question:

How can we proactively verify that the MLLP endpoint is reachable and alert the operations team when it becomes unavailable?

One approach is to combine PowerShell-based TCP connectivity testing with BizTalk360 Automated Tasks.

In this blog, we will see how to use BizTalk360’s Automated Task to periodically monitor MLLP adapter port availability and proactively detect connectivity issues.

Why monitor MLLP Ports?

An unavailable MLLP endpoint can result in:

Failed HL7 message delivery
Delayed patient data exchange
Increased operational overhead
Manual troubleshooting and recovery

Rather than waiting for messages failures or customer reports, it’s better to verify the endpoint availability at regular intervals and receive alerts immediately when connectivity is lost.

“The MLLP Receive Location may be enabled in the BizTalk Administration Console, but the corresponding TCP endpoint is available only when the required BizTalk Host Instance and MLLP listener are operational.”

This may be the situation often BizTalk admins confused with.

As integration engineers, you have all experienced this moment-the one where the configuration says Enabled, but reality says Unavailable.

The Problem That Wasn’t Obvious

You may work with an MLLP Receive Location named “Tutorial_MLLP_Receive”.

Its configuration looked perfectly normal:

Receive Location: Tutorial_MLLP_Receive

URI: localhost:11000

Status: Enabled

At first glance, nothing suggested a problem.

So, you may decide to verify whether the endpoint was actually accepting TCP connections.

Test-NetConnection – ComputerName localhost -Port 11000

The result was disappointing.

TCP connect to (:1 : 11000) failed

TCP connect to (127.0.0.1:11000) failed

The receive location was enabled. The TCP port wasn’t reachable.

That contradiction led to an important realization.

An enabled Receive Location doesn’t always mean the MLLP listener is actually running.

Looking Beyond the Receive Location

Your next place to investigate was the BizTalk Host Instance.

Sure enough, the Host Instance responsible for the MLLP Receive Location wasn’t running. The configuration existed, but the runtime component responsible for opening the TCP port wasn’t alive.

After starting the Host Instance, you have checked the listener again.

netstat -ano | findstr :11000

This time you may have noticed:

TCP 127.0.0.1:11000 LISTENING

Now the endpoint was genuinely available.

Running the same PowerShell test again produced the result:

Test-NetConnection -ComputerName 127.0.0.1 -Port 11000

TcpTestSucceeded : True

Problem solved, but it also raised another question.

How would I know the next time this happens?

I didn’t want to discover a stopped Host Instance only after customers reported missing HL7 messages.

I wanted BizTalk360 to tell me first.

Turning a Manual Check into Continuous Monitoring

BizTalk360 already provides PowerShell Automated Tasks, making it the perfect place to automate this health check.

Instead of manually running Test-NetConnection, you can create a reusable PowerShell script that periodically validates whether the MLLP endpoint is accepting TCP connections.

The script monitors one of more MLLP endpoints and reports whether each one is available.

$MllpEndpoints = @(
    @{
        Name = "Tutorial_MLLP_Receive"
        Host = "127.0.0.1"
        Port = 11000
    }
)

$UnavailablePorts = @()

foreach ($Endpoint in $MllpEndpoints) {

    $Connection = Test-NetConnection `
        -ComputerName $Endpoint.Host `
        -Port $Endpoint.Port `
        -WarningAction SilentlyContinue

    if ($Connection.TcpTestSucceeded) {

        Write-Output "AVAILABLE: $($Endpoint.Name) - $($Endpoint.Host):$($Endpoint.Port)"

    }
    else {

        $Message = "UNAVAILABLE: $($Endpoint.Name) - $($Endpoint.Host):$($Endpoint.Port)"

        Write-Error $Message
        $UnavailablePorts += $Message

    }
}

if ($UnavailablePorts.Count -gt 0) {
    throw "$($UnavailablePorts.Count) MLLP endpoint(s) are unavailable."
}

What the Script Is Actually Doing? The script is intentionally simple.

It performs the same verification an administrator would do manually-but automatically and consistently.

Then the expected result is:

AVAILABLE: Tutorial_MLLP_Receive – localhost:11000

Important Note: The Host value should correspond to the server where the MLLP endpoint is hosted, relative to where the PowerShell script is executed.

If the script runs on the BizTalk Server: use 127.0.0.1 (localhost) when the MLLP listener is running on that same server.

If the script runs on the BizTalk360 Server: provide the BizTalk Server host name where the MLLP listener is running.

For example:

Host = “BizTalkServer01”

This distinction is important because 127.0.0.1 always refers to the machine executing the script, not automatically to the BizTalk Server.

What BizTalk360 Monitoring Covers?

This script validates one very specific and very important – layer of your HL7 integration.

BizTalk360 confirms that:

The MLLP listener is running
The TCP port is reachable
The endpoint is accepting connections

Configuring the PowerShell Automated Task in BizTalk360

Once the script has been validated, it can be configured as a PowerShell Automated Task in BizTalk360.

The general configuration involves:

Environment Dashboard → Administration → Automated Tasks → PowerShell Script

The task can then be configured with:

The PowerShell script
The execution server
The execution frequency
Notification settings

For example, the task could execute every 5 or 15 minutes depending on the required monitoring frequency.

When the endpoint is reachable, the task completes successfully.

When one or more monitored endpoints become unreachable, the script returns a failure condition, allowing the automated task to be treated as a monitoring exception.

BizTalk360 supports both inline PowerShell scripts and scripts stored as .ps1 files. It also provides script validation before the task is scheduled for execution. Script output generated through Write-Output and Write-Error can be viewed in task execution history and notifications.

Defining the Automated Task

For this scenario, the task is configured with following details:

Task Name:

MLLP Endpoint Availability Monitor

Description:

Periodically validates the TCP availability of configured HL7 MLLP Receive Location endpoints and reports unreachable endpoints for Proactive monitoring.

Script Name:

Monitor-MLLPEndpoints

The task name describes What is being monitored, while the script name identifies the PowerShell implementation performing the check.

The script is then associated with the BizTalk Server on which the MLLP connectivity check needs to be performed.

The Select Server(s) option is particularly important in this scenario. The TCP test is executed from the selected server, so the server should have network connectivity to the MLLP endpoint being monitored.

BizTalk360 allows the PowerShell task to execute scripts on local or remote servers, with up to five servers configurable for a task. The execution account must have the required access to the selected server.

For this example, the script is configured as an Inline Script. For larger or reusable scripts, the File Path option can be used to execute an existing .ps1 file from a server.

The Validate option can then be used to verify the script before proceeding with the remaining task configuration.

Choosing How often the Endpoints Should Be Checked

The next step is to determine how frequently the MLLP endpoint should be validated.

BizTalk360 Automated Tasks support both One Time and Recurrence schedules. A one-time schedule is useful during initial validation, while a recurring schedule is more appropriate when the objective is continuous endpoint monitoring.

For example, a production environment could use a recurring schedule such as:

Every 15 minutes

This means that BizTalk360 periodically executes the PowerShell script and verifies whether the configured MLLP endpoint is reachable.

The appropriate frequency depends on the business criticality of the integration.

A highly critical HL7 interface may require more frequent checks, while a less critical interface may be adequately monitored at longer intervals.

Handling a Temporary Failure

An MLLP endpoint being unavailable for a single check does not always mean that there is a prolonged outage.

This is where the Retry Failed Task option becomes useful.

BizTalk360 allows a failed automated task to be executed again by configuring the number of retries and the retry interval.

For this monitoring scenario, a reasonable example could be:

Retry Failed Task: Enabled
Number of Retries: 2
Retry Interval: 2 minutes

These values are only examples. The appropriate retry behaviour should be based on the operational characteristics of the BizTalk environment.

The purpose of the retry is not to hide an outage. It provides a short opportunity for a transient condition to recover before the failure is treated as persistent.

If the endpoint remains unavailable after the configured retries, the task should continue to report the failure.

Avoiding Notification Noise

A monitoring solution is only useful if the notifications it generates are actionable.

Imagine an MLLP endpoint being checked every 15 minutes and generating an email every time the check succeeds:

For a continuously monitored production endpoint, these messages provide little operational value.

Instead, the Notify only on Failure option can be enabled.

With this configuration, the normal state remains silent:

When the endpoint becomes unavailable:

BizTalk360 supports the Notify only on Failure option specifically to send notifications when an automated task execution fails.

This makes the notification model much more suitable for availability monitoring.

Choosing the Notification Channel

BizTalk360 provides multiple notification options for automated tasks, including email and collaboration channels.

For this example, email notifications can be configured for the integration or operations team.

The recipients should be selected based on who is responsible for responding to an MLLP connectivity failure.

For example:

Integration Operations Team
BizTalk Administrators
HL7 Application Support Team

Success Alert from BizTalk360:

The above screenshot shows you can configure an email recipient for the task.

In a real production environment, the recipient should be an appropriate operational distribution list rather than an individual’s mailbox.

Email notifications also require the corresponding BizTalk360 SMTP configuration to be available.

Depending on the organization’s operational model, collaboration channels such as Microsoft Teams or Slack can also be used.

The important consideration is not simply where the notification is sent, but whether the notification reaches the team that can actually investigate and recover the MLLP endpoint.

Failure Alert from BizTalk360:

Success Alert from BizTalk360:

Conclusion

BizTalk360 Automated Tasks provide a flexible way to automate routine operational activities in a BizTalk Server environment. By combining scheduled execution, PowerShell scripts, retry options, and notifications, administrators can turn manual checks and operational actions into repeatable and manageable processes.

The MLLP endpoint availability scenario is one example of how Automated Tasks can be used to proactively identify potential issues before they become larger operational problems. The same approach can also be extended to other monitoring, validation, and administrative requirements across the BizTalk environment.

Rather than relying entirely on manual checks or waiting for an issue to be reported, Automated Tasks help bring automation into day-to-day BizTalk operations, reducing repetitive effort and providing a more consistent approach to operational monitoring and response.

To know more about the BizTalk360 features, try out the free trial or book a demo.

The post Monitoring MLLP Adapter Port Availability with BizTalk360 PowerShell Automated Tasks appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

Process Monitoring Custom Message: Turning Technical Alerts into Business-Friendly Guidance

Vaishnavi Thiruppathi — Sat, 12 Sep 2026 04:25:54 +0000

Key Takeaways

The Challenge: Generic Alerts Leave Business Users Guessing
What’s New: Custom Notification Messages in Process Monitoring
How It Works: Configuring Custom Messages Step by Step
Real-Time Use Case: Order Processing Monitoring for a Retail Distribution Center
Operational Benefits: Faster Understanding, Faster Resolution

Process Monitoring in BizTalk360 tracks the number of messages processed by your receive ports and send ports, so you know when an expected flow of messages has gone quiet. You set the threshold you expect over a time window, and if it isn’t met, your team is notified because there is a business impact. This helps teams catch silent failures, like a partner not sending files or orders not reaching a backend system, before they turn into business problems.

But knowing that something went wrong is only half the battle knowing what to do about it is where teams often lose valuable time. That gap is exactly what the Process Monitoring Custom Message enhancement addresses.

The Challenge: Generic Alerts Leave Business Users Guessing

Let’s consider a typical scenario where a Process Monitoring schedule detects that no files were processed on a business-critical port within the expected window. An alert is triggered and reaches the operations team, and a business stakeholder who doesn’t have deep BizTalk expertise.

The alert says something like: “Threshold violated: message count 0, expected greater than 5.”

The message received is technically accurate, but practically insignificant to anyone who isn’t familiar with BizTalk’s. The recipient may not know:

Whether this is a transport-level issue, a partner-side problem, or a mapping failure.
Where to start investigating?
Which team or stakeholder should be involved?

This can lead to additional back-and-forth between business and technical teams. the business user contacts the integration team, the integration team logs into the BizTalk Admin Console, and only then does actual troubleshooting begin. This delay matters even more for time-sensitive processes, like order flows or partner integrations with strict SLAs. Every extra minute spent figuring out a violation alert brings the team closer to missing a deadline, breaking compliance, or upsetting a customer.

What users need is not just an alert that reports a threshold violation, but a notification that provides clear context and actionable guidance on what to check next. What’s New: Custom Notification Messages in Process Monitoring. With this enhancement, BizTalk360 allows users to attach a tailored, business-friendly message to any Process Monitoring schedule. When the monitored ports don’t meet the expected message-processing rule, the notification no longer just reports the failure it explains it, in language the recipient can act on immediately.

This means the same alert that once looked like a raw threshold violation can now be transformed into a clear, structured explanation of what likely went wrong and the exact steps to verify and resolve it without requiring the reader to be a BizTalk expert.

How It Works: Configuring Custom Messages Step by Step

The custom notification message can be configured directly within the Process Monitoring schedule under Manage Schedule → Process Monitoring, so no separate configuration is required. Set up the schedule as usual. Choose the alarm (for example, “Transaction Tracker”), name the schedule, and enable it for monitoring.

Choose the ports to monitor. Define whether the rule should apply when All or Any of the selected ports match, then pick the Receive Ports/Receive Locations and Send Ports that make up the business process — for instance, an outbound send port to a warehouse management system alongside its corresponding inbound acknowledgment receive location.
Define the expected message volume. Using an operator (greater than, equal to, or less than) and a threshold value, specify what “normal” looks like for that process — for example, expecting more than 0 messages within the monitoring window.
Enable “Send custom notification message.” This is the new capability. Once enabled, users can specify exactly when the custom message should trigger — such as when no files are processed in the selected ports, or when the file count doesn’t meet the specified threshold.
Add custom notification message. This is a free-text field where teams can write a structured, business-friendly explanation including likely root causes and a checklist of things to verify, ordered from the most common culprits to the less common ones.

Because the message is fully customizable, each Process Monitoring schedule can provide guidance depending on the business process they monitor. Example – an order fulfilment schedule can point administrators to check the warehouse management system’s connectivity, while a different schedule monitoring an internal application interface can point to its own set of checks, like database connectivity or service availability.

Real-Time Use Case: Order Processing Monitoring for a Retail Distribution Center

Consider a retail chain that pushes purchase orders from its central ERP system through BizTalk to a third-party warehouse management system (WMS) at its distribution center, expecting a confirmation acknowledgment back for every order sent. A “Order Fulfilment” Process Monitoring schedule watches the outbound send port to the WMS alongside the inbound acknowledgment receive location, expecting more than zero messages per monitoring cycle during business hours.

One afternoon, store orders stop generating acknowledgments from the WMS. Without a custom message, the on-call administrator receives a bare threshold alert and must manually start investigating — checking the orchestration, then the send port, then the WMS endpoint, and so on, often while store managers are already asking why replenishment orders haven’t been confirmed.

With a custom notification message enabled, the alert can include a guided troubleshooting checklist tailored to this specific process: “When order acknowledgments from the WMS stop arriving, work through the layers from the send side outward — most ‘stuck order’ issues sit at the send port or the trading partner’s endpoint.

Send Port / Orchestration

Is the send port enabled and not suspended due to a prior delivery failure?
Are orders reaching the orchestration and completing without being suspended — check for suspended instances first?
Is the outbound message correctly formed — has the order schema or mapping changed recently?
Is the WMS endpoint (API, file share, or message queue) reachable and accepting connections?
Have WMS-side credentials, API keys, or certificates expired?”

This single notification does what previously took a support ticket, a login to the Admin Console, and a call to the warehouse team. The administrator immediately knows to check for suspended orchestration instances, verify the send port’s status, and confirm the WMS endpoint is reachable — all before opening BizTalk360 or the Admin Console. If the root cause turns out to be an expired API key on the WMS side, the team can resolve it within minutes of the alert, well before store managers escalate the missing restocking orders.

Because this message is reusable across every alert this schedule generates, the same guidance reaches whoever is on call, even someone new to the team — making tribal knowledge part of the alert itself rather than something locked in a senior engineer’s head.

Operational Benefits: Faster Understanding, Faster Resolution

Reduced Investigation Effort: Responders don’t want to invest their time in figuring out where to look, the message tells them.

Business-Friendly Communication: Stakeholders without technical BizTalk knowledge can understand what’s happening and why, reducing unnecessary escalations to the integration team.

Consistent Troubleshooting Standards: Custom messages can include predefined troubleshooting steps, helping team members follow a consistent approach when responding to process monitoring alerts, including those who are new to the role.

Tailored to Business Context: Because each schedule can carry its own message, alerts stay relevant to the specific process being monitored, whether it’s order fulfilment, EDI, or internal application integration.

Conclusion

The Process Monitoring Custom Message capability is a small configuration change with an outsized operational impact. By letting teams attach clear, actionable, business-friendly guidance directly to threshold-based alerts, BizTalk360 closes the gap between detecting a problem and understanding how to fix it. Instead of alerts that simply report failure, teams get alerts that guide them toward resolution, reducing downtime, easing pressure on integration teams, and keeping business-critical processes like order fulfilment and partner transactions running smoothly.

To know more about the BizTalk360 features, try out the free trial or book a demo.

The post Process Monitoring Custom Message: Turning Technical Alerts into Business-Friendly Guidance appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

Automating BizTalk Health Checks with BizTalk360 BHM Scheduling and Maintenance

Nekalya Kundan — Tue, 25 Aug 2026 12:03:55 +0000

Introduction

Maintaining the health of a BizTalk Server environment requires regular monitoring and timely maintenance to ensure smooth and reliable operations. BHM provides valuable insights into the overall health of the environment and identifies recommended maintenance actions. BizTalk360 enhances this experience with BHM Maintenance and BHM Custom Schedule, allowing administrators to establish a recurring health-check routine and address maintenance requirements identified during ongoing health monitoring. With flexible daily, weekly, and monthly scheduling options, administrators can maintain a consistent health-check routine, minimize manual effort, and simplify BizTalk Server management.

BHM Custom Schedule

The BHM Custom Schedule option in BizTalk360 allows administrators to schedule the execution of selected BHM profiles at a predefined time and frequency. Instead of manually running profiles whenever a health report is required, administrators can configure a recurring schedule based on their monitoring requirements.

The feature supports Daily, Weekly, and Monthly scheduling options, providing the flexibility to establish a consistent health-check routine and generate BHM reports at scheduled intervals.

Types of Custom Schedule Use Case:

The Custom Schedule provides three scheduling options:

Daily – Run the selected BHM profiles every day at the configured time.
Weekly – Run the profiles on one or more selected days of the week at the configured time.
Monthly – Run the profiles on a specific date or on a particular occurrence of a day within the month.

These options allow administrators to choose a scheduling pattern that aligns with their organization’s health-check requirements.

Once the schedule is configured, BizTalk360 automatically executes the selected BHM profiles according to the defined schedule and generates the corresponding BHM health reports.

This ensures that up-to-date health information is available for review without requiring administrators to trigger the profiles manually.

Use Case

Consider an organization that performs a weekly BizTalk Server health review every Monday. Previously, an administrator had to manually execute the required BHM profiles before the review.

With BHM Custom Schedule, the administrator can select the required profiles and configure a Weekly schedule to run every Monday at 4:00 PM. BizTalk360 automatically executes the profiles and generates the BHM reports at the scheduled time.

The team can then review the reports as part of their weekly health-check process, helping them identify potential issues and take appropriate action without relying on manual execution.

BHM Maintenance

BHM Maintenance in BizTalk360 helps administrators manage and maintain BHM data efficiently. The maintenance activity can be performed on demand from the Administration section or automated through an Automated Task based on a defined schedule. This provides flexibility to perform maintenance when needed while also supporting regular, scheduled maintenance with minimal manual effort.

Manual Trigger for BHM Maintenance

Administrators can trigger BHM Maintenance manually from the Administration section whenever an immediate or on-demand maintenance activity is required. This provides administrators with control over when the maintenance operation is initiated and allows them to review and validate the recommended maintenance actions before execution.

The manual trigger is useful when maintenance needs to be performed during a planned maintenance window or when an administrator wants to review the current recommendations before proceeding.

Automating BHM Maintenance

For recurring maintenance, administrators can configure BHM Maintenance as an Automated Task. Once configured, BizTalk360 automatically performs the maintenance according to the defined task schedule, eliminating the need for administrators to trigger the activity each time.

Use Case

After the weekly health-check process, the BHM report is generated every Monday at 4:00 PM. The report highlights issues identified in the BizTalk environment, including cases where orphaned DTA tracking data is present. Over time, tracking data can become orphaned when tracked message parts or their associated fragments no longer have their corresponding message or tracking part available.

To simplify the cleanup, the administrator can configure Delete Orphaned DTA Tracking Parts and Fragments as an Automated Task and map it to the respective BHM profile. Once the BHM report is generated, the mapped task can be executed to clean up the identified orphaned DTA tracking data. During execution, the task first removes the orphaned tracking parts and then removes the associated orphaned fragments.

When the BHM report identifies a significant amount of orphaned DTA data, it recommends the Delete Orphaned DTA Tracking Parts and Fragments maintenance task in the Administration section for the respective BHM profile. The administrator can review the recommendation and manually execute the task when cleanup is required.

Conclusion

Maintaining a healthy BizTalk Server environment requires regular health checks and timely maintenance. With BHM Maintenance and BHM Custom Schedule, BizTalk360 simplifies these activities by reducing manual effort and automating routine BHM operations. Administrators can schedule BHM profiles to run daily, weekly, or monthly and perform maintenance manually or through Automated Tasks. Together, these capabilities help ensure consistent health monitoring and make it easier for teams to review BHM reports and maintain their BizTalk Server environments efficiently.

To know more about the BizTalk360 features, try out the free trial or book a demo.

The post Automating BizTalk Health Checks with BizTalk360 BHM Scheduling and Maintenance appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

IIS Log Monitoring: Ensuring API Availability Through Optimized Performance

Senthil Kumar — Mon, 10 Aug 2026 10:26:19 +0000

Key Takeaways:

Why IIS Log Monitoring is vital in Business-Critical Environments
Optimized IIS Log Collection for Better Throughput
IIS Log Monitoring: Key Metrics to Track
Proactive Action with Automated Tasks

Why IIS Log Monitoring Is Vital in Business-Critical BizTalk Environments

BizTalk message process relies heavily on IIS-hosted endpoints (WCF/HTTP adapters in Receive/Send Ports) to handle real-time integrations between business systems. In this context, IIS logs are often the only visibility layer into request failures, latency spikes, and throttling before they cascade into missed SLAs or failed transactions.

BizTalk’s dependency on IIS: Receive/Send ports exposed via HTTP/SOAP/REST adapters run through IIS, making IIS health directly tied to integration uptime.

Business impact of blind spots: A single unmonitored IIS failure can silently break order processing, EDI exchanges, or partner API calls, often discovered only after downstream complaints.

Compliance and audit need many BizTalk deployments sit in regulated industries (finance, healthcare, logistics) where request/response logs are needed for traceability. With the optimized log visibility to trace the transactions interruption with IIS log monitoring.

Early warning signal: IIS logs surface degrading response times or rising error rates before they escalate into full outages, giving ops teams lead time to act.

For instance, after deploying a new API version, IIS may start logging 401 Unauthorized errors on certain methods this indicating the requesting user lacks the required permission set, a signal that surfaces in logs well before it’s reported as a business issue.

Optimized IIS Log Collection for Better Throughput

Collecting every line of an IIS W3C log including 200 status codes, static asset request, every health check — can increase I/O overhead on the server and bloats storage without adding diagnostic value. BizTalk360’s IIS Server management addresses this directly through targeted Log Collection Filters, letting administrator to collect only operationally relevant logs.

Enable logging at the website level: BizTalk360 lets you turn on log collection per website (here, Default Web Site under W3SVC1) rather than blanket-enabling every site on the server, so only the endpoints that matter to your integration layer are tracked.

Filter by status code: Instead of ingesting the full spectrum of response codes, the configuration narrows collection to 400, 401, 403, 500, and 503 — the codes that indicate a problem (bad requests, auth failures, forbidden access, server errors, service unavailability). Successful 200/301 traffic, which typically makes up the bulk of log volume, is excluded from collection.

Filter by method: Scoping collection to specific HTTP methods (GET, POST, DELETE, PATCH, OPTIONS) ensures the logs capture the operations relevant to BizTalk transaction flows, without noise from irrelevant verbs.

Filter by port/endpoint: Restricting collection to a specific port or path filters scoped the integration endpoints logs collection, rather than every site hosted on the same IIS server.

Throughput impact: Because filtering happens at the collection layer rather than post-processing, the server writes and processes a fraction of the log volume it otherwise would. This reduces disk I/O contention, lowers CPU overhead from log parsing, and keeps the monitoring pipeline itself lightweight, the IIS log monitoring adds visibility without becoming a performance tax. It also means the 401 examples from the earlier section gets surfaced immediately, since error-code filtering is already tuned to catch it, rather than being buried in a firehose of routine 200s.

Monitor API methods Key Metrics to keep track of Availability

Effective IIS log monitoring isn’t about collecting every field available it’s about tracking the key metrics that indicate API health and availability. For BizTalk-integrated environments, the following are the essential core metrics:

Method types: Monitor HTTP methods such as GET, POST, PUT, DELETE, PATCH, and OPTIONS separately helps distinguish between read and write operations. so, a spike in failed POSTs (which usually carry business transactions) can be treated with more urgency than a failed GET.
Status codes: Monitoring 400, 401, 404, 500, 502, and 503 surfaces the full range of failure modes like bad requests and unauthorized access to missing resources and backend/service outages, so teams can triage by severity rather than treating all errors the same.
URI: Tracking failures at the URI level pinpoints exactly which endpoint or API operation is degrading, rather than surfacing a generic “IIS is throwing errors” signal.
Port number: Useful in multi-site or multi-application IIS servers, where isolating traffic by port confirms which service or application is impacted.

Use case: Shipping API monitoring in logistics

In a logistics organization, on-time shipment tracking depends on a chain of APIs working together for order creation, carrier dispatch, and shipment status updates. If one of these APIs fails, it can delay dispatches, tracking data, and impact delivery SLAs across the supply chain.

This is where metric-driven alerting closes the gap between detection and action. In the example configuration above, an alert named “Track-Shipping API 401” is configured to the Default Web Site and filtered to POST requests returning a 401-status code on the shipping endpoint. Rather than waiting for a manual log review, the system is configured to warn after 10 matching log entries and escalate to an error after 20, within a rolling 15-minute window a permission or authentication issue on the shipping API before it silently blocks order processing.

Proactive Action with Automated Tasks

Detecting a problem early is only half the equation done, the real value of IIS log monitoring comes from what happens next. BizTalk360’s Automated Tasks bridge the gap between detection and recovery by triggering predefined corrective actions as soon as an alert threshold is exceeded.

In the example configuration above, the “Shipping Process Pool” task is built specifically to restore API availability when the shipping process starts failing. Its workflow runs in two coordinated steps:

Step 1 — Restart the IIS App Pool: On the KOVLTP355 server, the BizTalkManagementServiceAppPool is restarted rather than just recycled. A restart re-establishes the app pool’s identity against Active Directory, syncing the account’s group memberships and permissions with the latest AD policy changes. This directly resolves 401 Unauthorized errors caused by stale cached credentials or recent AD group policy updates that a simple recycle wouldn’t pick up, since recycling only replaces the worker process without refreshing the identity token.

Step 2 — Restart Host Instances: Once the app pool is restarted, as the next step the associated Processing Host instances are started, ensuring BizTalk’s message processing resumes cleanly rather than left orphaned mid-cycle.

Tied back to the earlier alert example, this task is exactly what gets triggered when “Track-Shipping API 401” crosses its error threshold that the alert detects the authentication failures on the shipping API, and this automated task responds by cycling the app pool and restarting host instances, restoring order processing before the delay cascades into missed shipment SLAs.

This is the practical payoff of the whole monitoring chain covered in this post: optimized log collection keeps the pipeline lightweight, key metrics and alerts catch the right failures fast, and automated tasks act on them in seconds which turning IIS log monitoring from a passive diagnostic tool into an active safeguard for both performance and API availability.

Conclusion

The outcome is clear with IIS Log monitoring strategy that actively supports business continuity not just reports on failures after they occur.

The latest version of BizTalk360 offers more features with more control on your BizTalk environments. Try out the BizTalk360 which provides reliable monitoring with lesser manual interaction and more control during the maintenance.

The post IIS Log Monitoring: Ensuring API Availability Through Optimized Performance appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

BizTalk360 v11.9 – Smarter Monitoring, Greater Automation, and Stronger Security

Saranya — Tue, 21 Jul 2026 07:18:36 +0000

Keeping enterprise integrations running smoothly requires more than just monitoring—it demands proactive visibility, and intelligent automation. With BizTalk360 v11.9, we have introduced enhancements designed to help administrators detect issues earlier, reduce manual effort, and strengthen the security of their BizTalk environments.

Highlights from BizTalk360 v11.9

IIS Log Monitoring – Monitor IIS logs with configurable filters and threshold-based alerts to quickly detect API failures and recurring HTTP errors.
Optimized IIS Log Collection – Collect only relevant IIS logs by filtering based on website, status code, HTTP method, URI, client IP, and username.
Process Monitoring – Custom Notification – Configure business-friendly notifications that help users quickly understand integration issues without BizTalk expertise.
Enhanced BHM Scheduling – Schedule BizTalk Health Monitor (BHM) profiles with flexible Daily, Weekly, and Monthly recurrence options.
BHM Automated Task – Manual Trigger – Review and validate BHM maintenance recommendations before executing maintenance tasks.

IIS Log Monitoring

Modern integrations often depend on web applications and APIs hosted on IIS. Identifying recurring HTTP errors or API failures often required manually reviewing IIS log files.

With IIS Log Monitoring, BizTalk360 can now monitor IIS log entries and alert administrators when predefined thresholds are exceeded.

You can configure filters based on:

Website
HTTP Status Code
HTTP Method
URI
Client IP
Username

This allows you to focus only on the log entries that matter.

You can even configure an Automated Task to restart the IIS Application Pool or a BizTalk application, reducing downtime and accelerating recovery.

Use Case

Suppose your Order Management API suddenly starts returning HTTP 500 errors when new version of API’s deployed in the production or after any windows patch update.

Instead of waiting for business users to report failures, configure an alert to monitor:

Website: OrderManagementAPI
Status Code: 500
URI: /api/orders
Threshold: More than 50 errors in 15 minutes

When the configured threshold is exceeded, BizTalk360 immediately raises an alert. You can also configure an Automated Task to automatically restart the corresponding IIS Application Pool or BizTalk application, helping restore the service quickly, reduce downtime, and minimize manual intervention.

IIS Log Configuration

In complex Integration environments, IIS servers can generate thousands of log entries every hour. Collecting each event of logs consumes storage and makes troubleshooting more difficult.

BizTalk360 now allows you to optimize IIS log collection by filtering logs before they are collected.

Rather than collecting logs for every application hosted on IIS, you can collect only 400 and 500 errors for your public APIs, significantly reducing storage while improving troubleshooting efficiency.

Configure collection based on:

Website
Status Code
HTTP Method
URI
Client IP
Username

The URI filter supports Contains matching, making it easy to monitor all requests to a specific endpoint without configuring multiple rules.

Process Monitoring – Custom Notification

Monitoring alerts often contain technical information that business users may find difficult to interpret.

With Custom Notification Messages, Process Monitoring now lets you send the clear instructions that BizTalk operators can take actions with minimal BizTalk Expertise whenever message processing thresholds are not met.

The custom message is sent when:

No files are processed in the selected ports.
The processed message count does not meet the configured threshold.

Use Case

Consider an EDI integration where purchase orders are expected every hour. Configure Process Monitoring to expect a minimum number of EDI order messages within a one-hour interval. If no messages are received during the configured period, BizTalk360 detects the violation and raises an alert.

Instead of sending a technical notification, configure a Custom Notification Message to provide clear, business-friendly guidance, such as:

“Expected EDI order messages were not received. Please verify the trading partner and receive location.”

This notification immediately informs operations and business support teams about the nature of the issue and the recommended action, without requiring any BizTalk knowledge.

BizTalk Health Monitor – Custom Schedule

Keeping BizTalk environments healthy requires regular health checks.

BizTalk360 now offers enhanced scheduling options for BHM with flexible:

Daily schedules
Weekly schedules
Monthly schedules

Administrators can schedule different BHM profiles to match maintenance windows and operational requirements.

Use Case

Run a comprehensive health check every Sunday during planned maintenance while scheduling a lightweight monitoring profile every weekday morning before business hours begins.

BHM Maintenance Task-Manual trigger

Automation is powerful, but administrators often want control over maintenance activities.

BizTalk360 now introduces Manual Trigger support for BHM Maintenance Tasks.

Instead of executing recommendations automatically, administrators can review the generated BHM report and manually trigger only the required maintenance tasks.

Use Case

A BHM report recommends purging old tracking data and deleting orphaned DTA instances.

The administrator reviews the recommendations and executes only the approved maintenance tasks, ensuring production changes remain fully controlled.

Artifacts Adapter Properties Export

The Adapter Properties Export enhancement now exports Send Ports and Receive Ports with their adapter properties, making configuration reviews and migrations much easier.

During an environment migration or configuration audit, administrators can export complete adapter settings without manually documenting each property.

Improved Monitoring Dashboard Access Control

Organizations frequently provide dashboard access to support teams while restricting configuration changes.

BizTalk360 now introduces enhanced role-based access for the Monitoring Dashboard and BizTalk Group Dashboard. Users can continue to view dashboard health and status while navigation to underlying features is controlled by their assigned permissions.

Security Improvements

Security continues to be a key focus in BizTalk360.

This release introduces several important security enhancements, including:

Application-wide CSRF protection across API endpoints.
Enhanced protection of sensitive fields in SFTP, FTP, API Apps, and Web Endpoint monitoring.

These improvements help protect sensitive configuration data and strengthen the overall security posture of the platform.

Conclusion

BizTalk360 v11.9 delivers meaningful improvements across monitoring, automation, usability, and security.

Upgrade to BizTalk360 v11.9 to take advantage of these latest enhancements and keep your integrations running smoothly.

BizTalk360 v11.9 Release Notes – https://docs.biztalk360.com/docs/v119

11.9 feature videos – https://youtu.be/szfI5l-uDOo

The post BizTalk360 v11.9 – Smarter Monitoring, Greater Automation, and Stronger Security appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

Unlock More Value from Enhanced BizTalk360 Reporting with Smarter Dashboards & Custom Widgets

Senthil Kumar — Wed, 24 Jun 2026 11:24:40 +0000

Key Takeaways:

The Reporting Challenge in Complex BizTalk Environments
What’s New: A Quick Look at the Enhanced Capabilities
Administration Dashboard: Total Operational Clarity
ESB Exception Dashboard: Turning Exceptions into Opportunities
Smarter Reports, Faster Decisions: What’s Changed in Analytics

The Reporting Challenge in Complex BizTalk Environments

BizTalk Server environments are inherently complex managing multiple host instances, orchestrations, send/receive ports, and message pipelines simultaneously. BizTalk Administrators needs clear, real-time visibility across landscape to keep operations running smoothly. Spotting the performance degradation, identifying suspended messages, and detecting infrastructure bottlenecks before they escalate requires consolidated insight rather than scattered, manual checks. As environments grow, so does the need for a centralised reporting layer that turns raw operational data into actionable intelligence helping administrators anticipate issues, prioritise effectively, and spend less time in troubleshooting and more time in resolving the issues.

What BizTalk environments need is a unified, intelligent reporting layer that speaks the language of BizTalk/SQL Administrators and Business Users: operational precision for administrators, transactional clarity for EDI teams, business-level visibility for BAM users, and rapid fault resolution for ESB teams. That is exactly where enhanced BizTalk360 reporting steps in.

What’s New: A Quick Look at the Enhanced Capabilities

BizTalk360 has steadily evolved its dashboard and reporting experience to give every stakeholder a tailored, data-rich view of their integration environment. The most recent releases bring a powerful set of dashboards with custom widgets, which are designed to represent the metrics that Administrators/Business users are interested.

Here’s a quick look at what’s now available:

Administration and ESB DASHBOARDS (INTRODUCED in v11.8)

The latest release rolls out two significant additions. The Administration Dashboard gives BizTalk and SQL administrators a consolidated, real-time view of infrastructure and operational health, while the ESB Dashboard brings clarity to fault handling and itinerary processing. Both are built to reduce the time it takes to move from detection to resolution.

EDI and BAM Dashboards (Introduced in v11.6)

Earlier, version 11.6 delivered the EDI Dashboard and the BAM Dashboard, extending rich visibility to EDI trading partner activity and Business Activity Monitoring data. These dashboards put transactional and business-level insights directly in front of the people who need them without requiring deep technical intervention each time.

Custom Widgets Across the Board

A defining theme across all these dashboards is flexibility. The ESB, BAM, and EDI dashboards all support custom widgets, allowing users to configure exactly the metrics they want to track and display. Whether it’s transaction counts, partner-level interchanges, or business milestones, each user can shape their dashboard around their own priorities.

This widget-driven approach extends to the newest dashboards as well. The Administration Dashboard offers configurable widgets covering key operational metrics, and the ESB Dashboard provides custom widgets for faults and itinerary metrics, letting integration teams keep the most critical fault and routing data front and centre.

To summarise where each feature is included in BizTalk360 reporting to share the trend analysis and failure insights, to respective stakeholders with periodic schedules (Daily, Weekly and Monthly)

Administration Dashboard (v11.8) – operational and infrastructure health, with configurable widgets. Dashboard widgets
ESB Dashboard (v11.8 – faults and itinerary metrics, with custom widgets. ESB Exception Dashboard
BAM Dashboard (v11.6) – BAM Dashboard (v11.6) BAM Dashboard
EDI Dashboard (v11.6) – trading partner and EDI transaction metrics, with custom widgets EDI Dashboard and widgets | EDI custom widgets
Analytics Dashboard (Earlier versions) – BizTalk Messaging and Server Performance metrics
Application Dashboard (Earlier versions) – Deep insights about the application artifacts
Secure SQL Queries (Earlier versions) – Consolidate query results

Together, these dashboards form a cohesive, customisable reporting experience – one that scales across the various metrics.

Administration Dashboard: Total Operational Clarity

The Administration Dashboard gives BizTalk and SQL administrators a single, consolidated view of their entire environment’s operational health. Instead of jumping between multiple consoles and queries, administrators get real-time visibility into the metrics that keep integrations running smoothly – all in one place.

What makes it truly powerful is its flexibility. The dashboard supports a range of configurable widgets, letting administrators build a view tailored to their priorities. Whether tracking host instance status, message processing activity, suspended service instances, or overall system performance, you decide what appears front and centre.

This widget-driven approach transforms the dashboard from a static report into an actionable operational insight.

ESB Exception Dashboard: Turning Exceptions into Opportunities

The ESB Exception Dashboard is designed to handle the complexity, transforming scattered fault data into clear, contextual insight that teams can act on immediately.

Rather than discovering failures only after downstream systems are affected, integration teams get a centralised, real-time view of ESB faults and itinerary processing. The dashboard surfaces what’s failing, where, and how often — giving teams the context they need to identify root causes faster and prioritise resolution based on actual business impact.

Configurable Widgets for Faults and Itineraries

The real strength of the ESB Exception Dashboard lies in its custom widgets. Teams can configure widgets to track critical metrics like

Fault counts by application
Exception trends over time
Itinerary processing volumes
Service-level routing activity

Use Case: Proactive ESB Monitoring in Order Processing — Purchase Orders & Invoices with ESB Reporting

The Scenario

Consider a manufacturing company that processes thousands of Purchase Orders (POs) and Invoices daily through its BizTalk ESB infrastructure. Purchase Orders arrive from customers via multiple channels, are validated and enriched through ESB itineraries, and are routed to the ERP system. Once orders are fulfilled, Invoices flow back through the ESB transformed, validated, and delivered to customers and the finance system. Every step is governed by dynamic itinerary-based routing across multiple services.

The Challenge

In this flow, a single failure can have a direct business cost. A Purchase Order that fails during validation or routing means a delayed or lost sale. An Invoice stuck in an itinerary step means delayed revenue recognition and frustrated customers. Worse, these failures often surface in different services at different stages making it hard to see whether an issue is an isolated glitch or a growing systemic problem.

How the ESB Exception Dashboard Changes the Game

With ESB fault and itinerary metrics consolidated into one configurable view, the order processing team gains continuous, contextual oversight:

Fault widgets configured by application and service instantly reveal where Purchase Order failures are clustering – for example, a spike in validation faults pointing to a malformed message format from one specific customer channel.
Itinerary metrics widgets track processing volumes across each stage of the PO and Invoice journeys, making it immediately obvious if Invoices are entering an itinerary but not completing it signalling a stalled routing step or an unavailable downstream service.
Trend visibility highlights patterns over time: if invoice transformation faults rise every month-end during peak billing cycles, the team can address capacity or design issues before the next cycle hits.

Dive deeper into the capabilities in the ESB Exception Dashboard documentation.

Smarter Reports, Faster Decisions: What’s Changed in Analytics

The latest enhancements to the reporting including ESB, EDI, BAM Dashboards with custom widgets and Administration Dashboard they’re about enabling faster, more confident decisions across the organisation. By combining real-time dashboards with the ability to deliver insights periodically, BizTalk360 ensures the insightful information reaches the right people at the right time, even when they aren’t actively following the analytics data.

Empowering BizTalk Administrators

For administrators, the Administration Dashboard turns continuous operational data into a decision-ready summary. Instead of manually compiling status updates, administrators can rely on periodic reports that capture infrastructure health, message processing activity, and system performance immediately. This means trends are spotted earlier, capacity issues are anticipated rather than discovered, and routine reporting no longer eats into time better spent on resolution. Decisions about scaling, maintenance windows, or troubleshooting priorities can be made quickly, backed by clear and current data.

Supporting Business Users

For business users, the value lies in clarity and timeliness. The ESB Dashboard surface’s fault and itinerary metrics that, when delivered as periodic reports, translate technical events into business-relevant insight. Business stakeholders can understand the health of critical processes, see where exceptions are impacting operations, and gauge whether service levels are being met all without needing to interpret raw technical logs. This shared visibility bridges the gap between IT and the business, ensuring everyone is working from the same picture.

The Power of Periodic Reporting

What ties it all together is the shift from on-demand checking to proactive, scheduled insight. Periodic reports drawn from these dashboards keep both technical teams and business leaders continuously informed, reducing the lag between an event occurring and a decision being made. The outcome is a more responsive where issues are addressed sooner, priorities are clearer, and decisions are grounded in up-to-date, role-relevant data.

Conclusion

In short, smarter dashboards combined with timely reporting mean less time gathering information and more time acting on it.

To know more about the BizTalk360 features, try out the free trial or book a demo.

The post Unlock More Value from Enhanced BizTalk360 Reporting with Smarter Dashboards & Custom Widgets appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

How BizTalk360 Helps Non-Technical Teams Confidently Manage BizTalk Operations

Mithesh Krishna Kumar — Mon, 08 Jun 2026 09:21:06 +0000

In many organizations, BizTalk Server quietly powers critical business processes in the background. Processing orders, exchanging invoices, handling partner integrations which is the kind of work that nobody notices until something goes wrong.

But while BizTalk is robust and reliable solution for the typical integration scenarios in BizTalk Environment, the way it is traditionally managed often creates an unintended challenge.

Operations become too technical.

A simple question like “Why did this order fail?” can quickly turn into a dependency on developers or senior administrators. Accessing the BizTalk Administration Console, understanding artifacts like receive locations or orchestrations, or even identifying failed messages is not straightforward for someone outside the technical team.

Over time, this creates a familiar pattern: business teams lack visibility, support teams feel blocked, and developers end up handling routine operational issues that really shouldn’t need their attention.

Making BizTalk Understandable — Not Just Manageable

What makes BizTalk360 different is not just that it adds features on top of BizTalk. It changes how people interact with it.

Instead of exposing users to the complexity of the underlying system, it presents a clean, web-based interface that focuses on what matters in day-to-day operations.

A non-technical user doesn’t need to understand what a “send port” is. They just need to know: did the message go through or not?

BizTalk360 answers that question instantly. Dashboards give a clear view of system health, ongoing processes, and failures in a way that feels intuitive. Without digging into multiple tools or servers, users can quickly spot if something needs attention.

Managing Multiple Integration Tools from a Single Platform

For non-technical and support teams, managing multiple integration technologies like ESB, EDI, BAM, BHM, and BRE through separate tools can quickly become overwhelming. Different consoles, disconnected monitoring experiences, and scattered operational data often make day-to-day support more complex than it needs to be.

BizTalk360 simplifies this by bringing these integration technologies together into a single web-based platform, giving teams one centralized place to manage and monitor the entire environment.

With BizTalk360, teams can:

Monitor and manage ESB exceptions, including message tracking and resubmission, from a dedicated ESB Portal
Access BAM dashboards and business activity data to gain better visibility into transaction flows and business processes
Monitor Business Hosts and Host Instances through BHM, helping teams quickly identify performance bottlenecks and availability issues
Track EDI transactions, acknowledgements, parties, and agreements without switching between multiple tools
Manage Business Rules through the web-based BRE Composer without requiring direct access to BizTalk servers

Instead of navigating multiple consoles and servers, operations and support teams get a unified operational experience inside BizTalk360. This reduces complexity, improves visibility, and helps both technical and non-technical users work more efficiently across the entire integration ecosystem.

From “Escalate Everything” to “Handle It Confidently”

In traditional setups, even minor issues get escalated. A failed message? Escalate. A stopped service? Escalate. When retry needed? Escalate. Not because the issue is complex, but because the tools are.

BizTalk360 changes this dynamic by simplifying how issues are presented and handled. Failed messages are no longer buried inside technical consoles. They’re surfaced clearly, along with meaningful error information.

More importantly, actions like resubmitting a message or retrying a process are made accessible in a controlled, user-friendly way. First-level support teams can resolve a large percentage of issues on their own, without waiting on developers.

Empowerment Without Risk

One of the biggest concerns when opening operational access to non-technical users is safety. What if someone accidentally stops a critical process? What if too much access is given?

BizTalk360 addresses this with granular role-based access control. Rather than an all-or-nothing approach, organizations can define exactly what each user can see and do. A business user might only track transactions, while a support engineer can handle resubmissions without touching configurations.

It’s a balance where teams are empowered to act, but within safe boundaries.

Removing the Need for Server Access

Traditionally, managing BizTalk means logging into servers, using remote desktop connections, and navigating complex admin tools. BizTalk360 removes that dependency entirely. Everything is accessible through a browser.

This might sound like a small change, but the impact is real. Operations teams can work faster, security overhead is reduced, and the friction of accessing production environments goes away. For non-technical users, it also removes the intimidation factor that comes with handling backend systems directly.

Proactive Instead of Reactive Operations

One of the bigger shifts BizTalk360 brings is in how issues are detected and handled. In many environments, problems only surface after they’ve already impacted the business when a partner raises a concern or a transaction fails downstream. That reactive cycle puts unnecessary pressure on support teams and delays resolution.

BizTalk360 introduces proactive monitoring and intelligent alerting, so teams are notified the moment something deviates from expected behaviour. But it doesn’t stop at alerts. With automated corrective actions, the system can step in on its own like restarting a stopped service, triggering a predefined action, or stabilizing a known issue without waiting for manual intervention.

Operations become less about watching and responding, and more about the system quietly taking care of itself. Non-technical users can trust that BizTalk360 will both flag and, in many cases, fix issues automatically so they can focus only on what genuinely needs their attention.

Learn More about the monitoring dashboard

Staying on Top of Azure Services Too

Modern BizTalk environments don’t live in isolation. Many organizations run Azure Logic Apps, Service Bus, and other Azure services alongside their BizTalk infrastructure, and monitoring them through separate tools only creates extra overhead.

BizTalk360 brings Azure services into the same monitoring experience. Logic Apps can be viewed, managed, and monitored directly within BizTalk360, allowing teams to check run history, enable or disable workflows, and resubmit failed runs without switching platforms. It extends the same simplicity and visibility from BizTalk into the cloud layer.

Learn More about Azure Services in BizTalk360

Getting Notified the Right Way

Knowing something went wrong is only valuable if the right person is informed quickly.

BizTalk360 supports multiple notification channels, allowing teams to receive alerts through the platforms they already use, including email, Microsoft Teams, Slack, and other integrations. This ensures organizations are not dependent on a single communication method for critical issues.

The notifications themselves are designed to be actionable. Instead of sending a vague alert, BizTalk360 provides meaningful context about the issue, helping recipients understand what happened and respond faster without having to start the investigation from scratch.

Learn More about Notification Channels

Analytics That Tell the Story Behind the Data

Day-to-day operations become far more manageable when teams can identify patterns instead of only reacting to isolated incidents.

BizTalk360’s Analytics section provides a historical view of environment performance, helping teams understand trends over time rather than focusing only on immediate issues. Customizable dashboards allow organizations to track the metrics that matter most to them, while shared dashboards ensure teams are aligned with the same operational insights.

Scheduled reports also make it easy for managers and stakeholders to stay informed through regular summaries, without needing to log into the platform themselves.

This shifts the conversation from simply asking “What is broken right now?” to understanding “How has the environment been performing over time?” — a far more proactive and informed way to manage operations.

Learn More about Analytics Dashboard

Understanding Performance Without Being a BizTalk Expert

Throttling is one of those issues that often goes unnoticed until business processes start getting delayed. When BizTalk comes under stress, it slows down message processing, but identifying the exact cause traditionally requires deep technical expertise and manual analysis of performance counters and logs.

BizTalk360’s Throttling Analyser simplifies this completely. It presents throttling data in a clear, visual way, helping teams quickly understand when the system is under pressure, what is causing it, and how long it has been happening.

This allows operations teams to detect performance issues early, escalate them with proper context, and respond proactively instead of reacting after failures occur.

Learn More about Throttling Analyser

Self-Service Help Through the Knowledge Base

In many BizTalk environments, the same issues keep repeating, but teams still spend time searching through emails, documents, or waiting for developer support to find the resolution.

BizTalk360 addresses this with its integrated Knowledge Base feature. Teams can create articles and directly map them to specific error codes, event IDs, exception messages, service instances, or throttling conditions. When the issue occurs again, BizTalk360 automatically displays the relevant Knowledge Base article alongside the error, helping users quickly understand the cause and resolution without additional investigation.

Because the guidance is available directly within the monitoring experience, support teams can resolve issues faster, reduce dependency on developers, and build a more efficient operational process over time.

Explore the BizTalk360 Knowledge Base

Speaking the Language of the Business

Perhaps the most underrated advantage is how BizTalk360 brings visibility closer to the people who need it.

Technical logs and message IDs don’t mean much to someone in operations or finance. They care about outcomes. Did the order go through? Was the invoice processed? Is the partner integration working?

BizTalk360 makes it possible to track at a level that aligns with business context, so non-technical stakeholders can get the answers they need without having to go through IT every single time.

A Shift That Impacts the Entire Organization

When non-technical teams can handle day-to-day operations confidently, the impact goes beyond convenience. Support teams become more efficient. Developers stop getting pulled into routine issues. Resolution times improve. And the relationship between business and IT becomes a lot smoother.

What was once a tightly controlled, technically heavy environment starts to feel more accessible and responsive to everyone involved.

Final Thoughts

BizTalk Server remains a powerful integration platform but managing it does not have to be complex. BizTalk360 takes a more practical approach by simplifying operational tasks, improving visibility, and helping non-technical teams manage environments without constant dependence on deep BizTalk expertise.

It is not just about making BizTalk easier to manage. It is about making it easier for people to work with.

To know more about the BizTalk360 features, try out the free trial or book a demo.

The post How BizTalk360 Helps Non-Technical Teams Confidently Manage BizTalk Operations appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

Transform Monitoring Alerts into Actionable Jira Tickets with BizTalk360

Nekalya Kundan — Sat, 30 May 2026 10:28:52 +0000

In modern enterprise environments, proactive monitoring is essential to ensure system reliability and minimize downtime. BizTalk360 provides comprehensive monitoring capabilities with intelligent alerting that helps teams quickly identify and respond to critical issues.

By integrating BizTalk360 with Jira, monitoring alerts can automatically be converted into trackable Jira tickets. This enables centralized incident management, improves accountability, reduces manual effort, and enhances collaboration between operations and support teams.

Use case

In BizTalk environments, SQL Servers are essential because BizTalk Server databases handle message processing, tracking, configurations, and operational data. Any issue with the SQL Server can directly impact BizTalk performance and message flow. With BizTalk360, administrators can continuously monitor the health, availability, and performance of SQL Servers from a centralized monitoring platform.

For example, if the SQL Server hosting the BizTalk databases becomes unavailable or experiences high CPU or memory usage, BizTalk360 immediately detects the issue and triggers an alert. Through the Jira notification channel, the alert is automatically converted into a Jira ticket with the violation details. This enables support teams to quickly assign ownership, track the incident, and resolve it faster. Reducing downtime and improves operational efficiency.

JIRA integration in BizTalk360

The JIRA notification channel in BizTalk360 enables teams to link monitoring alerts to Jira, a widely used platform for tracking and managing issues. This integration helps teams organize incidents, assign ownership, set priorities, and monitor progress in a centralized, structured way.

With this capability, BizTalk360 automatically converts alerts into tickets whenever a threshold is violated or an issue is detected. Instead of relying on traditional methods like email, notifications are sent via REST APIs, ensuring that every incident is captured as an actionable task. This approach ensures that critical problems are not only notified but also effectively tracked and resolved on time.

Configuring Authentication types in JIRA

To start using the JIRA notification channel, configure the JIRA channel in BizTalk360 and associate it with an alarm. Whenever a monitoring violation occurs, a corresponding ticket is automatically created in Jira with relevant details.

API Token Authentication

An API Token is a simple and commonly used method for authentication. It is easy to configure and can be set quickly without complex permissions configurations.

After generating the token, users need to select API Token as the authentication type in BizTalk360. Then, enter the Jira Base URL, provide the generated Jira API Token, and specify the Atlassian account email address to complete the configuration.

OAuth Authentication

OAuth provides a more secure and controlled way of authentication. Ideal for enterprise environments that require higher security and strict access control. More secure and scalable, as credentials are not directly exposed.

For OAuth 2.0 authentication, select OAuth 2.0 as the Authentication Type and provide the Jira Base URL, Callback URL, Client ID, and Client Secret obtained from the Atlassian developer console. Once the required details are entered, click Authorize to authenticate the Jira account and then save the configuration successfully.

Mapping JIRA Notification Channel to Alarm in BizTalk360

Once authentication is configured in the JIRA channel, the next step is to map the JIRA notification channel to an alarm in BizTalk360. This configuration ensures that whenever a monitoring rule violation occurs, BizTalk360 automatically creates a Jira ticket for the issue.

To send alerts to Jira, a few important properties need to be configured in the Alarm settings. These properties help define how the alert will appear in Jira and ensure that the ticket is assigned and categorized correctly for faster issue resolution.

Title and Preview – Used to configure the Jira ticket title by adding dynamic tags such as Alarm Name, Environment Name, Alert Type, and Overall Status. The Title Preview section shows how the final alert title will appear in Jira after the configured tags are applied.
Project Name – Specifies the Jira project where the alert ticket should be created. This ensures alerts are routed to the correct support or operations team.
Work Type – Determines the type of Jira issue to be created, such as Bug, Task, Incident, or Story, based on the organization’s workflow.
Assign To – Allows the alert ticket to be automatically assigned to a specific user or team member responsible for handling the issue.
Priority – Sets the severity level of the alert, such as High, Medium, or Low, helping teams prioritize critical issues effectively.
Labels – Add keywords to the Jira ticket for easier filtering, tracking, and categorization of alerts across projects.

By configuring these properties in the Alarm section, BizTalk360 can automatically generate well-structured Jira tickets whenever an issue is detected to improve visibility and collaboration. Whenever a monitored artifact, such as a SQL Server, application, or queue, violates a configured rule, an alarm is triggered, and BizTalk360 automatically creates a Jira ticket for the issue.

Conclusion

The JIRA notification channel in BizTalk360 bridges the gap between alerting and incident management by converting monitoring alerts into actionable tickets in Jira. This ensures that critical issues are not only detected promptly but also consistently tracked, assigned and resolved on time.

This integration helps organizations move towards a more proactive and structured approach to operations, improving both system reliability and team productivity.

To know more about the BizTalk360 features, try out the free trial or book a demo.

The post Transform Monitoring Alerts into Actionable Jira Tickets with BizTalk360 appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

What’s New in BizTalk360 v11.8

Saranya — Sun, 10 May 2026 09:12:54 +0000

Mission critical integration environments demand’s continuous monitoring, faster issue resolution, and simplified operational management. With BizTalk360, we continue to enhance the platform with smarter automation, improved visibility, and stronger integrations, helping teams manage their BizTalk environments more efficiently and proactively.

Highlights from BizTalk360 v11.8

64-bit Support for BizTalk360 Services – Monitoring and Analytics services now run as 64-bit processes ,enabling improved scalability, better performance, and enhanced memory utilization for handling large-scale monitoring and analytics operations.

JIRA Notification Channel – Automatically create JIRA tickets when the monitoring detects violations. JIRA supports OAuth and API Token authentication for faster and secured incident tracking.

Azure Service Bus Automated Tasks – Schedule enable or disable actions for Service Bus queues and topics to automate message flow management during deployments and maintenance window.

File Monitoring Bulk Configuration – Define Folder, FTP, and SFTP monitoring configurations in a single place and reuse them across multiple locations for faster and consistent setup.

Enhanced Reporting Experience – Generate and share the ESB and Administration dashboards reports to the Administrators/Business users.

Acknowledge BizTalk360 Logs – “Acknowledge” the known issues in BizTalk360 Logs which helps to improve Advisor Score and focus only on active and relevant operational problems.

Let’s look at what’s new in BizTalk360 v11.8.

New Features

JIRA Notification Channel

Managing the incidents becomes much easier with the new JIRA Notification Channel.

BizTalk360 can now automatically create JIRA ticket whenever an alarm violation occurs. The integration supports secure authentication methods including OAuth and API Token, enabling seamless integration with existing support and DevOps workflows.

In many organizations, support teams manually create tickets after receiving alert notifications. This process can delay response time and increase the risk of missed incidents.

With JIRA integration:

Alarm violations are automatically converted into actionable tickets.
Teams can immediately begin troubleshooting.

Example Scenario

If a BizTalk Receive Location disabled unexpectedly or a Service Instance gets suspended, BizTalk360 detects the violation and instantly creates a JIRA ticket with the relevant details allowing teams to take immediate action.

Azure Service Bus Automated Tasks

BizTalk360 now supports Azure Service Bus Queues and Topics operations through the Automated Tasks, enabling users to manage queue and topic states through scheduled execution.

Users can automate actions such as:

Active
Disable

During deployments or maintenance windows, organizations often need to temporarily stop message inflow to avoid processing interruptions.

Using automated tasks, BizTalk360 disables selected Service Bus queues before deployment and enables them again after completion, ensuring controlled message flow and smoother operations.

With automated tasks schedule:

Queues/Topics can be disabled before deployment
Automatically re-enabled after maintenance
Automatically re-enabled after maintenance

User will also get notified about the action taken to the configured email.

Monitoring Enhancements

File Monitoring Bulk Configuration

Configuring monitoring settings individually for hundreds of Folder, FTP, or SFTP locations can be repetitive and time-consuming.

Organizations with large integration landscapes often maintain consistent monitoring policies across environments. Repeating the same configuration for every endpoint increases operational overhead.

Now user can specify the File/FTP/SFTP configuration such as Authentication, Firewall configuration, Security details once and that can be reused for monitoring all the file locations.

User can also specify the centralised monitoring rule say, if all FTP locations are expected to receive at least one file every hour, teams can configure the rule once and reuse it across all locations instead of configuring each individually.

With Default Monitoring Configuration, users can now:

Define monitoring rules once
Reuse them across multiple locations
Apply monitoring configurations in bulk

SHA-2 Authentication Support for SFTP

BizTalk360 now supports SHA-2–based authentication for nSoftware SFTP monitoring. Which supports enhanced security and compatibility with modern encryption standards.

Monitor Time

To provide better operational insights, BizTalk360 now includes:

Violation Time in Errors & Warnings notifications
Last Monitored Time visibility in dashboards and monitoring sections

These enhancements help teams to identify when an issue occurred and Verify whether monitoring is running correctly.

Direct Navigation from Monitoring to Administration

Users can now directly navigate from the Monitoring section to the corresponding artifacts in the Administration section for quicker action on artifacts and reduce the operational delay.

Enhanced Reporting Experience

Reporting has been significantly improved in v11.8.

1)Users can now include both ESB and Administration dashboards in scheduled reports and receive them automatically via email.

Operations and support teams often require regular visibility into:

ESB exception activities
Failed itineraries and processing trends
Environment health and administrative status

Instead of manually logging into BizTalk360 to review dashboards, teams can now schedule reports and receive the required insights directly in their inbox.

2)Improved report generation using the new Playwright-based rendering engine.

The previously used “SelectPDF” rendering engine has been deprecated. We strongly recommend upgrading BizTalk360 to the latest version v11.8 to continue generating reports without issues.

64-bit Support for BizTalk360 Services

The BizTalk360 Monitoring and Analytics services now run as 64-bit processes. This enhancement allows BizTalk360 to handle larger workloads more efficiently in enterprise environments.

Acknowledge BizTalk360 Logs

Enterprise environments often contain recurring warnings or known operational events that do not require action.

Say, non-critical warning generated during scheduled maintenance no longer needs to repeatedly impact the environment health score.

With the new Acknowledge Logs capability ,known issues can be acknowledged and suppressed for defined duration. These acknowledged logs are excluded from Advisor Score calculations and Health status reflect only active and relevant issues.

Conclusion

Whether you are managing complex hybrid integrations or large-scale BizTalk environments, v11.8 helps your teams operate more efficiently and proactively.

Upgrade to BizTalk360 v11.8 today and experience smarter monitoring, seamless integrations, and greater operational control. BizTalk360 v11.8 Release Notes – https://docs.biztalk360.com/docs/v118

The post What’s New in BizTalk360 v11.8 appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.

Enhanced Service Instance Monitoring with Intelligent Automation!

Senthil Kumar — Tue, 17 Mar 2026 08:41:44 +0000

Key Takeaways:

The Challenge: BizTalk Service Instance Failures Disrupt Critical Business Transactions
Enhanced Capabilities Service Instance Monitoring
Simplified Automation with Automated Tasks
Operational Benefits: Smarter Monitoring. Greater Control. Confident Operations

BizTalk360 is one stop tool to manage your BizTalk environments with powerful Monitoring, Administrative capabilities.

Let us see how BizTalk360 effectively manage the Services Instances.

The Challenge: BizTalk Service Instance Failures Disrupt Critical Business Transactions

In BizTalk environments, failed or suspended service instances can silently interrupt critical business transactions. Relying solely on reactive monitoring often means teams discover issues only after business impact has already occurred.

In a typical Microsoft BizTalk Server environment, service instances represent the live execution of your integrations like order processing, invoice submissions, EDI exchanges, API orchestration, and internal system synchronization. When these service instances fail or become suspended, the impact goes far beyond the middleware layer.

A suspended orchestration might mean:

Orders are not reaching the ERP system
EDI messages are not delivered to trading partners
Invoices are stuck before billing
Business acknowledgments are never sent

The real challenge is that many of these failures occur without immediate visibility.

Many teams still rely heavily on reactive monitoring manually checking the Admin Console, responding to user complaints, or waiting for downstream systems to report missing data. By the time issue is detected, the damage is already done:

Escalations from business users
Revenue delays
Compliance risks

Service instances can fail for many reasons including,

Mapping or transformation errors
Schema validation issues
Connectivity failures to SQL, FTP, SFTP, or APIs
Throttling conditions
Resource constraints (CPU, memory, disk)

Without proactive monitoring and automated handling, suspended instances accumulate rapidly in the Message Box database. Performance degrades. Troubleshooting becomes harder because engineers must sift through historical noise to find the real issue.

In high-volume environments, even a short monitoring gap can translate into hundreds or thousands of unprocessed transactions.

Modern BizTalk operations require:

Real-time visibility into running and suspended instances
Intelligent filtering and categorization
Automated remediation where possible
Alerting that prioritizes business impact, not just technical failure

How BizTalk360 effectively manage suspended service instances

Let us see how BizTalk360 Service Instances monitoring and automated tasks proactively act to avoid the transactions failures.

When it comes to managing your BizTalk environment, BizTalk360 offers a comprehensive set of capabilities designed to keep business transactions running smoothly.

With powerful Service Instance management, including bulk operations and archive options, teams can quickly resolve and maintain large volumes of transactions. Threshold and Data Monitoring enable proactive oversight, while Automated Tasks and Automated Actions help address potential issues before they impact operations. On top of that, built-in Analytics metrics provide clear visibility into performance trends and recurring challenges, empowering teams to make informed decisions and continuously optimize their environment.

Data Monitoring Automated Actions

When an incorrect schema is deployed, one that doesn’t align with the transform schema configured in the Send Pipeline. This situation can immediately disrupt message processing and push transactions into a suspended state.

With BizTalk360 Data Monitoring, you can proactively track such failures and configure automated actions on suspended service instances. Instead of relying on manual intervention, the system can automatically resume valid instances once the schema issue is corrected reducing downtime, preventing transaction backlogs, and keeping business operations moving without disruption.

This feature is widely used by many customers over a decade in-order to take control of business transactions without degrading the performance.

Enhanced Capabilities in Service Instance Monitoring

In earlier versions, Service Instance monitoring was limited to detecting issues based solely on instance status. In the latest version, monitoring has been enhanced with metric-based threshold rules and advanced filtering capabilities, enabling more precise detection and refined monitoring results.

Threshold rules monitoring
Configure thresholds to detect abnormal service instance volumes before they escalate into failures. Gain granular visibility to take timely and appropriate actions, such as resuming, suspending, or terminating affected instances.
With the multiple filter search options, instances monitoring can cover the multiple failure scenarios in a single threshold rule configuration. It helps the operation teams to validate the business transaction from the single view.
Improved filters with the multiple values and flexible operators
In the service instance queries, multiple filter values selection for the parameters like Service Name, Application, Error Description are being in-corporate. This implementation provides the flexible control over the service instances with granular and targeted instances.

Simplified Automation with Automated Tasks

Monitoring the service instances is no longer just about visibility, it’s about decisive action.

With enhanced Service Instance Monitoring, automated tasks can now trigger corrective measures the moment predefined conditions are met. Instead of waiting for manual intervention, the system can automatically:

Start or stop artifacts
Restart NT Services
Restart Host Instances
Execute predefined PowerShell scripts

By combining automated actions with configured threshold rules, you can proactively respond to abnormal conditions before they escalate into business disruptions.

For example, when files are not being processed at a receive location, it often signals that the associated Host Instances are in a throttled state. Instead of waiting for manual intervention, automated tasks can immediately trigger corrective measures such as restarting the impacted Host Instances. This will help in restoring the normal processing and minimizing downtime.

This approach shifts operations from reactive firefighting to controlled, intelligent remediation ensuring business continuity without constant manual monitoring.

Service instances often face other real-world scenarios such as suspended messages, failed orchestrations, or unusually long processing times. Left unchecked, these can disrupt critical business transactions and escalate quickly.

The result of proactive monitoring and automation?

Faster resolution. Reduced operational overhead. Greater confidence in business continuity.

Automation isn’t just about convenience, it’s about ensuring your integration platform stays resilient, responsive, and business-ready always.

Operational Benefits: Proactive Monitoring, Stronger Control, Audit-Ready Security

The modern integration environments demand more than basic health checks. They require intelligent monitoring that not only detects issues but actively helps to prevent business disruption.

Smarter Monitoring

Instead of relying solely on service instance status, monitoring now incorporates threshold-based detection and refined filtering. This enables you to identify abnormal service instance volumes, recurring failures, or performance bottlenecks before they escalate. It’s about spotting patterns early avoid the business disruption.

Smarter Monitoring

Greater Control

With enhanced filtering capabilities and automated corrective actions, teams gain precise control over service instances. Whether it’s restarting host instances, stopping artifacts, or executing predefined scripts, actions can be triggered automatically when thresholds are breached. You define the rules. The system executes them consistently.

Confident Operations

Reduced manual intervention leads to fewer firefighting scenarios. Automated responses shorten resolution time and minimize business disruption. Teams can focus on optimization and innovation rather than repetitive operational tasks.

Security & Auditing

BizTalk360 enforces role-based access through user access policies, ensuring operational users can view and manage only the service instances relevant to them. It maintains a detailed audit trail of all service instance operations, tracks corrective actions taken during monitoring, and captures activities performed through the BizTalk Admin Console. This provides complete operational transparency, accountability, and governance across the environment.

Conclusion

The outcome is clear: improved stability, better visibility, and a monitoring strategy that actively supports business continuity not just reports on failures after they occur.

The post Enhanced Service Instance Monitoring with Intelligent Automation! appeared first on BizTalk Server Monitoring & Management Solution | BizTalk360.