Integración de SQL Azure con SharePoint 2010 y Windows Azure
Integración de SQL Azure con SharePoint 2010 y Windows Azure
Esta entrada es más útil si se consulta junto con mi serie de cinco partes sobre el kit CASI (del inglés Claims, Azure, and SharePoint Integration).
· Parte 1: información general sobre todo el marco y la solución, así como una descripción de los temas que se cubrirán en la serie.
· Parte 2: la parte de orientación del kit CASI. Comenzaré por hacer que WCF sea el front-end para todos los datos; podría tratarse de conjuntos de datos, XML, clases personalizadas o simplemente puro HTML. En la fase 1, tomamos el servicio WCF estándar y lo convertimos en apto para notificaciones. Esto es lo que nos permite tomar el token de usuario desde SharePoint y enviarlo a través de los límites de la aplicación o del centro de datos a las aplicaciones WCF personalizadas. En la fase 2, revisaré la lista de todas las cosas que debe hacer para llevar esta aplicación WCF típica desde su ubicación local a hospedarse en Windows Azure. Una vez que se complete esta tarea, el back-end podrá admitir un centro de datos múltiples y de varias aplicaciones con autenticación integrada.
· Parte 3: describe el ensamblado del kit de herramientas personalizado que proporciona la adherencia para conectar la aplicación WFC para notificaciones de la nube con el conjunto o la granja de servidores de SharePoint. Describiré la forma de usar el ensamblado, hablaré sobre el control personalizado bastante sencillo que debe crear (aproximadamente 5 líneas de código) y explicaré cómo puede hospedarlo en una página en el directorio _layouts como medio para recuperar y representar datos en un elemento web. También publicaré el código fuente completo para el control personalizado de ejemplo y la página _layouts.
· Parte 4: el elemento web que incluyo en el kit CASI. Proporciona una solución integrada sin código para enlazar y conectarse con una consulta asincrónica del lado cliente para recuperar datos del servicio hospedado en la nube y, a continuación, mostrarlos en el elemento web. También tiene enlaces integrados para que pueda personalizarla bastante y usar sus propias funciones de JavaScript para representar los datos.
· Parte 5: un breve tutorial sobre un par de aplicaciones de ejemplo que demuestra algunos otros escenarios en los que puede usar el control personalizado que creó y que se describió en la parte 3 en un par de otros escenarios comunes. Uno será el uso del control para recuperar datos de usuario o configuración y almacenarlos en la memoria caché de ASP.NET, y a continuación, usarlo en un elemento web personalizado. El otro escenario será sobre el uso del control personalizado para recuperar datos de Azure y usarlos en una tarea personalizada; en este caso, un trabajo del temporizador de SharePoint personalizado. También incluiré el código fuente completo para estas aplicaciones de ejemplo.
Con el kit CASI proporcioné orientación y algunas herramientas para ayudarle a conectarse de forma rápida y sencilla a Windows Azure desde SharePoint 2010, mientras envía el token para el usuario actual para poder tomar decisiones de seguridad avanzadas. La aplicación WCF original que consumió el kit CASI simplemente usaba una colección de datos codificados de forma rígida que expuse. En una compilación posterior (que no está documentada en las entradas del blog sobre el kit CASI), actualicé la parte de datos para que pueda almacenar y recuperar datos usando almacenamiento de tablas de Windows Azure. Ahora, lo he mejorado un poco más expandiendo los datos de SQL Azure y haciendo que mi WCF en Windows Azure recupere datos desde allí. Ahora es realmente un conjunto de aplicaciones multinube: Windows Azure, SQL Azure y (aparentemente) SharePoint Online. El objetivo de esta entrada es simplemente compartir algunas sugerencias para trabajar con SQL Azure e incorporarlo más rápidamente a los proyectos de desarrollo.
Sugerencias de integración
1. Realmente debe actualizarse a SQL 2008 R2 para poder abrir bases de datos de SQL Azure con la herramienta SQL Server Management Studio. Técnicamente, puede hacer que SQL Server 2008 funcione, pero deberá recurrir a una serie de soluciones alternativas para que eso sea posible. SQL Server 2008 R2 ha resuelto el problema y obtendrá la mejor experiencia con él. Si realmente desea usar las soluciones alternativas con SQL Server 2008, vea este vínculo: https://social.technet.microsoft.com/wiki/contents/articles/developing-and-deploying-with-sql-azure.aspx. Este artículo contiene varias sugerencias interesantes, por lo que vale la pena leerlo de todas maneras.
2. Planee usar T-SQL para hacer todo. Las herramientas gráficas no están disponibles para usarlas con bases de datos, tablas, procedimientos almacenados, etc. de SQL Azure. Una vez más, algo que me ha resultado útil, ya que en realidad no soy un genio de T-SQL, es simplemente crear primero una base de datos de SQL Server. En la herramienta SQL Management creo dos conexiones: una a mi sesión de SQL local y otra a mi sesión de SQL Azure. Creo tablas, procedimientos almacenados, etc. en la instancia SQL para poder usar las herramientas gráficas. A continuación, uso el script [cualquier objeto SQL] As…CREATE to…New Sql Query Window. Esto genera el script SQL que creará mis objetos y que podré pegar en una ventana de consulta que he abierto en la base de datos de SQL Azure.
3. Esto es muy importante: por lo general, el tiempo de espera predeterminado no es suficiente para conectarse a SQL Azure. Puede modificarlo si usa las clases .NET SqlClient en la cadena de conexión, es decir, agregue "Connection Timeout=30;". Si usa SQL Server Management Studio, haga clic en el botón Avanzadas en el diálogo donde se escribe el nombre del servidor y las credenciales y cámbielo a al menos 30. El valor predeterminado es 15 segundos y suele producir un error, pero un tiempo de 30 segundos parece funcionar bastante bien. Lamentablemente, no hay forma de modificar el tiempo de espera de la conexión para un tipo de contenido externo (por ejemplo, definición de aplicación BDC) a un origen de datos de SQL Azure.
4. No use la cuenta del administrador de la base de datos para conectarse a sus bases de datos (es decir, la cuenta que recibe para crear la base de datos). Cree una cuenta separada para trabajar con los datos. Lamentablemente, SQL Azure solo admite cuentas SQL, por lo que no puede usar directamente la identidad del usuario solicitante para tomar decisiones sobre el acceso a los datos. Ese problema se puede resolver usando una aplicación WCF que sea el front-end de los datos en SQL Azure y usando autenticación basada en notificaciones en Windows Azure, que es exactamente el modelo que usa el kit CASI. Además, se requieren varios pasos para crear un inicio de sesión que se pueda usar para conectarse a una base de datos específica. Aquí hay un ejemplo:
--primero cree la base de datos
CREATE DATABASE Customers
--ahora cree el inicio de sesión y, a continuación, cree un usuario en la base de datos a partir del inicio de sesión
CREATE LOGIN CustomerReader WITH PASSWORD = 'FooBarFoo'
CREATE USER CustomerReader FROM LOGIN CustomerReader
--ahora conceda derechos al usuario
GRANT INSERT, UPDATE, SELECT ON dbo.StoreInformation TO CustomerReader
--conceda derechos de ejecución a un procedimiento almacenado
GRANT EXECUTE ON myStoredProc TO CustomerReader
Para ver más ejemplos y detalles, incluida la configuración de derechos a nivel del servidor para cuentas de SQL Azure, vea https://msdn.microsoft.com/en-us/library/ee336235.aspx.
5. Debe crear reglas de firewall en SQL Azure para cada base de datos que tenga a fin de permitir comunicaciones de diferentes clientes. Si desea permitir la comunicación de otros servicios de Azure, debe crear la regla de firewall MicrosoftServices (que SQL Azure ofrece crear automáticamente cuando se crea la base de datos), que es un rango de inicio de 0.0.0.0 a 0.0.0.0. ¡Si no crea esta regla, ninguna de sus aplicaciones de Windows Azure podrá leer, agregar o editar datos de sus bases de datos de SQL Azure! También debe crear una regla de firewall para permitir las comunicaciones con los servidores de enrutamiento que use para Internet. Por ejemplo, si tiene un cable o enrutador ADSL o un servidor RRAS, le conviene usar su dirección externa o dirección NAT para algo como el Servicio de enrutamiento y acceso remoto (RRAS).
Seguramente estas sugerencias le ayudarán a disponer mejor de sus datos.
Acceso a datos
Por suerte, el acceso a los datos desde su código personalizado (Windows Azure WCF, elemento web, etc.) es muy similar a la recuperación de datos de un servidor SQL Server local. Aquí hay un breve ejemplo de código (después describiré algunas partes en más detalle):
//set a longer timeout because 15 seconds is often not
//enough; SQL Azure docs recommend 30
private string conStr = "server=tcp:foodaddy.database.windows.net;Database=Customers;" +
"user ID=CustomerReader;Password=FooBarFoo;Trusted_Connection=False;Encrypt=True;" +
"Connection Timeout=30";
private string queryString = "select * from StoreInformation";
private DataSet ds = new DataSet();
using (SqlConnection cn = new SqlConnection(conStr))
{
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = new SqlCommand(queryString, cn);
da.Fill(ds);
//do something with the data
}
En realidad no hay nada aquí que requiera mucha explicación aparte de la cadena de conexión. Los puntos principales que vale la pena señalar y que son posiblemente diferentes de una conexión típica a un servidor SQL Server local son:
· server: escriba “tcp:” antes del nombre de la base de datos de SQL Azure.
· Trusted_Connection: debería ser false ya que no está usando seguridad integrada
· Encrypt: debería ser true para cualquier conexión a una base de datos hospedada en la nube
· Connection Timeout: como ya mencioné antes, el tiempo de espera predeterminado es de 15 segundos y, por lo general, no es suficiente; establézcalo en 30 segundos.
Otro escenario que quería comentar brevemente es el uso de migración de datos. Puede usar la herramienta BCP que viene con SQL Server para mover datos de un servidor SQL Server local a SQL Azure. La rutina básica para migrar datos es la siguiente:
1. Crear un archivo de formato. Este archivo se usará para exportar los datos locales e importarlos en la nube. En este ejemplo, voy a crear un archivo de formato para la tabla Region de la base de datos de prueba y lo voy a guardar en el archivo region.fmt.
bcp Test.dbo.Region format nul -T -n -f region.fmt
2. Exportar datos del servidor SQL local. En este ejemplo voy a exportar datos de la tabla Region de la base de datos de prueba a un archivo llamado RegionData.dat. Voy a usar el archivo de formato region.fmt que creé en el paso 1.
bcp Test.dbo.Region OUT RegionData.dat -T -f region.fmt
3. Importar datos a SQL Azure. Lo más importante para señalar aquí es que cuando se importan datos en la nube, DEBE incluir “@nombreDeServidor” con el parámetro de nombre de usuario; de lo contrario, la importación producirá un error. En este ejemplo voy a importar datos a la tabla Region de la base de datos Customers de SQL Azure. Voy a importar del archivo RegionData.dat al que exporté mis datos locales. El nombre de mi servidor (el parámetro -S) es el nombre de la base de datos de SQL Azure. Para mi nombre de usuario (parámetro -U) voy a usar el formato nombreDeUsuario@nombreDeServidor que describí antes. Voy a indicarle que use el archivo de formato region.fmt que creé en el paso 1 y he establecido un tamaño de lote (parámetro -b) de 1000 registros a la vez.
bcp Customers.dbo.Region IN RegionData.dat -S foodaddy.database.windows.net -U speschka@foodaddy.database.windows.net -P FooBarFoo -f region.fmt -b 1000
¡Eso es todo por ahora, amigos! Espero que les ayude a entender mejor la mecánica básica para la creación de una base de datos de SQL Azure y cómo conectarse a ella y usarla en un sitio de SharePoint. Como comentario al margen, usé el kit CASI para recuperar estos datos a través de mi front-end WCF de Windows Azure en SQL Azure y para representarlos en mi sitio de SharePoint. Seguí mi propio blog sobre el kit CASI cuando lo creé para validar todo lo que había publicado anteriormente allí, y en general, me pareció que todo era correcto. Hice un par de correcciones menores en la parte 3 y agregué una pequeña sección sobre la solución de problemas. Pero en total me llevó unos 30 minutos crear un nuevo control personalizado y unos 15 minutos crear un nuevo elemento web visual. Usé el elemento web del kit CASI para mostrar un conjunto de datos de SQL Azure de WCF y, en el elemento web visual, creé una instancia del control personalizado mediante programación para recuperar un conjunto de datos y después lo enlacé a una cuadrícula ASP.NET. Reuní todo en una sola página de ejemplo que se ve bastante bien y que podría ampliarse para mostrar datos de varias formas muy fácilmente. Así es cómo se ve:
Esta entrada de blog es una traducción. Puede encontrar el artículo original en Integrating SQL Azure with SharePoint 2010 and Windows Azure