Terminating Dehydrated Service instances through BizTalk360 PowerShell Notification channel

Terminating Dehydrated Service instances through BizTalk360 PowerShell Notification channel

BizTalk360 has introduced notification channels from its major version release V8.0. One of the most greeted features from our customers. With the introduction of this capability, it’s easy to send alerts to any external systems like your ticketing system, internal databases, calling REST endpoints or executing PowerShell scripts.

One of the most powerful capabilities is to use an API, to enable you to create notification channels for connecting to your own systems. The PowerShell notification channel allows you to execute a PowerShell script, each time an alarm is triggered when the threshold is crossed.

During business transactions in mission-critical BizTalk Server environments, if any of the service instances are waiting for response messages, they will be turned to the dehydrated state. There might be valid reasons why such service instances are not needed anymore. So, as a BizTalk administrator, you should keep an eye on these instances in their environments to avoid further critical business consequences.

BizTalk360 provides Monitoring capabilities for dehydrated service instances and it sends periodic alerts via different notification channels. One such channel is the PowerShell Notification channel.

This blog post will give you an insight about how to terminate the dehydrated service instances through the PowerShell notification channel in BizTalk360, just by configuring it with the Alarms.

Steps to implement the PowerShell Notification Channel

1. Create the PowerShell script
2. Configure the PowerShell notification channel
3. Configure the PowerShell notification channel with the Alarm

Creating the PowerShell script

To develop the PowerShell script, it is essential to identify the API’s which will take care of these actions.

Step 1:

Retrieve the dehydrated service instances from the Message Box using the below API.
http://localhost/BizTalk360/Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceQuery

Code Snippet


import-Module Microsoft.PowerShell.Management
$username = "DomainUserName"
$password = "ABC1236890"
$password_base64 = ConvertTo-SecureString $password -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential ($username, $password_base64)
$body_ExecuteServiceInstanceQuery='{
"context":{
"callerReference":"REST-SAMPLE",
"environmentSettings":{
"id":"3beb9328-c435-47ed-8c51-a406117e632b",
"licenseEdition":0
}
},
"query":{
"compositeFilter":{
"filterDescriptorCollection":[
{
"member":"Instance Status",
"filterAvailableMember":[
{
"name":"Application",
"alias":"Application Name",
"dataType": 1,
"isList":true,
"isAutoComplete":false
},
{
"name":"CreationTime",
"alias":"Creation Time",
"dataType":0,
"isList":false,
"isAutoComplete":false
},
{
"name":"GroupResultsBy",
"alias": "Group Results By",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "HostName",
"alias": "Host Name",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "InstanceStatus",
"alias": "Instance Status",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "ServiceClass",
"alias": "Service Class",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "ServiceInstanceID",
"alias": "Service Instance ID",
"dataType": 1,
"isList": false,
"isAutoComplete": false
},
{
"name": "ServiceName",
"alias": "Service Name",
"dataType": 1,
"isList": true,
"isAutoComplete": false
},
{
"name": "ServiceTypeID",
"alias": "ServiceType ID",
"dataType": 1,
"isList": false,
"isAutoComplete": false
}
],
"memberType": 1,
"filterOperator": 2,
"value": "Dehydrated",
"progressIndicator": false,
"validationError": "",
"isValid": true,
"tempValue": ""
}
]
},
"maxMatches": "10",
"queryType": 0
},
"maxMatches": "10"
}'
$headers=@{"Content-Type"="application/json"}
$uri="http://BT360SUP03/BizTalk360/Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceQuery"
$response = Invoke-WebRequest -Uri $uri -Headers $headers -Method Post -Body $body_ExecuteServiceInstanceQuery -Credential $creds

Step 2:

Pass the retrieved dehydrated service instances for the termination process to the below API.

http://localhost/BizTalk360//Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceOperation

Code Snippet


$ExecuteServiceInstanceQueryobj = ConvertFrom-Json $response
if (!$ExecuteServiceInstanceQueryobj.serviceInstances) {write-Host "There are no dehydrated service instances for termination"}

foreach ($serviceinstance in $ExecuteServiceInstanceQueryobj.serviceInstances)
{
$body_ExecuteServiceInstanceOperation='{
"context":{
"callerReference":"REST-SAMPLE",
"environmentSettings":{
"id":"3beb9328-c435-47ed-8c51-a406117e632b",
"licenseEdition":0
}
},
"serviceInstances":[
{
"ServiceName": "'+$($serviceinstance.ServiceName)+'",
"ServiceClass": "Orchestration",
"StatusDisplayText": "Dehydrated",
"Application":"'+$($serviceinstance.application)+'",
"ServiceInstanceID":"'+$($serviceinstance.serviceInstanceID)+'"
}
],
"operation": 1
}'
$headers1=@{"Content-Type"="application/json"}
$uri1="http://localhost/BizTalk360//Services.REST/BizTalkQueryService.svc/ExecuteServiceInstanceOperation"
$response1 = Invoke-WebRequest -Uri $uri1 -Headers $headers1 -Method Post -Body $body_ExecuteServiceInstanceOperation -Credential $creds
$ExecuteServiceInstanceQueryobj = ConvertFrom-Json $response
}

Points to Remember

Following are the parameters need to be changed as per your environment configuration.

  1. Service Account credentials for UserName
  2. Password
  3. Environment Id
  4. URI

As mentioned in the introduction section, BizTalk360 exposes its APIs and can be found in the section Settings -> API documentation.

Terminating Dehydrated Service instances - API Documentation screen

Configuring the PowerShell Notification channel

Once the PowerShell script has been created, the next step is to configure it with the notification channel in BizTalk360.The PowerShell notification channel can be found in Settings -> Monitoring Notification Channels ->B360.Notifier.PowerShellNotification.

Terminating Dehydrated Service instances - Configure PowerShell Notification channel

Select the notification channel and click on the “Configure” button on the top menu bar. In the Configuration Notification Channel section, enter the location of the script which has been created for terminating the dehydrated service instances and click on the Configure button. Now, the PowerShell script has been configured with the BizTalk360 notification channel.

Terminating Dehydrated Service instances - Associate the Powershell Script Path

Associating the PowerShell Notification Channel with Alarms

The next primary step is to Map the notification channel with the Alarms for further execution and configure the Threshold violation settings, as how frequent you want to terminate the dehydrated service instances from your environment. Based on the settings, BizTalk360 will terminate the dehydrated service instances in your BizTalk Server environment.

Terminating Dehydrated Service instances - Alarm Configuration with PowerShell Notification Channel

Terminating Dehydrated Service instances - Threshold Alarm Settings

Conclusion

We strongly believe BizTalk360 has transformed the way you do your work. It is a very common situation where administrators depend on various tools like BizTalk admin console, SQL queries and other custom build tools to monitor their BizTalk Environment. But with this capability “PowerShell Notification Channel”, administrators can create their own scripts and automate their daily activities. In this blog post, we have explained one such scenario we can accommodate with BizTalk360. This capability is not restricted for some functionalities, the component is generically implemented in the product where our customers can achieve a lot more business scenarios by using this powerful capability.

Do try BizTalk360 one-stop monitoring tool for your BizTalk Server.

Author: Mekala Ramesh

Lead QA & Product Support at BizTalk360 – Having around 8 years of experience in software testing & customer support field with the strong knowledge in SDLC and STLC phases. Specialized in various types of testing methodologies. Passionate tester, who always want to deliver the software product with the best quality to the end customers. Possess strong knowledge, to establish the testing process from scratch. Playing a pivotal role in BizTalk360 is making me deliver the product to every customer in a delicious way. View all posts by Mekala Ramesh

Introducing Send Port Groups management and Reset Functionality in BizTalk360 Monitoring

Introducing Send Port Groups management and Reset Functionality in BizTalk360 Monitoring

BizTalk360 v8.9.5 has been released for the public with lots of exciting new features. Many of our customers have already ugraded to the latest version and started experiencing the new features. As you know, BizTalk360 will always listen to customer ideas and implement them for the product development as like

“Software quality begins with the quality of the requirements.”

We gather those requirements through the BizTalk360 feedback portal and make sure to address customers ideas and suggestions. Based on the number of votes. we came up with new features and enhancements, with intuitive design, in our latest version, as follows:

  • Action on Send Port Groups
  • Alarm Reset Capability
  • Autocorrect Reset Capability

Above three features are the most awaited features by the customers. This will increase usability and will ease the process to maintain and monitor the BizTalk artifacts. Here we go!

Action on Send Port Groups

One of the major functionalities we are bringing is the ability to action on Send Port Groups. After getting several customer feedbacks, we are bringing this new feature in our latest release, which will ease the operation and monitoring capabilities.

A Send Port Group is a collection of Send Ports that BizTalk Server can use to send the same message to multiple destinations in one configuration. In earlier versions, user can search and view the Send Port Groups, however there was a gap in performing actions in BizTalk360. In this new version, we have added operational capabilities such as Start, Stop, Enlist and Unenlist for Send Port Groups as in line with BizTalk server.

Send Port Groups Operation

As there is a famous saying “Intuitive design is how we give the user new superpowers”, we have improved the Application Home Page UI. From now on, you can view all the available Send Ports, Receive Ports, Receive Locations, Orchestrations, Send Port Group and the associated Host Instances in the home tab for easy access.

Application Home tab

The BizTalk user can also audit the Send Port Groups activities in the Governance and Auditing sections. Once the user performs an action on Send Port Groups, it gets tracked on Application activities and User Activities with details as below.

Send Port Groups Auditing

The actions you perform on Send Port Groups are getting tracked and you can audit that on live through “Live Feed” as shown below.

Send Port Groups Live feed data

As you already know, Monitoring is one of the core functionalities of BizTalk360. With this functionality, you can monitor all the BizTalk artifacts and when the artifacts go down, you can perform actions through the auto-healing functionality, except, until earlier versions of BizTalk360, for the Send Port Groups. Now, the Monitoring capability has also been provided for the Send Port Groups.

Send Port Groups Monitoring

Note: To know the detailed information of Send Port Groups monitoring click here.

Alarm Reset Capability

Prior to v8.9.5, the alarm will get reset in two scenarios as follows.

  1. Manually select the respective alarm and Reset the Notification Counter
  2. Notification Counter will be reset once all the mapped artifact status are in the healthy state

As per the feedback from several customers (as below), we have included Auto Reset ability in our latest release.

Alert Reset limit can be set in Alarm configuration section as shown in the below screenshot.

Alarm reset configuration

Once the notification limit has been reached, the alarm will auto reset the counter after the configured X minutes.

Autocorrect Reset Capability

Prior to v8.9.5, as same as with an alarm, the Auto Correct configuration will get reset in two scenarios. The Auto Correct will get reset, once after the auto healing is successful:

  1. Auto Correct ‘Max Retry’ counter will be reset after the successful auto healing of the mapped artifacts
  2. Associated Auto Correct mappings will be reset after the alarm reset

But we don’t have the capability, to reset the Auto Correct automatically. As per the feedback from several customers, we have implemented Auto Correct Reset functionality in the latest version.

Customer feedback for Autocorrect functionality

Now, With Auto Correct parameters “Max Retry” and “attempt”, an additional parameter has been added, which is “Reset Interval”. The user can configure the time interval to do automatic Auto Reset. This configuration will reduce the manual intervention every time when the ‘Max Retry’ counter reaches it limit.

Reset Interval configuration in Autocorrect

Conclusion

We hope that the above features will increase the usability and reduce the manual work to reset. Are you tired of constantly having to monitor your BizTalk environment in a manual fashion? Give BizTalk360 a try and take benefits of newly added features. A trial version of BizTalk360 can be requested here.

Introducing Send Port Groups for Monitoring in BizTalk360

Introducing Send Port Groups for Monitoring in BizTalk360

We are super excited to welcome our new release version of BizTalk360, v8.9.5. Here is a blog which explains the new feature introduction of Send Port Groups Monitoring in BizTalk360 v8.9.5.

One of the most powerful and overlooked features in BizTalk Server is Send Port Groups, helps to route a single message to more than one destination. A Send Port Group is a collection of send ports that BizTalk Server can use to send the same message to multiple destinations in one configuration. Now, you can monitor Send Port Groups in BizTalk360.

Customer Feedback

As you already know, Monitoring is the core functionality of BizTalk360. With this functionality, you can monitor all the BizTalk artefacts except the Send Port Groups in the earlier versions of BizTalk360.

In BizTalk360, we aim at improving the product and adding new features based on customer feedback and business scenarios. The Feedback portal is one such platform for the customers to provide their suggestions, which can be voted upon by other customers if they feel that these ideas fit in their business requirements as well. It’s based on the priority of voting; the features and enhancements get picked up for development. One such feedback was Send Port Groups monitoring on BizTalk applications.

Customer Feedback for Send Port Group Monitoring

Hence, we have chosen Send Port Groups monitoring for one of the features in this release.

Send Port Groups Monitoring in BizTalk360

Send Port Groups is a “key” feature of BizTalk Server’s “Publish and Subscribe” architecture, where a publisher can have more than one subscriber.

User Scenario: Let’s say you need to map an inbound XML document to three different outbound formats and send each outbound document to a different system. All that’s required is a Send Port Group and a simple Filter Expression. The Send Port Group handles the Filter Expression with each Send Port using its own map! If any of the three transmissions fail, you can resubmit the failed message without resending the other two documents. The user may have one or more Send Port Groups. It can be hard to monitor your Send Port Groups manually. Now with the support of BizTalk360, you can monitor the Send Port Groups easily! In BizTalk360, we have included the Send Port Groups for monitoring for each BizTalk Application. The user can monitor the Send Port Groups by mapping with the alarm as below.

Alarm Mapping for Send Port Group Monitoring

The Send Port Group can go down for some situation; you can monitor the artifact in such situation by configuring the expected state in BizTalk360. When the current state is not equal to expected state, the user will get notified through an alert, as shown below.

Email Template for Send Port Group Monitoring

The same error and status will be displayed in the Monitoring dashboard and in the Errors and warning section as seen below.

Alarm Dashboard for Send Port Group Monitoring

Auto Healing functionality for the Send Port Groups

By any chance, when the Send Port Group artefact goes down for some specific reason, you need not to log in to the BizTalk server to make it up again. BizTalk360 Auto Correct feature will get it back to the expected state automatically with the Auto correct option. For this, the user needs to enable Auto Correct for the configured Send Port Groups.

Auto Correct for Send Port Group Monitoring

If in case the system is not able to Auto Correct Send Port Groups to its expected state i.e., when all the attempts to auto correct have failed, then the user will receive a down alert. For each attempt, the user will get notified with the detailed status information of auto correction operation that has happened on a Send Port Group. With this information, the user can get a clear picture of what is happening with the state of the Send Port Group.

User Scenario:  In BizTalk, the user cannot Start or Stop the Send Port Group from “unenlisted’ state when all the associated Send Ports are in “Unenlisted” state.In such scenario, there is a chance that the auto-healing may get failed to heal the Send Port Group from the “unenlisted” state to expected state and the auto correct attempts will get failed since the associated Send Ports gets “Started” or “Stopped” state.

Once all the maximum attempts failed, then the user will get intimated through down alert as “Maximum auto corrects attempts have been exhausted”.

Intelligent auditing

 BizTalk360 has very good intelligent auditing capabilities that will help administrators to find out “Who did what in the environment”. When the auto-healing is successful, it gets tracked at the Send Port Group level under “Application Activities” in Governance and Auditing section.

Auditing the Auto Correct for Send Port Group Monitoring

Live Activity Recorder

BizTalk360 has excellent Live activity tracking feature which helps you to govern user actions efficiently without compromising on regular activities. You can view the Live recording of all the user activities through the “Live Feed” on each successful auto healing of Send Port Groups. 

Live Feed - Auto Correct activity for Send Port Group Monitoring

This feature will be available in our upcoming release of BizTalk360 v8.9.5. Stay tuned to monitor and maintain the Send Port Groups easily through auto healing functionality.

Stop Alerts for Maintenance during Business Holidays

Stop Alerts for Maintenance during Business Holidays

Introduction

We are super excited to announce the availability of another interesting improvement in our upcoming version! BizTalk360 will allow you to setup monitoring maintenance, based on the business holidays configured for the environment.

Sometimes, administrators setup the maintenance period during new deployments or installation of security patches in their BizTalk environment. In such situations, to temporarily stop the monitoring in BizTalk360, there is a feature available “Stop Alerts for Maintenance”. Using this capability, the user can set the multiple future maintenance windows to stop false alerts being triggered from BizTalk360. This feature can be found in the Settings area of the application.

Initially, BizTalk360 allowed users to set only a single maintenance window. From v8.8 onwards, users can setup multiple future maintenance windows. So, during these maintenance periods the alarms will be disabled and no notifications will be sent from BizTalk360. At the same time, a maintenance notification will be shown in the Home dashboard and in the Stop Alerts for Maintenance Settings section. Refer to this article, to know more about this enhancement.

What is the new enrichment?

The basic idea here, is that perhaps if a user is able to setup multiple maintenance windows, they need to configure the business holidays individually. It will take much of your time, to configure for every single environment in BizTalk360. To reduce the time and ease the maintenance configuration for the users, the capability to add business holiday calendars has been introduced.

Stop_Alerts_for_Maintenance_during_business_Holidays_business_Holiday_calendar_tab_sub_section_in_settings_section

What is a business holiday calendar?

BizTalk360 provides this new capability to configure the business holidays in a calendar. These business holiday calendars can be mapped during maintenance window setup. This new configuration section is introduced in the Monitoring Notification settings section as “Configure Business Holidays”.

Using this intuitive UI, users can configure the business holidays in a calendar and save it for further mapping during the maintenance setup process.

Stop_Alerts_for_Maintenance_during_business_Holidays_Create_new_business_Holiday_Calendar

Let’s take an example: as a user, I wanted to configure a calendar for London business holidays. By clicking the “New” button, you can access the screen to configure the business holiday calendar.

Stop_Alerts_for_Maintenance_during_business_Holidays_business_holiday_calendar_configuration_section

After providing the basic details (Holiday Calendar Name, Description, Status), you can configure the dates for the business holiday in the Calendar Configuration part of the screen. For each date selection, a set of text boxes will be generated. The user has the liberty to provide their own text for the selected dates. On the right-hand side of the calendar configuration section, there are two checkboxes. Using these checkboxes, a user can include Saturdays and Sundays in the maintenance window. You can select both options or either one option, based on the business need.

Stop-Alerts-for-Maintenance-during-public-Holidays_Adding_public_holidays_to_the_calendar

Once the calendar is configured with business holidays, the user can save it for further use. The calendar will be listed in the Manage Business Holiday grid view. At any point in time, a user can add/delete new business holidays to the existing calendar configuration and save it. The changes will be updated automatically and maintenance will happen accordingly.

Preventing the business holiday calendar from accidental deletion

There is a chance that a configured calendar becomes deleted accidentally. The UI is designed in such a way that accidental deletion of calendars which are associated with maintenance windows is prevented. By any chance, if a user tries to delete a calendar which is associated with a maintenance window, a message will be shown in the UI that deletion is prevented.

Stop_Alerts_for_Maintenance_during_business_Holidays_business_Holiday_Calendar_Delete_Scenario_error_message

How to associate the business holiday calendar to maintenance windows?

In the Stop Alerts for Maintenance settings page, A new section is introduced to configure the business holiday calendars. All the configured calendars with Status enabled will be displayed in the “Select Business Holiday Calendar” dropdown list. A user can select the desired calendar and use it for a maintenance window. During the business holiday, a maintenance window will be active.

Stop_Alerts_for_Maintenance_during_business_Holidays_Holiday_Calendar_association_for_alert_maintenance

There is a new tab “Business Holidays” added in the grid section to view the configured business holidays to the calendar.

Stop_Alerts_for_Maintenance_during_business_Holidays_List_of_dates_configured_in_the_calendar_will_be_displayed

Excluding alarms during maintenance

wherewith this capability, users can exclude alarms during the maintenance. This means, that, except the selected alarms, other alarms will undergo maintenance.

Scenario: Enable Monitoring for few alarms (for example to monitor system resources) during deployments or security patch updates.

Let’s consider a situation, where administrators have configured critical alarms to monitor the system resources (CPU usage, Memory usage) of their BizTalk Environment in BizTalk360. It is important to monitor these resources in their BizTalk Environment to identify any performance glitches as early as possible to avoid significant business consequences.

In such scenarios, there will be a need to keep those alarms always on. Though the environment is in maintenance mode, if administrators wanted to monitor their system resources, they can make use of this new capability.

This capability is very useful in situations where administrators don’t want to receive alerts during the weekends except for few alarms.

Stop_Alerts_for_Maintenance_during_business_Holidays_Exclude_alarms_during_maintenance_option

Conclusion

Definitely, these improvements are like icing on the cake to our existing Stop Alerts for Maintenance capability. Happy migrating and try BizTalk360!!!

Get started with the free 30 days trial. For any queries/feedback please write to us support@biztalk360.com.

Author: Mekala Ramesh

Test Lead at BizTalk360 – Software Testing Engineer having diverse exposure in various features and application testing with a comprehensive understanding of all aspects of SDLC. Strong knowledge to establish the testing process from the scratch. Love to test the software product to deliver it with good quality. Strongly believes on “Testing goes beyond just executing the test protocol”. View all posts by Mekala Ramesh

How we solved daylight saving issue?

How we solved daylight saving issue?

DST in General

It is a universal practice around the world to observe daylight saving time(DST). We all moved our clocks one hour forward this last March. We woke up an hour sooner, had some additional espresso and tried to adjust to the jet-lag. Every spring we set the clocks forward and winter we turn the clock back. Most nations do not participate in DST and even within the USA, not all the states are participating in DST.

Real business scenario

In the software business, it is fundamental part to deal with business situations cautiously during the DST time. For instance, a company has rules created in an order taking system, that the order depends on the time of the order – if the clock changes, the rules might not be as clear. Like this, there are infinite scenarios we can consider.
In the integration business arena, a flow of the business information may happen from one end of the world to another. For this kind of situations, the business decision logic may work based on the time. Likewise, in BizTalk Server, administrators dependably should watch out for the deployed applications, its artifacts states and flow of the information. In case of anything turns out badly, there may be a huge effect on the mission-critical business (Eg: Banking, Insurance, Healthcare, Logistics etc.,). To stay away from these issues, BizTalk360 is used as an integral tool in 500+ business in 30+ nations.

Advanced Monitoring in BizTalk360

In BizTalk360, we have powerful monitoring capabilities to monitor the business information using the query builder functionality, which is looking for the information about suspended service instances, running service instances, tracked Service instances and tracked message events. Similarly, you can query BAM views, perform activity searches, filter out ESB exceptions, query the event logs and monitor Azure Logic apps.

Daylight Saving: Data Monitoring Dashboard

While monitoring this data, BizTalk360 will send notifications to many notification media. These media contain Email, SMS, inbuilt notification channels like Slack, ServiceNow, and Webhook. Customers can also create their own notification channels to receive the alerts from BizTalk360. To know more about our advanced data monitoring capability click here “https://assist.biztalk360.com/support/solutions/folders/1000221446”.

Problem Statement

We wanted to share our experience in solving a daylight-saving issue in our application for a specific scenario, where the email alerts are sent from the application properly during the normal days, whereas false alerts will be sent once during the daylight-saving time. We started investigating the scenario in deep to nail down the problem.

Forward Scenario

Consider below EST (Eastern Time Zone, UTC-5:00) DST change as an example.

Daylight Saving: Forward example

Set the system time zone settings as (UTC-08:00) Pacific Time (US & Canada) in BizTalk360.
Sunday, 11 March 2018, 02:00:00 clocks were turned forward 1 hour, to 03:00:00.
Let’s consider a scenario where Message Box data monitor is configured to monitor the suspended service instances for a purchase order application on an hourly basis. There is a column to show “Next Run At“ time which populates the next expected cycle for the data monitor. For an hourly based scenario, it will populate data consistently to notify the next run cycle. At the time of DST, in the 1:00 am cycle, next run time should be calculated as 3:00 am. Instead of this, Next run cycle is computed as 2:00 am. The BizTalk360 monitoring service will pick this time and try to convert the invalid time for further processing. Due to the invalid time, an exception appears in the email for only that monitoring cycle.

Daylight Saving: Email notification

Backward scenario

Sunday, 4 November 2018, 02:00:00 clocks are turned backward 1 hour to 01:00:00.
In the Fallback scenario, the issue won’t appear since the clock will be turned backward 1 hour and the monitoring service will come to look for the Next run time and wait until that time for further processing.

Code Snippet

As the problem stated above, DST adjustment has not been handled in the inbuilt .Net libraries. BizTalk360 properly calculates DST from V8.8 version onwards. In the below code snippet, in the highlighted text you can find the logic.

TimeZoneInfo timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById(regionalSetting.timezone.timezoneId);
if (timeZoneInfo.SupportsDaylightSavingTime)
{
    DateTime dateTime = nextRunDateTime;

    if (timeZoneInfo.IsAmbiguousTime(dateTime))
    {}

    if (timeZoneInfo.IsInvalidTime(dateTime))
    {
        DateTime adjustedDateTime = Helper.AdjustDateTimeForDSTChange
       (dateTime, regionalSetting);
    }
}

public static bool IsValidDateTime(DateTime dateTime, SystemRegionalSetting regionalSetting)
{
    TimeZoneInfo timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById
    (regionalSetting.timezone.timezoneId);

    return timeZoneInfo.IsInvalidTime(dateTime) ? false : true;
}

public static DateTime AdjustDateTimeForDSTChange(DateTime dateTime, SystemRegionalSetting regionalSetting)
{
    TimeZoneInfo timeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById
    (regionalSetting.timezone.timezoneId);

    return dateTime.Add(timeZoneInfo.GetUtcOffset(dateTime.AddDays(1)) - timeZoneInfo.BaseUtcOffset);
}

Testing

Time conversion is much more complicated than you imagine, because different countries/locales switch to daylight saving time at different dates, it is not just one sweep change. Hence, we have thoughtfully derived the scenarios for testing to cover all the combinations.

Following are the test scenarios which we need to take care of during the DST testing:
1. UTC (Coordinated Universal Time)
2. GMT time zones which observers DST during summer time (Eg: British Summer Time)
3. UTC –(Minus) time zones which observe DST (Eg: Pacific Time US & Canada)
4. UTC –(Minus) time zones which don’t observe DST (Eg: Arizona)
5. UTC + (Plus) time zones which observe DST (CEST)
6. UTC +(Plus) time zones which don’t observe DST (IST)

Conclusion

We took a just more efficient way to solve the DST issue in our recent version 8.8. Happy migrating and try BizTalk360!!! Get started with the free 30 days trial. For any queries/feedback please write to us support@biztalk360.com.

Author: Mekala Ramesh

Test Lead at BizTalk360 – Software Testing Engineer having diverse exposure in various features and application testing with a comprehensive understanding of all aspects of SDLC. Strong knowledge to establish the testing process from the scratch. Love to test the software product to deliver it with good quality. Strongly believes on “Testing goes beyond just executing the test protocol”. View all posts by Mekala Ramesh