Almost one month after I released it, BizTalk Scheduled Task Adapter suffered its first update in order to fix an important bug.
One of the important bugs that were fixed in the previous version (5.0) was the support for timespan with more than 60 seconds, but while doing that, I unintentionally created another bug.
- The adapter was not respecting the start time property defined in the Schedule property page after restarting the Host Instance; instead, it was using the host instance’s date and time.
The time interval defined in the Schedule property page of the receive location must respect the Start time property defined there (and is now fixed and restored the correct behavior in this minor version)
The expected behavior of the BizTalk Scheduled Task Adapter, in this case, is:
- The first message will be triggered at 16:55.
- The second at 17:00.
- Third at 17:05… 17:10, 17:15, and so on.
However, if I stop the host instance, let’s say at 17:18, and start the host instance again at 17:21, the expected behavior of the Scheduled Task Adapter is to:
- The first message will be triggered at 17:25 because it is the next 5 min interval based on the start date defined in the properties, then 17:30, and so on.
Once again, this bug is now fixed and restored the correct behavior in this new minor version.
You can download this new version of the adapter from the BizTalk Scheduled Task Adapter GitHub project page:
📝 One-Minute Brief
One-Minute Brief (TL;DR):
V5.0.4 Changelog
- Bug fixes
- Bug: TimeSchedule didn’t respect the start date defined in the receive location. Instead, it was using the host instance starting date after a restart – Solved
Release History
This adapter has been available since BizTalk Server 2004.
- Release 5.0.4: minor release for BizTalk Server 2013 R2 on March 16, 2015, by Sandro Pereira: bug fixes.
- Release 5.0: released on February 18, 2015, by Sandro Pereira. This adapter was tested to work on BizTalk Server 2013 R2. Compiled in .NET Framework 4.5
- Release 4.0: released on June 12, 2012, by Sandro Pereira. This adapter was tested to work on BizTalk Server 2010. Compiled in .NET Framework 4.0
- Release 3.0: released on Aug 10, 2010, by Greg Forsythe. This adapter was tested to work on BizTalk Server 2009. Compiled in .NET Framework 2.0
- Release 2.0: last release on Apr 20, 2008, by Greg Forsythe. This adapter works with BizTalk Server 2006 and BizTalk Server 2006 R2. Compiled in .NET Framework 2.0
- Release 1.02: last release on Apr 20, 2008, by Greg Forsythe. This adapter works with BizTalk Server 2004, BizTalk Server 2006, and BizTalk Server 2006 R2. Compiled in .NET Framework 1.1
Note: The version change from V5.0 to V5.0.4 because some internal versions were made
Download
You can download this “new” version of the adapter in BizTalk Scheduled Task Adapter from GitHub:
Please feel free to use the adapter, and if you find any problems or bugs, please open an issue on the adapter GitHub site: https://github.com/sandroasp/BizTalk-Scheduled-Task-Adapter and help evolve this community adapter. You can also suggest new features, and I am also open to new ideas.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
Great catch, Sandro. I have not started using the 2013 version yet and I use the Scheduled Task Adapter very often in our client’s BizTalk 2010 installation. Luckily this seems to be a bug only in the new version. 🙂
Hi Sandro,
Since it was compiled under the .NET Framework 4.5, I guess it is also compatible with BizTalk 2013. Could you please confirm this?
Obrigado e cumprimentos
Miguel
is there a way to configure File Mask or wildcards while configuring FileStreamProvider in the Scheduled Adapter like c:Temp*.xlsx
Hi Ashith,
At the moment I think not
I have an environment where we have multiple BizTalk nodes in a group. So, it is trying to run the schedule on all the hosts and creating duplicate requests. Is there anyway we can control with a setting just to use one host instance, like FILE pickup. Whoever is available and comes first, take the job and create the schedule request message.