Self-troubleshooting tools in BizTalk360

Self-troubleshooting tools in BizTalk360

We, the product support team, often receive different types of support cases reported by the customers. Some of them may be functional, others may be related to installation and so on. Every support case is a new learning experience and we put in our best efforts to resolve the issues, thereby providing a better experience to the customers. As the below quotes say,

“Customer success is simply ensuring that our customers achieve their desired outcome through their interactions with our company” – Lincoln Murphy

We must make sure that we are taking the customers in the right direction when they raise an issue and must give them confidence about the product as well as service.

As already known, BizTalk360 is the one stop monitoring tool for BizTalk server. BizTalk360 not only contains the monitoring options for BizTalk server, in turn contains other in-built tools as well such as BAM, BRE etc. Whenever an issue is reported by the customer, we start our investigation from the basic troubleshooting steps. Hope it would be interesting to know what are the basic troubleshooting that we do. Yes, it would be. In this blog, I will share the information about the basic troubleshooting tools that we have in BizTalk360 that help us in resolving the customer issues.

Installer Log Information:

The first step in using BizTalk360 is the installation and configuration. The installation, as well as the upgrade process, is seamless with simple steps and some of the permission checks are done in the installer. But there may be some cases where the installer may fail with the below error.

Self-Troubleshooting tools in BizTalk360

There is no much information about the error on the screen. So how do we check this error? Here comes the Installer logs for our help. Generally, when we install BizTalk360, we just give the name of the MSI in the admin command prompt and run it. But to enable installer logs we need to run the installer with the below command with the BizTalk360 version number.

msiexec /i “BizTalk360.Setup.Enterprise.msi” /l*v install.log

The installer log location can also be provided in the command, else the log will be created in the same folder where the MSI file is located. The steps performed during the installation will be logged in the installer log. The log will also contain information about any exception thrown. So, for the above error, the logged information was:

MSI (s) (E0:D4) [13:57:50:776]: PROPERTY CHANGE: Modifying CONNECTION_ERROR property. Its current value is ‘dummy’. Its new value: ‘Cannot open database “BizTalk360” requested by the login. The login failed.

Login failed for user ‘CORPsvcbiztalk360′.’.

The error clearly states that it is a permission issue. When BizTalk360 is installed, the BizTalk360 database gets created in the SQL server. BizTalk360 may be installed on the same machine where BizTalk server resides, or in a standalone machine and the SQL database may be on a separate server. As a prerequisite for BizTalk360, we recommend providing the SYSADMIN permission for the service account on the SQL server. Giving this permission to the service account resolves the above error. Hence, any installation related error information can be identified from the installer logs and can be resolved.

Troubleshooter:

This is an interesting tool which is integrated within BizTalk360 and available as a separate window-based tool. contains an extensive set of rules to verify all the prerequisite conditions in order to successfully run BizTalk360. As you can see in the below picture, the user just enters the password for IIS application pool identity and monitoring service account and clicks the “Troubleshoot BizTalk360” button. The rules will be verified and results will be indicated in the form of RED/GREEN/ORANGE.

This way, we can check the missing permissions for the BizTalk360 service account and provide the same.

Apart from the permissions, the other checks done by the troubleshooter are:

  • IIS Check
  • SQL Select Permission check
  • Configuration File check
  • Database report

If the customer faces any issue during the initial launch of the application, then they can run the troubleshooter and check for the permissions. Once the errors are resolved and everything is green, they can start BizTalk360 and it should work.

Self-Troubleshooting tools in BizTalk360

Self-Troubleshooting tools in BizTalk360

Hence all the information regarding the service account permissions, BizTalk360 configuration and database can be obtained with the help of troubleshooter. The integrated troubleshooter can be accessed from BizTalk360 itself as seen below.

Self-Troubleshooting tools in BizTalk360

BizTalk360 Service Logs:

The details of the exceptions that occur in BizTalk360 are captured in the log files that are generated in the BizTalk360 folder. The logs files not only contain the information of the exceptions, but they also contain the information about the alarm processing and the subservices statuses. There are different logs for each of them which are described below.

Monitoring Logs

Monitoring is one of the most important tasks performed in BizTalk360. There are new features getting added in every release of BizTalk360. The monitoring capability is also extended to File Locations, Host Throttling monitoring, BizTalk server high availability and much more. The BizTalk360 monitoring service is installed along with the BizTalk360 web application. Once the artefacts are configured for monitoring, the service runs every 60 seconds and triggers alert emails according to the conditions configured.

What happens if there occurs some exception during the monitoring and alerts are not triggered? Where can we find the information about these exceptions and take necessary actions? Here come the service logs that are located in BizTalk360 installation folder/Service/Log folder. There are about 25 different logs that get generated for each monitoring configuration separately and get updated whenever the monitoring service runs. Say for example, if the alerts are created, but not transmitted due to an exception, this information will be logged in the BizTalk360.SendMail.log file. So, when the customer raises an issue regarding the transmission of alerts, the support team starts the investigation from the logs. We ask the customers to share the logs from their environment and we check them. Let’s look at a customer scenario.

One of the issues came up such that:

  • The customer has configured a receive port for process monitoring
  • But they are getting Actual count = -1 even when there are messages processed via this port.
  • They wanted to know the reason why the actual count was -1.

In BizTalk360, the negative value denotes that there has been some exception occurring. And, the exception would be logged in to the service logs. Hence, we asked them to share the logs.

Self-Troubleshooting tools in BizTalk360

From the BizTalk360.ProcessMonitor.log, we could see the following exception:

2017-09-21 10:16:45 ERROR – ProcessMonitoringHelper:GetMonitoringStatus. Alarm Name:PROD_DataMonitor: Name: Application : Atleast 20 Messages from DHL per hour: Exception:System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. —> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)

The timeout exception generally happens when there is a huge volume of data in the BizTalkDTADb database since for Process Monitoring, we retrieve the results from this database and display it in BizTalk360. The database size was checked at their end and found to be 15 GB which was greater than the expected size of 10 GB. For more information on the database size, you can refer here.

Similarly, we have different log files generated from which we can get the information about the different sub services running for BizTalk360 Monitor and BizTalk360 Analytics services.

Self-Troubleshooting tools in BizTalk360

Self-Troubleshooting tools in BizTalk360

We can also check if all the subservices are started properly. The log information is captured along with the timestamp and this would make much easier for the support team to identify the cause and resolve the issues in time, thereby making the customer happy. In case of monitoring logs, the Alarm name and configurations are also captured. There are separate logs for Process Monitoring and other Data Monitoring alarms. We have separate logs for FTP and SFTP monitoring too for capturing the exceptions if any.

Analytics logs

Analytics is yet another important feature in BizTalk360 with help of which you can visualize a lot of interesting facts about your BizTalk environment like number of messages processed, failure rate at message type level, BizTalk server CPU/Memory performances, BizTalk process (host instances, SSO, rules engine, EDI etc) CPU/memory utilization and lots more. BizTalk360 Analytics service also contains different sub services run and any exception occurring for these services will be captured in the logs under C:Program Files (x86)Kovai LtdBizTalk360AnalyticsLog folder.

Self-Troubleshooting tools in BizTalk360

BizTalk360 Analytics is used to gather the information about the performance counters in the server and display them in the form of widgets. Also, BizTalk360 will display the information if the system is under throttling condition in a graphical format. There was a case from the customer that the Throttling Analyser was not displaying any formation when the system was under throttling condition.  We then checked the logs and found the below error in the BizTalk360.Throttling.log.

Self-Troubleshooting tools in BizTalk360

From the logs, we could understand that the performance counters were corrupted and rebuilding the counters resolved the issue.

Web and Svc logs

At times, there are scenarios where a page in BizTalk360 may take some time to get loaded leading to performance issues. The time taken to load the page can be captured in the svc logs present in C:Program Files (x86)Kovai LtdBizTalk360Web folder.

Self-Troubleshooting tools in BizTalk360

Once a customer reported that there was performance latency in some of the BizTalk360 pages. We checked these trace logs and found that the service calls GetUserAccessPolicy & GetProfileInfo methods were taking more than 30 seconds to get resolved.

GetUserAccessPolicy–>Groups/user assigned to provide access to the features of BizTalk360.

GetUserProfile –> Fetch the UserProfile of the group/user been configured.

These methods were then optimized for caching in the next BizTalk360 version release and hence the performance issue was resolved.

BizTalk360 subservices status

As mentioned before, we have different subservices running for BizTalk360 Monitor and Analytics services. In case, if there is any problem in receiving alerts or if the service is not running, the first step would be to check for the status of the monitoring subservices for any exceptions. This can be found in BizTalk360 Settings -> BizTalk360 Health -> Monitoring Service Status. The complete information will also be captured in the logs.

Self-Troubleshooting tools in BizTalk360

Similarly, we have the check for the Analytics sub services under Settings -> Analytics Health.

What if the customer has configured BizTalk360 under High Availability(HA)? High Availability is the scenario where BizTalk360 is installed on more than one servers pointing to the same database. The BizTalk360 Monitor and Analytics services can also be configured for HA. So, when there is an issue reported with these services, the logs from the active server must be investigated. The active server can be identified from BizTalk360 Settings -> BizTalk360 Health -> High Availability Status.

Self-Troubleshooting tools in BizTalk360

Conclusion:

These basic troubleshooting tools available in BizTalk360 make our support a little easier in resolving the customer issues. The first step analysis can be done with these tools which help us identify the root cause of the problem. We have our latest release BizTalk360 v8.6 coming up in a few weeks with more exciting features. In case of further queries, you can write to us at support@biztalk360.com.

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.”

The Role of Data Purging in BizTalk360 Data Monitoring

The Role of Data Purging in BizTalk360 Data Monitoring

As the below quote says,

Quality in a service or product is not what you put into it. It is what the client or customer gets out of it – Peter Drucker

We, the product support team at BizTalk360, always put in our best efforts to solve the customer problems to make them feel satisfied. Our team often gets different varieties of problems, some related to functionality, performance, and data related issues and we make sure the issue is resolved within proper timelines. Recently there was a case with the customer that they were facing exception in Data Monitoring. In this blog, I am going to share my experience on how we resolved this problem.

The Message Box Data Monitoring:

How many times in a day does the support person have to watch for suspended instances in a particular application and take an appropriate action, or look out for ESB exceptions with a particular fault code? Wouldn’t it be nice if there was a way to set up monitoring on a particular data filter, get notified when there is a violation, and take actions automatically depending on the actual situation? Yes, that’s exactly what BizTalk360 achieves through the concept of data monitoring, which was a result of a customer feedback.

In MessageBox Data Monitoring, we can identify the number of suspended instances, the messages flowing and take appropriate action, either to suspend, resume or terminate the instances. This can be done from BizTalk360 itself, given the user has appropriate permissions. In my previous blog, I have explained about the permissions to be given for the user to resume/suspend/terminate service instances. Let’s look into the customer’s case.

Customer’s case:

The support ticket was raised for the case that the customer has configured auto termination functionality for the suspended instances. The messages were neither getting archived nor terminated. But the Data Monitoring dashboard was showing the details of the successful run.

BizTalk Data Monitoring in BizTalk360

BizTalk Data Monitoring in BizTalk360

Our investigation starts:

For a support ticket, with respect to Data Monitoring section, the first thing that we would check is for the alarm configuration details and then the logs for an exception. So, we started the investigation by checking the alarm details and they seemed to be fine. But the exception was captured in the Data Monitoring dashboard when the details of the task action were checked for.

BizTalk Data Monitoring in BizTalk360

BizTalk Data Monitoring in BizTalk360

System.Data.SqlClient.SqlException (0x80131904): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. —> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)

The real cause for the Timeout exception:

There was an additional information from the customer that they were not able to delete the existing MessageBox data alert from BizTalk360, even though the BT360 service account was a superuser. The same timeout exception was displayed while deleting the alarm also. The suspended instances were getting terminated from BizTalk admin console without any issues. Since this was an issue in the production environment, we immediately went on a call with the customer to probe further on the case.

There were four BizTalk360 servers configured in High Availability mode in the production environment, out of which 3 were passive and one was active. We checked the status of the monitoring sub-services and found that Purging was not getting updated properly.

The timeout exception usually happens when there is a large volume of data. Checking all the permissions and configurations, everything was fine. The next step was to check for the data in the BizTalk360 database. But from where does the large volume of data come from?

BizTalk360 communication with other BizTalk databases:

It’s a well-known fact that BizTalk360 is a one-stop monitoring solution to monitor BizTalk server. So, for monitoring the BizTalk artefacts and the messages flowing through the receive and send ports, BizTalk360 polls for the data from the BizTalk databases namely BizTalkDTADb and BizTalkMsgBoxDb and inserts the required data into the BizTalk360 database as per the alarm configurations. For MessageBox Data Monitoring, the data from BizTalkMsgBoxDb is fetched. If there is any action (resume/terminate) is configured for the suspended instances in Data Monitoring, then the data is inserted into the following tables in BizTalk360 database.

– b360_st_DataMonitorResults
– b360_st_DataMonitorTaskActionResults

When we checked the number of records in the b360_st_DataMonitorTaskActionResults table, the select query was just spinning and was taking lot of time to load the results. This was due to the reason that there were 8 million records in that table. And obviously, this was cause for the timeout exception in BizTalk360.

Purging in BizTalk360:

BizTalk360 comes out of the box with the ability to set purging duration and the background monitoring service has the capability to purge older data automatically after the specified period. The Administrators/Superusers can set up the “Purge duration” under “Settings”. This will control the database growth and hence the performance of BizTalk360 will not get affected. The default purging settings in BizTalk360 can be seen in the below screenshot.

We can see that the purging duration for Data Monitoring is 2 Months. Hence the historical data for 2 months will be present in BizTalk360 database.

Purging needs to be done to remove the historical data, thereby making the database healthy. BizTalk360 purges the data by running the stored procedure in the specified duration specified in the settings. The purging settings can be altered by the customers according to their business needs and data flow. If a large volume of data flows through the ports, they can set the purge duration to a minimum value so that data growth is controlled.

We recommended the customer to decrease the purge duration to 1 month and the observe the Data Monitoring. After modifying the purge duration, the MessageBox Data Monitoring started working as expected. The suspended instances were getting terminated as per the alarm configuration and there were no timeouts happening.

The best practice to follow in case of timeout exception:

Whenever a timeout exception occurs, the first thing to be checked is the standard database reports in the relevant databases. This will ensure which table occupies more space. Then we can act on the purging policy and change it according to the business needs and data flow.

If you have any questions, contact us at support@biztalk360.com. Also, feel free to leave your feedback in our forum.

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.”

Permissions required to setup Monitoring SQL Jobs

Permissions required to setup Monitoring SQL Jobs

Biztalk360 comes with a lot of exciting features in every release. One of the important functionalities in BizTalk360 is the monitoring with the autocorrect options. BizTalk360 is the one-stop monitoring solution for BizTalk server. We can not only monitor the artefacts, but also the SQL jobs. Yes, the SQL jobs present in the SQL server can also be monitored. We can also set the autocorrect (enable/disable) functionality for the SQL jobs.

There may be separate servers for BizTalk databases and BizTalk360 database or even single server hosting all the databases. The jobs in all these servers can be monitored via BizTalk360. But then, can all the users have access to monitor and autocorrect the SQL jobs? In this blog, I am going to explain about the permissions required by the users for monitoring SQL jobs and setting autocorrect functionality which we learnt from one of the support tickets.

Customer’s case:

Our support team often get some interesting tickets which do not directly deal with the functionality and features of BizTalk360. Some tickets may be related to performance, access permissions, AD users etc. Each ticket experience is a new learning for our support engineers. Let’s see one such case of a customer related to the access permission for the databases in the SQL server.

The customer got the below exception when they tried to set up monitoring for SQL jobs.

Permissions required to setup monitoring SQL jobs

The sp_help_job is the stored procedure used to list the SQL jobs running in the server. This job returns information about jobs that are used by SQL Server Agent to perform automated activities in SQL Server. There are SQL jobs that get installed and scheduled automatically to maintain the health of the BizTalk environment.

BizTalk360 allows to set the threshold for SQL jobs (Monitoring -> Manage Mapping ->SQL Server Instances ->SQL Jobs) to list out those SQL jobs and perform the automatic operation this “sp_help_job” job is being used.

The exception in the above screenshot comes because of a missing permission for the BizTalk360 service account while accessing the SQL server. We have our support article in place which describes about the permissions for the SQL jobs. The customer has given the permission according to this article. But they were facing the error again when trying to enable autocorrect feature for SQL jobs.

Permissions required to setup monitoring SQL jobs

In this error message, it says “Only members of sysadmin role are allowed to update or delete jobs owned by a different login”

This means that only if the service account has the SYSADMIN permission, then it can enable/disable the sql jobs from BizTalk360. But some of the customers would not prefer to provide SYSADMIN permission for the service account due to some security policies. So, what happens in such case? Let’s go ahead and check the resolution given. Before that lets have a quick glance at SQl jobs and permissions.

The SQL jobs:

A job is a series of operations performed by SQL Server Agent sequentially. A job can run on one local server or on multiple remote servers. The jobs are used to define administrative tasks that can be run one or more times and monitored for success or failure. SQL server agent runs these scheduled jobs. A job can be edited only by its owner or by the members of the sysadmin role.

The SQL job permissions:

SQL server has the following msdb database fixed roles through which the SQL server can be accessed and controlled. The roles from least to most privileged are:

  • SQLAgentUserRole
  • SQLAgentReaderRole
  • SQLAgentOperatorRole

Can we have a brief look at each one of them?

SQLAgentUserRole:

This is the least privileged role. It has permissions on only operators, local jobs, and job schedules. Members of SQLAgentUserRole have permissions on only local jobs and job schedules that they own. They cannot use multi-server jobs (master and target server jobs), and they cannot change job ownership to gain access to jobs that they do not already own.

SQLAgentReaderRole:

This role includes all the SQLAgentUserRole permissions as well as permissions to view the list of available multi-server jobs, their properties, and their history. Members of this role can also view the list of all available jobs and job schedules and their properties, not just those jobs and job schedules that they own. SQLAgentReaderRole members cannot change job ownership to gain access to jobs that they do not already own.

SQLAgentOperatorRole:

This is the most privileged role which includes all the permissions of the above-mentioned roles. They have additional permissions on local jobs and schedules. They can execute, stop, or start all local jobs, and they can delete the job history for any local job on the server. They can also enable or disable all local jobs and schedules on the server. SQLAgentOperatorRole members cannot change job ownership to gain access to jobs that they do not already own.

The below table summarizes some of the properties for all these roles.

Database RoleAction – Create/modify/delete

Action – Enable/Disable

Local JobsMultiserver jobsJob schedules
SQLAgentUserRoleYes

Yes

(Owned jobs)

No

No

Yes

Yes

(Owned schedules)

SQLAgentReaderRoleYes

Yes

(Owned jobs)

No

No

Yes

Yes

(Owned schedules)

SQLAgentOperatorRoleYes

Yes

No

No

Yes (Owned schedules)

Yes

Of all the above-mentioned SQL database roles, the SYSADMIN is the highest privileged role which has the administrator rights on the SQL server.

The resolution provided:

As mentioned earlier, the BizTalk360 service account would require the SYSADMIN permission to monitor and autocorrect the SQL jobs. But in some customer scenarios, they would not prefer to provide the SYSADMIN permissions. In that case, we need to see what is the minimum level of permission that we can provide to the service account for monitoring the SQL jobs.

Our support team did an extensive testing to check for various scenarios and permissions for the service account. The outcome of the testing is given below:

As the table summarizes, when the BizTalk360 service account is given the permissions as SQLAgentUserRole or SQLAgentReaderRole, it can only view the SQL jobs and cannot perform any operations on them. But when the SQLAgentOperatorRole is given for the service account, the auto correct functionality will work for the SQL jobs. The SYSADMIN permission is not required for this. This role is the highest privileged role next to the SYSADMIN.

Permissions required to setup monitoring SQL jobs

Conclusion:

Hence, for setting the autocorrect functionality (enable/disable) the SQL jobs, the BizTalk360 service account needs to be given the SQLAgentOperatorRole permission to the system database, if SYSADMIN permission is not preferred to be given.

PS: BizTalk360 will not do any operation by itself until monitoring has configured for any of the available SQL Jobs and enable the Auto-correction ability.  In case, you don’t wish to monitor the SQL jobs you can avoid the permissions shown in the above image.

If you have any questions, contact us at support@biztalk360.com. Also, feel free to leave your feedback in our forum.

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.”

Our experience at Design Thinking Summit 2017

Our experience at Design Thinking Summit 2017

Design Thinking –the name sounds different. Can we design our thinking? Yes, we can and this is what we learnt from the Design Thinking Summit 2017 which was held at IIM Bangalore. We are grateful to our organization for providing us such a wonderful opportunity to participate in this event.

BizTalk360 always focus on the motto “You grow, we grow, together we grow”. In this way, they always help the employees acquire skills through different learning and training programs. One such opportunity was given to 6 of us to attend the Design Thinking Summit 2017 and I am lucky to be the one among them. In this blog, I would like to share my experiences in the DTSummit. Special thanks to Saranya and Umamaheshwaran for adding more meaning to this blog by sharing their experiences.

Design Thinking Summit 2017

An intro to Design Thinking Summit – Insight:

Design Thinking is a creative, repeatable, human centered approach to problem-solving and innovation. It draws upon experience, imagination, intuition, and reasoning to explore possibilities of what could be—to create desired outcomes that benefit your customers. This summit was organized by a group called Pensaar, powered by a team of highly experienced design thinkers and problem solvers. Over the 3-day workshop conducted by Pensaar team, we learnt how to understand customers, articulate insights that will inspire innovation, ideate till you get disruptive ideas that we can rapidly test with customers. It is focused on learning by doing. All while experimenting, experiencing, having fun and being surprised. There were around 160 participants this year for the DTSummit.

Day 1 at the Design Thinking Summit:

It was all new for our BizTalk360 team about the event. We were asked to assemble in the event venue at 8.30 AM. To our surprise, the participants were split into different teams and each one of us was in the different team. This was a nice experience as we got to know different people as the participants were people from different professionals. We were given cards with our photo attached and the table number written on it. Everything was a team activity with a team coordinator for each team.

Design think involves four stages namely

  • Discover – understand people and their ideas
  • Insight – Identify trends and inspire innovation
  • Dream – Ideate solutions for problem statements defined
  • Disrupt – Prototyping techniques that visualize solutions

Design Thinking Summit 2017

The first day was about “Insight”. The first step towards insight is “Discover”. The foremost task is to understand people and their ideas. The “Insight” stands for identifying trends and pattern of data which will inspire innovation. The below quote explains it.

Fall in love with the problem and not with the solution

Products must be created for behaviors and not for intentions

The first day started with an event to come up with an innovative team name for each team. The stationeries were provided along with post-its. An interesting this to be noted at the venue (IIM- Bangalore) was that plastics are banned and we were given glass water bottles with our names printed on them. There were around 12 teams and each team came up with unique names.

The interesting interview:

The next event was an interesting interview with a reputed industrialist. The aim was to capture the insights of the person and utilize them for a better understanding of the requirements.  We were asked to listen to the interview and note down our points in the post – its. The important feature of the post is that we cannot write long stories in it. The notes must be short and understandable. Hence, we need to make sure we have better words to describe our points and ideas. Some of the key insights derived from the interview were:

  • Be focussed on process
  • Build expertise and use them when opportunity is given
  • Soft skills to be more focused.

For example, consider a scenario where we gather the requirements for a product from a customer. The skills to be observed in this process is:

  • Asking open ended questions
  • Listening skills
  • Observing skills

The Research Methodology:

Once the customer requirements are gathered, the next step is to dig deep into them for better understanding. One of the research methodologies was:

Ecosystem Map:

This is a visual representation of landscape within which a problem exists. The map contains the connections between the different stakeholders involved in the problem. We can visually depict the interconnections and inter-dependencies between the stakeholders in the system. This way we can draw key inferences and insights by asking questions like, what are the challenges in the system, what can be improved, what interventions can be made to make a positive impact.

Arriving at the problem statement:

We now have the ecosystem map. The next activity is to identify the problem statement. We can consider anyone of the stakeholders and derive the statement for them. The stakeholder may be a customer, an employee, the government or the senior management of the organization. Each individual team member was asked to write down his/her problem statement based upon the following points describing:

  • User characteristics
  • Outcome the user tries to achieve
  • Barrier existing to achieve the outcome
  • Root cause of the barrier
  • How the user feels because of the root cause and the barrier

This problem statement is important because it is from this point, we will move forward in deriving the solution for them. From the individual points, the team coordinator would discuss and come with a single problem statement for the team. The problem statement is written from the user’s point of view and it helps to identify and articulate the right problem to solve for the users.

There are different tools which help us in deriving the problem statement which may be:

Empathy map – mapping the different data points for the user

Subway map – plotting the objectives with respect to the current state and prioritizing them.

Design Thinking Summit 2017

User persona – Using quote cards, we can derive the insights for different problems given in the cards.

Journey line – steps involved from arriving at the problem statement to improving on the solutions

These tools are considered the convergent research technique tools for understanding the problem better. At the end of the first day, the Pensaar team collected the feedback about the activities conducted.

Day 2 at the Design Thinking Summit:

The first day went interesting and the outcome was the problem statement. Now comes the second day of the event. We were all more excited for the second-day activities. The second day started with the Introduction of the Pensaar team, who are behind the screen for this wonderful Summit.

The agenda for this day was “Dream”. The first day resulted in finding the problem statement with the insights obtained from the different groups. Now, we need to walk our way to find the solution for this problem. But that would not be so easy. One problem statement would be worked upon by all the 12 teams. So, there would be different solutions and it’s important that we identify the best solution.

Arriving at the Customer Benefits:

The first activity for the second day was to “Identify three key customer benefits”. Customer benefit leads to improvement in customers’ life. It is what matters most to the customer when choosing our product over others. The benefits can be measured through certain metrics, which help you in identifying right priorities to acquire many customers. It can be done by crafting a creative Q starting with “How might we”. This lets you to reframe the problem as an opportunity and ideate solutions with a sense of optimism and see the possibilities

Lunch break:

There was another surprise waiting for us during the lunch break. It was picnic lunch for each team. The team members had to collect the lunch for their team mates and have under the trees in a different area. This was very interesting and we all enjoyed it.

Tools for Ideating:

The next step is to ideate solutions for the problem statement based on the key customer benefits. This was the next activity given. There are various tools that are used for the ideation and few of them were given for the teams for activity. Few among them are:

Question storming:

This is a method for discovering the questions to make breakthrough differences in problem-solving, innovation, operational excellence and culture. The questions must be focussed on the facts and situation to get the root of a problem.

Emerging Tech cards:

These are small cards containing information about the emerging technologies in different areas. The activity was to identify the relevant tech card and find out how to make use of it in identifying the solution to the problem.

Design Thinking Summit 2017

Biomimicry:

This is drawing inspiration from nature to design the solution. Simply put its mimicking nature to inspire sustainable and innovation solution. We can take an example of ants and their ability to self-organize to find the shortest route. This can be used to find the best solution.

World Café:

This was a post lunch activity. The teams were asked to write the problem statement and the ideas for a different solution. It is to build a collaboration among the teams than to be an individual. So each team member would be visiting other teams to gather knowledge about their ideas and provide some inputs for the improvements.

With this activity, we came to an end for the second day.

Day 3 at the Design Thinking Summit:

The day 3 was even more filled with enthusiasm among the team because we all had new friends and the past two days gave us a different experience. This day started with the activity for “Disrupt”. This will develop prototypes for the solutions derived and then be experimenting them. It started with

Story Board:

It’s a visual tool to build a narrative around the solution to get feedback and refine the concept. The teams were asked to build the story board with their problem statement and the solutions.

Design Thinking Summit 2017

Message Map:

This is an excellent tool to create an elevator pitch to communicate our concept to users in less than 15 secs. The steps include creating a Twitter-friendly message about the solution and adding supporting points to explain it.

Design Thinking Summit 2017

Experimenting the solution:

The final activity of the event was experimenting the solutions. Each team was asked to create an experiment card which includes the hypothesis, the experiment. Metric and the outcome. With this card, we can experiment our solutions with different users and find the outcome. The teams move around IIM to find the users and the filled in those cards according to the responses received. It was totally a different experience where we also traveled out to find the users and got the feedback from them.

Conclusion:

It was totally a fantastic experience for all of us. Design thinking starts from identifying the exact problem statement (Insight), ideating through different solutions (Dream) and experimenting those ideas (Disrupt) for the development of an employee as well as an organization. These tools can also be utilized in our day to day activities for the betterment of our life as well as career. Thanks to BizTalk360 for giving us a chance to participate in this event and looking forward to more such events.

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.”

Can a non-super user Terminate/Resume suspended instances?

Can a non-super user Terminate/Resume suspended instances?

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.

MessageBoxData Monitoring

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.

Action Performed on Suspended Instance

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).

User permission exception for suspended instances

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.

Monitoring Service User

Service Account Added as super user

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.”

Can a non-super user Terminate/Resume suspended instances?

Can a non-super user Terminate/Resume suspended instances?

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.

MessageBoxData Monitoring

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.

Action Performed on Suspended Instance

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).

User permission exception for suspended instances

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.

Monitoring Service User

Service Account Added as super user

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.”

SendPort is not showing in BizTalk360

SendPort is not showing in BizTalk360

BizTalk360 v8.4 is now released for public with lots of exciting new features and enhancements. Many of our customers have upgraded to the latest version and started enjoying the new features.  We at BizTalk360 support get a lot of queries in the form of tickets. Many customers are asking for the installation path, few raise some clarifications and others may be issues. We categorize the tickets as a clarification, feature requests, and bugs.

Our support team often get some strange issues which did not belong to either of these categories. I am here to explain about one such interesting case and how we identified the root cause and resolved it. As per the below quote,

“The job isn’t to just fix the problem. It is also to restore the customer’s confidence. DO BOTH!” – Shep Hyken

we, the BizTalk360 support team, always work hard to resolve the customers’ issues and achieve customer satisfaction.

The original case stated by the customer

There was a ticket from the customer stating that “Send port is not showing on BT360 Application portal”. In BizTalk360 console, the artifacts get listed when we navigate to Operations -> Application Support -> Applications. The case was that a send port was not getting listed here. But all the send ports were getting listed at the time of assigning alarm for monitoring activity. There was no issue with the other artifacts and they were getting listed properly.

Sendport information missing in BizTalk360

Backtracking and Analyzing the case with the Network Response

Generally, when there is any issue related to UI, we ask for the JSON response from the Network tab in the Developer’s console of the browser. By pressing F12, we can open the browser console and check for any exceptions in the service calls. In the Network tab of the console, the service calls for each operation gets listed from which we can get the request headers and JSON response. This way we can check for the exception details and work on the same. So, we replied to the ticket asking for the network response. But we did not get the required information from the JSON response. The next step was to go on a call with the customer involving one of our technical team members through the web meeting with a screen sharing session.

In the web meeting, we tried different scenarios to check for the send ports. We tried in the Search Artifacts section and it was getting listed without any problem. But there was a weird thing seen. There were multiple entries for the same send port with different URI configured. This is the first time we have come across such an issue. But will this be the issue for the send port not getting listed? Let’s see what’s happening.

Discrepancy in the Send Port information

We exported the send port data from the customer and checked it.  There were multiples entries for the same send port but with different transport type and protocols configured. But in BizTalk server, it does not allow us to create send ports with duplicate names. Then how come this would happen at the customer end? We started our investigation further. Then we found that the multiple entries were due to the backup transport configured for the send ports.  But this was not the cause of the issue. What a strange issue? Shall we move further with the analysis?

Discrepancy in send port information pattern

Was the DB2 Adapter causing the real problem

On further analysis on this case, we found that DB2 adapter was being used in one of the send ports and it is not a standard BizTalk adapter. The BizTalk Adapter for DB2 is a send and receive adapter that enables BizTalk orchestrations to interact with host systems. Specifically, the adapter enables to send and receive operations over TCP/IP and APPC connections to DB2 databases running on a mainframe, AS/400, and UDB platforms. Based on Host Integration Server (HIS) technology, the adapter uses the Data Access Library to configure DB2 connections, and the Managed Provider for DB2 to issue SQL commands and stored procedures.

The trace logs also indicated a NULL assignment for the Transport type for the send port with this adapter. It’s a prerequisite for BizTalk360, that BizTalk Admin components must be installed in the BizTalk360 server, in case of the BizTalk360 standalone installation. Since DB2 adapter comes with HIS, it was suggested to the customer to install HIS in the BizTalk360 server and observe for the send ports listing. But even after installing HIS, the same issue persisted. We also tried to replicate the same scenario by installing HIS with the DB2 adapter in a BizTalk360 standalone server. The send ports with different combinations of adapters in the transport types were created and tested. But the issue was not reproducible. So, we concluded that the DB2 adapter was not the real cause of the problem.

The Console App made the trick

Sometimes, the issue may seem to be simple. But identifying the root cause of the issue is very difficult. And that too for some strange issues, it would be extremely difficult if the issue is not reproducible. It might not be good to disturb the customers often since they might be busy. Our next plan was to provide a console app to get the complete details of the send ports configured. This app was quite helpful for us to find the root cause. Read further to know the real cause.

The console app was given to the customer to get the complete details of the send ports. The app would give the result in the JSON format with all the details like the name, URI configured, transport type, send handlers etc., The BizTalk application which contained the send port and the database details must be entered in the app to fetch the response.

JSON response with the sendport details for the console app

From the screenshot, we can see that the sendHandler for the secondaryTransport

does not contain the value of transport type. This was the cause for the send port not getting displayed. It was causing the exception.

Finally, the Backup Transport configuration was the cause

We probed further into the case as to why the sendHandler details were not coming up. The Backup transport was configured to “None” in the BizTalk admin console for that send port. Even though it was configured to None, we again asked them to update it again to None and then save it. This time, the issue was resolved and the send port got listed in BizTalk360 UI. It might have happened when importing the send port configuration, back up Transport Type is set to other than “None”. (Type can be empty or NULL).

If Transport type is other than None, then the code will generate the send handler and look for Transport Type. But it could not find the transport type and hence throws an error. The same issue happened in the production environment also and got resolved the same way.

To configure BackupTransport for send port in BizTalk server

Conclusion

When we import the send port configuration, we must make sure that the Backup transport type data is properly set to None. It should not be set to NULL or empty. This way we can make sure that all the send ports are getting listed in the BizTalk360 UI without any problem. We could identify this with the help of the console app.

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.”

Alarm Configuration Changes in BizTalk360 v8.4

Alarm Configuration Changes in BizTalk360 v8.4

Here comes BizTalk360 version 8.4 with a bunch of exciting new features and enhancements as usual. As per the below quotes,

Customers often know more about your products than you do. Use them as a source of inspiration and ideas for product development. – David J. Greer

we always listen to the ideas of our customers and implement them for the product development. We make sure their suggestions are addressed and update them in the feedback portal. Based on the priority of the voting by the customers, the features are added to the product in the upcoming releases.

The Monitoring capability is the key feature of BizTalk360. Setting up monitoring is a very easy and quick task with two step process, create an alarm and map the artefact to be monitored. We can configure three different types of alarms namely Threshold, Health check and Data monitoring alarms.

In BizTalk360 v8.4, there are certain enhancements done as part of the alarms. The following are the features as part of the alarm configuration.

  • Alarm renaming capability
  • Segregation of Data monitoring alarms
  • Alarm bulk status update.

In this article, we will have a look into each one of them.

Alarm renaming capability

Prior to v8.4, we cannot rename an alarm and it would be grayed when we edit an alarm. As per the feedback from many of the customers, we have included this ability in our latest release. So now you can rename the alarm as per the business requirement. This renaming applies to Data monitoring alarms also. Once the data monitor alarm is renamed, it will be reflected in the Data monitoring section as well.

With respect to the database changes, earlier, only the Alarm Name was referred in all the places and now AlarmId is being referred everywhere.

configuring alarms in biztalk360

Limitation:

  • You cannot have same names for two different alarms in the same environment. The alarms can have the same names across the environments.

Segregation of Data Monitoring alarms

In BizTalk360 v7.9 the Data Monitoring functionality was introduced. This also came as a requirement from the customers. It was designed to monitor the data transfer happening in the BizTalk server and trigger alerts based on the conditions set.

In the monitoring home dashboard screen, all the alarms are displayed in a drop down. There might be a chance of unintendingly mapping an artefact to the wrong data monitoring. This confusion can be avoided if the data monitoring alarms are separated from the other alarms. Hence the data monitoring alarms are now segregated and they will be available only in the Data Monitoring section. They will no more be available in the Monitoring home dashboard section and under the Manage Mapping drop-down.

Alarm bulk status update

Under Settings -> Stop alert for maintenance, BizTalk360 has the capability to stop all the alarms from triggering emails. This was as per the feedback from the customer for which we received many votes.

From a business perspective, customers can have created many alarms and a situation might arise that they want to disable certain alarms for maintenance purposes, instead of stopping all of them at once.

enable or disable alarms in biztalk360

In this version of BizTalk360, we can select multiple alarms and enable/disable them at once by clicking on the “Status” button. This is a newly added option for alarm status update. It might look like a small improvement done, but it will be very helpful when doing large implementations and transitions.

alarm monitoring status

What happens during the migration?

Migration scenarios occur when a customer upgrades from a lower version to the latest one. Lot of testing efforts is required to ensure that all the information is retained after migrating from a lower version to higher one. We need to take care that all the data gets migrated without any problem and there is no data loss happening from each of the versions. Also, new changes must get reflected. Extensive testing efforts need to be put to see that this is taken care of and we have assured this.

When the customers migrate from the old versions to the latest one, the ability to edit the alarm name will be shown. The following picture contains some of the migration scenarios that were tested.

monitoring migration in biztalk server

One important thing to be noted is the listing of data monitoring alarms. In the older versions, we can see the data monitoring alarms getting listed along with the other types of alarms. Now in the new version, they will get displayed only in the data monitoring section. However, we can edit the names of those alarms in the Manage Alarms page.

Conclusion

Apart from the alarm configuration changes, we have a lot of new features like Logic Apps Data monitoring, IBM MQ monitoring and folder monitoring. We always hear the feedback and suggestions from the customers and try hard to fulfill them to make our product better and at the same time to achieve 100% customer satisfaction.

You can write to us at support@biztalk360.com. Have a try at our latest version by downloading a 14-day free trial of BizTalk360.

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.”

Alarm Configuration Changes in BizTalk360 v8.4

Alarm Configuration Changes in BizTalk360 v8.4

Here comes BizTalk360 version 8.4 with a bunch of exciting new features and enhancements as usual. As per the below quotes,

Customers often know more about your products than you do. Use them as a source of inspiration and ideas for product development. – David J. Greer

we always listen to the ideas of our customers and implement them for the product development. We make sure their suggestions are addressed and update them in the feedback portal. Based on the priority of the voting by the customers, the features are added to the product in the upcoming releases.

The Monitoring capability is the key feature of BizTalk360. Setting up monitoring is a very easy and quick task with two step process, create an alarm and map the artefact to be monitored. We can configure three different types of alarms namely Threshold, Health check and Data monitoring alarms.

In BizTalk360 v8.4, there are certain enhancements done as part of the alarms. The following are the features as part of the alarm configuration.

  • Alarm renaming capability
  • Segregation of Data monitoring alarms
  • Alarm bulk status update.

In this article, we will have a look into each one of them.

Alarm renaming capability

Prior to v8.4, we cannot rename an alarm and it would be grayed when we edit an alarm. As per the feedback from many of the customers, we have included this ability in our latest release. So now you can rename the alarm as per the business requirement. This renaming applies to Data monitoring alarms also. Once the data monitor alarm is renamed, it will be reflected in the Data monitoring section as well.

With respect to the database changes, earlier, only the Alarm Name was referred in all the places and now AlarmId is being referred everywhere.

configuring alarms in biztalk360

Limitation:

  • You cannot have same names for two different alarms in the same environment. The alarms can have the same names across the environments.

Segregation of Data Monitoring alarms

In BizTalk360 v7.9 the Data Monitoring functionality was introduced. This also came as a requirement from the customers. It was designed to monitor the data transfer happening in the BizTalk server and trigger alerts based on the conditions set.

In the monitoring home dashboard screen, all the alarms are displayed in a drop down. There might be a chance of unintendingly mapping an artefact to the wrong data monitoring. This confusion can be avoided if the data monitoring alarms are separated from the other alarms. Hence the data monitoring alarms are now segregated and they will be available only in the Data Monitoring section. They will no more be available in the Monitoring home dashboard section and under the Manage Mapping drop-down.

Alarm bulk status update

Under Settings -> Stop alert for maintenance, BizTalk360 has the capability to stop all the alarms from triggering emails. This was as per the feedback from the customer for which we received many votes.

From a business perspective, customers can have created many alarms and a situation might arise that they want to disable certain alarms for maintenance purposes, instead of stopping all of them at once.

enable or disable alarms in biztalk360

In this version of BizTalk360, we can select multiple alarms and enable/disable them at once by clicking on the “Status” button. This is a newly added option for alarm status update. It might look like a small improvement done, but it will be very helpful when doing large implementations and transitions.

alarm monitoring status

What happens during the migration?

Migration scenarios occur when a customer upgrades from a lower version to the latest one. Lot of testing efforts is required to ensure that all the information is retained after migrating from a lower version to higher one. We need to take care that all the data gets migrated without any problem and there is no data loss happening from each of the versions. Also, new changes must get reflected. Extensive testing efforts need to be put to see that this is taken care of and we have assured this.

When the customers migrate from the old versions to the latest one, the ability to edit the alarm name will be shown. The following picture contains some of the migration scenarios that were tested.

monitoring migration in biztalk server

One important thing to be noted is the listing of data monitoring alarms. In the older versions, we can see the data monitoring alarms getting listed along with the other types of alarms. Now in the new version, they will get displayed only in the data monitoring section. However, we can edit the names of those alarms in the Manage Alarms page.

Conclusion

Apart from the alarm configuration changes, we have a lot of new features like Logic Apps Data monitoring, IBM MQ monitoring and folder monitoring. We always hear the feedback and suggestions from the customers and try hard to fulfill them to make our product better and at the same time to achieve 100% customer satisfaction.

You can write to us at support@biztalk360.com. Have a try at our latest version by downloading a 14-day free trial of BizTalk360.

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.”

Alarm Configuration Changes in BizTalk360 v8.4

Alarm Configuration Changes in BizTalk360 v8.4

Here comes BizTalk360 version 8.4 with a bunch of exciting new features and enhancements as usual. As per the below quotes,

Customers often know more about your products than you do. Use them as a source of inspiration and ideas for product development. – David J. Greer

we always listen to the ideas of our customers and implement them for the product development. We make sure their suggestions are addressed and update them in the feedback portal. Based on the priority of the voting by the customers, the features are added to the product in the upcoming releases.

The Monitoring capability is the key feature of BizTalk360. Setting up monitoring is a very easy and quick task with two step process, create an alarm and map the artefact to be monitored. We can configure three different types of alarms namely Threshold, Health check and Data monitoring alarms.

In BizTalk360 v8.4, there are certain enhancements done as part of the alarms. The following are the features as part of the alarm configuration.

  • Alarm renaming capability
  • Segregation of Data monitoring alarms
  • Alarm bulk status update.

In this article, we will have a look into each one of them.

Alarm renaming capability

Prior to v8.4, we cannot rename an alarm and it would be grayed when we edit an alarm. As per the feedback from many of the customers, we have included this ability in our latest release. So now you can rename the alarm as per the business requirement. This renaming applies to Data monitoring alarms also. Once the data monitor alarm is renamed, it will be reflected in the Data monitoring section as well.

With respect to the database changes, earlier, only the Alarm Name was referred in all the places and now AlarmId is being referred everywhere.

configuring alarms in biztalk360

Limitation:

  • You cannot have same names for two different alarms in the same environment. The alarms can have the same names across the environments.

Segregation of Data Monitoring alarms

In BizTalk360 v7.9 the Data Monitoring functionality was introduced. This also came as a requirement from the customers. It was designed to monitor the data transfer happening in the BizTalk server and trigger alerts based on the conditions set.

In the monitoring home dashboard screen, all the alarms are displayed in a drop down. There might be a chance of unintendingly mapping an artefact to the wrong data monitoring. This confusion can be avoided if the data monitoring alarms are separated from the other alarms. Hence the data monitoring alarms are now segregated and they will be available only in the Data Monitoring section. They will no more be available in the Monitoring home dashboard section and under the Manage Mapping drop-down.

Alarm bulk status update

Under Settings -> Stop alert for maintenance, BizTalk360 has the capability to stop all the alarms from triggering emails. This was as per the feedback from the customer for which we received many votes.

From a business perspective, customers can have created many alarms and a situation might arise that they want to disable certain alarms for maintenance purposes, instead of stopping all of them at once.

enable or disable alarms in biztalk360

In this version of BizTalk360, we can select multiple alarms and enable/disable them at once by clicking on the “Status” button. This is a newly added option for alarm status update. It might look like a small improvement done, but it will be very helpful when doing large implementations and transitions.

alarm monitoring status

What happens during the migration?

Migration scenarios occur when a customer upgrades from a lower version to the latest one. Lot of testing efforts is required to ensure that all the information is retained after migrating from a lower version to higher one. We need to take care that all the data gets migrated without any problem and there is no data loss happening from each of the versions. Also, new changes must get reflected. Extensive testing efforts need to be put to see that this is taken care of and we have assured this.

When the customers migrate from the old versions to the latest one, the ability to edit the alarm name will be shown. The following picture contains some of the migration scenarios that were tested.

monitoring migration in biztalk server

One important thing to be noted is the listing of data monitoring alarms. In the older versions, we can see the data monitoring alarms getting listed along with the other types of alarms. Now in the new version, they will get displayed only in the data monitoring section. However, we can edit the names of those alarms in the Manage Alarms page.

Conclusion

Apart from the alarm configuration changes, we have a lot of new features like Logic Apps Data monitoring, IBM MQ monitoring and folder monitoring. We always hear the feedback and suggestions from the customers and try hard to fulfill them to make our product better and at the same time to achieve 100% customer satisfaction.

You can write to us at support@biztalk360.com. Have a try at our latest version by downloading a 14-day free trial of BizTalk360.

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.”