Any support technician will face challenges when keeping a hybrid integration (messaging) environment up and running. Such an environment can include a BizTalk Group, and then these challenges can be of various magnitudes; one or more receive ports down, throttling, memory leaks, time-outs on send ports, or performance issues. Furthermore, not acting promptly on these issues can result in a severe impact on the business and increase the total cost of ownership (TCO) of the environment. In this post, we will discuss how one could face these integration challenges using AIMS.
BizTalk, Azure or hybrid integration environment
An integration (messaging) environment can be a set up to support on-premise connections to various other systems and their message exchange or a hybrid set up including communication with SaaS and Azure services like Service Bus or Blob Storage. Moreover, the environment could consist of an integration broker product like BizTalk server, which through its adapters can communicate with on-premise Line-of-Business (LOB) systems like SAP, and Azure by using, for instance, the Service Bus Adapter.
With an integration environment in place, it is most likely that is a critical component in the enterprise architecture of any enterprise. Furthermore, the message exchange between systems and possibly the Cloud will need to be up and running 24/7. Hence, the health of such an environment has to be in good shape and be sustainable. Therefore, any issue has to be dealt with quickly with minimal impact on the business.
Hybrid integration monitoring challenges
In the introduction, we mentioned a few challenges support could face with integration environment that includes BizTalk server. In the following paragraphs, we will discuss these challenges, and how to meet them.
For a comprehensive look at the people, processes and tools needed to successfully maintain a hybrid integration environment, visit our hybrid integration performance monitoring guide.
1. Application health
One of the primary concerns of any BizTalk Administrator is knowing that applications are online and healthy. Healthy means in this context that artifacts like Receive Locations, Send Ports and Orchestrations are configured and enabled. Furthermore, when a source or destination system is no longer available, it is crucial that a BizTalk Administrator receives a notification. The BizTalk admin console, however, does not provide that functionality out-of-the-box. Therefore, either a third-party or homegrown solution should be available for BizTalk administrators with notification capabilities.
Many monitoring tools, products, and even scripts can notify you that one or more receive locations are down. Usually, some issue is the cause of the receive location going down. For instance, a password has changed, and you are not made aware of it, or the address, i.e., someone changes the folder name or removes it. There can be various reasons that a receive location is shutting down. Or a time-out occurs on the send port, hence BizTalk cannot send a message cannot send or retries it. Again there are tools, products that can notify you and tell you why the time-out is occurring. With AIMS, you will be able to identify a trend or receive locations shutting down or which send port regularly has a time-out. Furthermore, AIMS provides a subscription mechanism to these events like email notifications. Thus you can start investigating how to prevent these issue beforehand.
.jpg?width=1050&name=BizTalk%20Integrations.screenshot%20(1).jpg)
2. BizTalk Hosts
BizTalk has by default two types of hosts, the in-process and isolated. Both are set in the database and create corresponding tables and rows in the BizTalk databases so the host instances can process data. For the servers you generate host instances, these instances perform jobs, either orchestrating, receiving files or sending them out.
If host instances go offline, it will probably have an immediate impact on an application unless multiple host instances exist. However, host instance does not go offline without any underlying reason. Again like with application health issues, BizTalk administrators should get notifications as these incidents warrant immediate investigation.
Several monitoring tools, products, and scripts can help in identifying if a host is down, and notify you about it. You can investigate the underlying cause of host instance going offline. Moreover, it can be interesting to learn how host instance goes offline by applying artificial intelligence. What activities in a BizTalk Group lead to host instance going offline. Spotting those activities and or keeping knowledge bases and checklists can help in the prevention of host instance going offline.
3. Host Throttling
BizTalk Throttling is a protection mechanism that will significantly slow down the rate at which BizTalk is processing messages. BizTalk will do this to prevent an all-out outage. Throttling conditions can severely slow-down BizTalk farm and will probably have a negative impact on real-time processing. Throttling issues usually need time to work themselves out, but through proper tuning can often be prevented.
BizTalk and Logic App solutions depend on connectivity with other systems, and services. Besides a stable network and enough bandwidth, adapters and connectors play an essential factor. Adapters and connectors provide access to the actual system or service. Furthermore, the amount of workload pushed through an adapter or connector can lead throttling and degrade performance.
It is essential to learn what the amount of traffic in messages is with each interface. Moreover, you need to know the volume, and frequency of the messages to each receive- and send port, and will be processed by orchestrations. A product like AIMS can help you learn and understand the traffic going through your BizTalk Group. Furthermore, it can identify anomalies in traffic to your environment – AIMS collects the throttling metrics and will generate the analomies in any significant way. Thus you can see what leads to throttling issues.
4. Single Sign-On Service availability
Single Sign-On Service availability doesn’t immediately result in a BizTalk outage, however, with the Single Sign-On Master Secret Server offline, a simple activity like Windows Patching will render your BizTalk environment inoperable. Dealing with Single Sign-On Master Secret Server issues proactively is a good practice and will prevent unnecessary downtime.
The downtime of the SSO database and service can be detected by scripts, tools, and various monitoring tools. With AIMS you can set up an alert to notify you when the SSO database is offline and or the SSO service is not running.
5. Growing BizTalk Server database
BizTalk databases are growing more substantial even though the BizTalk database jobs are running correctly. Execution of the BizTalk Server SQL Agent jobs is crucial for managing the BizTalk Server databases and for maintaining optimal performance. Even with the jobs running successfully, there can be more causes of the uncontrolled growth of the databases like:
- Excessive suspended message or service instances
- Disk failures
- High levels of tracking
- BizTalk Server throttling
- Poor SQL Server performance
- Network latency issues
The health of BizTalk server databases is critical to keep the BizTalk Group, i.e., the integration environment healthy. Uncontrolled growth of BizTalk databases is unwanted. Again with the appropriate monitoring tools and products in place you can be notified of any anomaly regarding BizTalk databases.
With AIMS the SQL Server metrics are collected, and any relevant anomaly is generated.
Conclusion
When supporting an integration environment with BizTalk, you will face challenges as mentioned in this post. You can meet these challenges with a process in place and who deals with the issue. Furthermore, besides a well-described process, you need tools and knowledge of what type of issues can occur. This awareness of potential issues is valuable, and help in quickly identifying and resolving them.
