Отправка форм infopath по электронной почте (в виде вложения) для анализа SQL Server 2005?

Question

Просто посмотрел на требования нового проекта, и я хотел убедиться, что этот вариант использования был обоснованным:

• пользователь заполняет форму InfoPath (2003) локально на своем компьютере
• кнопка в форме InfoPath под названием "отправить" открывает новое сообщение электронной почты Outlook (2003) с прикрепленной формой infopath.Пользователь нажимает кнопку отправить, и электронное письмо отправляется на почтовый ящик exchange.
• sql server периодически проверяет этот почтовый ящик, загружая все новые отправленные данные с прикрепленной формой infopath
• sql server анализирует вложение и поля в форме infopath.

Способен ли SQL Server анализировать почтовые вложения таким образом?Есть какие-нибудь предостережения в связи с таким подходом?

Привлекательность использования Outlook в качестве технологии отправки заключается в том, что процесс для пользователя тот же, если он находится в автономном режиме.Затем Outlook автоматически синхронизируется, когда они снова подключатся к сети.Важно, чтобы у пользователей был какой-то способ заполнить формы в автономном режиме, "отправить" их, а затем автоматически синхронизироваться с сервером, когда они в следующий раз выйдут в Интернет.

Редактировать:чтобы уточнить, я не ищу способ кэширования данных формы с сервера-> клиент.Я ищу способ кэширования заполненной формы.Создание отдельного приложения для кэширования завершенных отчетов на клиенте - это не вариант.

Answer 1

Более поздние версии SQL Server способны работать .В них есть сетевой код, и поэтому вы могли бы опросить почтовый ящик с SQL Server и обработать форму InfoPath.Однако я не уверен, что сделал бы это таким образом.

Возможно, было бы лучше рассмотреть возможность написания службы Windows, которая выполняет эту работу.Служба Windows запустится, проверит почтовый ящик "учетной записи службы", прочитает письма, извлечет вложения, обработает xml и, в конечном счете, запишет данные в SQL.Предположительно, он также мог бы ответить на это письмо с подтверждением или ошибками, если бы возникли бизнес-правила или ошибки проверки.

Я не уверен, что поместил бы всю вышеприведенную логику в SQL - во-первых, я подозреваю, что у вас возникли бы проблемы с учетными записями (для доступа к учетной записи почтового ящика Exchange требовалась учетная запись, под которой был запущен SQL).

Ваш пробег может отличаться, и вам следует создать прототип этого, чтобы определить, что лучше всего подходит для вас, но я бы постарался сохранить код, использующий Exchange в качестве "рабочей очереди", отдельно от SQL и поместить только код, который занимается записью данных в таблицы в SQL.

Answer 2

Я бы не стал использовать подход, который вы изложили выше.Существует несколько подходов, которые кажутся мне более желательными, чем использование SQL Server для просмотра почтового ящика Exchange.Главное, что вы делаете, и важное требование заключается в том, чтобы форме InfoPath было разрешено работать в автономном режиме.Я бы рассматривал части вашего проекта "автономный режим" и "передача данных" как две отдельные части:1) Форма и данные должны храниться на клиенте до тех пор, пока не будет доступно подключение к Интернету, и 2) как только соединение станет доступным, форма и данные должны быть переданы на сервер.

Вы можете настроить свою форму InfoPath таким образом, чтобы она отправлялась непосредственно на SQL Server и полностью обходила "посредника" Exchange.Настройка в InfoPath при разработке вашей формы довольно проста:1) вы включаете "Отправлять данные" для подключения и 2) вы настраиваете параметры отправки.Это Статья содержит подробную информацию о том, как это сделать.Кроме того, ваше подключение к SQL Server может быть настроено для автономного использования, как это обсуждается в этом Статья.Единственное предостережение при таком подходе заключается в том, что вам, возможно, потребуется изменить схему вашей базы данных для его поддержки.

Другой подход заключается в отправке вашей формы InfoPath в конечную точку HTTP SQL Server 2005.Клиент InfoPath - это просто прославленный редактор XML, а конечная точка HTTP - это, по сути, другое название веб-службы.Вы получаете данные формы на конечной точке HTTP в промежуточную таблицу, где данные хранятся в формате XML, а затем вы можете выполнить свой синтаксический анализ этих данных из этой промежуточной области.Тем не менее, вам придется настроить подключение InfoPath для автономного использования.Основное предостережение при таком подходе заключается в том, что Microsoft откажется от конечной точки HTTP в SQL Server 2008 в пользу WCF.

И другой подход, который я хотел бы предложить, заключается в использовании самого WCF для получения данных XML-формы от клиента InfoPath.Этот подход потребует от вас подключения источника данных формы к вашей веб-службе WCF во время разработки, а затем также настройки формы для автономного использования.

Я надеюсь, что это будет полезно для вас и, по крайней мере, укажет вам правильное направление.

Answer 3

Я видел похожие проекты, которые прибегали к экспресс-версии на клиенте, сохраняли infopath (или данные приложения) в Express и использовали Service Broker для доставки в center из-за семантики гарантированной доставки SSB противПочта.Это упрощает продажу ИТ-решения на основе всего SQL, и вам не нужен опрос на сервере.Также вам не придется иметь дело с синтаксическим анализом MIME, это все прямая обработка XML.Однако это не для слабонервных, запустить SSB в эксплуатацию - непростая задача.Если вы решите использовать доставку почты, то внешнюю службу, возможно, будет проще создавать, отлаживать и устранять неполадки.Есть несколько более тонких вопросов, на которые у вас должен быть ответ:-Как вы будете поддерживать согласованность операций удаления почты из очереди и операций записи в таблицу?Ваш компонент должен включать чтение / удаление Exchange и вставку SQL в одну распределенную транзакцию.- Готова ли ваша логика иметь дело с документами infopath, выходящими из строя?почтовый транспорт не дает абсолютно никаких гарантий в отношении порядка доставки, поэтому вы можете увидеть документ "удалить заказ" перед документом "создать заказ" - Как вы собираетесь обнаруживать недостающие документы (не доставленные по почте)?Собираетесь ли вы внедрить порядковый номер отправителя и в конечном итоге заново изобрести TCP поверх почты?- Допускает ли ваша обработка параллельную обработку взаимосвязанных документов?Если поток 1 получает документ 1, а поток 2 получает документ 2 от одного и того же отправителя, и документ 2 коррелирует с документом 1 (т.е.обратитесь к той же бизнес-транзакции), что произойдет при записи в базу данных?Зайдет ли это в тупик, потеряет ли обновление, будет ли оно откатано?

Впереди под мостом много драконов...