Michael Stephenson

keeping your feet on premise while your heads in the cloud
posts - 358 , comments - 425 , trackbacks - 11

My Links

News

View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn

Twitter












Archives

Post Categories

Image Galleries

BizTalk

Mates

Implementing scheduling requirements in BizTalk solutions

Written by: Michael Stephenson (http://geekswithblogs.net/michaelstephenson)

The Scenario

This is a common scenario with potential BizTalk solutions. You are implementing a process which needs to be triggered at specific points. The problem you have is that BizTalk doesn’t really do scheduling. There are service window features in BizTalk where you can control when messages can be received or sent, however this depends on a message being already there.
What you really want is a trigger to start the process. This article is intended to cover some of the solutions I have seen or heard about and other ideas on this. If you have any additional ideas which I don’t mention then please point me to your source.
 
Scheduling from SQL Server Job Agent
When you implement BizTalk you will automatically be using SQL Server, and therefore also using the SQL Server Agent to schedule and run the database jobs which maintain a healthy BizTalk setup. You could also take advantage of this feature to use the SQL Server Agent to schedule a job which you use to trigger BizTalk.
SQL Server would take care of the scheduling and allow your BizTalk Administrator to manage the jobs. The bit you would also need to do is to work out how to get a message into BizTalk. The most common approaches I have seen is to write a script of executable and then call that from the SQL Job. The custom code would then do something like create a file or call a web service, etc which would get a message into the message box and as result start your process.
This technique is quite easy and uses tools you will already have so there will be no additional cost. It is also easy for your BizTalk Administrator to manage.
In terms of failover and disaster recovery this solution should be in line with your standard practices for your clustered SQL Server. 
 
Scheduling from Windows Task Scheduler
Another option would be to use the Windows Task scheduler to execute a batch file or custom executable. The normal ways I’ve heard about this being done is to in a similar way to the SQL Server Agent write out a file or call a service.
While the task scheduler may be suitable for demo purposes I wouldn’t really recommend it for a production environment because you would only want to have the schedules enabled automatically on one server. If that server went down you would need to solve the problem of enabling the schedule on a different server. To me this is quite a big disadvantage so I wouldn’t really use this approach and would favour the SQL Server Job Agent. Also your BizTalk Administrator would have multiple places to manage the jobs.
 
Scheduled Task Adapter
There is a scheduled task adapter available on CodePlex and is available from the following location: http://www.codeplex.com/BizTalkScheduledTask/
The Scheduled Task Adapter provides a similar interface to the Windows Task scheduler but it is hosted as an adapter in BizTalk. It contains 3 different ways you can push a message into BizTalk when your schedule fires. These are:
-          An xml string as set in the adapter properties
-          A message extracted from a particular file
-          A message downloaded from a web site
I quite like the way you can also create your own classes to create the message you want provided you use an interface defined by the code that comes with this adapter. Based on what I have seen, the one key thing I’m not sure about and doesn’t seem to be covered by the documentation is how you would manage this adapter in a multi server environment. I would assume that the adapter would send two messages to BizTalk if you had this port running on 2 BizTalk boxes. A similar scenario to the FTP adapter if it is not clustered where you have to only have one host instance running at a time.
I think if you are considering this adapter you would need to do a POC to validate it works as you require in a multi server environment or you would need to work out a duplicate elimination process for your solution.
 
Frends
Frends is a Microsoft Gold Partner who have a product which is complimentary to BizTalk and contains a number of components which can help you deliver quality BizTalk and BPM solutions. One of the Frends components is a scheduling component which allows you to define quite complex schedules which can then use the Frends workflow components to trigger a BizTalk process.
The cool bits about Frends are:
·         There is an Administration interface which is similar to the BizTalk one
·         You can easily manage and track your scheduled instances
·         There is integration with HAT so if your schedule has a problem you can open the message flow for the specific instance directly from the Frends UI. This makes tracking and troubleshooting the process very easy.
·         Schedules are abstracted from the routines that they run meaning you don’t end up with a million schedules to manage. You can say specify a schedule which is once per day at 2am, and then a number of routines can be assigned to this schedule. If you need to move all routines then you can do this just by updating the schedule instance.
·         Frends provides an enterprise level scheduling capability and supports a similar scaling, disaster recovery and fail over model to BizTalk
·         The team at Frends are also really cool and very helpful when you are working with them
As with all 3rd party products there is a cost associated with the Frends product. I think if you will also benefit from the other features of Frends then you should definitely consider this product as it is also easy to implement. 
To find out more info about Frends check out their website: http://www.frends.com/
 
Other
I have also seen products like Tivoli used on some projects. I think if your client already has an enterprise level scheduling tool that is used to manage other similar jobs then it is always good to consider using that. However if a company is making a strategic move towards a Microsoft based BPM solution then scheduling is a key part of that and you should also consider if value can be gained by moving to a Microsoft compatible product. By this I mean that the scheduling when you have another product involved means you also need another skill set to maintain it. The above solutions would all be easily maintainable by a BizTalk Administrator however with the Tivoli solution I mention here and potentially other options you need to consider how these will be managed and if there will be internal costs associated with this. You would also need to be aware and declare your interest in the road map for this other scheduling tool within your organisation as this would have a direct impact on your project.
On the project where I saw Tivoli used the way we integrated with BizTalk was again the same as the SQL Server Agent techniques by using a script of executable which was called. I think when you are considering non Microsoft orientated scheduling tools you are likely to lose the end to end interactive traceability which with Frends is a really useful feature.
 
Summary
As with most design decisions there is not usually a right or wrong answer, it is mostly what best fits your scenario. What I’ve tried to do in this article is to provide some information and thoughts around some of the choices you have. In terms of my opinion what I would say is for this particular requirement the SQL Agent is a good all round choice to consider and has no additional charge or special skill requirements. In most cases this can do the job just fine. If you want some nice features and can get benefits from the other features it offers then Frends is definitely worth consideration too.
I think the key thing to remember here is that all of the choices do offer a scheduling ability but you need to ensure your chosen solution will be able to survive in an enterprise solution and not just do the job for a single machine POC.

Print | posted on Friday, May 16, 2008 9:25 PM | Filed Under [ BizTalk ]

Feedback

Gravatar

# re: Implementing scheduling requirements in BizTalk solutions

I haven't seen the Frends implementation so cannot really comment on that, but I am a big fan of the scheduling adapter.

I really like the fact that it keeps everything tucked nicely within the BizTalk server configuration and runtime boundary. there are virtualy no dependencies (other than if you rely on somethng to generate the message for you)
I particularly like the fact that you can write your own provider for the message submitted, which means it is completely extendible (not so with regards to the scheduling logic, but thats understandable).

It is a very good point regarding the scalability, and I have not tested but I would agree with your guess regadling the similarity with the FTP adapter in that respect. but that is true for several adapters and simply requires a good bit of planning and operational procedures or automation via MOM and the like.

I would still rather deal with that than add any external dependencies and additional configuration/operation environment. but as you've said - there's probably no correct answer. it has to come down to the specific requirements/company etc.
5/19/2008 12:11 PM | Yossi Dahan
Gravatar

# re: Implementing scheduling requirements in BizTalk solutions

Is it possible to use a SQL Receive Port for this purpose?
We would use a static SQL query such as:
SELECT 1 AS [MyValue]

For the database connection string we would provide the connection string to BizTalk's database. The SQL port would act as a trigger, and we would be able to use its polling capabilities as a scheduler.

Would this work? I might test it out.
5/29/2008 10:49 PM | Bobby
Gravatar

# re: Implementing scheduling requirements in BizTalk solutions

Version 3.0 of the Scheduled Task adapter has fixes for the duplicate firing problem.
2/28/2011 8:16 PM | Greg Forsythe
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 
 

Powered by: