2011-05-12 21 views
14

Tengo una base de datos de SQL Server y una aplicación web de intranet en una red local. La aplicación web de intranet crea registros y los envía a la base de datos. Tengo una aplicación web de Internet a la que me gustaría enviar nuevos registros utilizando la base de datos de SQL Server en la red local.¿Puede SQL Server enviar una solicitud web?

No puedo cambiar/modificar la aplicación web de intranet por varias razones, así que la única opción que tengo es crear un desencadenador en el servidor local SQL que envíe nuevos registros a la aplicación web de Internet utilizando algún tipo de http solicitud o llamada url.

La aplicación web de INTERNET está configurada con una API REST que puede recibir nuevos registros a través de una publicación de formulario a una url de acceso público (por ejemplo, http://www.example.com/records/new).

¿Alguien sabe si el envío de datos (xml, json, variables simples en la url) a través de una url se puede lograr en SQL Server?

Gracias por cualquier idea!

Respuesta

7

Como buena opción (bastante confiable y escalable), puede usar SQL CLR para interactuar con la aplicación web/servicio web. Por ejemplo, SQL CLR WebRequest o SQL CLR WCF.

+1

O SSIS - Integration Services. –

+0

@marc_s: Desde mi experiencia de poco alcance, SSIS es un tema más complejo que SQLCLR – abatishchev

+0

@marc_s También con SSIS terminas escribiendo C# de todos modos porque a menudo no es lo suficientemente flexible. – John

13

Es posible, pero en el mundo real es un poco más complicado que el enfoque ingenuo que imaginas. En primer lugar, es inaceptable tener una espera detonante de una petición HTTP:

  • Por un lado, su aplicación se arrastrará a un alto, debido a factores desencadenantes bloquearán los recursos (principalmente cerraduras) a la espera de una respuesta por parte de algunos a lo largo y Servicio WWW alejado.
  • En segundo lugar, más sutil pero mucho peor, es la cuestión de la corrección en presencia de retrocesos. Si la transacción que se emitió a las solicitudes HTTP se retrotrae, no hay forma de 'deshacer' la solicitud HTTP.

La solución es desacoplar el activador de la solicitud HTTP a través de una cola. El desencadenador coloca la solicitud en una cola local y se compromete, mientras que una parte separada del proceso desempaqueta estas solicitudes y emite la solicitud HTTP. Esto resuelve los dos problemas señalados anteriormente. Puede usar tablas comunes para colas (consulte Using Tables as Queues) o puede usar Service Broker, ambas funcionan bien.

Ahora, sobre cómo desasular estas solicitudes y ubicar realmente la llamada HTTP, recomiendo usar un proceso dedicado (es decir, una aplicación dedicada para este propósito). Si bien es posible usar SQLCLR, es una muy mala elección. Los recursos de SQL Server (específicamente workers) son muy valiosos para perder en la espera de respuestas de Internet.

+0

No estoy esperando una solicitud http. Quiero que el disparador inicie la solicitud http. Quiero que el desencadenador llame a una url cuando se actualiza un nuevo registro.No necesito que espere una respuesta o algo así –

+1

Pero ese disparador estará esperando la solicitud http. El Trigger se ejecutará en la inserción/actualización y solo cuando el Trigger complete la ejecución, esa inserción/actualización se completará y "finalizará" el proceso de inserción/actualización. Todo sucede sincrónicamente. Los desencadenantes deben ser lo más mínimos y RAPIDOS posible. Si es posible, NO use disparadores, excepto tal vez para volcar los datos del tipo de auditoría a otra tabla. –

0

Para sumar la buena respuesta de Remus Rusanu. Y relacionado con el comentario de Lehi Sanchez. El problema es que siempre debe esperar la solicitud http. El código en el desencadenador es una ejecución paso a paso, por lo que la solicitud debe volver para que el desencadenador pueda finalizar su ejecución.

Cuestiones relacionadas