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

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

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

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

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

Я бы не стал использовать описанный вами подход. Есть несколько подходов, которые мне кажутся более желательными, чем просмотр почтового ящика Exchange с помощью SQL Server. Главное, что вы делаете, и важное требование - чтобы форма 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 во время разработки, а затем также настройки формы для автономного использования.

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

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

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