Why did we build Receive Locations, Send Ports and Orchestrations Monitoring for BizTalk?

Why did we build Receive Locations, Send Ports and Orchestrations Monitoring for BizTalk?

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360“.

BizTalk Server Receive Locations, Send Ports and Orchestrations Monitoring

Why do we need this feature?

Microsoft BizTalk Server is a powerful middleware product which allows integrating all kind of information systems, independent of whether these systems are on-premise or in the cloud. BizTalk Server uses Receive and Send ports to communicate with a broad set of on-premise/cloud systems, both on the technology level (FILE, FTP, POP3, SMTP, etc.) as on the business level (ERP, CRM, etc.).

Besides just receiving and transmitting messages, BizTalk solutions might also contain Orchestrations, which can process all kind of business logic,  for example, Order processing, Credit card validation, Claims processing etc.

As BizTalk Server is very scalable, a BizTalk environment can contain many deployments for all kind of different integrations. All together a BizTalk environment may contain hundreds of ports and orchestrations. The well-being of these artifacts is of vital importance to have the integrations working properly. When not running properly, these interruptions may cause serious damage to the business processes they support.

What are the current challenges?

To be well aware of the state of the BizTalk artifacts, the BizTalk administrator needs to consult the BizTalk Administration console multiple times per day. However, there are few challenges when depending on the BizTalk Administration console for checking the state of these artifacts.

Access to the Administration console – Often, the BizTalk Administration console is only installed on the BizTalk servers. Besides that there is the risk of unintended damaging the BizTalk server while accessing the server, you need to be authorized to access the servers. Not to be forgotten, is the fact that it constantly takes time to setup Remote Desktop connections to access the BizTalk server and the Administration console. Time which can easily be used for something more tangible.

Not suited for less experienced administrators – The Administration console is such a powerful tool, which is great when you are an experienced BizTalk Administrator. However, in the hands of less experienced administrators, unintentionally a lot of damage can be done. Think of for example stopping ports or terminating processes!

Not an efficient way of monitoring – Checking the state of the ports and orchestrations manually, multiple times per day, is just not efficient. It can easily be forgotten in the rush of the day, thereby putting the wellbeing of your integrations at stake.

Too many artifacts to monitor efficiently – BizTalk environments can contain hundreds of ports and orchestrations. In most scenarios, the artifacts should be in the Enabled/Started state. But there can be several reasons why certain artifacts are not in the expected state. Just to mention a few:

  • After the deployment of an update of a BizTalk application the artifacts are in a wrong state
  • Due to a temporary maintenance window, some of the artifacts need not be in the Enabled/Started state, to prevent suspended instances
  • Artifacts might be Disabled as a result of a temporary outage
  • Certain artifacts need only be Enabled/Started as a fall back scenario

By the given examples, it must be clear, that it can be very challenging to constantly be aware of the desired state of all the artifacts. This makes it hard to manually monitor the state of the artifacts in an efficient way.

Instead of having to monitor BizTalk manually, it is much more efficient to have automated, state-bound, artifact monitoring. Automated BizTalk monitoring will prevent you of constantly having to check for the state manually, enabling you to spend your time on more important activities. In the next section, we’ll show which features BizTalk360 has, to allow you to automatically monitor your BizTalk artifacts.

How BizTalk360 solves this problem?

To give you that comforting feeling that you are in control over the state of your ports and orchestrations, BizTalk360 provides multiple features.

Threshold Monitoring – While using the concept of Threshold Monitoring, BizTalk360 allows you to setup state-bound monitoring. This means that you can easily setup monitoring to have the product check for the Expected state of your ports and orchestrations.

In above screenshot, you can see how some Send Ports are being monitored against their Expected State. Once, the Current State deviates from the Expected State, a threshold violation has occurred and BizTalk360 will notify you of that fact.

Positive and Negative monitoring – In most scenarios, the Expected State of your Ports and Orchestrations will be Enabled/Started; which is called Positive Monitoring. However, there might be valid reasons that certain ports/orchestrations need NOT be Enabled/Started. Setting up that kind of monitoring is called Negative Monitoring. BizTalk360 allows to setup for both Positive and negative Monitoring.

Receiving Notifications via multiple channels – Once a threshold violation has occurred, by default, you will receive notifications by email. Moving forward, BizTalk360 also allows you to receive notifications via multiple other channels.

We are constantly considering new ways to send notifications, but currently, the following Notification Channels are provided out-of-the-box: Email, SMS, Event Log, Slack, Microsoft Teams, ServiceNow, HP Operations Manager, Webhook. In addition, you can build your own custom notification channel like writing to a database, calling an internal system etc.

Auto Correct – BizTalk360 not just monitors your artifacts, it can also try to bring the artifacts back to their Expected state, once there is a mismatch between the Current State and the Expected State. Think of for example that FTP Receive Location which goes down at night or during the weekend.

The Auto-Correct feature works for the following artifacts:

  • Receive Locations
  • Orchestrations
  • Send Ports
  • BizTalk Host Instances
  • Windows NT Services
  • SQL Server Agent Jobs
  • Azure Logic Apps

There is an extensive article on BizTalk360 Auto correct, which also explains in which kind of scenarios this feature comes at hand. You can that article here:

Monitoring Dashboard – Although receiving notifications of any mismatches between the Current State and the Expected State is very handy, it will equally be handy to have a large screen, at for example the Support Desk, which simply shows the current health of your artifacts. For this, we bring the Monitoring Dashboard, which does exactly that.

As you can see from below screenshot, it brings you a nice Expandable/Collapsible and filterable treeview, with automatic refresh, thereby constantly showing the current state of the artifacts.

Health Check Reports – Last but not least, are the Health Check Reports you can receive at your convenient timing. These reports function as your daily health check, providing you with an overview of the state of all the artifacts from your alarm. Very handy to receive for example at the beginning of your working day!

Conclusion

In this article, we have seen why being aware of the state of your ports and orchestrations is important. We have also seen why manually monitoring that state is very inefficient and sometimes very complex. As a company which knows these challenges from our own experiences, we have brought multiple features which will help the BizTalk administrator being in control, without having to manually check the state.

Get started with a Free Trial today!

Download and try BizTalk360 on your own environments free for 30 days. The installation will not take more than 5-10 minutes.

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.

Why did we build FTP/SFTP Monitoring for BizTalk Server?

Why did we build FTP/SFTP Monitoring for BizTalk Server?

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”.

BizTalk Server FTPS-FTP-SFTP Monitoring

Why do we need this feature?

In the day to day activities of a BizTalk administrator, you might come across integrations where FTP sites are used for receiving and transmitting messages. FTP sites are often used for cross-platform integrations. For example, when you have an SAP system on Unix that has to be integrated, via BizTalk Server, with other systems, you might use FTP for receiving and transmitting of messages.

SFTP & FTPS are just the secured version of FTP with advanced transport encryption mechanisms, so your end-to-end data transmission is secure and safe.

To keep the business process going, it can be of vital importance that the FTP/SFTP sites are online and the messages are being picked up. So, when a BizTalk administrator needs to be constantly aware whether the FTP/SFTP sites are online and working properly, the administrator needs to monitor the sites and the activities which take place on these sites.

What are the current challenges?

BizTalk Server offers no monitoring capabilities, not for Receive Locations / Send Ports and also not for endpoints like FTP, SFTP and FTPS sites. So, using just the out-of-the-box features of BizTalk Server, a BizTalk administrator will have to manually check whether the FTP sites are online and whether all (appropriate) files are being picked up for further processing.

Manual monitoring

This kind of manual monitoring can be quite cumbersome and time-consuming. The administrator will probably use multiple pieces of software to be able to perform these tasks. Think of for example the BizTalk Administration console to check whether the Receive Locations/Send Ports are up and some FTP client to check whether files are being picked up.
It is obvious that this is not a very efficient scenario, which could easily be automated by setting up monitoring.

Maintaining scripts for monitoring FTP sites

To reduce their workload, we experience that BizTalk administrators are creating their own scripts to monitor FTP sites and all kind of other resources. Although this kind of scripts certainly can be of help, we still think this does not fully solve the problem.

For example, often these kinds of scripts need maintenance when FTP sites need to be added, changed or deleted from monitoring. This kind of tasks can be easily forgotten.

Also from a knowledge transfer perspective, it’s easy to forget to update new colleagues about the existence of this kind of scripts, as they will probably be installed on some (monitoring) server.

Another challenge with solving this kind of problems with scripts is that not each administrator is capable to write this kind of scripts, which makes knowledge transfer even harder.

To keep the overview, we think that it is easier to use software, like BizTalk360, to have everything in one easily accessible place, with good visibility of all the features/capabilities, fine-grained security/auditing and without the need to maintain custom scripts etc..

How BizTalk360 solves this problem?

With BizTalk360, we make monitoring of FTP/SFTP/FTPS sites a lot easier. For a very long time, the product offers monitoring of Receive Locations and Send Ports, but for some time now, BizTalk360 also offers to monitor of the physical FTP/SFTP/FTPS endpoints.

We wanted to make setting up this kind of endpoint monitoring as seamless as possible and therefore we simply show all the ports in the current BizTalk group which make use of the FTP/SFTP/FTPS adapter.

In BizTalk360, you can find FTP monitoring under Monitoring => Manage Mapping => File Locations (File, FTP, SFTP).

Next, you can set up monitoring rules based on File Count and Directory Size and have BizTalk360 send Warning or Error notifications through the notification channels which are configured on the associated alarm.

A fully monitored FTP endpoint might look like shown below.

Of course, besides the greater-than-or-equals operator, also other common operators are available.

Conclusion

As a final point, we see from time to time that administration teams maintain a administrators handbook, which contains all the tasks a (BizTalk) administrator should take care of. We think that by using software like BizTalk360, we can reduce the number of pages in such handbooks, as the kind of scripts we mentioned no more have to be described in that kind of books.

This description could be replaced by, for example, a general guideline on how FTP sites should become monitored and the monitoring rules with BizTalk360.

As a result, we hope to make the work of BizTalk administrators a bit easier so the team can focus on the more exciting parts of the job of BizTalk administrators, instead of constantly having to update their handbooks.

So, we think that we make the day to day life of a BizTalk administrator, who needs to monitor the well-being of FTP sites, a little bit easier by bringing this feature.

If you want to read more on FTP/SFTP monitoring in much more detail, you can check the following article:

FTP, FTPS, SFTP Location monitoring

BizTalk360 also offers an advanced monitoring capability called “Data Monitoring” which allows monitoring the traffic/volume of messages going through the ports for a given period, ex: expected 50 PO orders from our partner via FTP/SFTP. Please check out this article. Introducing BizTalk Server Data Monitoring in BizTalk360

Get started with a Free Trial today!

Download and try BizTalk360 on your own environments free for 30 days. Installation will not take more than 5-10 minutes.

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.

Why did we expose all of our BizTalk Operations and Management REST API’s?

Why did we expose all of our BizTalk Operations and Management REST API’s?

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

Why do we need this feature?

On a daily base, our customers use BizTalk360 for a lot of their activities related to BizTalk operations and monitoring. However, in a number of scenarios, BizTalk administrators are faced with activities which need to be automated, for example: during the deployment of BizTalk Applications. It is easy to forget some tasks and doing them manually can be error-prone. So, it may be better to address such challenges in an automated way.

Here are some example automation scenarios in that can happen in your BizTalk Server environment

BizTalk Server Operations

  • You might want to automatically stop certain Ports over the weekend, because of regular or temporary maintenance of internal or external systems
  • External systems, like portals, might need BizTalk data/metrics on a regular basis, like information around EDI transactions, BizTalk usage or BizTalk performance metrics
  • You want particular users to have easy access to download links for the messages of suspended instances, without having to give them access to BizTalk Server and/or BizTalk360
  • You may want to Deploy/Publish a Business Rule Policy at a particular moment (additional discounts for the holiday season or laws to which should be complied as of a particular moment)

BizTalk Applications Maintenance and Deployment

  • Before or after deployment of BizTalk Applications, you may want to automatically stop and start Host Instances
  • After a deployment, you may want to set certain ports/orchestrations to a particular state
  • You want to bring BizTalk down at a given date and time, due to system maintenance

Identity and Access Management

  • Your organisation uses tooling for Identity and Access Management and you want to automatically create User Access Policies for accessing BizTalk360 and BizTalk
  • For auditing purposes, you need to provide user lists and profiles and audit information on a regular bases

Because of the nature of this kind of scenarios, the administrators would need programmatically access to BizTalk server and rely on command files or PowerShell scripts to be able to fulfil the requirements.

What are the current options and challenges?

BizTalk Server comes with different tooling for programmatic access to BizTalk Server. This tooling is described below.

WMI and ExplorerOM

Let’s briefly discuss the purpose of both WMI and ExplorerOM:

  • WMI (Windows Management Instrumentation) – an infrastructure, which comes with Windows, and which allows you to automate administrative tasks on (remote) computers. BizTalk Server comes with its own WMI management pack to do preliminary management activities like starting/stopping host instances, restarting ports etc.
  • ExplorerOM – a DLL used to perform all kind of BizTalk Application related tasks like exploring the schemas, maps, orchestrations, operating on them like starting/stopping etc.

BizTalk PowerShell Provider

There is also a community initiative to provide a BizTalk PowerShell provider so you can execute some of the management tasks using PowerShell (since PS has become the core of any automated administrative tasks). However, the project is not actively maintained anymore and it’s not advisable to rely on this for any critical usage.

BizTalk Server 2016 Feature Packs

Starting with BizTalk Server 2016, Microsoft started to release Feature Packs. With the first Feature Pack (BizTalk Server 2016 Feature Pack 1). a unified API became available for BizTalk Server 2016 (not for earlier versions).

This Management API enables you to perform some of the scenarios which we mentioned in the first paragraph but still lacks API’s to do extensive automation. For example, stop and start host instances.

So, although BizTalk Server comes with multiple capabilities for programmatic access to BizTalk Server, writing and testing all kind of scripts is time-consuming and not all scenarios can be covered.
Even when these custom scripts seem to work nicely, non-functional requirements, like security, auditing and logging, are not taken into account in these kinds of scripts. This would leave you in the dark when something unexpected happens. Definitely, not a scenario where you want to be.

How BizTalk360 solves this problem?

BizTalk360 consists of multiple components, a responsive user interface, few backend services and a rich API service layer.

The API service layer consists of over 400 REST API operations. The user interface of BizTalk360 uses these extremely rich API’s to perform all the tasks to manage the BizTalk environment.

A couple of years ago, we thought, exposing our API’s will hugely help BizTalk Server Administrators to automate most of their routine activities we mentioned in the beginning.  Hence we documented all the BizTalk360 API’s (which are of course the management and monitoring API’s for your BizTalk Environment) using swagger and live test within the BizTalk360 application.

The API currently contains 14 services with more than 400 API operations, covering a breath of management activities you can do on your BizTalk Environment. To give you a better understanding of the capabilities, these services are:

  • ActivityMonitoringService – BAM related services
  • BizTalkQueryService – Execute all kind of MessageBox and Tracking oriented queries
  • AlertService – All kind of Monitoring related API’s
  • BizTalkGroupService – BizTalk Platform oriented API’s
  • SchedulerService – Data Monitoring Scheduler related API’s
  • ESBManagementService – Exception Management related API’s
  • AdvancedEventViewerService  – API’s to query the Eventlog entries which are collected by the Advanced Event Viewer feature
  • BizTalkApplicationService – Search for and action on BizTalk Application artifacts
  • AdminService – Get and maintain all kind of settings within BizTalk360
  • EDIManagementService – Get/Set EDI configuration and get EDI statistics
  • EnvironmentMgmtService – API’s mainly for Knowledge Base and Dashboard management
  • RulesEngineService – API’s for maintenance of Business Rules
  • AnalyticsDataService – Analytics, Message Patterns and Throttling related API’s
  • AzureService – Get/Operate on Logic Apps and get Integration Account artifacts

With the API you cannot just retrieve information from BizTalk via GET operations, but you can also action on BizTalk Server, BizTalk360 and even certain Azure services via POST operations.

Each API can be tried from the API documentation, which comes with a Swagger definition file, by using the Try it out! feature. This helps you testing with the required parameters. All you need to do is to choose the needed API, provide the needed parameters for the API, click the Try it out! button and view the results.

Let’s have a look at few examples of how you could make use of the API.

  • Stop and start Host instances before and after deployment of BizTalk applications
  • Disable/Enable Receive Locations and/or Stop/Start Orchestrations/Send Ports
  • Get a list of currently deployed BizTalk Applications for Support purposes
  • Get Event Log data of all the BizTalk servers in one go
  • Get Throttling data from the BizTalk Hosts
  • Get all kind of Performance metrics of your BizTalk system
  • Test, Deploy, Undeploy and Publish Business Rules
  • Disable/Enable BizTalk360 alarms during deployments
  • Show data in an Operations Dashboard widget, for example, the state of your SQL jobs
  • Automatically create BizTalk360 alarms during deployment of BizTalk applications

Conclusion

By using the BizTalk360 API and its documentation, the complexity from WMI and ExplorerOM is shielded from the user. Besides being able to act on BizTalk, the API also allows you to action on BizTalk360. You can even show the output of API calls in the Operations Dashboard!

Few examples of how the BizTalk360 API`s can be used in real-world scenarios: Automate Monitoring Alarm creation in BizTalk360

If you are using BTDF (BizTalk Deployment Framework) we have a wrapper console application called BT360Deploy that can be used to automate certain tasks like creating monitoring alerts during deployment. The project can be accessed here.

Get started with a Free Trial today

Why not give BizTalk360 a try. It takes about 10 minutes to install on your BizTalk environments and you can witness the benefits of auto-healing on your own BizTalk Environments. Get started with the free 30 days trial.

The post Why did we expose all of our BizTalk Operations and Management REST API’s? appeared first on BizTalk360.

Why did we build Auto Healing capability in BizTalk Server Monitoring?

Why did we build Auto Healing capability in BizTalk Server Monitoring?

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

BizTalk Host Instances and Ports auto healing

Why do we need this feature?

Imagine the following scenario. It’s Monday morning, you arrive at the office and you do some extra health checks on your environment, as planned maintenance has been done over the weekend, also involving the BizTalk servers. You notice that the Host Instances are not started! This occurred because, after a reboot of the BizTalk servers, the Host Instances and other vital services like the Enterprise Single Sign On service did not start. Because of this, ever since that reboot no processing has been done by BizTalk, which results in an enormous backlog of processing for an already busy Monday morning.

There is one more very common scenario. Let’s assume you are using an FTP/SFTP receive location polling files (Purchase Orders, Invoices etc) from a remote server. There are various reasons we might encounter the problem in this setup, example network connectivity, the remote server is down, someone changed the password etc.

In these instances, the BizTalk FTP/SFTP receive location will attempt to connect few times and finally quietly shut down (without notifying anyone). This is a major problem,  we need a solution where a system can notify the BizTalk Administrators and also try to recover the failure condition automatically.

Above scenario is just a couple of the example of possible outage conditions. Besides Host Ithe instances and other Windows NT services, not being in the expected state, think of Receive Locations being disabled because of network disruptions, Orchestrations being unenlisted, so no messages will be picked up by then or performance degradation because the wrong Windows NT services are being started (either manually or automatically).

All these kind of artifacts being in the wrong state, may lead to disruptions of your valuable business processes and put your business at stake.

What are the current challenges?

Off course you want to prevent your business processes from being disrupted by just a few Windows NT services, or other state-bound artifacts, being in the wrong state. Ideally, you want the expected state to be recovered as soon as the artifact hits the wrong state.

No auto-recovery support by BizTalk

Unfortunately, BizTalk Server itself provides no functionality to detect that artifacts are in the wrong state, let alone that these artifacts are brought back to the desired state. So what’s left is creating custom scripts to take care of that task. More on custom scripting, a little bit later in this article.

No auto-recovery support by SCOM

Your organization might already use SCOM for monitoring your server platform. Although SCOM has a so-called Management Pack for BizTalk server, it is quite challenging to setup  SCOM for proper BizTalk monitoring and operating.

Check out below whitepaper, to find out the differences between BizTalk360 and SCOM when it comes to maintaining your BizTalk environment.

Auto-recovery is one of the reasons why SCOM is not the best fit for maintaining your BizTalk environment as  SCOM offers very little support for auto-recovery of your BizTalk and other artifacts which are important for your integrations. SCOM provide event-handlers which can be used for executing custom scripts, you as an administrator, still have to create these scripts.

Custom scripting

So, whether you are using just BizTalk Server or use SCOM, in case you want to auto-recover your artifacts which are in the wrong state, you need to develop custom scripts to have something in place for auto-recovery of your state-bound artifacts. Developing such scripts can be time-consuming and often it is hard to properly maintain such scripts. Also, the visibility of such scripts is bad, as they are being run through Windows Scheduler, which is, in turn, another component you should be aware of, when you are considering the overall health of your BizTalk environment.

At BizTalk360, we have the philosophy that businesses should take care of their core businesses and not be developing scripts and tools to maintain their BizTalk environments. As we have many years of experience in the field of BizTalk Server and Microsoft integration, we understand the problems you might run into, as we have faced them ourselves as well.

The goal of BizTalk360 is to take away your challenges when it comes to operating and maintaining your BizTalk environment. Even though anything can be done using custom coding/scripts, that’s not the best use of your time + management overhead of maintaining that code base.

How BizTalk360 solves this problem?

For many releases now, BizTalk360 contains the Auto Healing feature for recovery of artifacts which have hit the wrong state. While in the beginning, mainly the BizTalk artifacts could be brought back to the expected state, the feature has evolved to support below artifacts:

  • Send Ports
  • Receive Location
  • Orchestrations
  • Host Instances
  • Windows NT Services
  • SQL Server Jobs
  • Azure Logic Apps

The Auto Healing can be configured as part of the monitoring settings for the above-mentioned artifacts. Below picture shows a Receive Location for which monitoring has been set up. The Expected state of this Receive Location is Disabled. Besides that, also Auto Healing has been set up.

Once set up, the BizTalk360 Monitoring service will evaluate whether the Receive Location is still in the expected state. In case the Receive Location hits a state which is not the expected state, the Monitoring service will try to bring the Receive Location back to the expected state. Depending on the configured value for the Max Retry setting, this will be tried at most 10 times. If the Receive Location still is not in the expected state, the artifact will move to the Critical state.

Note: To the Auto Healing, it makes no difference whether the expected state is Enabled or Disabled, or Unenlisted or Started. Depending on what you have configured for the Expected state, BizTalk360 will always try to bring the artifact to that Expected state.

Conclusion

In this article, we have seen how valuable it can be to have your artifacts being brought back to the expected state without manual intervention. Auto Healing is easy to setup with BizTalk360 as, instead of having to develop custom scripts, it is just a matter of configuring Auto Healing on the required artifacts. This increases ease of use and minimizes downtime.

Do you want to read more about Auto Healing? Here you have few articles on this topic:

Introducing Auto Healing for BizTalk Environment
Automating BizTalk Administration Tasks via BizTalk360 Auto-Healing

Get started with a Free Trial today!

Why not give BizTalk360 a try. It takes about 10 minutes to install on your BizTalk environments and you can witness the benefits of auto-healing on your own BizTalk Environments. Get started with the free 30 days trial.

The post Why did we build Auto Healing capability in BizTalk Server Monitoring? appeared first on BizTalk360.

Why did we build Azure API Apps Monitoring in BizTalk360?

Why did we build Azure API Apps Monitoring in BizTalk360?

Azure API Apps Monitoring BizTalk360

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

Why do we need this feature?

Azure API Apps is a modern way of building web services hosted in Microsoft Azure. Out of the box it provides capabilities such as security, load balancing, auto-scaling, and automated management. You can also take advantage of its DevOps capabilities such as continuous deployment from VSTS, GitHub, Docker Hub, and other sources, package management, staging environments, custom domain, and SSL certificates.

In the context of Azure Logic Apps connectors, Azure API Apps plays a vital role. Sometimes there may not be an out of the box connector to an external system and you may need to wrap a web service on top of that external system to create a custom Azure Logic Apps connector. This article explains how you can easily Create a custom connector for a web API.

The Azure API App can contain multiple endpoints to be able to perform multiple actions like creating an order or requesting the status of an order.

The Azure API Apps are powerful building blocks for your hybrid integration scenarios. As these API Apps can be of critical importance, you should be well aware of the status of these API Apps.

What are the current challenges?

We have already seen why Azure API Apps are important building blocks and can be of vital importance for your integration scenarios. So, whether you are consuming the external Azure API Apps from other parties or you are exposing your own API Apps, depending on the importance of the Azure API App, it is equally important to constantly be aware of the state of the Azure API Apps and their endpoints.

The main challenge at the moment is the management and monitoring of Azure API Apps in isolation via the Azure Portal. You’ll miss the end to end context of the importance of the API App in your integration scenario.

For example, you might have an order processing system that uses few BizTalk Receive Locations, Orchestrations, Send Ports and few Azure API Apps connected via BizTalk WCF-REST/HTTP adapters and are part of the same end-to-end solution. If the Azure API App is down or returning errors, then your end-to-end purchase order solution is broken. It’s important to monitor the API Apps and understand the end to end context.

We address this challenge in BizTalk360 by providing a unified platform to monitor and manage both BizTalk artifacts and some of the key Azure artifacts which are important from the integration point of view.

How BizTalk360 solves this problem?

Depending on whether you want to monitor your own Azure API Apps or the API Apps which are exposed by others, BizTalk360 offers multiple methods to setup monitoring. This is due to the fact that to be able to monitor whether API Apps are enabled, you need access to the Azure subscription which contains these API Apps. In case of API Apps which are exposed by others, you won’t have access to that Azure subscription, so you’ll only be able to monitor the HTTP Endpoints of the API Apps.

To monitor API Apps from within BizTalk360, the product offers the following features:

  • Azure API App of others – Web Endpoint monitoring
  • Your own Azure API Apps – Azure API App monitoring

Web Endpoint Monitoring

If you are simply consuming the Azure API Apps from external parties, then they are not any different from a standard REST/HTTP web services. In this case, the BizTalk360 web endpoints monitoring solution will be sufficient.  The features and capabilities of BizTalk360 Web Endpoint monitoring are described in the Why did we build Web Endpoints Monitoring in BizTalk360? article.

Azure API Apps Monitoring

If you are owning the Azure API Apps, then BizTalk360 provides a rich set of capabilities to monitor the Azure API Apps like auto-discovery of multiple endpoints and granular control on monitoring setup.

Monitoring API Apps from BizTalk360 consists of the following types of monitoring:

  • State Monitoring – monitor whether the API Apps are Enabled/Disabled
  • Endpoint Monitoring – monitor if the HTTP Endpoints of the API App are accessible

State Monitoring API Apps
From BizTalk360, you can monitor the state of API Apps. An API App can have the following 2 states:

  • Enabled – the API App is active and can receive requests
  • Disabled – the API App is disabled and cannot receive requests

With BizTalk360, you can monitor for both states and of course, we want to provide a monitoring experience which as seamless as possible. After you have selected the correct alarm and Azure subscription, it is just a matter of selecting the Azure API Apps and select the required expected state from the drop-down box. Once that’s done, BizTalk360 immediately starts to monitor the API App(s).

Azure API Apps Monitoring in BizTalk360Endpoint Monitoring
Azure API Apps basically are REST services which use JSON for data exchange. These REST services are the actual endpoints of the API Apps, which can be called by other systems. Each Azure API App has at least one endpoint but can contain many more endpoints. 

BizTalk360 has a quite extended feature set for Web Endpoint Monitoring, and it comes with advanced capabilities like adding custom GET parameters and HTTP headers:

  • Custom GET parameters – provide required/optional parameters
  • HTTP headers – provide additional HTTP headers (for example for authorization)

When the Endpoint sends a response, you can perform multiple checks to find out whether the Endpoint is in good health. You can check, for example:

  • HTTP Return codes – like HTTP 200 must exist, else throw warning/error
  • Existing and Non Existing keywords – like ‘success’ must exist in the response message
  • Response times – if it takes longer than, say, 5 seconds before the response is received, something might be wrong

HTTP Return codes
You can add multiple monitoring rules for HTTP return codes. This allows you to check for the existence, but also the non-existence of certain HTTP return codes. Besides that, you can also determine whether a Warning or an Error will have to be thrown in case the monitoring rules have not been met.

Existing and Non-Existing keywords
This is a very strong capability, as it allows you to check whether certain keywords exist or do not exist. As the response message might be in different formats, BizTalk360 allows you to check for the following formats and throw a Warning/Error based on the outcome of the monitoring rule:

  • Plain Text – search for keywords which should/should not exist
  • XML – enter an XPath query and the expected value which should/should not exist
  • JSON – enter an XPath query and the expected value which should/should not exist

For each format, you can search for just one keyword or multiple keywords to (not) exist.

Response times
Bad response times of endpoints might indicate that the endpoints (or the system/service behind it) are under stress. So monitoring on response times helps you to be aware of such situations.

As all of the above mentioned checks can be combined with each other, this provides very strong monitoring capabilities.

BizTalk360 API Apps Monitoring Response Alert

Multiple Azure Subscriptions
You might have multiple Azure subscriptions which contain different Azure API Apps. You can register all the relevant subscription and attach them to corresponding BizTalk Server environments within BizTalk360. This provides a seamless management/monitoring experience.

Conclusion

With Azure API Apps monitoring, we make it easy to constantly be aware of the well-being of your API Apps, without having to check that yourself manually. Besides monitoring whether the Azure API App is Enabled, we bring strong features for monitoring the actual HTTP endpoints.

You can read more about Azure API App monitoring and the other Azure services for which BizTalk360 provides support.

Get started with a Free Trial today!

If you want to monitor your Azure API Apps or have other BizTalk Monitoring related challenges, why not give BizTalk360 a try! It takes about 10 minutes to install on your BizTalk environments and you can witness and check the security and productivity of your own BizTalk Environments. Get started with the free 30 days trial.

BizTalk360-Free-Trial

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.

Why did we build Azure Logic Apps Monitoring in BizTalk360?

Why did we build Azure Logic Apps Monitoring in BizTalk360?

Azure Logic Apps Monitoring BizTalk360

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

Why do we need this feature?

Traditionally, a lot of system integration happened on-premise. When integration with partners or external systems was the need of the hour, this was achieved using SOAP/REST/HTTP/FTP/SFTP etc.

With the rise and adaption of cloud technologies like Amazon AWS and Microsoft Azure, cloud solutions became more and more capable to support scenarios where on-premise systems needed to interface to the on-premise systems of your partner(s) or with SaaS solutions like Office365 and SalesForce.

Microsoft is positioning Azure Logic Apps as the integration platform in the cloud mainly for connecting SaaS based solutions like Dynamics 365, Salesforce, ServiceNow, Workday etc.

Since the introduction of the Azure Logic Apps adapter for BizTalk Server 2016 and Azure Gateway, it is possible to integrate your on-premise systems via BizTalk Server with Azure Logic Apps seamlessly. This opens up great possibilities — it opens up some 300+ SaaS connectors that are available to Azure Logic Apps that can be utilized from BizTalk Server. Also, vice versa you can make the 100’s of external SaaS systems to talk to your on-premise BizTalk Server.

So it becomes very important to have a management/monitoring platform that’s capable of supporting both on-premise BizTalk Server and Azure Logic Apps from a single place.

What are the current challenges?

Azure Logic Apps provide a great way to extend your integration scenarios and capabilities to the cloud. However, from an operational and monitoring perspective, the Azure Portal is yet another portal the BizTalk Administrators need to be aware of and fit in their daily tasks.

So, besides their on-premises oriented BizTalk Server monitoring, organizations now also need to monitor their Hybrid solutions (which involve Azure Logic Apps) as events might occur they want to know about.

Think of, for example, somebody could have disabled your Azure Logic App  (that’s part of your end-to-end integration scenario), which prevents the Azure Logic Apps from being executed. Also, executions of the Azure Logic Apps might fail or run very slow, indicating that some other system might be under stress.

As it would take too much time to regularly check this kind of scenarios to take place, an administrator just wants to be informed automatically when these kind of events occur. You can use some of the monitoring features of Azure Portal, but you’ll not get the end to end visibility and it will operate on silo without giving the full context.

How BizTalk360 solves this problem?

At BizTalk360, we are closely following the trends in the integration landscape. We can clearly spot the necessity of using Azure Logic Apps in enterprise integration scenario along with BizTalk Server.

Because of this, we brought the support for Azure Logic Apps with BizTalk360. In addition to Azure Logic Apps, we also support other relevant integration technologies in Azure like Azure Service Bus, Azure API Apps and Azure Integration Account with BizTalk360.

In this article, we will just focus on how you can monitor your Azure Logic Apps from BizTalk360. Azure Logic Apps Monitoring with BizTalk360 consists of the following two parts:

  • State Monitoring – Monitor whether the Logic Apps are in the expected state
  • Data Monitoring – Monitor whether the executions of Logic Apps take place as expected

State Monitoring of Logic Apps

A Logic App can have the following two states:

  • Enabled – an instance of the Logic App can be started by means of a trigger
  • Disabled – the Logic App cannot be instantiated by means of a trigger

Azure Logic Apps monitoring with BizTalk360 consists of checking whether the state of a Logic App reflects the Expected state. In most cases, a Logic App will have to be in the Enabled state, but there might be scenarios where you want to monitor for the Logic App to be in the Disabled state, which is often referred to as Negative Monitoring. BizTalk360 allows you to monitor for both states.

Azure Logic Apps Monitoring in BizTalk360

Auto Correct
BizTalk360 has developed the Auto Correct feature for state-bound artifact monitoring. The feature allows you to let BizTalk360 try to bring the state bound artifact back to the expected state, once the artifact gets into the undesired state. This feature exists for the following artifact types:

  • Receive Locations, Orchestrations and Send Ports
  • Host Instances
  • Windows NT Services
  • SQL Server jobs
  • Logic Apps

As you can see from the list above, Azure Logic Apps monitoring can be decorated with Auto Correct. In case the Azure Logic App can’t be get back to the expected state, BizTalk360 will try to bring it to the desired state. You can also configure a maximum number of retries in the BizTalk360 portal. This is to prevent BizTalk360 to constantly keep on trying to bring the Azure Logic App back to the expected state, in case of some problem.

Multiple Azure Subscriptions
You might have multiple Azure subscriptions which contain different Azure Logic Apps. You can register all the relevant subscription and attach them to corresponding BizTalk Server environments within BizTalk360. This provides a seamless management/monitoring experience.

Data Monitoring of Logic Apps

With Data Monitoring of Azure Logic Apps, you can monitor for example whether:

  • expected number of runs are met in a certain time frame
  • a number of failures occur during a certain time frame
  • number of billable trigger executions in a certain time frame

The above scenarios are just an example – there are many more combinations.

Data Monitoring of Logic Apps will be discussed in more detail in another article, but here we just wanted to reveal a bit of that feature.

Conclusion

With the rise of Hybrid integration solutions, the job of BizTalk administrators has extended to the (Azure) cloud. BizTalk360 helps these administrators by providing operational and monitoring support for a number of Azure services, thereby taking away the need to constantly have to check the Azure portal to be aware of the health of these services.

In this article, we discussed the state monitoring capability of Azure Logic Apps. If you want to read more about the other Azure services BizTalk360 supports, just follow the articles in the Why did we built series.

You can read more on setting up Azure Logic Apps monitoring on our Documentation portal.

Try BizTalk360 Free for 30 days today!

Download and try BizTalk360 on your own environments free for 30 days. Installation will not take more than 5-10 minutes.

try biztalk360 for free

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.

Why did we build SQL Jobs Monitoring for BizTalk Environment?

Why did we build SQL Jobs Monitoring for BizTalk Environment?

BizTalk360 SQL Jobs Monitoring

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

Why do we need this feature?

As you will probably be aware of, BizTalk Server heavily relies on SQL Server databases for storing, for example, the configuration of BizTalk artifacts and the state of in-flight and completed processes. After installing and configuring BizTalk Server, few databases are created. The most important databases are the Configuration database, the MessageBox database and the Tracking database, but depending on the configured features, other databases might be created for BAM, BRE and SSO.

Further, there are a number of SQL jobs that gets created when you install and configure BizTalk Server. These SQL jobs are maintenance jobs and are of vital importance for the health of the BizTalk Server environment. The BizTalk SQL Jobs take care of making backups of the BizTalk databases, transfer tracking data from the MessageBox database to the Tracking database and all kind of cleaning up data from the databases.

Without having these jobs enabled (in cases disabled, not all the jobs are supposed to run) and properly running, it is just a matter of time, before you will get into trouble. This kind of trouble might lead to interruptions of the business process(es) which are being processed through BizTalk. For that reason, it is important to be aware of the (health) status of the SQL Jobs.

What are the current challenges?

There are two basic challenges at the moment with the current default tooling.

  • There is no out of the box support for monitoring SQL Jobs and keeping an eye on the health
  • Accessing SQL jobs for viewing, changing state, etc requires access to SQL Server

Although for experienced BizTalk administrators, it is obvious that they need to be well aware of the health of their BizTalk databases, for organizations with less experience on administrating BizTalk, this might come as a surprise.

We have seen that BizTalk administrators did not have access or insufficient access to the SQL Server management tools. This could especially be true, in case BizTalk Server has to share its SQL Server instance with databases of other systems, which is not a good idea anyway.

Even if the administrator has access to the SQL Management tools, having to manually monitor these SQL jobs is a time consuming and adds up to all the other assignments of the BizTalk administrator.

How BizTalk360 solves this problem?

As we, at BizTalk360, understand the importance of the SQL jobs, we brought both operational and monitoring features related to these jobs. In this section, we will discuss the Monitoring features.

BizTalk360 allows you to set up monitoring on SQL jobs seamlessly. You need to simply register the name of the SQL Server instances where your SQL jobs are running via the Settings -> Monitoring -> SQL Server Instances and all the SQL jobs will be ready for monitoring configuration.

BizTalk360 Add SQL servers for monitoring

Once configured, BizTalk360 enables you to achieve the following:

  • Monitor the Expected Job State (both enabled and disabled)
  • Configure Auto-correct
  • Monitor the Expected Last Job Run State

Below, all these capabilities will be discussed.

Monitor list of SQL jobs BizTalk360

Monitor the Expected Job State

With this kind of monitoring, you can check whether the SQL job is in the correct state. In most cases, the expected state will be Enabled, but in certain cases, the expected state must be Disabled. BizTalk360 allows you to monitor for both states.

The possibility of negative monitoring comes in handy for BizTalk Server, as the MessageBox_Message_Cleanup_BizTalkMsgBoxDb jobs need to be in disabled state. This job works like a stored procedure and used internally by other jobs. It should not be manually started by a DBA or BizTalk Administrator.

Configure Auto-Correct

The Auto-Correct feature is an extension of Expected State Monitoring. Basically, it allows you to bring State-bound artifacts back to the expected state after they reached the wrong state.

Auto-correction works 2 ways. If an artifact, say a SQL Job, is expected to be in the Enabled state but reached the Disabled state, the Auto-Correct feature will try to bring the SQL job back to the  Enabled state.

However, when a SQL job is expected to be in the Disabled state (like the MessageBox_Message_Cleanup_BizTalkMsgBoxDb job) but got Enabled, the Auto-Correct feature will try to bring the job back to the Disabled state.

This helps to maintain the state of the SQL jobs in the desired state even if there is a human error.

This feature works not just for SQL Server jobs, but also for:

  • Receive Locations, Orchestrations and Send Ports
  • Host Instances
  • Windows NT Services
  • Azure Logic Apps

Monitor the Expected Last Job Run State

This allows you to check whether the job runs successfully. Once you have setup monitoring for Expected Last Run state, you will be notified in case the Last Run State was unsuccessful.

Conclusion

By bringing SQL job monitoring, including the auto-correct feature, we think that this will make the life of both BizTalk administrators and SQL Server DBA’s a bit easier.

If you want to read more about SQL job monitoring, please read this article.

Get started with a Free Trial today!

If you are struggling with all the above-mentioned challenges, why not give BizTalk360 a try. It takes about 10 minutes to install on your BizTalk environments and you can witness and check the security and productivity of your own BizTalk Environments. Get started with the free 30 days trial.

BizTalk360-Free-Trial

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.

Why did we build Web Endpoints Monitoring in BizTalk360?

Why did we build Web Endpoints Monitoring in BizTalk360?

BizTalk360 Web Endpoints Monitoring

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

Why do we need this feature?

SOAP & REST based Web Services are one of the most used technologies in integration scenarios. In the last few years, the need for HTTP based communication with external vendors/systems has increased significantly. Pretty much it became a norm to expose the API’s of the system for external consumption. Examples: Salesforce API, Microsoft Graph API for Office365 and so on. Also, the companies want to reuse their legacy system as much as possible internally and they expose them as internal web services.

BizTalk Server offers great support for HTTP(S) based web services, both on the Receive and the Send side of interfaces.

When you are integrating multiple endpoints via HTTP(s), it is important to know whether the web services are available, responsive, returning expected values etc., to be able to communicate with them and to support the business process.

What are the current challenges?

The use of web services (web endpoints) comes into play on both receive side and send side in BizTalk Server. Both comes with its own significance and it’s important to monitor them.

Receive Side web services

BizTalk Server allows you to publish schemas and orchestrations as WCF services, which are then published in the IIS web server on the BizTalk Server. In case, you have multiple BizTalk servers in the same BizTalk group, you can set up an NLB (Network Load Balancing) cluster to achieve Load Balancing and High Availability.

The published WCF services are associated with Receive Locations. As a result, if something is wrong with a particular WCF service, for example, the Application Pool in IIS is down, the Receive Location will automatically be set to Disabled.

If the Receive Location/Port is down, then it won’t accept any incoming messages via this channel. Therefore, it’s important to make sure it’s up and running all the time.

Send Side web services

On the outgoing side, you configure either HTTP, SOAP, REST, BizTalk Send port to connect to external web endpoints. If something is wrong with the external web endpoints, the state of the Send Port will remain the same inspite of the state of the external web endpoint.

So, to be able to know the actual state of the web endpoint, the well-being of the endpoint will have to be monitored and checked. This helps to be sure that when a real request to the web endpoint is made, that the actual endpoint can be accessed and the request is properly being processed.

When a web service is down and requests are being sent to that web service, the failing requests will lead to suspended messages in BizTalk, resulting in an interruption of the business process and some work for the BizTalk administrator to have the issue solved and to resume the suspended messages.

An external web service can be down for a variety of reasons.

  • Internal web server/service issues – you might get for example the famous, though non-informative, HTTP 500 return codes
  • Certificate issues – expired certificates, incorrectly configured or unaccepted client certificates
  • Firewall issues – web server/service cannot be contacted at all due to wrongly configured firewall rules
  • Flooding – there’s more work than the web server/service can handle

All this kind of errors will lead to unavailability of the web endpoint and interruptions of the business process. This is exactly what we want to prevent, and as it is impossible for a BizTalk administrator to manually monitor web endpoints 24/7, it is way more efficient to have monitoring in place.

How BizTalk360 solves this problem?

For monitoring the physical HTTP web endpoints, BizTalk360 offers Advanced Web Endpoint Monitoring. Once set up, this feature will periodically fire requests against the web service which is being monitored and report any issues identified.

The feature is quite rich and offers, amongst others, support of:

    • HTTP and HTTPS web services (REST/SOAP)
    • Using Gateway proxies
    • Providing credentials
    • GET and POST methods
    • Multiple content types like
      • Text
      • XML
      • JSON
    • providing custom
      • HTTP headers
      • GET parameters
      • POST payload

Advanced Web Endpoints Monitoring BizTalk360

These features allow you to monitor for example HTTP return codes (200 is okay, 500 is warning/error). But you can also check for certain keywords to exist in the XML/JSON response message, by entering XPath/JSON queries.
You can even monitor for response times of the web service, as this might be an indication that the web service is under stress.

BizTalk360 Web Endpoint Monitoring - Endpoint details

So with the Advanced Web Endpoint Monitoring feature of BizTalk360, you will be able to cover pretty much all the web endpoint monitoring scenarios, whether these web services reside inside your organization or outside and whether these services use XML or JSON.

Conclusion

To underline the importance of web endpoint monitoring, let’s shortly discuss the often forgotten concept of Chain Monitoring.
It is a bit of a human behavior, to just focus on your own work and systems, meanwhile forgetting the impact of your work on other systems.

A simple example: a Technical/Functional Application administrator is responsible for the administration of a CRM system. On a day to day basis, he is very busy with functional questions, which results in not always having the overview of the health of the web services of his CRM system, while these services received data on a regular base from an ERP system, via BizTalk Server.

It was with this kind of scenario where we have experienced that the BizTalk administrator who was using BizTalk360 and had set up Web Endpoint Monitoring, was notified by BizTalk360 of problems with a web endpoint. The administrator contacted the owner of the web endpoint, who was not yet aware of the issue! The issue was solved by the owner of the web service and no interruption of the business process took place.

The above example was based on a scenario which really took place in one of our customer and a very clear example of the purpose of Advanced Web Endpoint monitoring.

If you want to read more on the nitty/gritty of the Advanced Web Endpoint Monitoring feature in BizTalk360, please read this article.

Get started with a Free Trial today!

If you are struggling with the above mentioned challenges, why not give BizTalk360 a try. It takes about 10 minutes to install on your BizTalk environments and you can witness and check this feature on your own BizTalk Environments. Get started with the free 30 days trial.

try biztalk360 for free

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.

Why did we build Graphical Message Flow viewer in BizTalk360?

Why did we build Graphical Message Flow viewer in BizTalk360?

Graphical Message Flow Viewer BizTalk360

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

Why do we need this feature?

To be able to do his job, a BizTalk administrator needs to know what kind of processes flow through the BizTalk environment. This insight can be used for a number of purposes, like:

  • analysis and/or debugging of issues
  • learning/training purposes
  • documentation purposes

One of the features which can be used to better understand the processes in BizTalk is the Tracking queries which can be accessed through the BizTalk Administration Console. These queries provide insight on which messages and orchestrations have been processed by BizTalk. From the Tracking queries, it is also possible to have some insight on the message flow.

What are the current challenges?

The major problem with the message flow which can be shown in BizTalk Admin console is that it is very textual and doesn’t allow you to show the entire flow. This makes understanding the processes in BizTalk a time-consuming task.

Another disadvantage is that when somebody accesses the tracking queries in the BizTalk Admin console, confidential information might be revealed to unauthorized people.

How BizTalk360 solves this problem?

BizTalk360 offers a lot of features to provide insight in BizTalk processes. One of these features is the Graphical Message Flow viewer.
As with the Tracking queries in the BizTalk Admin console, the Graphical Message Flow viewer depends on tracking data. So, to start using the Graphical Message Flow viewer, you start with creating a Tracking query in BizTalk360.

Graphical Flow Tracking BizTalk360

As you can see from the Build Query Expression part of the screen, you can create the same kind of queries as in the BizTalk Administration console. You can also save your tracking queries for later use. These queries are stored in the BizTalk360 database, so you always have them at hand. Whereas with the BizTalk Admin console, your queries are stored to the file system which can make it harder to retrieve them, especially when you have multiple BizTalk servers.

Details of the tracked service instances can be viewed by simply clicking the eye icon in the most right column of the grid.

The first column of the results grid shows the name of the service as a hyperlink. By clicking the hyperlink, the Graphical Message Flow for the service instance will be shown.

Graphical Flow Tracking in BizTalk360

The Graphical Message Flow viewer shows the service instance as a shape and depending on the type of artifact, then it will appear under the Receive Port, Orchestration or Send Port label. The blue dot in the shape reflects the receive side of a message at the artifact, while the green dots reflect that the message has been sent out of the artifact. In the above screenshot, one message has been received and multiple messages have been sent out, depicting a debatching scenario.

Besides the graphical shape of the service instance, also all kind of properties of the service instance is shown. You can even directly navigate to the BizTalk artifact in its BizTalk application, by simply clicking the provided hyperlink.

Also, the related service instances can be viewed, depicting the complete message flow. This can be done by clicking the subsequent green dots.

Graphical Flow Tracking scenario BizTalk360

Depending on the amount of tracking turned on for the artifacts and whether the user is authorized in BizTalk360, message context and content information can be viewed in the pane at the right of the screen.

The Graphical Message Flow viewer is a very useful feature and it is likely that BizTalk administrators will use it on a near day to day basis.

Get started with a Free Trial today!

Download and try BizTalk360 on your own environments free for 30 days. Installation will not take more than 5-10 minutes.

try biztalk360 for free

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.

Why did we build Search and Action on BizTalk Artifacts?

Why did we build Search and Action on BizTalk Artifacts?

Search and Action Artifacts BizTalk360

This blog is a part of the series of blog articles we are publishing on the topic “Why we built XYZ feature in BizTalk360”. Read the main article here.

Why do we need this feature?

In their day to day operations, BizTalk administrators will regularly need to check the status of different BizTalk artifacts. There might be multiple reasons to do so, amongst which are:

  • Artifacts being in the wrong state (a Receive Location being Disabled, instead of Enabled)
  • The configuration of an artifact needs to be checked for analysis of an issue
  • The state of artifacts needs to be persisted, because of an upcoming deployment

To access the actual state and configuration of BizTalk artifacts, BizTalk administrators need to use a Remote Desktop connection to access the BizTalk server and start the BizTalk Server Administrator Console. The BizTalk Administrator console is not very helpful in finding the needed artifact(s) as the console has no or only limited search functionality.

What are the current challenges?

Besides the fact that BizTalk administrators will not always have access to RDP, because they might not be at their own desk, the Administration console is not very helpful, when certain artifact(s) need to be found. For example, the Admin console has:

  • no or limited search feature (depending on the BizTalk Server version)
  • no state persisting feature

No or limited search feature

In versions older than BizTalk Server 2016, there are just browse features per artifact type, which can make it quite time-consuming to find the artifact(s) you are looking for.

With BizTalk Server 2016, Microsoft introduced a Search feature. However, that feature is limited to search only for the name of any artifact. So for example, it is not possible to search for the URI or the transport type of an artifact.

No state persisting feature

Besides taking screenshots, there is no feature to store the status of the artifacts. Taking screenshots will help a bit, but it is not very practical. Reason for that is because not all artifacts (of the same type) for which you want to persist the state might fit on the same screen. Therefore, you’ll have to make multiple screen shots and store them in for example a Word document, which decreases the usability.

How BizTalk360 solves this problem?

To address all the mentioned problems, BizTalk360 has the Search Artifacts feature. The Search Artifacts feature allows you to search for BizTalk artifacts in one single screen. Depending on the kind of artifact, you can search and filter for different properties of that kind of artifact. For example, for Receive Locations and Send ports, you can search and filter for:

  • Name of the artifact
  • The URI of the artifact
  • Application where the artifact resides
  • The status of the artifact (Enabled/Disabled or Started/Stopped/Unenlisted)
  • Host name which processes the artifact
  • Transport Type of the artifact

When you have searched for certain artifacts, BizTalk360 shows the results in a grid. Depending on the kind of artifact, this result grid will show the most important data for that kind of artifact.

BizTalk360 Search Artifacts

You can also, directly, action on a single artifact or on multiple artifacts. In case of Receive Locations for example, you can immediately Enable or Disable one or multiple Receive Locations from the grid. BizTalk360 shows a handy drop down box to select artifacts, depending on their state.

BizTalk360 Search Artifacts - Perform Actions

Further, you can access the properties of a certain artifact by clicking the eye icon which appears in the last column of the grid.

BizTalk360 Search Artifacts - Properties

Another handy feature is the ability to export the entire result grid to Excel. This feature is especially handy in case you are preparing the deployment of BizTalk application(s) and you want to persist the current state of the artifacts, as the state might be changed by the deployment package(s).

BizTalk360 Search Artifacts - Save to ExcelAll in all, the Search feature in BizTalk360 not only saves time in the day to day operations of a BizTalk administrator, but it will also make him or her look better, when a business user arrives at his or her desk with a quick question on the state of a particular artifact!

Get started with a Free Trial today!

Download and try BizTalk360 on your own environments free for 30 days. Installation will not take more than 5-10 minutes.

try biztalk360 for free

Author: Lex Hegt

Lex Hegt works in the IT sector for more than 25 years, mainly in roles as developer and administrator. He works with BizTalk since BizTalk Server 2004. Currently he is a Technical Lead at BizTalk360.