¿Enviar formularios de información vía correo electrónico (como archivo adjunto) para que SQL Server 2005 los analice?

Question

Solo mirando los requisitos de un nuevo proyecto y quería asegurarme de que este caso de uso fuera sólido:

• el usuario completa el formulario de InfoPath (2003) localmente en su PC
• un botón dentro del formulario de InfoPath titulado 'enviar' muestra un nuevo mensaje de correo electrónico de Outlook (2003) con el formulario de InfoPath adjunto. El usuario presiona los envíos y el correo electrónico se envía a un buzón de intercambio.
• el servidor sql verifica periódicamente este buzón, descargando cualquier envío nuevo con el formulario de ruta de información adjunto
• el servidor sql analiza el archivo adjunto y los campos dentro del formulario de ruta de información.

¿SQL Server es capaz de analizar los archivos adjuntos de correo de esta manera? ¿Alguna advertencia con este enfoque?

La atracción de usar Outlook como tecnología de envío es que el proceso para el usuario es el mismo si está desconectado. Outlook se sincronizará automáticamente cuando vuelvan a estar en línea. Es esencial que los usuarios tengan alguna forma de completar los formularios sin conexión, 'enviarlos' y luego sincronizarlos automáticamente con el servidor la próxima vez que estén en línea.

editar: para aclarar, no estoy buscando una forma de almacenar en caché los datos del formulario del servidor > client. Estoy buscando almacenar en caché el formulario completado. Crear una aplicación separada para almacenar en caché los informes completados en el cliente no es una opción.

Answer 1

Las versiones posteriores de SQL Server son capaces de ejecutar código .NET dentro de ellas y, como tal, puede sondear un buzón de SQL Server y procesar un formulario de InfoPath. Sin embargo, no estoy seguro de hacerlo de esta manera.

Podría ser mejor considerar escribir un servicio de Windows que haga este trabajo. El servicio de Windows se iniciaría, inspeccionaría el buzón de una "cuenta de servicio", leería los correos, extraería los archivos adjuntos, procesaría el xml y, eventualmente, escribiría los datos en SQL. También podría, presumiblemente, responder a ese correo con una confirmación o errores si ocurrieran reglas comerciales o errores de validación.

No estoy seguro de si pondría toda la lógica anterior en SQL; por un lado, sospecho que tendría problemas con las cuentas (tener que tener la cuenta en la que se ejecutaba SQL para poder acceder al buzón de Exchange cuenta).

Su kilometraje puede variar, y debe crear un prototipo para determinar qué funciona mejor para usted, pero trataría de mantener el código que usa Exchange como una "cola de trabajo". separado de SQL y solo ponga el código que se ocupa de escribir datos en tablas en SQL.

Answer 2

No usaría el enfoque que describiste anteriormente. Hay varios enfoques que me parecen más deseables que tener SQL Server mirando un buzón de Exchange. El punto principal que usted hace y un requisito importante es que se permita que el formulario de InfoPath funcione en modo fuera de línea. Pensaría en el " modo fuera de línea " y la "transferencia de datos" partes de su proyecto como dos partes distintas y separadas: 1) El formulario y los datos deben almacenarse en el cliente hasta que haya una conexión a Internet disponible y 2) una vez que la conexión esté disponible, el formulario y los datos deben transferirse al servidor .

Puede configurar su formulario de InfoPath para enviarlo directamente al SQL Server y omitir el intercambio "intermediario" enteramente. La configuración en InfoPath cuando diseña su formulario es bastante sencilla: 1) habilita "Enviar datos" para la conexión y 2) configura las opciones de envío. Este artículo tiene los detalles sobre cómo hacerlo. Además, su conexión al SQL Server puede configurarse para uso fuera de línea, como se explica en este artículo . La única advertencia con este enfoque es que es posible que deba cambiar el esquema de su base de datos para admitirlo.

Otro enfoque es enviar su formulario de InfoPath a un punto final HTTP de SQL Server 2005. El cliente InfoPath es solo un editor XML glorificado y el punto final HTTP es básicamente un nombre diferente para un servicio web. Recibe los datos del formulario en el punto final HTTP en una tabla de preparación donde los datos se almacenan como XML y luego puede analizar los datos desde esa área de preparación. Aún así, deberá configurar la conexión de InfoPath para su uso sin conexión. La principal advertencia con este enfoque es que Microsoft desaprobará HTTP Endpoint en SQL Server 2008 a favor de WCF.

Y el otro enfoque que me gustaría sugerir es usar WCF para recibir los datos del formulario XML del cliente InfoPath. Este enfoque requerirá que conecte la fuente de datos del formulario a su servicio web WCF en el momento del diseño y luego también configure el formulario para su uso fuera de línea.

Espero que esto sea útil para usted y, como mínimo, le indique la dirección correcta.

Answer 3

He visto proyectos similares que recurrieron a una edición Express en el cliente, guardan la ruta de información (o los datos de la aplicación) en Express y usan Service Broker para entregar al centro, debido a la semántica de entrega garantizada de SSB frente al correo. Esto le brinda una solución de SQL más fácil de vender a TI y no necesita sondeo en el servidor. Además, no tendrá que lidiar con el análisis MIME, todo es un procesamiento XML directo. Sin embargo, no es para los débiles de corazón, poner en marcha SSB es un desafío. Si decide continuar con la entrega de correo, podría decirse que un servicio externo será más fácil de construir, depurar y solucionar problemas. Hay algunos problemas puntuales más finos para los que debería tener una respuesta: -¿Cómo mantendrá consistentes las operaciones de eliminación de correspondencia y las operaciones de escritura de tabla? Su componente debe comprometer la lectura / eliminación de Exchange y la inserción de SQL en una transacción distribuida. - ¿Está su lógica preparada para tratar con documentos de InfoPath que están fuera de servicio? el transporte de correo no garantiza en absoluto el orden de entrega, por lo que puede ver un documento de "eliminación de pedido" antes del documento de "creación de pedido" - ¿Cómo va a detectar los documentos faltantes (no entregados por correo)? ¿Va a implementar un número de secuencia de remitente y terminará reinventando TCP sobre el correo? - ¿Su procesamiento permite el proceso paralelo de documentos correlacionados? Si el subproceso 1 recoge el documento 1 y el subproceso 2 recoge el documento 2 del mismo remitente y el documento 2 se correlaciona con el documento 1 (es decir, consulte la misma transacción comercial), ¿qué sucederá en la escritura de la base de datos? ¿Se bloqueará, perderá una actualización, se revertirá una?

Hay muchos dragones debajo del puente por delante ...