В MS BizTalk Server встроен очень удобный визуальный редактор XML-схем, с помощью которого можно создавать новые XML-схемы, в которых атрибуты и сущности заданы структурой XML-схемы. Инструмент настолько простой и прозрачный для понимания, что им может воспользоваться даже абсолютный чайник.

Тулза "Orcestration" MS BizTalk Server специально ориентирована на разработку бизнес-процессов связкой "прикладной специалист" - "IT специалист". Прикладной специалист в графической среде рисует алгоритм, используя набор графических средств и не вдаваясь в детали их физической реализации. После того, как алгоритм готов, IT-специалист к каждому из нарисованных блоков прикручивает через доступный только для него интерфейс реализацию каждого блока (с помощью механизма портов).

Структуры многочисленных документов можно создавать с помощью InfoPath, входящего в состав MS Office 2003. Структура создается в виде XML-схемы. В InfoPath можно также производить текущую работу с массивами документов. Документы в виде XML-документов обрабатываются BizTalk Server с использованием заранее настроенных алгоритмов. При этом может производиться XSLT-преобразование из форматов одних документов в формат других документов с использованием так называемых "функтоидов" (похожи на функции VBA, кстати на VBA можно писать новые функтоиды, если не устроит набор встроенных). В BizTalk Server имеется очень удобный инструментарий для визуального конструирования XSLT-преобразований.

Хранить информацию в систематизированном виде лучше всего в MS SQL Server - BizTalk Server может разложить все документы там по полочкам в соответствии с заданным IT-специалистом реализацией алгоритмов обработки информации. Если не лежит душа к MS SQL Server, можно для этих же целей использовать любой другой SQL-сервер.

Отчетность можно получать с помощью MS Reporting Services, который очень удобен для обработки данных в формате XML. Структура самих отчетов также задается в формате XML.

Reporting Services и InfoPath - относительно новые продукты, и в силу недостаточной обточенности некоторых острых углов там иногда возникают проблемы. Но в общем и целом совокупность этих продуктов позволяет решать задачу так, как Вы ее обрисовали.

Одно важное замечание. MS BizTalk Server ориентирован на работу с так называемыми "длинными транзакциями". Одна такая транзакция может длиться сутки и даже месяцы. Такие транзакции продолжают оставаться запущенными даже после перезагрузок компьютера, на котором запущен MS BizTalk Server и MS SQL Server. Но... Не удастся добиться, чтобы подобные транзакции выполнялись слишком быстро. Каждая подобная транзакция предварительно регистрируется в базе данных MS SQL Server, и лишь после этого выполняется запуск стадий бизнес-процесса, обращение к портам (в терминологии BizTalk Server). Это я к тому, что не стоит расчитывать на интерактивную обраотку информации, которую пользователь наколачивает на экране, прямо в процессе ее ввода с помощью алгоритмов Orcestration MS BizTalk Server. Этот инструментарий для таких нужд не приспособлен. Он приспособлен для обработки уже набранной и "отправленной на обработку" пользователем информации. Примитивные средства защиты от дурака в процессе ввода информации необходимо реализовывать средствами InfoPath, насколько это получится.

Еще один вариант. Начиная с версии 2003 MS Office позволяет сохранять документы MS Word и MS Excel в формате XML. Если сохранять документы в формате XML (файл - сохранить как - XML) и разобраться в структуре XML-представления этих документов, их можно отправлять на обработку в MS BizTalk Server напрямую. И спомощью XSLT-преобразования, например, получать из XLS-файла несколько различных DOC-файлов, отправляемых нужным адресатам (или делать какую-то иную обработку).

Механизма распарзивания (контроля на соответствие схеме) позволяет корректно обрабатывать ошибки несоответствия структуре документа, а также грамотно строить обработку подобных ошибок с возвратом документа его источнику и понятным объяснением, почему документ не принят на обработку.

Programmer_Ortodox Garya
Одна такая транзакция может длиться сутки и даже месяцы.


Если в базе не миллиарды терабайт, то что же конкретно эта какашка делает все это время? Под термином "длинная транзакция" в MS BizTalk Server подразумевается совсем не то, что подразумевается под термином "транзакция" в терминологии СУБД. Под "длинной транзакцией" подразумевается запущенная по схеме заданного бизнес-процесса реальная фактическая операция. Например, имеется бизнес-процесс обработки заявки клиента. Поступила заявка - не важно откуда и в каком формате, она попадает в BizTalk Server, распознается в нем как некий факт, инициирующий бизнес-процесс. Бизнес-процесс стартует. Заявка преобразуется в типовую, принятую в организации форму (средствами BizTalk Server) и отправляется в отдел проработки заявок клиентов (по электронной почте, например). Сутки этот отдел мудрит, оптимизирует цены, готовит ответное предложение... Всё это время бизнес-процесс обработки данной конкретной заявки числится в BizTalk Server как запущенная, но не завершенная транзакция, которая на текущем этапе имеет статус "обработка заявки в рамках допустимых сроков". Если сроки обработки заявки превысят сутки, может истечь отведенный под данную операцию таймаут, и статус транзакции изменится. Как именно изменится, определяется логикой бизнес-процесса. Допустим, отдел обработки заявок подготовил ответное предложение и отправил его клиенту. Предложение регистрируется в базе данных, привязывается к содержимому заявки, бизнес-процесс переходит на следующую фазу ожидания ответа от клиента. Если от клиента нет ни привета, ни ответа на протяжении, скажем, недели, бизнес-процесс автоматом может аннулировать транзакцию, либо отправить напоминание. В бизнес-процессе могут быть циклы в виде итераций "на заказали" - "мы предложили, но не совсем то" - "нас поправили, что это не совсем то, что нужно" - "мы уточнили, что у нас есть другое, т.к. нет требуемого" - и т.д. Когда заявка согласована, может понадобиться выписать счет или спецификацию и отправить его на согласование руководству. После согласования BizTalk Server в соответствии с настройкой бизнес-процесса автоматом может разослать оповещение в отдел снабжения. Отдел снабжения, проверив наличие, в рамках этого же бизнес-процесса может сформировать заявку в транспортный отдел на доставку, при этом запускаются операции, связанные с оплатой, с включением в бюджет (при бюджетном управлении) и т.п. Когда отдел снабжения установит флажок "готово к отгрузке", соответсвтующее оповещение автоматом поступает к курирующему менеджеру отдела сбыта. Он связывается с клиентом, договаривается об отгрузке. Когда прошло две недели от даты отгрузки, "длинная транзакция" завершается и складывается в архив выполненных транзакций, по которым можно делать анализ (крутить OLAP-кубики, например). В настройках бизнес-процесса указывается, с какой периодичностью "заснувшая" транзакция на определенных этапах должна "просыпаться", чтобы проконтролировать наступление определенных событий.
Есть там такая база трэкинга - по ней отслеживаются эти самые "длинные транзакции", их статусы, ошибки, которые могли возникнуть и т.п.

Находящихся в обработке заявок может быть одновременно сотни или тысячи. Каждая заявка может находиться на своей стадии обработки, иметь специфические статусы. Каждая из них - отдельная "длинная транзакция".

Mik ProkoshinХотя... может и не исключено, но все равно не очень понимаю, как он может помочь. Связь с удаленными пользователями только по email.По email можно отправить XML-файл. Который либо попадает на обработку в BizTalk, либо открывается юзером напрямую InfoPath.

Я изучал BizTalk по этой книжке:
http://www.ozon.ru/context/detail/id/845771/