Как правило, имеет смысл, чтобы система, которая владеет данными, также имела планирование отправки данных. Например, если данные поступают с SQL Server, используйте встроенную функциональность SQL Server для планирования (задания SQL) в качестве триггера для запуска всего процесса. Затем пусть задание SQL создает данные в файл в папке, отслеживаемой местоположением получения BizTalk с помощью файлового адаптера. BizTalk всасывает файл и порт отправки, который подписывается на сообщения, поступающие с порта приема, который извлекает файл, использует адаптер WCF или SOAP для отправки данных в веб-службу на внешнем сервере.
Если вы не хотите или не можете делать такие вещи, я видел, как люди использовали:
- Адаптер запланированных задач в CodePlex (как указано @tomasr)
- Запланированная задача Windows (более сложная для управления, особенно до Windows Server 2008)
- Стороннее программное обеспечение для планирования заданий (особенно, если оно уже используется)
Если механизм запуска не имеет доступа к данным, которые должны передаваться через BizTalk, BizTalk, безусловно, может пойти и получить данные (например, из SQL Server) перед отправкой их веб-службе сервера. В этом случае запланированное задание может удалить файл в папке, отслеживаемой BizTalk, с некоторым содержимым, о котором BizTalk не заботится - просто убедитесь, что в файле есть что-то, потому что BizTalk любит отбрасывать пустые 0-байтовые файлы. .
BizTalk не является планировщиком заданий. Таким образом, хотя вы можете использовать что-то вроде адаптера запланированных задач, преимуществом BizTalk действительно является преобразование, маршрутизация и / или согласование бизнес-процессов вместе с подключаемой архитектурой (с использованием адаптеров). Обычно вы хотите, чтобы BizTalk обрабатывал все эти функции и использовал какую-то другую систему (если она доступна) для планирования.