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

Question

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

• пользователь заполняет форму InfoPath (2003) локально на своем ПК
• кнопка в форме InfoPath под названием «submit» вызывает новое электронное сообщение outlook (2003) с прикрепленной формой infopath. Пользователь нажимает «Отправить» и электронная почта отправляется на почтовый ящик обмена.
• Сервер SQL предварительно проверяет этот почтовый ящик, загружая все новые сообщения с прикрепленной формой инфопата
• Сервер SQL анализирует вложение и поля в форме инфопата.

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

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

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

Answer 1

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

Может быть, стоит подумать о написании службы Windows, которая выполняет эту работу. Служба Windows запускается, проверяет почтовый ящик «учетной записи службы», читает почту, извлекает вложения, обрабатывает xml и, в конце концов, записывает данные в SQL. Он также может предположительно отвечать на это письмо подтверждением или ошибками, если произошли бизнес-правила или ошибки проверки.

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

Ваш пробег может варьироваться, и вы должны создать этот прототип, чтобы определить, что работает лучше для вас, но я постараюсь сохранить код, использующий 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

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

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