May 2011 - Artículos
El otro día preguntaban en los foros si es posible personalizar el enlace característico que tenemos en toda lista de SharePoint para añadir nuevos elementos: “Add new item” (o “Agregar nuevo elemento”). Por suerte, y como casi siempre con SharePoint, la respuesta es que sí. Con un poco de JavaScript y CSSs se puede personalizar dicho enlace como queramos. Podéis encontrar un ejemplo ilustrativo sobre esta idea en este enlace.
Siguiendo con la serie de artículos en torno a la integración de SharePoint 2010 y SQL Azure, en esta nueva entrega vamos a ver como podemos modelar esa integración por medio de una WebPart que creemos con ayuda de las herramientas de desarrollo de Visual Studio 2010 para SharePoint 2010:
-
Creamos en primer lugar un proyecto de tipo “Empty SharePoint Project”.
-
Elegimos como tipo de despliegue “Deploy as farm solution”.
-
Añadimos al proyecto un elemento de tipo “Visual Web Part”
- Añadimos dentro del SPI (SharePoint Project Item) correspondiente a la WebPart visual un elemento de tipo LINQ To SQL Classes.
-
Para definir el correspondiente modelo, creamos a través del Server Explorer una conexión a nuestra BD de SQL Azure especificando la dirección del servidor y el usuario SQL que nos permita acceder a la correspondiente BD.
-
Añadimos a la WebPart visual los controles que necesitemos de acuerdo a la funcionalidad a implementar.
- En el code behind de la WebPart añadimos el siguiente código en el que:
- Añadimos dos directivas using a System.LINQ y a nuestro modelo LINQ To SQL.
-
En el manejador del botón definimos una simple instancia del correspondiente contexto de datos especificando la cadena de conexión que nos permita conectarnos a la BD de SQL Azure.
-
Realizamos la correspondiente consulta LINQ y volcamos el resultado de la misma en el control GridView de la WebPart.
1: using System;
2: using System.Web.UI;
3: using System.Web.UI.WebControls;
4: using System.Web.UI.WebControls.WebParts;
5:
6: //Espacios de nombres necesarios
7: using System.Linq;
8: using SPSQLAzureWP.SQLAzureWP;
9:
10: namespace SPSQLAzureWP.SQLAzureWP
11: {
12: public partial class SQLAzureWPUserControl : UserControl
13: {
14: protected void Page_Load(object sender, EventArgs e)
15: {
16: }
17:
18: protected void lnkbtnGetStoreInformation_Click(object sender, EventArgs e)
19: {
20: using (SQLAzureCustomersDataContext ctx =
21: new SQLAzureCustomersDataContext(
22: "Server=tcp:<Server>.database.windows.net;Database=<BS>;User ID=<User>;Password=<Password>;Trusted_Connection=False;Encrypt=True;"))
23: {
24:
25: var Stores = from s in ctx.StoreInformations
26: select s;
27: datagrdStoreData.DataSource = Stores;
28: datagrdStoreData.DataBind();
29: }
30:
31: }
32: }
33: }
-
Realizamos el despliegue de la WebPart y comprobamos que se muestran los datos consultados.
-
Lógicamente, estos datos son los mismos a los que podemos acceder desde el portal de gestión de SQL Azure.
Y hasta aquí llega este post sobre la integración de SQL Azure.
Antes de que llegue el veranito, hay un par de eventos sobre nuestro servidor favorito que no te deberías perder. El primero de ellos esta misma semana, en el que por segunda vez los grupos de usuarios de SharePoint de habla hispana repetimos experiencia con una nueva sesión de la Charla con los expertos: Todo lo que siempre quisiste saber sobre SharePoint, pero no te atreviste a preguntar!… y dentro de un par de semana llegan los BizSpark SharePoint & Azure Camps esponsorizados por el equipo de METRO en DPE EE.UU en los que tendremos la oportunidad de unir y ver como se llevan las dos plataformas de moda del momento de acuerdo al siguiente programa:
-
Días 13 y 14 de junio, training de desarrollo para SharePoint & Azure. Más información e inscripción en
este enlace.
-
Días 15 y 16 de junio, realización de pruebas de concepto. Si quieres participar en las POC, envía un correo a
buzonciin@ciin.es para darte más detalles al respecto.
Siguiendo con la serie de posts sobre las alternativas de integración que existen entre SharePoint & Azure, en esta ocasión y continuando con los artículos previos quería completar los patrones de integración introducidos con los que se detallan en este artículo de Todd Baginski muy completo y recomendable. Para finalizar, este breve post, os recuerdo los dos post previos sobre la misma temática:
Un tema muy recurrente en preguntas en foros y blogs de SharePoint es el de la integración de SQL Server Reporting Services (SSRS) y SharePoint 2010, sobre todo cuando se trata de definir arquitecturas de integración en despliegues en modo granja de SharePoint. Por suerte, con la última versión de ambas plataformas disponemos de abundante documentación sobre este tema comenzando en este enlace de MSDN que conduce a una serie de Hows-To bastante ilustrativos sobre como realizar la configuración de la integración paso a paso.
Hace unos días os comentaba en este post un ejemplo de sitio público de Office 365 plenamente operativo en el que a partir de la plantilla estándar de sitio estándar que viene como parte de SharePoint Online (SPO) en Office 365 se puede ver hasta dónde se puede llegar con las personalizaciones disponibles en el diseñador online para este sitio de plantillas. Precisamente, en esta línea, tenemos disponibles dentro de la documentación de Microsoft varios artículos relativos a la personalización de sitios públicos de SPO…podéis ver estos artículos desde este enlace.
Sin duda, dos de las plataformas que están más de moda son SharePoint por un lado y Windows Azure por otro…una pregunta que siempre ronda por el ambiente es la referente a la integración de ambas. En este post os voy a mostrar como podemos integrar en SharePoint 2010 datos de SQL Azure. Empecemos:
-
Lo primero que necesitamos es disponer de una BD en SQL Azure que disponga de una o varias tablas con datos que mostraremos en un sitio de SharePoint 2010.
-
Esta BD la podremos crear en el portal de Windows Azure o bien usando el SQL Server Management Studio.
-
A continuación, abrimos el sitio de trabajo con SharePoint Designer 2010 (SPD 2010) y en la sección “Data Sources” creamos un nuevo origen de datos de tipo “Database Connection”.
-
En la primera pantalla de configuración de la conexión especificamos el nombre de nuestro servidor de SQL Azure, el proveedor de conexión, así como el usuario y contraseña para acceder a la base de datos en SQL Azure.
-
Si pulsamos “Next” veremos que se muestra un mensaje de error y pulsamos OK.
-
En la siguiente pantalla del asistente, tendremos que elegir la opción de especificar la consulta a utilizar en lugar de seleccionar una tabla de la BD ya que da lugar a más errores. Pulsamos “Finish” para concluir el asistente.
- Guardamos los cambios y visualizamos la página de WebParts en el navegador comprobando que los datos de SQL Azure se muestran correctamente.
Y hasta aquí llega este primer post sobre la integración de SharePoint 2010 con SQL Azure.
Una pregunta que surge en casi cualquier conversación en torno a la plataforma Windows Azure es la de ¿y cuánto me cuesta mi aplicación que se está ejecutando allá en la nube? Responder a esta pregunta no es tarea fácil, ya que hay que tener en cuenta muchos factores: qué si el número de instancias a usar, que si el almacenamiento necesario, etc. Para facilitar el cálculo de cuanto nos cuesta nuestra aplicación, Microsoft acaba de liberar el Windows Azure Prizing Calculator.
Otra de las novedades que incorpora SharePoint 2010 es el control de texto enriquecido que permite que el usuario que trabaja con páginas Wiki o páginas de publicación tenga una experiencia de trabajo similar a la que ya tiene con Microsoft Word 2007 / 2010, lo que sin duda facilita su trabajo y le asegura una alta productividad desde el principio:
Además, este control es muy interesante en cuanto a que las opciones disponibles para trabajar con páginas son extensibles y es posible añadir estilos propios. Os dejo en este sentido varios ejemplos al respecto…como veis, se trata de jugar con CSSs :
Una de las posibilidades que tendremos a la hora de administrar Office 365 es la de la línea de comandos y más concretamente a través del uso de PowerShell que nos permitirá de forma remota realizar ciertas configuraciones. En concreto, y vía el blog de Oscar Maqueda (Powershell en Office 365), en este post se recogen las posibilidades que tendremos.
Siguiendo con la serie de artículos sobre el plan P1 de Office 365 para pequeñas empresas y profesionales, en esta ocasión vamos a ver con algo más de detalle que características tenemos disponibles en SharePoint Online (SPO) para este plan:
-
Si accedemos desde el portal de administración de Office 365 para un plan P1, podremos acceder a las opciones de administración de SPO desde la sección “Sitios de grupos y documentos”.
-
En concreto, la opción “Administrar sitios de grupos” nos lleva a la página de administración de un subsitio de SPO dentro de la colección de sitios única que tenemos disponible en el plan P1 de Office 365. Como se aprecia en la figura, no tenemos todas las opciones de administración disponibles que por ejemplo tenemos en los planes de tipo E.
-
De hecho, si visualizamos las características a nivel sitio disponible veremos que es un subconjunto bastante reducido de las que podemos tener en SharePoint On-Premise y en los planes E.
-
Si accedemos a la página en la que se muestra todo el contenido del sitio, nos daremos cuenta de que tenemos disponible una única colección de sitios de tipo raíz (“/”) en la que tenemos un sitio raíz que apunta al sitio web público disponible en el plan P1 y un subsitio de tipo Team Site.
-
En el provisionamiento de ambos sitios se ha realizado una rotura de permisos entre el sitio raíz y el subsitio como podremos comprobar al examinar los permisos de este último.
-
También es destacable como se intenta facilitar al usuario el trabajo con un sitio de grupo mediante los correspondientes accesos rápidos para crear una nueva página en el sitio o acceder al listado de documentos disponibles. En este último caso, además se proporcionan accesos rápidos para crear documentos mediante las Office Web Applications:
Y hasta aquí llega este segundo artículo sobre las características del plan P1 para pequeñas empresas y profesionales.
Como Visual Studio 2010 ya tiene más de un año de vida, Microsoft ha decidido celebrarlo aumentando los beneficios de uso de la plataforma Windows Azure para suscriptores MSDN que hayan adquirido o dispongan de una suscripción con la versión de Visual Studio Ultimate, Premium o Professional. Podéis leer más información al respecto en este enlace.
Siguiendo con la serie de artículos en torno a las alternativas de integración entre SharePoint y Azure, en esta ocasión vamos a seguir viendo que otras posibilidades tenemos desde una u otra plataforma:
- Desde SharePoint:
-
Podemos usar el modelo de objetos en cliente de SharePoint (.NET, Silverlight o ECMAScript) para interactuar con datos de Windows Azure.
-
A través de los Business Connectivity Services (BCS) para modelar la integración de datos de Azure en SharePoint por medio de tipos de contenido externos y listas externas.
-
Integración de servicios de Azure o de datos a través de WebParts de SharePoint.
-
Usando Silverlight para construir interfaces de usuario ricas que tiren de servicios o datos de Azure.
-
A través de las búsquedas federadas de SharePoint que permitan incluir datos de Azure.
-
Desde Windows Azure:
-
Uso de los servicios web de SharePoint para interactuar con sitios, listas, usuarios y otros elementos de la plataforma.
-
Uso de la API REST de SharePoint para interactuar con datos de listas de SharePoint.
Un resumen de estas opciones de integración de Azure y SharePoint es el siguiente:
| Azure Integration | How |
| SharePoint Client Object Model | Interact with Azure data in a list. |
| BCS | Model data from Azure and/or build external list to SQL Azure. |
| Silverlight | Create UI against Azure services or data. |
| InfoPath 2010 | Data Connections via SOAP |
| Sandboxed Solutions | Silverlight application leveraging Azure deployed to site collections. |
| Standard / Visual Web Parts | Leverage services and data from Azure. |
| REST | Use REST to interact with Azure data to integrate with SP artifacts. |
| Office Server Services | Combine with OO to auto-gen docs (ex: PDFs) on server. |
| Workflow / Event Receivers | State or events that tie into Azure services or data. |
| LINQ | Use for querying Azure data objects. |
| Search | Federate search to include Azure data. |
| Silverlight | Create UI against Azure services or data. |
Si nos centramos en escenarios de integración, surgen los siguientes:
- Escenario 1: Llamar a código externo:
- Escenario 2: Acceso a datos externos:
- Escenario 3: Exponer datos de SharePoint al exterior
Y hasta aquí llega este segundo artículo sobre alternativas de integración entre SharePoint y Azure.
Uno de los planes que tendremos disponibles dentro de Office 365 es el P1 o Little Pack pensado para que pequeñas empresas y profesionales tengan la posibilidad de disponer de servicios de correo electrónico, un sitio de grupo para colaborar, presencia en Internet con un sitio web, etc y todo ello por poco más de 5 € / mes por usuario. En este artículo haremos una primera inmersión al plan P1 en lo que a capacidades se refiere:
-
-
Desde esta página de administración tenemos un acceso rápido a una página de acceso rápido para que el usuario utilice las distintas capacidades disponibles en el plan P1.
-
Por ejemplo, desde esta página dispone de una acceso directo a la bandeja de entrada de su correo electrónico.
-
La administración de las opciones de correo electrónico también están disponibles desde la página anterior así como el acceso a la descarga del cliente de Lync para aprovechar las capacidades de comunicaciones unificadas.
-
El plan P1 no cuenta con la posibilidad de usar los clientes de escritorio de la suite Microsoft Office 2010 como sucede con los planes E de Office 365, pero si que posibilita la creación de documentos Office (Word, Excel, PowerPoint y One Note) directamente desde el navegador gracias a las Office Web Applications que si se incluyen como parte del offering de P1.
-
Para crear un documento inicial, basta con especificar el nombre del mismo en el navegador y comenzar el proceso de edición del mismo.
A la espera de que se vaya generando más documentación por parte de Microsoft, y teniendo en cuenta los diferentes planes que formarán parte de Office 365, no vienen nada mal las primeras comparativas que van apareciendo en la red. Os recuerdo que en Office 365 tendremos los siguientes tipos de planes:
-
P1 para pequeñas empresas y profesionales.
-
K1 y K2 para trabajadores kiosko, de decir, que con una conexión a Internet y el navegador ya están listos para sacar el máximo partido a la suite de productividad en la nube.
-
Los planes E1, E2, E3 y E4 para empresas de tamaño medio y grande.
Una primera idea de que diferencias a nivel funcional tendremos entre cada uno de estos planes lo podemos encontrar en este enlace. Si lo que queremos es saber a nivel de desarrollo que caracterizará cada versión, tenemos que irnos a este enlace. Finalmente, para comparar SharePoint Online y On-Premise os recomiendo este otro enlace.
A la hora de implementar soluciones para SharePoint 2010 tenemos dos posibilidades:
-
Solución de tipo Farm (Granja) que permite desplegar archivos físicamente en el servidor dónde tenemos instalado SharePoint: páginas de aplicación en la carpeta LAYOUTS, imágenes bajo la carpeta IMAGES, ensamblados en la GAC, etc.
-
Solución de tipo Sandbox (o recinto aislado) que no permite lo anterior y en la que todo su contenido se guarda en la BD de contenidos correspondiente, de dónde es leído por los servicios de Sandbox para que se ejecuten cuando estas soluciones están activas.
Si nos quedamos con el caso de las soluciones Sandbox, hay ciertos tipos de artefactos que contienen un ensamblado. Esto sucede con las WebParts o los manejadores de eventos, por lo que una pregunta que surge es ¿A dónde van a parar los ensamblados de una solución Sandbox? Evidentemente, a la GAC no, pero sí por defecto a un directorio especial y aislado dónde los ensamblados se copian la primera vez que se ejecuta el artefacto en cuestión. Este directorio (configurable) es: C:\ProgramData\Microsoft\SharePoint\UCCache. Podéis encontrar información adicional respecto a esta cuestión en:
Finalmente, os recuerdo este otro artículo en el que se trataron temas de arquitectura de SharePoint 2010.
El otro día os comentaba algún pequeño truco que hay que hacer para asegurar que la vista del explorador de SharePoint Online (SPO) nos funcione sin problemas en nuestro equipo. Además de este pequeño truco, y gracias a un e-mail de Oscar Maqueda al respecto, es necesario asegurar que hacemos el “Desktop Setup” que asegura la carga de certificados necesarios para trabajar con SPO y Office 365 a pleno rendimiento:
- Lo primero que tenemos que hacer es irnos a la zona de descargas disponible en la administración de Office 365. Esta zona la tendremos tanto para los planes de tipo E como los planes de tipo P1.
- En el caso de un plan E3, tendremos que fijarnos en la descarga # 3.
- En el caso de un plan P1, la descarga que nos interesa es la #2.
- En cualquier de los dos casos, pulsamos “Configurar” para iniciar el proceso de “Desktop Setup”.
- Comprobamos en una biblioteca de documentos cualquiera la experiencia de creación de un documento Office.
-
Se abre la ventana de signin en Microsoft Online Services para confirmar las credenciales de acceso al sitio de SPO y sobre todo para que en posteriores operaciones el usuario no tenga que especificar las credenciales.
-
Si pulsamos “Guardar como”, la ubicación por defecto para guardarlo es la de la biblioteca de documentos desde que hemos iniciado el proceso de creación.
Y hasta aquí llega este post sobre la instalación y configuración de las aplicaciones de escritorio.
Tal y como podéis leer en el blog del equipo de SharePoint, el primer service pack (SP1) de la plataforma está a punto de caer. En concreto, parece que será a finales del mes que viene cuando vea la luz junto con el SP1 para Office 2010, Office Webs Applications (con soporte para Chrome incluido) y Project Server. Volviendo a nuestro servidor favorito, os recomiendo revisar el artículo publicado en el blog del equipo de SharePoint para conocer algunas de las novedades que vendrán en el SP1.
De nuevo una pregunta, que ya surgió en tiempos de SharePoint 2007, en torno a la extensibilidad de la plataforma es la de si podemos de alguna forma usar WebParts existentes dentro de nuestras propias WebParts para poder por ejemplo configurar de forma dinámicas las propiedades que expone en su panel de herramientas. La respuesta es que sí, así por ejemplo podremos usar dentro de nuestra WebParts otras existentes por defecto como el PageViewer o la OWA WebPart entre otras. En torno a este tema se pueden encontrar varios artículos bastante explicativos como:
Algo importante, y de ahí este post, es que usar un WebPart de SharePoint dentro de nuestra WebPart en la práctica implica que estamos usando un control propio de SharePoint en nuestra WebPart. La implicación de este echo es que no podremos usar WebParts existentes dentro de WebParts que vayamos a desplegar en modo Sandbox ya que a día de hoy sólo se permiten usar controles ASP.NET y no controles propios de SharePoint. Por lo tanto, no tendremos este escenario de uso de WebParts existentes en SharePoint Online (SPO) dentro de Office 365 (al menos de momento). Por lo tanto, lo primero que tendremos que hacer en nuestra solución es asegurarnos que el tipo de despliegue para la misma es SandBox:
A partir de aquí, usar por ejemplo la WebPart de OWA de SharePoint 2010 (Server) es tan sencillo como:
1: using System;
2: using System.ComponentModel;
3: using System.Web;
4: using System.Web.UI;
5: using System.Web.UI.WebControls;
6: using System.Web.UI.WebControls.WebParts;
7: using Microsoft.SharePoint;
8:
9:
10: using Microsoft.SharePoint.Portal.WebControls;
11:
12: using Microsoft.SharePoint.WebControls;
13:
14: namespace UCOWADemo.OWAWebPart
15: {
16: [ToolboxItemAttribute(false)]
17: public class OWAWebPart : WebPart
18: {
19: protected override void CreateChildControls()
20: {
21: Label lblDatos = new Label();
22:
23: var owaIPinbox = new OWAInboxPart {
24: MailboxName="mycorreo@miempresa.com",
25: OWAServerAddressRoot = "https://<Direccion_OWA>"
26: };
27:
28: this.Controls.Add((Control)owaIPinbox);
29: }
30: }
31: }
Y hasta aquí llega este artículo sobre como usar WebParts existentes de SharePoint en nuestras propias WebParts.
Como sabéis, con la nueva generación de SharePoint en la nube (SharePoint Online o SPO) que forma parte de Office 365 podremos subir código que se ejecute de forma segura a nivel de colección de sitios (en el Sandbox) lo que habilita escenarios de extensibilidad de SPO que no eran posibles en la versión anterior de la suite de productividad de Microsoft en la nube. Ahora bien, aunque el código que se suba se ejecute de una forma más o menos segura, cualquier tipo de análisis que permita validar el código antes de subirlo siempre es bienvenido y esto es lo que podemos conseguir con el MSOCAF o Microsoft Online Code Analysis Framework concebido originalmente para despliegues en BPOS-D (Dedicados), pero que podremos usar (eso sí, ahora mismo el enlace de descarga no está operativo) de forma extensiva con nuestras solucionas para recoger información relativa a:
- Gestión de la memoria.
- Posibles vulnerabilidades de seguridad.
- Gestión de excepciones.
- Uso del modelo de objetos.
- …
MSOCAF se apoya en herramientas como FxCop, CAT.Net y SPDisposeCheck para realizar el análisis de nuestras soluciones y generar informes como el siguiente:
Además de detectar errores en nuestro código, MSOCAF nos dará información inicial para solucionarlos. Podéis descargaros MSOCAF (en cuanto el enlace vuelva a la vida) desde aquí.
Más artículos
Página siguiente >