by Senthil Kumar Palanisamy | Nov 5, 2019 | BizTalk Community Blogs via Syndication
Introduction
The ability to query BizTalk Subscriptions is useful when you want to review how Orchestrations and Send Ports subscribe to messages etc. For example, when troubleshooting routing failures, you can review the existing subscriptions to see if any of them are improperly configured, thereby causing the routing failure. It is handy for the BizTalk users to view the publisher and subscriber when they troubleshoot or determine the use case.
Until now, BizTalk360 had all other queries (Message Box, Tracking Data and EDI), except Subscriptions. That feature is pending with respect to match the functionalities in BizTalk Admin Console. Based on customer feedback, we have implemented this feature in the upcoming release (9.0.3) of BizTalk360.
Type of Subscriptions
Subscriptions are created by service classes in BizTalk Server, which is listed in the “adm_ServiceClass” table in the BizTalk Server Management database. These services include the caching service; in-process and isolated messaging, hosted by the Endpoint Manager; and orchestrations/XLANG hosted by the XLANG subservice. Each of these service classes can create subscriptions and receive published messages.
Subscribers use subscription in BizTalk to define the properties or criteria of the messages in which they are interested. A Subscription in BizTalk is like a filter or criteria or a condition that dictates BizTalk which message needs to be routed to which component or entity in BizTalk. There can be more than one subscriber to the same message. If that happens, each subscriber will get its own copy of the message.
In BizTalk Server, there are two subscription types are available. Both types are described below
Activation Subscription
An activation subscription specifies that when a message that fulfills the subscription, it should activate or create a new instance of the subscriber when such a message is received.
Example: Activation subscriptions include send ports with filters or send ports that are bound to orchestrations, and orchestration’s receive shapes that have their Activate property set to true.
Instance Subscription
An instance subscription indicates that messages that fulfill the subscription should be routed to an already-running instance of the subscriber.
Example: Instance subscriptions are orchestrations instances with correlated receives and request/response-style receive ports waiting for a response from an external system.
Subscriptions queries in BizTalk360
The Subscription query feature can be found under Operations-> Data Access-> Message Box Queries. As like the other MessageBox queries (Suspended Service Instances), subscriptions are fetched from the BizTalk Message Box database(s) with filters and Max Matches similar as in the BizTalk Admin Console.
Clicking the Execute Query button will fetch the subscription list with both activation and instance subscriptions. BizTalk360 has the capability to export the results in excel format. Users can manage the filters with saved query functionality.
In the Subscription list view, there are three buttons are available to display the following
1. Subscription Details & Predicates
When navigating to the subscription details page, it will present detailed information about subscriptions and predicates. Subscription General tab will display Subscription Priority, Ordered Delivery, Creation Time, Subscription Type, etc.
Predicates: The Message Agent calls the bts_FindSubscriptions stored procedure held in the BizTalk Message Box to establish which subscriptions if any, match this message. This stored procedure queries the Subscription and Predicate SQL tables and joins them with the properties inserted for the batch of messages to identify potential subscribers.
Different Predicate SQL tables are used to match all the possible subscription expression combinations.
- EqualsPredicates
- ExistsPredicates
- GreaterThanPredicates
- GreaterThanOrEqualPredicates
- GreaterThanPredicates
- LessThanOrEqualPredicates
- LessThanPredicates
- NotEqualPredicates
2. Service Properties
Clicking the Service properties button will provide the service instance details, error information and Message details, Message content and Message context properties.
When subscribing, it is not possible to subscribe to any content of the actual messages entering BizTalk, but only to what information is stored in the Context of the message. The message metadata is called Context Properties; on receiving the message, the Adapter, Pipeline, and Map will possibly add information to the Context.
Context Properties can either be Promoted or Not promoted. Properties that are promoted can be used for subscribing to the message. However, Not promoted properties cannot be used for subscribing to the message.
3. Messages
When you click on the Message icon, it will populate the Messages query with Service Instance ID and Host Name related to the subscriptions.
Subscription processing is complex, so in short, you just need to remember that once a message arrives at the Message Agent, subscribers are evaluated, the message is inserted, and references are then added into the host instance queue, ready for processing by the subscriber hosted by the host instance.
User Access Policy
When users are having the permissions for Message Box Queries, they are also able to access the Subscriptions. To view the Messages and Content, the user should have permission to view the Message Content/Context in the user access policy.
When the user does not have the privilege to view Message Content/Context, they will be restricted to view Message Content/Context from the Subscriptions List.
Note: Subscriptions are only implemented in the BizTalk360 Operations section. Subscriptions are not implemented in Data Monitoring as it is not applicable for the feature.
Conclusion
We are constantly improving on the features based on feedback in the customer forum. BizTalk360 will continue to provide more useful features in every release. 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.
The post Querying BizTalk Subscriptions in BizTalk360 appeared first on BizTalk360.
by Lex Hegt | Oct 28, 2019 | BizTalk Community Blogs via Syndication
As part of our efforts to help you make the best of your investment in BizTalk360, we provide several services. Take for example our very responsive support team which helps you with your support requests, installation and implementation best practice sessions and quarterly client relationship calls. Typically, these ways to support you are carried out via remote conference calls. In most scenarios, we are very well able to help our customers via such calls. However, sometimes it is just more convenient to speak to somebody in person and with your BizTalk environment at hand. For such scenarios, we provide our customers with the opportunity to have an experienced BizTalk360 Product Consultant visit you at your premises.
In this blog post, we wanted to explain more on this topic of on-site BizTalk360 consultancy and why this could be beneficial for you, as a BizTalk360 user, too! We have been doing these consultancy visits for a couple of years now and our experience is positive – these sessions are of great value, not only for you, the customer but also for us!
To demonstrate the rationale and effectiveness of these sessions, we have provided a few examples:
BizTalk360 Upgrades & Newer Versions
We often see that our customers have not upgraded to the latest release of BizTalk360. That is totally fine, as we bring 3 to 4 releases per year and not each version will contain features that are relevant for you. We understand that and, in fact, that’s the reason why we test upgrade scenarios from multiple previous BizTalk360 versions before we release a new version.
One of the topics we discuss during consultancy visits is explaining the new features and improvements since the customer’s latest upgrade.
On multiple occasions, we arrived wanting to discuss a particular requirement from a customer, only to find out that the requirement can be met once the customer upgrades to a newer version! Similarly, we also see that a specific requirement can already be met in the currently installed version, but the customer was not yet aware of it. In the latter case, we can immediately dive into the details and start using the required feature.
Move your organization forward by maximizing your investment in BizTalk360
As you are probably aware, BizTalk360 is very rich in features. Since its inception in 2011, the product has constantly been matured and improved by bringing 3 to 4 releases a year. As a customer of the product, it is likely that you will take the implementation of the product one step at a time.
This is exactly how we can help our customers during consultancy visits. During face to face meetings with all the employees involved, we discuss the current status and any requirements. The product consultant will actively participate in the conversations, share his/her experiences and explain how specific requirements can be met with the product. After such meetings, we can immediately have a look at implementing any requirements which have been identified. By doing similar sessions with a certain frequency, you will be able to quickly move forward fulfilling requirements and, at the same time, make most of your investment in BizTalk360.
Potential agenda and outcome of a visit
To make the actual visit as effective as possible, we usually set up an agenda for the day, beforehand. This helps to structure the day and will also help in identifying any preparations, from either side, to be done.
An agenda of a previous on-site visit looked like below:
- The customer tells about the current situation at the customer’s side, including any issues (high level)
- The product consultant tells about the features which appeared in BizTalk360 since the latest installed version at the customer’s site. During the explanation, the customer identifies features they might be interested in
- A detailed look into any issues the customer faces, address these issues or plan how the issues will be solved
- Product consultant does several checks of the current configuration of BizTalk360 and where possible gives the advice to make the most of the product
- Upgrade to the latest or latest minus 1 release of BizTalk360, depending on the company policy
- Product consultant demonstrates the earlier identified features and configures them, based on the customer’s requirements
In the above case, the customer had the latest release of BizTalk360 installed and could immediately benefit from a new feature. Besides that, an improvement request has been identified which has been released in the next version of the product and installed during the next visit of the consultant.
These are just a couple of examples we have experienced. Let’s take a closer look at some more advantages of this service.
Face to face meeting with an experienced product consultant
Sometimes, face to face meetings is simply the best way to investigate and have a look at a specific requirement you might have. In your busy day to day activities, you might find it hard to allocate time to have a good look at your operations and monitoring requirements. Sitting down with a BizTalk360 product consultant is helpful as you will allocate some time to have a better look at your BizTalk operations and monitoring requirements and immediately optimize your current setup.
Focused on your requirements
The product consultant has many years of BizTalk and BizTalk360 experience. He/she can relate to your pain points and can share with you similar customer scenarios more often than not from the same industry. BizTalk360 has always prided itself on improving business processes. The main focus for the consultant is, therefore, helping you out in the best possible way when using the product, thereby helping you achieve the best possible return on investment.
We often see cases where customers have a particular business requirement with respect to their BizTalk administration unaware it could be solved with BizTalk360.
Any BizTalk360 or BizTalk Server topic can be discussed
When you have a BizTalk360 product consultant on-site, any BizTalk360 or BizTalk Server topic is on the table. The consultant has rich experience in both fields, so is happy to take your questions in these areas and share his/her views and experience.
For example, you might be in the process of installing our BizTalk360 product. The consultant will explain the different deployment models and, based on your requirements, give you a recommendation making you aware of any prerequisites. Moreover, if you are not sure how to implement the monitoring of your BizTalk environment, you can discuss and implement, based on your requirements and the recommendations of the consultant. Even if you have concerns about BizTalk administration in general, the consultant will be more than happy to provide you with best practices and his/her own experiences from the field. If required, the consultant can do a short health check of your BizTalk environment, which might give you the confidence that your BizTalk environments are in a healthy state.
Quick access to the BizTalk360 Dev team
Although the product consultant has rich experience with BizTalk360, it might still happen that there are areas where the consultant does not immediately have an answer. If there is no direct urgency to have the answer, the consultant will take your question(s) and get back to you once there is more clarity about the topic. However, if urgency is required and time is of the essence, the consultant will escalate the matter with the developers of BizTalk360.
Listening to & logging your improvement requests
BizTalk360 is a very mature and feature-rich product. Nevertheless, you might have a requirement that BizTalk360 cannot solve.
Having a BizTalk360 product consultant at hand is probably the best way to discuss requests for new or improved features.
When such improvements or new features are discussed, there will be an open conversation about the improvements you have in mind and if the request is considered valuable, it will be logged in our internal systems.
New feature requests generally take the following course: by listening to other customers & partners on a regular basis we tend to hear the same or similar requests. Naturally, we want to bring features that are useful to as many customers as possible. Deciding which requests will be taken for development is carried out, amongst others, on a voting system. The more votes a feature request receives, the more likely it will be that we will take it up for development.
Keep up to date with the latest product developments
Keeping up to date with product development can be tricky especially if you are always busy with important daily activities. It is our responsibility to make you aware of new additions to BizTalk360. As we bring new releases so frequently, we notice that users of BizTalk360 have not always upgraded to the latest version. During the meeting, the consultant will give you an overview of the features which have been added since the version you are using was installed. It might very well be that it contains features of interest to you!
Summary
We have agreements with multiple customers who we serve with quarterly or half-yearly visits. Normally, we receive positive feedback on the usefulness of the consultancy visits. We hope that, based on the above-mentioned arguments, you will understand that such visits can be useful for you too. In most cases, a full day will be allocated for the consultancy visit, but any duration from half a day to multiple days can be considered.
If you would like to discuss the possibility of an on-site visit, feel free to contact us at [email protected].
Besides these product consultancy visits, we can also provide BizTalk360 training and BizTalk Server Administrator or Developer training.
The post On-site BizTalk360 Consultancy appeared first on BizTalk360.
by Sowmiya Subramanian | Oct 22, 2019 | BizTalk Community Blogs via Syndication
From the upcoming BizTalk360 version 9.0 phase 3 on, we extend our support to monitor SQL Server clusters. By configuring the SQL Server Network Name for monitoring, BizTalk360 will start monitoring the current active node and in case of failover scenario, BizTalk360 will automatically take the active server for monitoring.
It’s important to make sure the physical infrastructure of your SQL servers like disks, CPU, memory, etc., are healthy for proper functioning. BizTalk360 made this simpler by having the SQL Server Monitoring capability.
BizTalk360 will alert to the user when the configured disk space, CPU, memory usage exceeds the set percentage.
Challenge
In existing BizTalk SQL Monitoring, we came across a few challenges on monitoring the clustered SQL Server
- The user could not find the active node while monitoring the clustered SQL Server.
- When the Failover happens, the disk monitoring could not identify the disks of the failover node and an error message was displayed as below.
Scenario 1 (Active/Active): As the same as the previous version of BizTalk360, you can monitor the Clustered SQL Server (Active/Active) or a non-clustered SQL Server, by simply adding the SQL Server physical node in the “Add SQL Server For Monitoring”.
Scenario 2 (Active/Passive): In BizTalk360, you can monitor the Clustered SQL Server (Active/Passive), by adding the common “SQL Server Network Name” for the physical node into the “Add SQL Server For Monitoring”. It will automatically pick up the active server node for monitoring and then it will start monitoring the active node. If a Failover happens, then it will automatically switch to the failover node (Active Node).
Let’s take a quick look at how you can monitor Non-Clustered/Clustered SQL Server (Active/Passive) using BizTalk360.
Non-Clustered SQL Server
The BizTalk server database will be pointed to one SQL server Instance as below.
Failover Clustered SQL Server
Windows Failover Clustering is a high-availability option which is designed to increase the uptime of SQL Server instances. A SQL Server cluster includes two or more physical servers, called nodes. One is identified as the active node, on which a SQL Server instance is running the production workload, and the other is a passive node, on which SQL Server is installed but not processing the workload. If the SQL Server instance on the active node fails, the passive node becomes the active node and begins to run the SQL Server production workload with some minimal failover downtime.
The SQL Server Network Name is used to identify a failover cluster (active node) on the network. This was known as the virtual SQL Server name.
The virtual SQL Server will automatically connect to the currently active node. You can find the SQL Server Network Name as below in the Failover Manager.
Prerequisites or Permissions required to monitor the Non-Clustered/Clustered SQL Server in BizTalk360
- MSDTC should be enabled in the BizTalk360 server and SQL Server. In the case of Clustered SQL Server, MSDTC should be enabled in all the SQL Servers which belong to the cluster. Follow the link to enable the MDTC.
- If BizTalk360 is installed using the service account, then the service account should get added to the Administrator group in the SQL Server node. In the case of a Clustered SQL Server, the service account should get added to both physical SQL Server Nodes(active & passive node).
How the (Non-Clustered) SQL Server is monitored in BizTalk360
Let’s have a detailed look at how you can monitor a non-clustered SQL server using BizTalk360.
By adding the Physical SQL server name for Monitoring, you can monitor the disks, CPU, memory, etc. You can add the SQL Server name under BizTalk360->Settings ->Monitoring and Notification ->Add SQL Server for monitoring.
Note: For non-clustered SQL servers you must add the physical SQL Server name for monitoring.
Once the above configuration is done, the added SQL servers will get available for monitoring as below.
The configured server will be listed for monitoring under BizTalk360->Monitoring ->Manage Mapping->SQL Servers. By clicking on the Server name you can configure Disks, System Resources (CPU, memory), Event Logs and NT Services of the specific SQL server for monitoring.
Disk Monitoring
A click on the Disks tab, will automatically pick up all the disks in the configured SQL server and show a graphical view of the disk properties with total and available disk space. To monitor the disk, you can simply set the appropriate warning and error threshold level for each disk in percentage (%), as shown below. For more detailed information, follow the article link.
Note: The system reserved and the unpartitioned disk will not be available for monitoring.
System Resource Monitoring
Click on the System resource tab to monitor the CPU usage and Memory consumption. Next, configure the appropriate warning and error thresholds for CPU and memory. The system will start alerting if the system condition hits the configured warning/error level for the persisted duration, which you can see below. For more detailed information about the CPU and Memory, follow the article link.
By default, warning and error thresholds for CPU and memory will be in 30% and 10%, but you are free to reconfigure these thresholds depending on your own requirements
Event Log Monitoring
You can monitor for various event log entry conditions using BizTalk360. You can have multiple combinations of event log monitoring, for example, certain sources, certain event ids, certain text in the message, with configured threshold conditions as below.
Note that you can also set up Event Log monitoring in the Data Monitoring section. Setting it up there helps in correlating event log entries across multiple servers. For more detailed information about the Event Log monitoring, follow the article link.
NT Service Monitoring
You may want to keep an eye on certain NT services that are running in SQL Server. BizTalk360 gives you the opportunity to automatically monitor the NT services by just setting the expected state. BizTalk360 will alert you when the configured expected state is not equal to the current state. For more detailed information about the NT Services monitoring, follow the article link.
How a SQL Clustered node is monitored in BizTalk360
Now, let us have a quick look at how we can use BizTalk360 to monitor a clustered SQL server.
Configuring a Cluster SQL Server for monitoring
If you want to monitor a Clustered SQL Server, all you need to do is, specify the name of the Virtual SQL Server (SQL Server Network Name). When you connect to SQL Server using this SQL Server Network Name, BizTalk360 will automatically connect to the currently active node.
Note: It is is enough to add just the SQL Server Network Name for monitoring the SQL Cluster, it is not required to add the actual physical SQL cluster nodes.
Once the above configuration is done, then the added clustered SQL Server Name will get listed for monitoring as shown below.
It will automatically pick the active node and the state of the (clustered) server.
Disk Monitoring
In clustered SQL Server monitoring, it will show the currently active monitoring Node, and also it will automatically pick up all the disks in the currently active node.
By Default, warning and error thresholds for each disk will be in 20% and 10%. You can also change the warning and error percentage as per your need and save it. Then, the currently active node will get monitored by the BizTalk360. If the disk space exceeds the set percentage, BizTalk360 will send the alert to the respective user.
If the “Failover” happens for the monitored disk, then the configured disk will automatically switch to the active server(Failover server).
Consider a scenario if Node 1 has disk A and disk B which are configured for monitoring (error and warning condition as 50 %). Let say, Node 1 went down, then BizTalk360 will automatically pick up the currently active node 2 for monitoring. But what happens if node 2 has Disk B and Disk C?
In the above scenario, the default monitoring configuration i.e error and warning condition 20% is set to the Disk C. Disk A, which is available in node 1 but not in node 2 will be moved to the orphaned state.
As in the above screenshot, the “STR-Disk1 (F:)” disk is newly added after failover with the default warning and error conditions. The other two disks are “STR-Disk2 (E:)”, which is a shared volume, and the (C:) drive is a common volume, which is also configured with the existing warning and error percentages.
System Resource Monitoring
As the same as disk monitoring, you can set up appropriate warning and error thresholds for CPU and memory as per your business needs. For a Clustered SQL Server, it will show the current active monitoring Node. It will automatically pick up the CPU usage and the memory for the currently active node.
In the case of a Failover, the CPU and the memory will automatically get updated for the active node (failover node) with the existing warning and error conditions.
Event Log Monitoring
In a Clustered SQL Server, BizTalk360 monitors the Event Log based on the active node. You can have multiple combinations of event log monitoring, for example, certain sources, certain event ids, certain text in the message, with configured threshold conditions.
Once after Failover, then BizTalk360 automatically starts monitoring the existing event log conditions based on the currently active node (Failover node).
NT Service Monitoring
In a Clustered SQL Server, current monitoring will be based on the active server. It will pick up the NT services from the active server for monitoring as you can below.
Once after Failover, the configured NT service will automatically switch to the failover node and start monitoring.
Conclusion
Our objective with the monitoring aspect of BizTalk360 is to make it simple to configure, manage and use it on a day to day basis. The above SQL Server Monitoring will do that, and it will also do the automatic way of monitoring when a failover happens. There is plenty to consider when planning on clustering SQL Server, but we trust that we came up with the best solution. For any suggestion or feedback, post it in the feedback portal.
The post SQL Server Monitoring in BizTalk360 appeared first on BizTalk360.
by Raja Sreenivasan | Oct 15, 2019 | BizTalk Community Blogs via Syndication
In any BizTalk environment, it is important to keep track of database growth and execute the data purging policies whenever necessary. When the database size grows, the SQL server needs more memory and CPU to read data from the tables, which slows down the database operation. Besides that, there is also the risk that, due to the growing database(s), you are running out of disk space. Database Administrators spend a lot of their time dealing with the problem of database processes consuming too much disk space. So, it’s very important to monitor the database size to ensure the database is not seizing the memory and CPU for smooth BizTalk server operation.
The ability of Database Size Monitoring is a feature request we picked up from our feedback portal. This feature will be available for production use from BizTalk360 version 9.0 phase 3 on.
What can be monitored with Database Size Monitoring?
With Database Size Monitoring, you can monitor the data file and log file sizes of below BizTalk Server and BizTalk360 databases, by simply configuring the error and warning threshold conditions for the data and log file sizes.
- BizTalkDTADb
- BizTalkMgmtDb
- BizTalkMsgBoxDb
- BizTalkRuleEngineDb
- BAM databases (BAMPrimaryImport, BAMAlertsApplication, BAMArchive, BAMStarSchema)
- SSODB
- BizTalk360
For example, if the size of the BizTalkDTADb is greater than a configured threshold value, then you will get notified.
Scenario
OutOfMemoryException in BizTalkDTADb
BizTalkDTADb contains the health monitoring data tracked by the BizTalk Server tracking engine. The size of the database can grow relatively quickly depending on the load of your server, which in turn results in OutOfMemory Exceptions.
This scenario can be overcome by proactively knowing the size of the database and acting against the exponential growth of the database by configuring the threshold limit in database size monitoring.
Monitor BizTalk360 database Growth
There might be a situation where the BizTalk360 database grows due to the amount and size of event log data and performance counter data. The BizTalk360 purging policy will take care of the data growth, but it is also important to monitor the size regularly to ensure BizTalk360 is working seamlessly.
Configuring Database for monitoring size
We wanted to simplify the process of configuring database size monitoring. To achieve this, we list all the BizTalk and BizTalk360 related databases. You can start monitoring by specifying the threshold details from the SQL instance.
To configure a database for monitoring, navigate to Monitoring->BizTalk environment-> Database Size, which lists all the BizTalk and bizTalk360 databases under the respective SQL Instances. Click on the config gear icon, as shown in the above image, to configure the threshold values to monitor the size of the database. Based on the threshold configuration, the user will get notified if there is any threshold violation occurring.
The available Threshold types, logical condition, and unit prefixes are:
|
Threshold Type
|
Logical Condition
|
Unit Prefixes
|
|
Data File Size
Data File Used Space
Data File Available Space
Log File Size
Log File Used Space
Log File Available Space
|
Equals
Not-Equals
Greater-than
Greater-than-or-Equal
Less-than
Less-than-or-Equals
|
Bytes
Kilo-Bytes (KB)
Mega-Bytes (MB)
GigaBytes (GB)
|
Following are the threshold types on which you can monitor a database:
|
Threshold Type
|
Explanation
|
|
Data File Size
|
This threshold type represents the reserved space for the data file.
For e.g.:
Warn Me if Data File Size is Greater-than 200 GB
Error if Data File Size is Greater-than 250 GB
|
|
Data File Used Space
|
This threshold type represents the size used by the data file.
For e.g.:
Warn Me if Data file Used Space not-equals 250 GB
Error if Data file Used Space not-equals 250 GB
|
|
Data File Available Space
|
This threshold type represents the available space for the data file
For e.g.:
Warn Me if Data file Available space less-than-or-equals 99 GB
Error if Data file Available space less-than-or-equals 99 GB
|
|
Log File Size
|
This threshold type represents the size reserved for the transaction log file.
For e.g.:
Warn Me if Log File Size is Greater-than 200 GB
Error if Log File Size is Greater-than 200GB
|
|
Log File Used Space
|
This threshold type represents the space used by the log file.
For e.g.:
Warn Me if Log File Used Space not-equals 250 GB
Error if Log File Used Space not-equals 250 GB
|
|
Log File Available Space
|
This threshold type represents the available space for the log file.
For e.g.:
Warn Me if Log File Available Space Greater-than 250 GB
Error if Log File Available Space Greater-than 250 GB
|
Once the threshold values are configured and saved, the monitoring conditions will be evaluated, and the status of the database size will be displayed in the grid.
The Monitoring Dashboard and BizTalk Group Dashboard display the overall status of the alarm including the Database size shown in the picture below.
The user will get notified through mail or notification channel when any threshold violation happens.
Quick Alarm
You can also configure database size for monitoring simply by configuring Quick alarm. In this case, an alarm will be created and all the BizTalk and BizTalk360 databases will get configured for database size monitoring with default threshold conditions.
Conclusion
Considering the feedback provided by our customers, via the feedback portal, BizTalk360 will continue to provide more useful features every single release. In the upcoming release v9.0 phase 3, the ability to monitor Database Sizes is only one of the features we bring. If you have any suggestions for a =n upcoming version, please write to us at [email protected].
The post Database Size Monitoring appeared first on BizTalk360.
by Yuvaranjani Kalichamy | Oct 15, 2019 | BizTalk Community Blogs via Syndication
The Analytics Reporting feature is one of the main features which offers out of the box capabilities. It allows users to create schedules and generate PDF documents based on critical performance metrics at specific time periods. In previous versions, we supported only default pre-configured widgets in the Analytics reporting section. From v9.0.2 we provided an option to configure the Secure SQL Queries widgets in the Reporting section.
In the upcoming version v9.0.3, we extended this to support Analytics custom widgets, with this the user can configure the performance metrics as a widget and get them as a report.
Analytics Custom Widgets
In the Analytics dashboard, we have an option to configure performance widgets to the dashboard. Once you enabled any of the types (BizTalk, SQL, IIS, and Windows) in any selected environment, the BizTalk360 Analytics service will start collecting the performance metrics. These performance metrics can be mapped to the custom widget.
Some of our customers requested us to bring the ability to manage analytics custom widgets in the Reporting section. Considering the business value, for BizTalk360 v9.0.3, we are bringing an option to manage analytics custom widgets to the Analytics Reporting, as well as new user experience of the Reporting section.
Analytics Custom Widgets in Reporting
Let’s take a few scenarios to understand what we can achieve with the custom widgets.
Get the Host Suspended Messages Metrics
Using Analytics custom widget, you can determine the Suspended messages metrics and also the number of instances, per host instances, in a graphical representation. For this, you need to enable the Performance counter Server->BizTalk->BizTalk: Message Box: Host Counters. Once you enabled the metrics and configured to the widget, it will fetch the current metrics values and represent them in a graphical way.
Comparing the performance of two BizTalk servers
Consider another scenario where you would like to compare the performance of two BizTalk servers and find which server consumes more memory and CPU. This can be achieved by configuring servers and select the appropriate metrics for the widgets.
BizTalk Host Performance By CPU
By enabling the Server->BizTalk->Process -> % Process time, in Analytics Configuration under the Settings section, you can see the Host Performance by CPU, by using an Analytics custom widget. Once you enabled the metrics and configured the widget, the Analytics service will collect the counters for the selected metrics and represent it in a graphical way.
Below are some of the BizTalk performance metrics which you can configure as an analytics custom widget and get it as a report.
BizTalk and SQL Server Health
- CPU Usage
- Memory Usage
- Disk Free Space
- Average Disk Queue Length
- Network Performance
- IIS Request Per Sec
- IIS Worker Process: CPU Usage
- IIS Worker Process: Memory Usage
Host Performance
- Host Instance performance by CPU
- Host Instance Performance by Memory
- CPU Consuming Host Instances
- Top 10 Memory Consuming Host Instances
BizTalk Messaging Performance
- BizTalk Host Performance
- Documents Receive/Second
- Documents Processed/Second
- Inbound Latency (Sec)
- Outbound Latency (Sec)
- Outbound Adapter Latency (Sec)
- Request -Response Latency
Throttling Performance
- Message delivery Throttling State
- Message Publishing Throttling State
- Message Delivery Outgoing Rate
- Message Delivery Incoming Rate
- Active Instance Count
- Database Size
- Database Session
- Database Session Threshold
- In-Process message Count
- In-Process Message Count threshold
- Message publishing incoming Rate
- Message Publishing Outgoing Rate
Reports
In order to improve the user experience in the Analytics Reporting section, we have modified the User Interface for that section.
Previously, when we create a new report, the report would be added under the Reporting group on the left side navigation bar. We felt that it would be a bit confusing to the customer like where to start with. So, we removed the navigations and introduced a new page for Manage Reports.
In the Analytics Reporting Section, we now have 3 sub-menus:
- Reporting Schedules
- Manage Reports
- Report Notification History
Reporting Schedules
As a first step, you need to create a schedule to get a periodic report of the configured widgets. To create a schedule, refer to this article.
Manage Reports
Once after creating a schedule, the next step is to create a report and add widgets to the report. Once you get into the Manage Reports section, you will be able to see the Sample report in the grid. You can’t do any operations with the ‘Sample Report’ except viewing the sample widgets.
By clicking Configure reports icon, you can see the Sample widgets in the Report.
In the Manage Reports section, you can manage (Add/Edit/Delete/Clone) the reports.
To create a new report, click on the ‘Add New Report’, the blade will open and then you can provide the name of the report and chose the schedule (how often do you want to receive the reported).
Once after you have saved the configuration, the new report will be generated and added to the grid. The Sample Report will be removed from the grid.
To manage the widgets in the report, click on the Configure Reports icon.
There you can see the options to add widgets(custom/basic). Refer to the Manage Widgets article to know more about how to manage the widgets in the Report.
Configure Analytics Custom Widgets to the Report
Click on ‘Add Widget’, this will open a blade. At the bottom of the blade you can see the ‘Create Analytics Custom widget’ option.
Click ‘Create Analytics Custom Widget’, it opens a blade where you can see the metrics which all are enabled (in Tracking data collection in the Settings section).
You can map whatever performance metrics you want to get as a PDF in your email box.
For instance, I will configure the metrics, as mentioned above, that I want to know how much memory and CPU my BizTalk Server consumes.
Live Data and Historical Data
Once the report has been generated and sent to the recipient’s email, the generated report will be stored and can be viewed by choosing the Date Time in the filter.
You can see the actual data sent as an attachment to your email address.
Using Live Data, you can see the actual metrics.
Report Notification History
Using Report Notification History, you can see whether the mail has been sent to the recipient’s Email address or not. This will be represented in a success and error icon; A green tick icon is for the successful message and a red cross icon for the failure of sent. It will show only the top 50 records.
Conclusion
I hope this blog has given you overall information about how to start with Analytics Reporting, the new user interface and how to configure the Analytics custom widget to the Reports.
For more information about how these widgets work, check our Documentation Portal.
The post Analytics Custom Widgets in Reporting appeared first on BizTalk360.
by Saranya Ramakrishnan | Oct 3, 2019 | BizTalk Community Blogs via Syndication
We are super excited to share the list of features that are planned for our upcoming BizTalk360 release 9.0 Phase 3. We always aim to constantly improve our product in every release, based on customer feedback and their business needs. Generally, we release a new version each quarter. In August 2019, we released Version 9.0 Phase 2. Now Version 9.0 Phase 3 is planned for late November and our team is energetically working towards it.
Reporting for Analytics custom widget
The BizTalk360 Reporting feature offers out of the box capabilities that allow users to create schedules and generate PDF documents of critical performance metrics at specific time periods.
From v9.0 phase 3 on, you can configure analytics custom widgets with the performance metrics of your BizTalk environment such as Messaging Performance, Message Transmission failure rate, Server performance, etc . and get that as a report, based on the schedule configuration.
For example, you can get a report by the end of the day with the number of messages processed for a particular schema or a particular send port.
Database Size Monitoring
This feature will be helpful for BizTalk administrators who frequently check the database growth to ensure the health of the BizTalk databases.
Some of the BizTalk databases can grow extremely big; it’s not uncommon to have over 1 million records in certain tables (ex: MessageInOutEvents table in Tracking Database). As the database size grows, the SQL server will need more memory and CPU to read data from the tables, and when the size of each table increases, it slows down the DB operations and affects the BizTalk operation.
With Database Size Monitoring, you can monitor the database and log file size of below BizTalk and BizTalk360 databases, by simply configuring the error and warning threshold values for the database and log file sizes.
- BizTalkDTADb
- BizTalkMgmtDb
- BizTalkMsgBoxDb
- BizTalkRuleEngineDb
- BAM Db’s
- SSODB
- BizTalk360
For example, If the size of the BizTalkDTADb is greater than a threshold value configured, then you will get notified.
Configurable polling interval for monitoring
The BizTalk360 Monitoring Service usually runs every 60 seconds and checks for the status of the artifacts which are mapped for monitoring, which include Application artifacts, File/FTP/SFTP, Queues, web endpoints, etc. We got requests from a few of our customers that they have configured multiple endpoints for monitoring and the BizTalk360 monitoring service calls the endpoint for every 60 secs to check the status, but they don’t want to call the endpoints frequently i.e. every 60 secs. So, to improve this, we are providing an option to configure the polling interval for monitoring; depending on the configurated time, only then the monitoring service calls the endpoint.
SQL Server Cluster Monitoring
In BizTalk360, we have a BizTalk and SQL Server Monitoring which allows you to monitor the Disks, System Resources, Event Log, and NT Services. From this version on, we extend our support to monitor the SQL Server cluster. By configuring the SQL Server network name for monitoring, BizTalk360 will start monitoring the current active node and in case of failover scenario, BizTalk360 will automatically take the active server for monitoring.
Support SQL Authentication SQL Query
The standard BizTalk Admin Console does not come with any capabilities related to accessing SQL Server data. This leaves the support people to rely on external SQL tools like SQL Server Management Studio (SSMS). Tools like SSMS are designed for DBA’s and Developers, and it’s not particularly friendly when it comes to pure support and management; a level of technical expertise is required to be able to use SSMS. We understood the practical challenges of not having an integrated SQL data access tool along with the BizTalk Administration and the challenges it exposes.
That’s why we have already built the “Secure SQL Queries” feature in BizTalk360.
Using Database Query monitoring, you can set up thresholds that are limited to database scalar values. For every BizTalk360 Monitoring cycle, the monitoring service will validate the results of the SQL query against the configured threshold values. If any violation happens, it will trigger a notification to the configured emails in the alarms.
However, since BizTalk360 does not support SQL authentication, currently you cannot access Azure databases from Secure SQL query and in Database Query monitoring. From this version on, the product supports SQL authentication for database access. You can query your Azure databases from the BizTalk360 Database query monitoring and Secure SQL Query sections.
Logic Apps Improvements
From this version on, you can provide access restrictions for logic apps. Based on the role, you can define which user can manage (enable, disable, delete, trigger) the Logic Apps.
Additional details such as Version, Last Run Time and Last Run Status of the logic app will get listed in the grid.
Copy Alarm along with artifact mapping
The first step in monitoring by using BizTalk360 is to create Alarms. Alarms in BizTalk360 act like a package to associate things together. We already have an option to copy the alarm which will copy only the alarm configuration. Now we are extending this to copy the alarm along with the artifact mapping configuration.
Alarm and Monitoring Dashboard Improvements
Below are some of the improvements, we have planned for this release in the Monitoring section:
- Indication of alarm status (Enabled/Disabled)
- Last Execution Time of the alarm
- Number of Alerts Notified (2/3)
- Indication whether Auto Correct is enabled or not
- The artifacts from the collapsed view will be made clickable to route to the respective configuration
Performance data collection improvement for DTA
We already optimized performance data collection in the last release. in this release, we are improving on DTA performance data collection. With this, we allow users to choose the relevant DTA metrics, which will reduce the number of calls to the DTA database.
Conclusion
Considering the feedback from our customers, BizTalk360 will continue to provide more useful features on every release.
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.
The post What is coming in BizTalk360 Version 9.0 Phase 3? appeared first on BizTalk360.
by Lattetapriyanka Vishu | Sep 19, 2019 | BizTalk Community Blogs via Syndication
For those who spend most of their time working with Service Instance messages, ESB exceptions and Event Log entries, it might be good to know that BizTalk360 can ease you with the feature “Knowledge Base”. The Knowledge Base acts as a repository of articles that contain solutions to the common problems which are faced by users while working/supporting the BizTalk environment. One of the great advantages of the Knowledge Base is that you can store the information related to the exact error condition and share that with other users for reference.
In BizTalk360 you can create and refer KB articles for the following sections:
- Service Instances
- Event Log entries
- ESB Exceptions
- Throttling Data
Importance of having KB article
A knowledge-base is the one thing that can be instantly useful for both your support agents and customers. Support agents can refer to the knowledge base and answer the customer queries quickly, instead of spending time asking someone for guidance or trying multiple solutions. Customers can search for answers to their questions in the knowledge base, instead of contacting Support and waiting for a reply.
By having KB articles, it is very handy to document the solution to known issues, and most importantly it is fully customizable and easy to document. It’s a simple and intuitive user interface, through which the users will enjoy using this repository.
Let us consider a scenario that will help us to understand the importance of KB Articles a bit more. In an organization, not every user will be available on time for providing guidance. Some may be remote users, for whom the Knowledge Base will act as a self-service hub that will hold the referral documents or solutions.
Say for instance, while handling support, some issue has been raised and solved for a customer. After a while, another user has raised a support ticket for the same issue. In case the solution to the issue has been documented, this kind of situation can be handled much more effectively and less- time-consuming.
BizTalk related KB articles
When an issue occurs in BizTalk which ends up as a Suspended instance, it will hold an error code. By using this as a key point, you can document the solution for each issue. If needed, you can even use criteria like BizTalk application, Service name and (parts of) the Error Description to associate an article to an issue. Similarly, BizTalk360 will also let you document issues related to Event Log entries, Throttling data, and ESB exceptions.
Scenario 1
Let me share with you a support case which we have handled recently. In a firm, we often used to upgrade our setup. While setting up the environment, we may face similar issues that occur frequently. Whenever any configuration related issue occurs it will be logged in the event viewer, along with the Description and Event Id. Say for instance, if the BizTalk server throws an “MSDTC” or “ENTSSO” exception while performing any operation. Using that Event Id, you can create a BizTalk360 KB article, through which you are providing visibility over the issue, which can be referred to in future cases.
Note: In the case of Event Log entries, BizTalk360 associates KB articles based on the Event ID. However, as the Event ID might not be enough to uniquely associate a KB article to a particular Event Log entry, you can also use properties like Event Log, Event Log Source, and few other properties. You can even take partial text from the actual Event Log entry description!
Scenario 2
Similarly, BizTalk Server continually monitors for throttling conditions, calculates the severity of the throttling condition, and applies host throttling progressively depending on the calculated severity. To handle this, BizTalk360 contains an Analytics (Windows NT) service specifically to collect the throttling performance counter data from the various BizTalk servers in the environment. Throttling activity of a host instance is being monitored and at a point in time, the monitoring service plots the throttling state against, for example, the ‘System Memory’. Once the reason and a mitigation strategy are identified for the throttling, as a best practice, the information can be documented in a KB article.
Scenario 3
Service instances can fail due to some error and BizTalk attaches the error with an error code and an error description. In the same way, other service instances can fail for the same reason as the previous one. I.e, if there is a suspended message, you can find the error code for the same. The error code 0xC0C01B4e represents routing failure messages.
With the BizTalk360 knowledge base, you can document the solution by referring to amongst others the error code and the error description. Once the Knowledge Base article is defined for one error code, event log, etc., it will be visible across all environments. In BizTalk360, whenever the issue occurs with the documented error code etc., then the user can see the KB article icon. By clicking on the properties (or eye icon), you can find the document under the KB article tab with the reason/solution you have created.
When creating multiple articles for the same error code, select the appropriate tags (Environment, Service Class, Application Name, Error Text, Host Name, Service Status, Service Name) for the error code. The tags will play the differentiator role to display the appropriate KB article.
Note: BizTalk360 allows super users to create KB articles specific to one environment. All the users in that environment will be able to see the articles.
Best practice of using the KB article
- Whenever an issue occurs and became resolved, make a practice to always document the solution in a KB article.
- Keep the Titles of the KB articles as straight forward as possible, the simpler, the more is it understandable. Ensure it is to the point and include the most important keywords.
- Formatting solution articles is extremely important. Clearly, differentiate your titles and subtitles. Split different sections using a horizontal line. Bold the action items in each step so it’s easy for the user to skim. Provide the step by step details of the solution.
- Refer to the link related to the article.
- Be descriptive with relevant points.
- Tag the article to have clear usage and better reference.
With the above-mentioned tips, you can make your KB articles a well understandable document.
Conclusion
With the Knowledge Base feature, we provide visibility over resolved issues and the same can be brought into the notice to all the users. With this feature, we can improve the visibility of issues and reduce time consumption in solving the issues which will lead to higher productivity.
The post An Effective Way of Using KB Articles in BizTalk360 appeared first on BizTalk360.
by Praveena Jayanarayanan | Sep 17, 2019 | BizTalk Community Blogs via Syndication
BizTalk360 is the one-stop monitoring solution for your BizTalk environment. Being a web application, security plays an important role in the application. Any organization installing the product would be considering the security aspects of the application. With BizTalk360 we provide high-level authorization capabilities through the User Access Policy and Governance/Audit capabilities. The level of access can be customized for any BizTalk360 user. The activities performed by the users within BizTalk360 are audited and listed in the Audit History section.
Security compliance is a legal concern for organizations in many industries today. In demonstrating security compliance, enterprises are better able to define and achieve specific IT security goals, as well as mitigating the threat of network attacks through processes like vulnerability management. The security requirements and standards may vary for different organizations.
Being a web application, BizTalk360 is also expected to comply with the security standards for the organization’s demands. In this blog, I would like to give some details on some of the security compliances that are accommodated in BizTalk360. Let’s get into the details of the security compliances in BizTalk360.
FIPS Security
The FIPS standards specify the best practices and security requirements for implementing crypto algorithms, encryption schemes, handling important data and working with various operating systems and hardware, whenever cryptographic-based security systems must be used to protect sensitive, valuable data. FIPS defines specific methods for encryption and specific methods for generating encryption keys that can be used.
BizTalk360 also uses encryption/decryption algorithms for security.
There are some modules that require information like passwords, application security keys (for adding Azure subscriptions in BizTalk360 UI) to be provided in the UI. This kind of data will be encrypted and stored in the database. The areas in BizTalk360 where encryption is used include:
- License activation
- Adding Azure Subscription
- Placeholders in custom widgets
- Notification channel configurations
- Accessing endpoints for monitoring
FIPS Compliance is mandatory for US government computers, which means that all computers used for government work must be FIPS compliant. Application developers who need to test their software for government computers must ensure that they perform their testing on FIPS compliant computers.
Often, the support team gets support tickets from customers through various channels like email, feedback widget, and the support portal. One such ticket from a customer was that there was an error message in BizTalk360 UI as seen below.
As per the Government rules, the organization had to turn on the FIPS encryption algorithm in all the servers. Once the encryption was turned on, the above error started displaying BizTalk360. This is due to the reason that FIPS supported encryption methods were not available since it was AES standard compatible. The development team checked for all the areas where the encryption algorithms were implemented and modified them to support the FIPS standard.
This is considered as one of the important security aspects because if the compliance is not met, it would have been difficult for the customer to continue to monitor their BizTalk environment using BizTalk360.
TLS latest version Support
Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.
The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. There are different versions of TLS available. BizTalk360 was supporting TLS 1.0 until BizTalk360 v8.8. With the latest version of TLS, it is important that BizTalk360 also supports this latest version. This must be done at the installer level; when TLS 1.2 was not yet supported, the BizTalk360 installer would fail while trying to connect to the SQL database. This has been modified to support TLS 1.2.
We are happy to inform you that, from v8.9 onwards, BizTalk360 supports TLS 1.2.
Other security considerations
From a security perspective, Databases are considered as important for any organization. As access permissions to the database are restricted for safety reasons, DBAs are not ready to give all rights to all users. They would only provide the absolute minimum of required permissions on the database. The same principle is used in BizTalk360 as well. Under the Secure SQL queries option, the user can create/execute queries.
The following are the advantages of Secure SQL queries functionality in BizTalk360:
- Single management tool for users to execute the queries. No need for SQL Server Management Studio
- Central Query Repository – maintaining queries is much easier
- The end-users need not have direct access to the SQL database. The queries will be executed in the context of the BizTalk360 service account, therefore only the service account requires access to SQL Server
- Queries can be executed against any SQL instance/database which can be accessed by the BizTalk360 service account
But how is the security imposed here? Well, in BizTalk360, the Super User can choose the required permissions for the user in the query execution and provide the necessary access permission under the User Access Policy. Based on these permissions, the user can perform the query execution when he logins to BizTalk360.
There might be some organizations that would run a security scan report to find any security issues that may come with BizTalk360. One such report was generated by one of our customers and they shared where the security risks were, classified as high, medium and low risks.
Some of the risks that were identified were SQL injection, database error patterns, and directory listing. Due to the SQL server injection, there might be the possibility to view, modify or delete database entries and tables. For the directory listing enabled, it is possible to view and download the contents of certain web application virtual directories, which might contain restricted files. The test result seems to indicate a vulnerability because the response contains SQL Server errors. This suggests that the test managed to penetrate the application and reach the SQL query itself, by injecting hazardous characters.
Being an on-premise application, the directory browsing should not affect the security because the application is installed on-premise and the database is also local and specific to the organization. The users who will have access to BizTalk360 will be Active Directory users of the specified domain. Also, BizTalk360 can be accessed in another domain only when there is a proper trust established between the domains and the users are added to the security group in the domain. The response contains the content of a directory (directory listing). This indicates that the server allows the listing of directories, which is not usually recommended.
Hence, disabling the directory browsing for the BizTalk360 site in IIS will not affect the application in any way. Once that was disabled, the risk was mitigated. For the SQL injection, the query to retrieve the tracking database performance counters and BizTalk Server performance counters were modified. These types of queries led to vulnerability because the response contained SQL Server errors. This suggests that the test managed to penetrate the application and reach the SQL query itself, by injecting hazardous characters. This was mitigated by modifying those queries accordingly.
Conclusion
With the security aspects in consideration and as per the feedback from the customers, we always enhance the features of BizTalk360. Considering the priority of the reported issue, our team will always act immediately, and the fix would be provided. This way we make sure that the product is secure and meets all the security standards so that there will not be any hindrance in monitoring your BizTalk environment using BizTalk360.
Happy monitoring with BizTalk360!
The post Security Compliances in BizTalk360 appeared first on BizTalk360.
by Senthil Kumar Palanisamy | Sep 12, 2019 | BizTalk Community Blogs via Syndication
Introduction
Managing the infrastructure of BizTalk/SQL Servers is a vital task to BizTalk/System Administrators. Manually monitoring the infrastructure of BizTalk Environment is a cumbersome task. BizTalk360 is the operational, monitoring and analytics tool which is used to manage the health of BizTalk and SQL Servers in an efficient way. Many customers approach the BizTalk360 Support Team to provide the Hardware Requirements of BizTalk360.
In our Documentation portal, we have provided the BizTalk360 installation document with hardware requirements for a BizTalk360 instance which contains one BizTalk Group. We provided the prerequisites with both software and hardware requirements, considering the BizTalk360 is set up in a stand-alone server.
We also have BizTalk360 Installation guide to set up BizTalk360. This article is focused on the hardware requirements of Windows Server to install the BizTalk360 application.
BizTalk Group Configuration
In most organizations, BizTalk Groups are set up in at least 3 environments (Production, Staging, QA/Dev). Considering these configurations of BizTalk Groups, we are suggesting the BizTalk360 application servers hardware requirements with BizTalk360 Gold tier. Having the Gold tier, and not Platinum, means that you will not have the ability to use the BizTalk360 Analytics features, but this will also save you from needing additional resources which come along with the Platinum features. However, with the mentioned hardware requirements, we kept the possibility open for upgrading to the Platinum tier, without the need for additional hardware requirements.
BizTalk360 – Application Server Configuration
Goal: Create a separate instance of BizTalk360 Application Servers for twos version of BizTalk Server environments (BizTalk Server 2016 & 2013 R2).
Scenario 1
We have written down the requirements for the BizTalk360 Application servers for BizTalk Server 2013 R2 environments, as well as BizTalk Server 2016 environments. Each of these BizTalk360 Application servers will be used to operate and monitor 3 different BizTalk environments. The specifications for these servers have also been written with that requirement in mind.
You will also find the requirements for the SQL server, which will host 2 SQL Server instances. Each SQL instance will host a BizTalk360 database, which will connect to either the BizTalk360 application server for monitoring the BizTalk Server 2016 environments or the one for monitoring the BizTalk Server 2013 R2 environments.
The system requirements to install BizTalk360 are considered to configure 3 BizTalk Groups in per BizTalk360 installation.
BizTalk360 Application Server
|
Resource
|
Requirements
|
|
Computer and Processor
|
A computer with an Intel Pentium-compatible CPU that is 1 GHz or higher quad processors. The 64-bit versions of BizTalk Server require a 64-bit operating system running on an x64 based system.
|
|
Memory
|
16 GB or higher
|
|
Hard Disk
|
Minimum 20 GB of available hard-disk space for a complete installation including the operating system and all prerequisite software. The hard disk must be NTFS formatted.
|
BizTalk360 – Database Server (2 SQL Instances)
|
Resource
|
Requirements
|
|
Computer and Processor
|
A computer with an Intel Pentium-compatible CPU that is 1 GHz or higher quad processors. The 64-bit versions of BizTalk Server require a 64-bit operating system running on an x64 based system.
|
|
Memory
|
16 GB or higher
|
|
Hard Disk (Database)
|
Minimum 200 GB of available hard-disk space for a complete installation including the operating system and all prerequisite software. The hard disk must be NTFS formatted.
|
Why do we need these specifications?
In complex BizTalk environments, multiple BizTalk Servers and SQL Servers are configured. Based on these BizTalk Group configurations, we arrived at the BizTalk360 Application Server and BizTalk360 Database Server Configuration.
BizTalk360 Application Server
- Processor: To process the various data from (2 or more) BizTalk Servers and SQL Servers, BizTalk360 Application Server requires a high-end processor.
-
WMI Queries are used to collect the Event Log Sources from BizTalk and SQL Servers
-
Querying against the BizTalk databases like Message Box and Tracking Database
-
PerfMon is used to collect System Resources and Performance Metrics analytics data
- Hard Disk: Disk Storage of BizTalk360 Application Server is necessary to hold the following data
BizTalk360 Database Server
BizTalk360 collects Event Log Sources and Performance Metrics from BizTalk and SQL Server and stores that data into the BizTalk360 database. It also collects Tracking Data to determine the Message Patterns and Transmission Failure Rates.
The BizTalk360 Administrator makes sure the Data Purging Jobs are in healthy status to manage the growth of BizTalk360 database.
BizTalk360 High Availability
Many customers are configuring the BizTalk360 Monitoring Service and Analytics Service in high availability with Windows server cluster setup. In this case, you need two BizTalk360 Application servers, with the configuration mentioned in the above table.
Note: Customers can install all three components in high availability configuration
- BizTalk360 Web Application
- Monitoring Service
- Analytics Service
Users can manage the BizTalk360 Monitoring and Analytics services in the Settings -> BizTalk360 Health. Read this article to know more about BizTalk360 High Availability status.
Scenario 2
Some customers use different instances of BizTalk360 for the same version of a BizTalk Group in QA, Staging and Production environments. In this scenario, three different Windows servers are required for BizTalk360 Application configuration. Similarly, three SQL Servers are required to configure the BizTalk360 databases. If they want to set up high availability of BizTalk360 in production, then one BizTalk360 Application Server and one SQL Server are added to the list.
Conclusion
Once all the setup and configurations are in place, it is a quick and seamless task to install/upgrade BizTalk360. The customer suggestion and feedback are always heard and addressed, which helps us to improve the product and provide better service.
The post BizTalk360 Application Server – Hardware Requirements appeared first on BizTalk360.
by Raja Sreenivasan | Sep 10, 2019 | BizTalk Community Blogs via Syndication
BizTalk360 aims to offer capabilities out-of-the-box from tools like the Windows Performance Monitor. The BizTalk360 Analytics service collects the performance data for the various server types like BizTalk, SQL, IIS, and Windows. Based on the server type selection, the Analytics service will start collecting the performance data and that can be visualized in BizTalk360 Analytics widgets or the user can push that data to third-party APM’s (Application Performance Monitoring) like New Relic, AppDynamics or Dynatrace.
BizTalk360 also allows administrators to automatically execute queries against the Tracking database, at a specific interval, to view, analyze and troubleshoot the tracked data. For the Tracking data, BizTalk360 provides a similar user experience to the performance data collection. This allows the user to pick the metrics they want to collect.
In this article we will look into detailed information about:
- Performance Data Collection of each type (BizTalk, Windows, SQL, IIS)
- Tracking Data Collection
- Analytics Custom widgets in BizTalk360
Performance Data Collection
To analyze the performance of a BizTalk environment, BizTalk360 is equipped with Performance Data Collection in the Analytics section. Once the user enabled any one of the server types (BizTalk, SQL, IIS, and Windows) in any selected environment, the BizTalk360 Analytics service will start to collect all the related counters.
For enabling the performance data, navigate to the Settings section of BizTalk360. In the Analytics configuration, you can manage the performance data collection in the Manage Analytics section.
Once the performance data collection is enabled for a server, the Analytics service will start to collect counter data on the next polling cycle.
For a larger environment, the Analytics service may need to collect multiple counter data, but the user might not require all those data. For instance, if a user wants only the BizTalk message related counter data to analyze the performance of the BizTalk environment, the Analytics service collects all the BizTalk related counters.
Performance Data collection Optimization
To address this challenge, BizTalk360 allows the user to manage the metrics collection from the v9.0 phase 2. To narrow down the data collection at a server level, the user can optimize the data collection using the “Manage Metrics” option for each server in an environment.
With the “Manage Metrics” option, the user can choose the required performance metrics based on types, so that BizTalk360 Analytics will start collecting data only for those metrics.
Let’s take a deep dive on how a user can manage the metrics collection at the server level.
In BizTalk360, each server’s counter is segregated into 4 types:
- BizTalk
- Windows
- IIS
- SQL
Most of the BizTalk environments will be in a multi-server setup where at least BizTalk Server and SQL Server are configured in different machines. A user may expect BizTalk related counters from BizTalk Server or SQL related counters from SQL Server. A user may not want SQL/IIS related performance metrics data in a BizTalk server machine. By using the “Manage Metrics” option in each server, the user can choose the metrics needed for each server. This improves the overall performance of the Analytics service and avoids the growth of the database.
Tracking Data Collection
BizTalk360 allows the user to run queries against the Tracking database and display the result in a widget. In some scenarios, retaining the tracking data longer than the actually required duration, causes the database to grow exponentially. In other scenarios, the environment doesn’t follow a strict purging policy. For both cases, it is hard to query against the Tracking database due to its size.
In a larger database, querying against the Tracking database and displaying the data, results in a graphical form in the widget. This could degrade the performance of the queries and impact on the user experience of the Analytics dashboard.
To overcome these challenges, we created a service in v8.3 that collects the tracking data periodically in small chunks and avoiding expensive queries on the Tracking database, and metrics are collected rather than pulling all the tracking data into BizTalk360 database.
Once decided to go with new this data collection method, BizTalk360 provides a customizable interface where user can pick the metrics they wanted to collect. A similar user experience to the performance data collection in BizTalk360 allows the user to fine-tune the data collection at an environment level.
Analytics Custom Widget in BizTalk360
BizTalk360 is loaded with customizable information and a variety of widgets to choose from, which can be added to your dashboards. The BizTalk360 Analytics dashboard is loaded with performance data widgets and tracking database widgets, like the Messaging performance and transmission failure rate widgets.
Users can add custom widgets to both the Analytics dashboard and custom dashboards in BizTalk360. The product provides rich options for adding widgets in these dashboards. Users can choose
- Date Range (24 hours, 7 days, 30 days, custom date range)
- Comparing data with previously generated data
- Graph type (line, column, area)
Based on the selected date range, the performance data gets collected from the BizTalk servers.
Once the analytics components, for which the data needs to be collected, are enabled, the different metrics for the custom widgets will get enabled. With the custom widgets, you can choose different metrics for which you want to view the data. Users can choose messaging performance/transmission failure of tracking data or performance data from the drop-down.
Conclusion
Do you wish to see more information on the widgets or from the product itself? Then, please put in your suggestions and feedback in our user voice portal. The existing ideas can also be voted for. We at BizTalk360 aim at providing the features that fulfill the customer requirements. It is from this feedback portal that the features get picked up for every release.
For more information about how these widgets work, check our Documentation Portal.
The post Performance Data Collection Optimization appeared first on BizTalk360.
