Remember to set Scheduled Task to future in Biztalk 2016 part 2 (and how to forget it)

(Update 15.3.2021)

According to Sandro Pereira’s blog post Scheduled Task Adapter is now updated and these triggering issues should be issues no more. Get the new adapter version here https://github.com/sandroasp/BizTalk-Scheduled-Task-Adapter/tree/master/BTS2020

Okay, this Scheduled Task Adapter issue didn’t leave my mind alone in the holidays. I made an issue to Scheduled Task Adapter’s GitHub repo and thought that maybe I should investigate this thing a bit further. I also noticed that there was similar mentions about issues in the comments of Sandro Pereira’s blog post about the adapter.

Get the code

The Scheduled Task Adapter’s code is not publicly available anymore since the shutdown of Codeplex. But wait, there’s Codeplex Archive. With some fiddling around I downloaded the source code for Scheduled Task Adapter. But this archived version was not the latest version that is published in GitHub.

Reverse Engineering

I checked the code and was quite certain that code from Codeplex Archive was maybe one or two versions behind GitHub version. I found out that the task triggering time was handled in Calendar.Schedules project of the solution. Now in the Sandro’s blog post comments and GitHub issues there were mentions about the using of DateTime.UtcNow causing issues. In the code that I got from archive I sure found out that DateTime.UtcNow was used.

Well I then grabbed Ildasm and opened Calendar.Schedules.dll from the latest release of the adapter. To my suprise there was no sign of the DateTime.UtcNow anymore, but there was DateTime.Now.

So I thought that replacing DateTime.UtcNow with DateTime.Now in Schedules.cs would be a good idea. There was actually commented Datetime.Now rows before DateTime.UtcNow code rows, so I just swapped the comments resulting the use of Now instead of UtcNow.

Further look to the code

Then I scrambled through the code in Calendar.Schedules project and specailly TimeSpanSchedule.cs file. Found out that the method GetNextActivationTime where the next trigger time was calculated, had code that just added the TimeSpan value to the current machine time. So the issue that I nagged about in the last blog post was actually a feature!

But there was interesting code commented at the end of the GetNextActivationTime method.

And there it was! That had to be the code that calculated the next trigger time in the BizTalk 2013 R2 (and 2009) versions of the Scheduled Task Adapter, feature that I was so used to trust.

“The Fix”

I took the mentioned commented code and placed it to where next trigger time was calculated and commented out the current calculation code (//return now.AddSeconds(this.timeSpan);). Then I built the solution, took Calendar.Schedules.dll, placed it to the Scheduled Task Adapter installation folder and finally added the dll to gac (gacutil /if).

Next stop testing. I restarted the host instance running my Schedule receive location, set the schedule to run in every minute and waited rloc to trigger. Everything looked good, but I scheduled the task to future. What about then if I set the schedule to past time… I set the trigger date to yesterday and tested again. The task triggered still at 00 seconds! Great! Then I restarted host instance and checked the result again. Still running fine!

I still have to test the modification thoroughly and with other scheduling methods (Daily, Weekly, and so on) to be sure, but I’m quite sure that my modification will work as expected since I actually didn’t add any new code.

If you like to know more or need this modification don’t hesitate to connect me. I’ll be happy to help.