by Lex Hegt | Feb 6, 2018 | BizTalk Community Blogs via Syndication
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.
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.
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. View all posts by Lex Hegt
by Lex Hegt | Feb 5, 2018 | BizTalk Community Blogs via Syndication
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.
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 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.
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. View all posts by Lex Hegt
by Lex Hegt | Feb 2, 2018 | BizTalk Community Blogs via Syndication
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
- providing custom
- HTTP headers
- GET parameters
- POST payload
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.
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.
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. View all posts by Lex Hegt
by Saravana Kumar | Jan 17, 2018 | BizTalk Community Blogs via Syndication
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 and Queuing Platforms
In any Enterprise integration scenario, message queuing technologies like IBM MQ, MSMQ, Azure Service Bus Queues etc., play a significant role. Message Queuing provides the solution to some critical business scenarios like the store and forward, first in first out, batch processing and so on.
Often times, queuing platform works more or less like a database — it accumulates the messages that was received from the source systems. The real power of the platform is realized when messages are pulled and utilized by the downstream systems like order processing, shipping etc.
BizTalk Server comes with native adapters for IBM MQ, MSMQ, Service Bus making it a powerful platform when your integration solution needs to communicate to Queuing endpoints.
Why do we need this feature?
Given the above scenario, the importance of a queuing platform in an Enterprise integration solution is pretty clear. In an integration scenario, it’s important to make sure both the BizTalk Server platform as well as the systems to which it is connected are all working seamlessly without any downtime. If an order receiving IBM MQ is down, then the entire integration journey of end-to-end order processing is also down. Hence it’s pretty important, you monitor those external queuing systems in addition to your BizTalk Server platform.
What are the current challenges?
No Monitoring: There is no out of the box monitoring solution that comes with BizTalk Server to monitor either BizTalk Server platform or the external sources like IBM MQ, MSMQ, Azure Service Bus Queue etc.
Custom Solutions: Often, developers write some C# or PowerShell scripts to monitor the external Queues which is hard to maintain, which will not have a good configuration experience, and will go out of sync over a period of time. Even though at the face it will look like few lines of code, real implementation will require correct type of client libraries, handling SSL certificates etc.,
Limited 3rd party solutions: There are third party options available to monitor the queues, however, they come with limited functionality. It’s not tightly integrated with your BizTalk Solution and the configuration is not seamless.
How BizTalk360 solves this problem?
The monitoring for Queuing technologies that work with BizTalk Server is built from the ground up in BizTalk360. The user experience of configuring the monitoring for Queues is seamless. If your environment uses any Queue based BizTalk Receive Port/adapter or Send Port/adapter, BizTalk360 picks up all the configuration from them. You only need to specify the conditions you are interested in monitoring.
Here is the list of supported thresholds for different Queuing technologies that comes along with BizTalk360
IBM MQ:
- Current Queue Depth
- Current Queue Usage %
- Backout Queue Depth
- Backout Queue Usage %
MSMQ:
- Queue Size
- Active Message Count
- Journal Message Count
- Dead Letter Message Count
Azure Service Bus Queue:
- Queue Status
- Active Message Count
- Dead Letter Message Count
- Transfer Message Count
- Queue Size
- Message Count
- Transfer Dead Letter Message Count
- Scheduled Message Count
- Queue Size
You can combine multiple check conditions using a logical AND/OR as shown in below, this makes it extremely powerful
General Monitoring Benefits
BizTalk360 monitoring comes with a set of standard features that’s applicable to all monitoring plugins. The Queue monitoring can also take advantage of the following capabilities.
Import/Export: The import/export function allows you to move your monitoring configuration from one environment to another. Example: From your UAT/Staging environment to Production.
Notification Channel: BizTalk360 comes with a list of Notification Channels like email, SMS, slack, HP Operations Manager etc., making it powerful to notify administrators as soon as something goes wrong.
Monitoring Dashboard: BizTalk360 comes with rich monitoring dashboard that visualizes the system health in a graphical way.
Notification History: You can also keep track of all the notification history that’s been sent to the support people.
Author: Saravana Kumar
Saravana Kumar is the Founder and CTO of BizTalk360, an enterprise software that acts as an all-in-one solution for better administration, operation, support and monitoring of Microsoft BizTalk Server environments. View all posts by Saravana Kumar
by Saravana Kumar | Aug 3, 2017 | BizTalk Community Blogs via Syndication
A typical highly available BizTalk Server group contains one or more BizTalk Servers. We have witnessed some of the complex BizTalk Server environment handling high volume traffic having an infrastructure similar to the one shown below with 6 BizTalk Server and 3-4 SQL Servers.
There are 2 main reason for having multiple BizTalk Server is the group
- Scalability
- Resilience/High Availability
Scalability: The more servers you have in the group means more processing power. You can create multiple BizTalk Server Host and Host Instances in each one of the available servers and increase the volume of messages you can process.
Resilience/High Availability: If you wanted to make sure the environment is highly available, you need to have at least 2 BizTalk Servers in the group and also need to carefully plan how the host/host instances are configured to make sure if one server goes down it doesn’t bring the whole environment down.
Why do you need this?
As a BizTalk Administrator you need to make sure all of your BizTalk Servers are up and running and processing messages at expected level. In the above 6 server configuration, there is a possibility one of the BizTalk Servers goes down and no one really notice it for a long period, until the environment itself becomes a bottle neck. In smaller environments (ex: 2 BizTalk Servers), it becomes super important to make sure your BizTalk Servers are up and running all the time to avoid down time or react to down time quickly.
To address these challenges we are introducing BizTalk Server Availability monitoring in BizTalk360 version 8.5.
As always, one of the core strength of BizTalk360 for monitoring BizTalk Server environments is we wanted to make it super simple and great user experience to configure things. It will literally take less than 2 minutes to setup BizTalk Server Availability Monitoring in-spite of the complexity of your environment.
The above screen show how you can configure the availability monitoring for a 2 BizTalk Servers group. The servers are already listed, you simply need to select them and click the “Enable Monitoring” button. (PS: You need to understand the concept of Alarms in BizTalk360)
Protocol Type: In order for us to check the availability we need to reach the servers, we support “Ping” and “Telnet” to achieve this, one of these protocols need to be enabled.
Monitor Availability (either all or one of them)
This is very important and very specific to BizTalk Server availability monitoring. You can choose the option to alert either if one of the BizTalk Server is the group has gone down or alert only when all of the servers in the group has gone down. The first one is useful if you know there are intermittent issues and the server will come back online after some time and there is no need to alert the teams unnecessarily.
Give it a try on your own environment by downloading a 14-day free trial of BizTalk360.
Author: Saravana Kumar
Saravana Kumar is the Founder and CTO of BizTalk360, an enterprise software that acts as an all-in-one solution for better administration, operation, support and monitoring of Microsoft BizTalk Server environments. View all posts by Saravana Kumar
by Saravana Kumar | Aug 3, 2017 | BizTalk Community Blogs via Syndication
A typical highly available BizTalk Server group contains one or more BizTalk Servers. We have witnessed some of the complex BizTalk Server environment handling high volume traffic having an infrastructure similar to the one shown below with 6 BizTalk Server and 3-4 SQL Servers.
There are 2 main reason for having multiple BizTalk Server is the group
- Scalability
- Resilience/High Availability
Scalability: The more servers you have in the group means more processing power. You can create multiple BizTalk Server Host and Host Instances in each one of the available servers and increase the volume of messages you can process.
Resilience/High Availability: If you wanted to make sure the environment is highly available, you need to have at least 2 BizTalk Servers in the group and also need to carefully plan how the host/host instances are configured to make sure if one server goes down it doesn’t bring the whole environment down.
Why do you need this?
As a BizTalk Administrator, you need to make sure all of your BizTalk Servers are up and running and processing messages at the expected level. In the above 6 server configuration, there is a possibility one of the BizTalk Servers go down and no one really notices it for a long period, until the environment itself becomes a bottle neck. In smaller environments (ex: 2 BizTalk Servers), it becomes super important to make sure your BizTalk Servers are up and running all the time to avoid down time or react to down time quickly.
To address these challenges we are introducing BizTalk Server Availability monitoring in BizTalk360 version 8.5.
As always, one of the core strength of BizTalk360 for monitoring BizTalk Server environments is we wanted to make it super simple and great user experience to configure things. It will literally take less than 2 minutes to setup BizTalk Server Availability Monitoring in-spite of the complexity of your environment.
The above screen shows how you can configure the availability monitoring for a 2 BizTalk Servers group. The servers are already listed, you simply need to select them and click the “Enable Monitoring” button. (PS: You need to understand the concept of Alarms in BizTalk360)
Protocol Type: In order for us to check the availability we need to reach the servers, we support “Ping” and “Telnet” to achieve this, one of these protocols need to be enabled.
Monitor Availability (either all or one of them)
This is very important and very specific to BizTalk Server availability monitoring. You can choose the option to alert either if one of the BizTalk Server is the group has gone down or alert only when all of the servers in the group has gone down. The first one is useful if you know there are intermittent issues and the server will come back online after some time and there is no need to alert the teams unnecessarily.
Give it a try on your own environment by downloading a 14-day free trial of BizTalk360. You can write to us at support@biztalk360.com.
Author: Saravana Kumar
Saravana Kumar is the Founder and CTO of BizTalk360, an enterprise software that acts as an all-in-one solution for better administration, operation, support and monitoring of Microsoft BizTalk Server environments. View all posts by Saravana Kumar
by Raja Sreenivasan | Jul 27, 2017 | BizTalk Community Blogs via Syndication
With this release of BizTalk360(v8.5), the user can customize email template. The earlier version of BizTalk360 only has a capability to change the color of the email body, font, logo, background, footer background etc. Most of our customer had requested to customize the email alert with more comprehensive improvements, so we have revamped the email template module with more additional functionalities to simplify and customize the email notification. This allows to create and manage custom templates for notifications.
The user can able to create a template with an in-built XSLT validator with preview options. Email template can be used in different alarms with light or dark theme, which helps to
• grab the support team’s attention to take on the relevant actions.
• choose different theme templates to indicate different business cases.
• easily identify which template belongs to which environment.
So, let’s us look how to create a template in the newer version of BizTalk360.
Creating Template
In BizTalk360, Manage Email Template can be found in the monitoring and notification section of setting side. While installing the newer version, the default template “BizTalk360 Email Template” will be used for all the existing or newly created alarm.
For creating a new template, click on “NEW” icons as shown in above picture, a blade opens for providing the basic details like template name, description of the template, toggle button for making it as default template as shown in the picture below.
In the following section, the user can edit and provide their own data like display name, email address, logo text, footer text etc.same as previous versions for a better manageability.
Theme
Initially, BizTalk360 provides a default template “BizTalk360 Email Template” with a light elegant theme. Themes are also available in two variants light and dark. A user can able to choose light or dark theme while creating a template.
However, the earlier version of BizTalk360 email colors are chosen by selecting colors from color picker and here we came up with the idea of providing “themes” instead of simply selecting the color code for the email template.
We categorized themes into two
• Light Theme
• Dark Theme
Light Theme
Dark Theme
We are not restricting the user to simply selecting light or dark theme, we have also provisioned to edit the themes.
Under the edit theme color settings, a user can choose 6 Body BG color which represents different themes for light and dark. Once the theme is selected, “PREVIEW TEMPLATE” option is being provided to cross check the desired changes on a new blade.
Once the template is created, it will be displayed in the main grid of Manage Email Templates page.
XSLT
BizTalk360 uses XSLT (eXtensible Stylesheet Language Transformations) as a styling language for customizing the email template. The XSLT file editing option is being provided to a user for changing font family and font size. “Please do not change any logic in XSLT file, as this might corrupt the mailing functionality”. This facility is available in the edit section of each template by clicking the edit gear icon.
Once the changes are made in the XSLT file, the inbuilt XSLT validator verifies the XSLT file and allows the user to save the file after successful verification.
The “Preview Template” option is provided in edit section to make sure the desired changes have been made in XSLT file.
Alarm Configuration
In the alarm configuration section, we have customized for a user-friendliness to choose the template that has been created at the manage email module. Also, we made the notification channel to be available in the Alarm configuration page itself. We have made the email configuration optional if the notification channel is being enabled so that either one of the choices can serve the purpose.
Conclusion
BizTalk360 already had a feature to format email template, with its latest release v8.5 it fills the gap by adding the ability to customize, create and manage template for different alarms based on user preference. Keep your mailing color codes intact with your thoughts using our customized email template feature. If you have any feedback or suggestion, please feel free to write to us at support@biztalk360.com.
by Vignesh Sukumar | Jul 25, 2017 | BizTalk Community Blogs via Syndication
BizTalk360, being a Middleware monitoring tool, it must deal with a lot of message transfer between different systems of BizTalk Server. In a typical enterprise level scenarios, the cluster of systems plays an important role in high availability. The Communication between different server systems happens from Server to a network and then to another system via ports/protocols.
In a typical StandAlone (or) High-Availability monitoring scenarios where BizTalk360 is installed on a server different from actual BizTalk server. This enables the BizTalk Server to be monitored on 24×7 without any downtime on monitoring. Even if the BizTalk physical server goes down, BizTalk360 can send the down alert. This blog summarizes the basic ports/protocols that need to be granted an access to receive or send a message across the interconnected systems.
As this is the best practice to install the BizTalk360, we need to make sure the BizTalk360 running servers should be enabled with below protocols/port number in the Windows Firewall to communicate with the BizTalk Server/Azure/any external services at runtime. Below is the list of basic ports/protocols utilized for all the features/services.
SQL Server:
As BizTalk Server Relies on the SQL server databases, connection to the SQL server is critical to fetch the Artifacts/any results via direct query or through BizTalk ExplorerOM. This SQL connectivity is responsible for a majority of the below functionalities.
Database responsible for the above functionalities includes the below BizTalk databases and also BizTalk360 database.
DTC/WMI Port
BizTalk360 communicates with other windows services with the help of Windows Management Instrumentation. MSDTC- Microsoft Distribution Coordinator is responsible for moving the transaction from one system to another system. Make sure the Network DTC is also switched on to communicate with other remote servers and MSMQ. Also make sure MSDTC, WMI and RPC windows services are up and running.
Useful Microsoft Links
As the BizTalk360 server requires the same level of permissions like BizTalk server and the usage of the ports/protocols are pertinent to the Business architecture of every client, the below Microsoft links provides the port level segregation for different features that must be enabled on the Firewall to make BizTalk360 monitoring work seamlessly
Random/Custom Ports:
At run time, TCP ports are randomly picked up by the server, make sure the dynamically allocated ports are also being unblocked by the firewall. Also, make sure if custom ports are utilized for any service, unblock that as well from the firewall for the seamless working. Please refer Microsoft article for guidance. For firewall security recommendations please visit this msdn-link.
Summary
BizTalk360 provides continuous support and suggestions to make the monitoring at your ease. This blog was one such effort to make sure our BizTalk360 users seamlessly follow best practices to make BizTalk monitoring an easier one.
Author: Vignesh Sukumar
Vignesh, A Senior BizTalk Developer @BizTalk360 has crossed half a decade of BizTalk Experience. He is passionate about evolving Integration Technologies. Vignesh has worked for several BizTalk Projects on various Integration Patterns and has an expertise on BAM. His Hobbies includes Training, Mentoring and Travelling View all posts by Vignesh Sukumar
by Praveena Jayanarayanan | Jul 4, 2017 | BizTalk Community Blogs via Syndication
BizTalk360 is a single platform to have total control over your BizTalk environment. It has the three main modules namely Operations, Monitoring and Analytics. Monitoring is considered as the main feature of BizTalk360 because it provides rock solid monitoring for the BizTalk environment and informs us via email alerts when the BizTalk server is suffering from problems and downtimes.
As per the below quotes,
“Listening to our customer’s feedback makes them feel appreciated and part of the value creation process”,
We always listen to their valuable suggestions and feedback and add them to BizTalk360 in every upcoming release. We also make enhancements to the existing features based on the customer feedback. This blog explains about one such enhancement on actions performed on the suspended instances.
MessageBox Queries Monitoring:
Data Monitoring was one such feature included in BizTalk360, from the customers’ feedback. Data monitoring helps to monitor the send/receive ports, service instances and exception data from different data sources in BizTalk server. Message Box Queries monitoring is a part of Data Monitoring which is used to monitor the service instances. The service instances may be running or may get suspended in BizTalk servers due to various reasons.
The messaging service instance is the service instance that’s created for your receive and send port at the run time. A receive port/send port is a combination of various things. Ex: An adapter (File, WCF, SQL etc.), a receive pipeline (and a send pipeline if two-way), and Maps. They get instantiated like the objects for the classes and have different states in their lifetime namely,
- Ready to Run
- Scheduled
- Dehydrated
- Suspended (Resumable)
- Suspended (Non-Resumable)
- Active
- In Breakpoint
Here in monitoring, we can monitor the count of these instances at various stages and the alerts will be triggered based on the filters and threshold value configured. It is important to monitor the number of service instances, to keep the BizTalk environment healthy. Having many instances will make the MessageBox database bloated which in turn will affect the performance of the environment. The service instance count can be retrieved from BizTalk Administrator group hub page which displays only the count and does not tell you if it’s the expected count or not. A person seeing this information needs to be a BizTalk expert to understand the various states. Here comes our MBQ monitoring which alerts users according to the threshold limit configured. A non-BizTalk person can now easily understand the alert message and act accordingly.
Actioning on the suspended service instances:
Based on the state of the service instances, the administrator can decide on whether to resume or terminate the instances. For example, when a message is sent through the send port and if it’s stopped, then the instance gets suspended. Once the send port is up, the message can be resumed and processed. Instead of going to the BizTalk admin console and checking it, BizTalk360 has the feature to terminate/resume the instances from the monitoring itself. We can also configure the time when we want to perform the action, either every time or during Error/Warning condition.
So, what happens when Action Required is ticked?
There may be scenarios wherein, the customer wants to monitor any suspended messages that by the end of the day are no longer relevant and should be terminated. So, in this case, BizTalk360 can automatically terminate the instances as per the alarm configuration. This can avoid the excess workload to the BizTalk user as he needs to go and manually run the query to find the instances and action it. We also have the option to bulk terminate the suspended instances altogether instead of doing one by one. There is also an archiving option and to download the instances.
Can non-super users terminate/resume suspended instances?
We have two kinds of users in BizTalk360, namely Super users and normal users. Super users enjoy the admin privileges and have access to all modules. They can define the authorization for the different level of users. They restrict the access permissions for the normal users. The normal users will have minimal access permissions.
The normal users can be anyone from the organization, may be supported engineers, other non-BizTalk group members who are just monitoring BizTalk servers. They would not be aware of the conditions of the service instances. Hence, they cannot decide upon the action to be performed on the suspended instances as it’s a sensitive area like terminating/resuming the instances. This may lead to security and auditing problems also. When normal users configure Data Monitoring and try to resume a suspended instance, they may get an exception message as follows-
System.Exception: User does not have enough rights to access the BizTalkQueryService(service) and ExecuteServiceInstanceOperation(operation).
The administrator alone can know the state of the instances and decide upon the action on them. For this reason, BizTalk360 has provided the restriction that only superusers can perform the resume/terminate action for them.
An in-depth analysis on the super user access to terminate instances:
Let’s have an in-depth look into this limitation and how it must be handled. The user logged into BizTalk360 may be a super user. But still, that user will not be able to perform any action on the service instances. Do you know why? Let’s move forward to know the reason.
When we install BizTalk360, we provide the service account credentials. This service account will be the user who is running the App Pool and monitoring service. The logged in user running the MSI to install BizTalk360 may be different from the service account. When the application is installed, the logged in user will be created as a superuser in BizTalk360 by default.
So, what happens to the service account if it’s different from the logged in user?
The service account running the IIS App pool and the monitoring service must be created as the “Super User” in BizTalk360. Only then this user can perform the resume/terminate actions on the service instances. Otherwise, the above exception will be thrown.
Since these are sensitive operations on the instances, only the super user/ administrator should be able to perform such tasks. Therefore, BizTalk360 has imposed this restriction that only when the service account is added as the super user, he can perform the operations on the suspended service instances.
Author: Praveena Jayanarayanan
I am working as Senior Support Engineer at BizTalk360. I always believe in team work leading to success because “We all cannot do everything or solve every issue. ‘It’s impossible’. However, if we each simply do our part, make our own contribution, regardless of how small we may think it is…. together it adds up and great things get accomplished.” View all posts by Praveena Jayanarayanan
by Praveena Jayanarayanan | Jul 4, 2017 | BizTalk Community Blogs via Syndication
BizTalk360 is a single platform to have total control over your BizTalk environment. It has the three main modules namely Operations, Monitoring and Analytics. Monitoring is considered as the main feature of BizTalk360 because it provides rock solid monitoring for the BizTalk environment and informs us via email alerts when the BizTalk server is suffering from problems and downtimes.
As per the below quotes,
“Listening to our customer’s feedback makes them feel appreciated and part of the value creation process”,
We always listen to their valuable suggestions and feedback and add them to BizTalk360 in every upcoming release. We also make enhancements to the existing features based on the customer feedback. This blog explains about one such enhancement on actions performed on the suspended instances.
MessageBox Queries Monitoring:
Data Monitoring was one such feature included in BizTalk360, from the customers’ feedback. Data monitoring helps to monitor the send/receive ports, service instances and exception data from different data sources in BizTalk server. Message Box Queries monitoring is a part of Data Monitoring which is used to monitor the service instances. The service instances may be running or may get suspended in BizTalk servers due to various reasons.
The messaging service instance is the service instance that’s created for your receive and send port at the run time. A receive port/send port is a combination of various things. Ex: An adapter (File, WCF, SQL etc.), a receive pipeline (and a send pipeline if two-way), and Maps. They get instantiated like the objects for the classes and have different states in their lifetime namely,
- Ready to Run
- Scheduled
- Dehydrated
- Suspended (Resumable)
- Suspended (Non-Resumable)
- Active
- In Breakpoint
Here in monitoring, we can monitor the count of these instances at various stages and the alerts will be triggered based on the filters and threshold value configured. It is important to monitor the number of service instances, to keep the BizTalk environment healthy. Having many instances will make the MessageBox database bloated which in turn will affect the performance of the environment. The service instance count can be retrieved from BizTalk Administrator group hub page which displays only the count and does not tell you if it’s the expected count or not. A person seeing this information needs to be a BizTalk expert to understand the various states. Here comes our MBQ monitoring which alerts users according to the threshold limit configured. A non-BizTalk person can now easily understand the alert message and act accordingly.
Actioning on the suspended service instances:
Based on the state of the service instances, the administrator can decide on whether to resume or terminate the instances. For example, when a message is sent through the send port and if it’s stopped, then the instance gets suspended. Once the send port is up, the message can be resumed and processed. Instead of going to the BizTalk admin console and checking it, BizTalk360 has the feature to terminate/resume the instances from the monitoring itself. We can also configure the time when we want to perform the action, either every time or during Error/Warning condition.
So, what happens when Action Required is ticked?
There may be scenarios wherein, the customer wants to monitor any suspended messages that by the end of the day are no longer relevant and should be terminated. So, in this case, BizTalk360 can automatically terminate the instances as per the alarm configuration. This can avoid the excess workload to the BizTalk user as he needs to go and manually run the query to find the instances and action it. We also have the option to bulk terminate the suspended instances altogether instead of doing one by one. There is also an archiving option and to download the instances.
Can non-super users terminate/resume suspended instances?
We have two kinds of users in BizTalk360, namely Super users and normal users. Super users enjoy the admin privileges and have access to all modules. They can define the authorization for the different level of users. They restrict the access permissions for the normal users. The normal users will have minimal access permissions.
The normal users can be anyone from the organization, may be supported engineers, other non-BizTalk group members who are just monitoring BizTalk servers. They would not be aware of the conditions of the service instances. Hence, they cannot decide upon the action to be performed on the suspended instances as it’s a sensitive area like terminating/resuming the instances. This may lead to security and auditing problems also. When normal users configure Data Monitoring and try to resume a suspended instance, they may get an exception message as follows-
System.Exception: User does not have enough rights to access the BizTalkQueryService(service) and ExecuteServiceInstanceOperation(operation).
The administrator alone can know the state of the instances and decide upon the action on them. For this reason, BizTalk360 has provided the restriction that only superusers can perform the resume/terminate action for them.
An in-depth analysis on the super user access to terminate instances:
Let’s have an in-depth look into this limitation and how it must be handled. The user logged into BizTalk360 may be a super user. But still, that user will not be able to perform any action on the service instances. Do you know why? Let’s move forward to know the reason.
When we install BizTalk360, we provide the service account credentials. This service account will be the user who is running the App Pool and monitoring service. The logged in user running the MSI to install BizTalk360 may be different from the service account. When the application is installed, the logged in user will be created as a superuser in BizTalk360 by default.
So, what happens to the service account if it’s different from the logged in user?
The service account running the IIS App pool and the monitoring service must be created as the “Super User” in BizTalk360. Only then this user can perform the resume/terminate actions on the service instances. Otherwise, the above exception will be thrown.
Since these are sensitive operations on the instances, only the super user/ administrator should be able to perform such tasks. Therefore, BizTalk360 has imposed this restriction that only when the service account is added as the super user, he can perform the operations on the suspended service instances.
Author: Praveena Jayanarayanan
I am working as Senior Support Engineer at BizTalk360. I always believe in team work leading to success because “We all cannot do everything or solve every issue. ‘It’s impossible’. However, if we each simply do our part, make our own contribution, regardless of how small we may think it is…. together it adds up and great things get accomplished.” View all posts by Praveena Jayanarayanan
