November 2011 - Artículos
Si tenéis necesidad de trabajar con servicios de tipo Open Data y no tenéis a mano uno propio, no os preocupéis porque hay un repositorio de servicios públicos listos para ser usados en nuestras aplicaciones que podéis acceder desde la sección Producers del sitio de Open Data: http://www.odata.org/producers. Por ejemplo, para la BD Northwind la url del servicio que tenemos disponible es http://services.odata.org/Northwind/Northwind.svc/.
Cuando parece que el “estándar” no da para más, en SharePoint Online dentro de Office 365 tienes que recurrir a truquillos para conseguir disponer de ciertas funcionalidades extra demandadas por tus usuarios…una de las últimas que salió en los foros de Office 365 era relativa a como conseguir hacer una redirección desde páginas del sitio publico de SharePoint Online a un sitio privado. Lógicamente, en seguida me vino a la mente que esto con JavaScript seguro que se podía conseguir…la cuestión es como añadir ese JavaScript que haga la redirección:
-
Lo primero que intenté utilizar es la interfaz de usuario del sitio público e intente añadir el código JavaScript necesario mediante alguno de los gadget disponibles, y en concreto el de HTML…pero no hubo forma.
-
Esto me llevó sin remedio a ver si con SharePoint Designer 2010 (SPD 2010) se podía conseguir…y aquí si tuve más suerte. Nos vamos a la sección “All Files” y buscamos la biblioteca “Pages”.
-
Hacemos clic sobre la página en la que queremos introducir la redirección.
-
A continuación aparece la correspondiente página de resumen que nos permite editar la página.
-
Al pulsar el enlace de editar la página, nos aparece un mensaje de warning indicando que para poder personalizar la página es necesario editarla en modo avanzado.
-
Una vez que hemos editado la página, añadimos el código JavaScript necesario para hacer la redirección.
- El código JavaScript a añadir es el siguiente (lo colocaremos bajo <asp:Content…>
1: <asp:Content ID="content1" runat="server" ContentPlaceHolderID="IWS_WH_CPH_Content" xmlns:asp="asp">
2: <script type="text/javascript" language="javascript">
3: window.location = 'http://www.ciin.es';
4: </script>
Tras guardar, simplemente comprobamos que al acceder a la página se hace la redirección como esperábamos.
Cuando se habla de la versión instalada de SharePoint 2010, tenemos que diferenciar entre la versión de producto que tenemos instalada (Foundation, Server Standard o Server Enterprise) y la versión de producto relativa a las build numbers o actualizaciones sucesivas que Microsoft va sacando y que vamos aplicando a nuestros despliegues de forma paulatina, y especialmente en el caso de los service packs (SPs). Por lo tanto:
-
Si queremos saber que versión de producto tenemos instalada, os recomiendo esta referencia (
http://www.jcubica.com.mx/?p=27) en la que se indica como a partir de la información de registro o utilizando PowerShell podemos sacar la versión de producto instalada. Por supuesto, la administración central de SharePoint 2010 nos dará también información al respecto.
Como sabéis, uno de los pilares de la plataforma SharePoint es el denominado “Insights o perspectivas” y que tiene que ver con como poder integrar, analizar y publicar información de negocio de una organización en la forma de KPIs (Key Performance Indicators), Informes, cuadros de mando, gráficos de distintos tipos, etc. Por lo tanto, estamos hablando de Business Intelligence (BI) siendo las capacidades disponibles en SharePoint 2010 las siguientes:
Capacidades de BI disponibles en SharePoint Foundation y SharePoint Server 2010
Si nos centramos en el núcleo de la plataforma y en el producto grande, presentan en común las siguientes capacidades de BI:
Capacidades de BI disponibles en SharePoint Server únicamente
Si nos centramos en SharePoint Server 2010, añade a las capacidades de BI anteriores las siguientes:
-
Diseñar e implementar KPIs a partir de información almacenada en listas de SharePoint, hojas Excel, Bases de Datos (BDs),…
-
Crear gráficos interactivos y dinámicos utilizando la Chart WebPart que es precisamente se aprovecha de la integración nativa de los .NET Chart Controls comentada anteriormente.
-
-
Los servicios de Excel que facilitan la publicación de libros Excel de forma segura (podemos elegir que partes del libro publicar) de forma que podemos disponer de toda la potencia de Excel para modelar KPIs, gráficos de distintos tipos, uso de los slicers, … directamente en el navegador. La experiencia de usuario desde el punto de vista de interactividad con la información es casi idéntica a la que tiene con el cliente de Excel.
-
-
¿Y cuándo uso cada cuál?
Esa es una buena pregunta, sobre todo si disponemos de SharePoint Server y aparentemente parece que con SSRS, PPS o los Servicios de Excel puedo hacer lo mismo…aparentemente porque hay diferencias entre ellos que debemos tener en cuenta a la hora de decantarnos por una u otra opción:
- SSRS:
-
A la hora de diseñar informes de tipo matricial y tabular de forma rápida es una opción muy adecuada.
-
Cuenta con la capacidad de modelar suscripciones, es decir, generar un cierto informe en un cierto formato de acuerdo a una planificación y una forma de entrega (en una biblioteca de documentos, por correo electrónico).
-
PPS:
-
El modelado de KPIs y cuadros de mando con el diseñador de paneles es muy productivo y espectacular.
-
La facilidad con la que definir informes analíticos es sin duda su capacidad muy potente, además del Decomposition Tree para analizar la información mostrada en los mismos.
-
Servicios de Excel:
Una pequeña tabla que nos puede ayudar a elegir es la siguiente:
Y hasta aquí este largo post sobre capacidades de BI en SharePoint 2010 y alguna pauta para elegir que capacidad utilizar en cada caso.
Pues eso, desde SUGES mañana 29 de noviembre sobre las 19:30 horas de la mano de David Martos tendremos la oportunidad de poder contestar a tan peregrina cuestión. Los detalles del WebCast son los siguientes:
Los grupos de usuarios de SharePoint de España (SUGES) y de Catalunya (SUG.CAT) organizan un nuevo WebCast en el que tendremos la oportunidad de hablar sobre un terreno un tanto “tabú” en el desarrollo de soluciones para SharePoint 2010: ¿Es posible gestionar el cíclico de vida o ALM en proyectos en los que el componente clave sea SharePoint. En esta sesión os enseñaremos como podéis gestionar el ciclo de vida de las aplicaciones (ALM) en proyectos que involucren SharePoint 2010 para conseguir así aumentar su calidad y su mantenibilidad. Veremos algunos de los problemas más habituales en el desarrollo de este tipo de proyectos así como algunas soluciones que podéis aplicar para minimizar su impacto.
Datos de Interés
Como sabéis, SharePoint está construido sobre la base de ASP.NET 3.5 SP1 lo que implica que mucho de los conceptos y elementos propios de este último son aplicables en la plataforma. Precisamente, esto es lo que sucede con los denominados HTTP Handlers que como sabéis son componentes que nos permiten proporcionar a nuestras soluciones ASP.NET y SharePoint de un mecanismo eficiente y flexible para procesar peticiones en las que no tenemos implicadas páginas HTML estándar como por ejemplo devolver texto plano, XML, datos binarios o datos de usuario. En el mundo SharePoint, los HTTP Handlers son una técnica muy habitual cuando queremos redirigir al usuario a una cierta página en situaciones en las que tenemos por ejemplo páginas de login personalizadas o simplemente porque queremos evitar que usuarios no autorizados accedan a nuestros sitios. La base de creación de un HTTP Handler es la interfaz IHttpHandler de la que deben heredar nuestras implementaciones. Finalmente os dejo una serie de enlaces relativos a HTTP Handlers:
- SharePoint 2010:
- SharePoint 2007:
No soy un gran fan de utilizar la aproximación declarativa a la hora de definir “artefactos” típicos de SharePoint como pueden ser columnas o tipos de contenido de SharePoint 2010, pero como se suele decir hay que saber de todo y a veces esta aproximación puede resultar ventajosa frente a trabajar exclusivamente en el mundo de los objetos. El caso es que la aproximación declarativa implica que tienes que tener cierto cuidado cuando defines los atributos que conforman un cierto artefacto, y de ahí el título de este post, ya que por ejemplo no es lo mismo especificar el ID de una columna de sitio de SharePoint 2010 de la forma ID=“ 59491385-A088-4CEA-AEC9-B6BE51276C0F” que hacerlo como ID=“{59491385-A088-4CEA-AEC9-B6BE51276C0F}”…la sutil diferencia viene dada por las llaves de inicio y cierre del ID ya que si no las indicamos provocamos que a la hora de usar esas columnas en la definición de un tipo de contenido éste no se dé por enterado y no las incorpore, amén de problemas en re-despliegue de los artefactos y otras situaciones curios…moraleja: define y referencia los atributos como los espera SharePoint:
1: <?xml version="1.0" encoding="utf-8"?>
2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
3: <Field ID="{59491385-A088-4CEA-AEC9-B6BE51276C0F}"
4: Name="SubmittedBy"
5: DisplayName="$Resources:SubmittedBy"
6: Type="User" List="UserInfo" ShowField="NameWithPicture"
7: UserSelectionScope="0" UserSelectionMode="0"
8: Required="TRUE" Group="Custom Columns"></Field>
9: </Elements>
- Referencia a la columna de sitio en la definición de un tipo de contenido:
1: <?xml version="1.0" encoding="utf-8"?>
2: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">
3: <!-- Parent ContentType: Item (0x01) -->
4: <ContentType ID="0x0100c660015c779343cd8a24648d752b6778"
5: Name="$Resources:WeeklyStatusReportCT"
6: Group="Custom Content Types"
7: Description="$Resources:WeeklyStatusReportCTDesc"
8: Inherits="TRUE"
9: Version="0">
10: <FieldRefs>
11: <FieldRef ID="{FA564E0F-0C70-4AB9-B863-0177E6DDD247}" Name="Title" Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE"/>
12: <FieldRef ID="{59491385-A088-4CEA-AEC9-B6BE51276C0F}" Name="SubmittedBy" Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE"/>
13: </FieldRefs>
14: </ContentType>
15: </Elements>
Una cuestión que empieza a ser un tanto recurrente cuando hablamos sobre las capacidades disponibles en SharePoint Online en Office 365 es respecto al soporte de correo entrante en listas de SharePoint que permita que sea suficiente con especificar la dirección de correo electrónico asociada a la lista para que todo correo enviado a la misma sea archivado en la lista en cuestión. Esta capacidad, disponible en instalaciones On-Premise, de momento no está disponible en SharePoint Online y a día de hoy Microsoft no ha comentado cuando estará o si ve factible que esta funcionalidad se encuentre como parte del offering de la plataforma de colaboración en la nube…los motivos, pues varios como: cuestiones de escalabilidad, rendimiento, configuración de políticas, etc. Os recomiendo leer este post en el que se trata bastante en profundidad este tema.
Siguiendo con la serie de artículos en torno a la integración entre SharePoint 2010 y SQL Server Reporting Services (SSRS) en esta ocasión quería tratar un tema que necesitaremos por ejemplo para poder crear suscripciones: crear una cuenta de ejecución de informes que resida en SQL Server. Antes de empezar, os remito al último post de la serie que a su vez tiene un enlace a todos los artículos relativos a esta integración que se han publicado hasta ahora: SharePoint 2010: Integración con SSRS 2008 y SSRS 2008 R2 (VII)!
Para crear una cuenta de ejecución de informes a nivel de BD:
-
En primer lugar, es necesario crear a nivel de BD un login con los privilegios mínimos que nos permita definir orígenes de datos de SQL Server usando dicho login. Para añadir el login, tenemos dos posibilidades:
1: --Añadimos el usuario en la master
2: use master
3: exec sp_droplogin @loginame='ReportExecution'
4: exec sp_addlogin @loginame='ReportExecution', @passwd='pass@word1'
5:
6: --En AdventureWorksDW
7: use AdventureWorks2008
8: if exists(select * from sysusers where name='ReportExecution')
9: exec sp_dropuser @name_in_db='ReportExecution'
10: exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'
11:
12: --En msdb
13: use msdb
14: if exists(select * from sysusers where name='ReportExecution')
15: exec sp_dropuser @name_in_db='ReportExecution'
16: --add the users to the databases and give them permissions
17: exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'
18:
19: --En ReportServer
20: use ReportServer
21: if exists(select * from sysusers where name='ReportExecution')
22: exec sp_dropuser @name_in_db='ReportExecution'
23: --add the users to the databases and give them permissions
24: exec sp_adduser @loginame='ReportExecution', @grpname='db_datareader'
Nota: Si la ejecución del T-SQL da algún tipo de error, se recomienda ejecutar los bloques relativos a cada BD en la que se está añadiendo el login de forma independiente.
-
Una vez que hemos creado el origen de datos, nos aseguramos que nuestro servidor de SQL Server permite autenticación Windows y SQL Server ya que por defecto puede ser que esté configurado para utilizar únicamente autenticación Windows.
-
Para realizar esta configuración nos conectamos al servidor de BD dónde está configurado SSRS (y también dónde estén las BDs fuente de los informes) con SQL Server Management Studio, hacemos clic con el botón derecho del ratón sobre el nombre del servidor y pulsamos la opción Propiedades o Properties.
-
En la ventana que se abre, nos vamos a la sección “Seguridad” o “Security” y marcamos la opción relativa al uso de autenticación Windows y SQL.
-
Pulsamos OK, de manera que se mostrará un mensaje informativo indicando que para que los cambios tenga lugar será necesario reiniciar el servicio de SQL Server.
-
Para reiniciar el servicio de SQL Server, nos vamos a la herramienta de configuración de SQL Server y simplemente re-iniciamos el servicio correspondiente.
-
Comprobamos a través de SQL Server Management Studio que accedemos a BD mediante autenticación SQL y especificando las credenciales del login de BD creado.
-
Creamos un origen de datos usando el login de BD creado. Por ejemplo, en Report Builder 3.0.
-
Comprobamos que la conectividad a la BD es correcta y generamos un primer informe de ejemplo.
- Por ejemplo, un informe creado con esta forma de autenticación y plenamente operativo es el siguiente.
- El mismo informe vemos que se visualiza en un sitio de SharePoint de forma correcta.sdf
Y hasta aquí llega este nuevo artículo en torno a la integración de SSRS y SharePoint 2010.
Esta mañana me he encontrado un canal de YouTube específico de la SharePoint Conference en la que se han colgado nada más y nada menos que 193 vídeos de sesiones impartidas allí. Podéis acceder a los videos desde este enlace: http://www.youtube.com/user/sharepointconference
Hace un tiempo comentaba en este artículo las limitaciones que nos podemos encontrar a la hora de trabajar con los metadatos administrados de SharePoint 2010 (disponibles a partir de la versión estándar de la plataforma). El caso es qué haciendo alguna prueba con este tipo de dato, me he dado cuenta de otra limitación adicional que intuía, pero que no había tenido la oportunidad de comprobar: el soporte de este tipo de campo a la hora de trabajar con listas “cuasi-relacionales”…y el resultado de las pruebas es que este tipo de campo no está soportado ni para relacionar dos listas ni para ser utilizado como un campo proyectado al realizar definir un campo de lookup en una lista hija con respecto a la lista padre en la que está disponible una columna de este tipo. Para probarlo, dos pasos sencillos:
-
Creamos en primer lugar una lista en la que esté disponible una columna de tipo metadato administrado.
-
Creamos a continuación la lista a vincular con la lista inicial mediante un campo de lookup y comprobamos como dicho campo no aparece a la hora de modelar el lookup.
En el primer artículo de la serie sobre configuración y uso de los Business Connectivity Services (BCS) en SharePoint Online dentro de Office 365 veíamos como integrar un servicio WCF publicado en Azure, mientras que en la segunda parte os referenciaba a como integrar datos de una BD de SQL Azure….una pregunta que puede surgir es si este tipo de integraciones sólo son posibles con servicios o BD’s en Windows Azure o por el contrario podemos ir más allá e integrarnos con servicios On-Premise y BD’s On-Premise…y la respuesta, como veremos, es que sí. Antes de comenzar os recuerdo los posts previos de la serie:
La idea de este artículo es ver como integrar un servicio On-Premise que requiera autenticación en SharePoint Online:
-
A modo de demostración, partiré de uno de los servicios web que expone SharePoint 2010 y en concreto los relativos al despliegue SharePoint 2010 que tenemos en el CIIN.
-
Por ejemplo, para el servicio Lists.asmx necesitaremos tanto la Url del servicio como la relativa al WSDL.
-
Lo siguiente que haremos es configurar la correspondiente aplicación de destino en el Servicio de Almacenamiento Seguro de SharePoint Online siguiendo las pautas vistas en
este artículo. En este caso, lo más peculiar es que las credenciales a especificar son las relativas a una cuenta de dominio.
-
Una vez que hemos establecido las credenciales, nos vamos a SharePoint Designer 2010 (SPD 2010)
-
Como siempre, nos iremos a la sección “External Content Types” para proceder a crear el correspondiente tipo de contenido externo (ECT) en el que tendremos que especificar la correspondiente conexión al servicio. En este caso, el tipo de conexión que elegiremos es “WCF”, de manera que los parámetros de conexión son:
-
Service Metadadata Url: <Sitio_SharePoint>/_vti_bin/Lists.asmx?WSDL
-
Metadata Connection Mode: WSDL
-
Service Endpoint Url: <Sitio_SharePoint>/_vti_bin/Lists.asmx
-
En las opciones de autenticación elegimos “Connect with impersonated custom identity” y especificamos el ID de la aplicación destino creada en el SSS.
-
Tras pulsar “OK”, se nos pedirán las credenciales de nuestra cuenta de dominio (únicamente la primera vez que nos conectemos) y al cabo de unos instantes tendremos disponible la conexión para modelar el ECT…cool!
Y listo, ya podríamos comenzar a modelar el ECT…en este caso el servicio no expone unos Web Methods adecuados para modelar un ECT, pero si hubiésemos publicado un servicio en nuestro entorno que si lo hiciese podríamos exponer las correspondientes entidades y crear todas las operaciones sin problemas.
Como esta pregunta empieza a ser un tanto recurrente, simplemente comentar que la opción de grabación de Lync Online no depende del servicio, sino del país dónde se esté usando como podéis ver en este KB con fecha el 8 de noviembre de este año:
At the release of Office 365, recording options will be disabled in the Microsoft Lync 2010 client for legal and privacy reasons. Because certain countries and nationalities require permission from all parties to record instant messaging (IM), audio, and video conversations, the Lync Online engineering team decided to remove this feature until a future update is released to address this. Recording options will be re-enabled after the update is released and deployed to Lync Online.
Discusiones al respecto en los foros de Office 365:
Configuración On-Premise: http://office.microsoft.com/es-es/communicator-help/grabar-y-reproducir-reuniones-en-lync-2010-HA101834765.aspx
Si tenemos la necesidad de hacer una redirección desde una página cualquiera de un sitio de SharePoint Online en función de los permisos de usuario, contamos con dos tipos de técnicas (teniendo en cuenta las limitaciones del servicio): utilizar código de cliente vs utilizar código de servidor. En el caso de utilizar código de cliente, recurriremos al modelo de objetos en cliente (sabor ECMAScript) que nos permite conocer el usuario logado, comprobar sus permisos y realizar la correspondiente redirección. Por ejemplo, podemos insertar el siguiente código en una Content Editor WebPart de una página de manera que si el usuario tiene un cierto nivel de permisos se haga la redirección correspondiente:
1: <script type="text/javascript">
2: ExecuteOrDelayUntilScriptLoaded(ConsultarUsuario, "sp.js");
3:
4: function ConsultarUsuario() {
5:
6: // Contexto de cliente
7: var context = new SP.ClientContext.get_current();
8:
9: // Carga del sitio actual (SPWeb)
10: this.site = context.get_web();
11: context.load(this.site);
12:
13: // Usuario actual
14: this.UsuarioActual = site.get_currentUser();
15: this.UsuarioActual.retrieve();
16:
17: //Permisos para el usuario actual
18: context.load(site,'EffectiveBasePermissions');
19:
20: // Ejecutar la consulta de forma asíncrona
21: context.executeQueryAsync(Function.createDelegate(this, this.onSuccess), Function.createDelegate(this, this.onFailure));
22: }
23:
24: function onSuccess(senger, args) {
25: alert("Usuario Actual: " + this.UsuarioActual.get_title() + "\n" + "Login de Usuario:: " + this.UsuarioActual.get_loginName());
26: if (this.site.get_effectiveBasePermissions().has(SP.PermissionKind.manageLists))
27: alert("No tienes permisos para ver esta página, redirigiendo ...");
28: window.location = 'http://www.ciin.es'
29: }
30: function onFailure(sender, args) {
31: alert("Petición fallida " + args.get_message() + "\n" + args.get_stackTrace());
32: }</script><input onclick="ConsultarUsuario()" type="button" value="Usuario Actual"/>
Para añadir el código en la WebPart, basta con utilizar la opción de añadir código fuente HTML en lugar de texto enriquecido:
Referencias:
Como sabéis, el modelo de objetos en cliente de SharePoint 2010 facilita el poder interoperar de forma remota con sitios de SharePoint en base a tres implementaciones: .NET, Silverlight y ECMAScript. El ámbito de operación de cualquiera de las tres implementaciones está dado por un nivel superior determinado por la colección de sitios y un nivel inferior que podemos considera que es un elemento / documento de biblioteca o lista. Entre medias, podemos crear muchos de los elementos específicos de la jerarquía de SharePoint como por ejemplo crear sitios, listas, elementos en listas, etc. Como ejemplo de la potencia del modelo de objetos en cliente, resulta bastante sencillo cargar un archivo en una biblioteca de documentos desde por ejemplo una aplicación de escritorio en la que usemos la implementación .NET:
1: using System;
2: using System.Collections.Generic;
3: using System.Linq;
4: using System.Text;
5:
6: //Espacios de nombres necesarios
7: using MO_NET=Microsoft.SharePoint.Client;
8: using System.IO;
9:
10: namespace NetClientOMDemo
11: {
12: class Program
13: {
14: static void Main(string[] args)
15: {
16: try
17: {
18: using (MO_NET.ClientContext ctx =
19: new MO_NET.ClientContext("http://demo2010a:100/sites/PortalIntranet/"))
20: {
21: MO_NET.List lBibliotecaDocumentos =
22: ctx.Web.Lists.GetByTitle("Documentos compartidos");
23: MO_NET.FileCreationInformation fciArchivo =
24: new MO_NET.FileCreationInformation();
25: fciArchivo.Content = File.ReadAllBytes(@"..\..\08 - Workflow.pptx");
26: fciArchivo.Url = "08 - Workflow.pptx";
27: fciArchivo.Overwrite = true;
28: MO_NET.File fToUpload =
29: lBibliotecaDocumentos.RootFolder.Files.Add(fciArchivo);
30: ctx.Load(fToUpload);
31: ctx.ExecuteQuery();
32: }
33: }
34: catch (Exception ex)
35: {
36: Console.WriteLine("Error: {0}", ex.Message);
37: }
38: Console.ReadLine();
39: }
40: }
41: }
Como vemos, los pasos a seguir son:
-
Definir un objeto de tipo ClientContext que se encargará de “orquestar” todas las peticiones que haya entre cliente y servidor.
-
Accedemos a la biblioteca con la que queremos trabajar mediante el método GetByTitle.
-
Definimos un objeto de tipo FileCreationInformation que nos va a permitir cargar un documento en la biblioteca en cuestión.
-
Configuramos dicho objeto especificando el archivo físico, el nombre en la biblioteca y si vamos a sobreescribir.
-
Llamamos al método Add() de la biblioteca de documentos para añadir el documento en cuestión.
-
Como siempre, definimos lo que queremos hacer mediante el método Load().
-
Realizamos de forma efectiva la ejecución de las operaciones mediante ExecuteQuery().
Y el resultado obtenido tras ejecutar la carga del archivo con nuestra aplicación cliente es que este se carga de forma efectiva en la biblioteca de documentos.
Cómo ya se ha comentado en varios artículos de este blog, la Ribbon de SharePoint 2010 es completamente extensible de manera que podemos añadir nuevas opciones en la misma u ocultar opciones existente. Además, y de ahí este post, podremos reemplazar opciones de la Ribbon por otras tal y como se muestra en este How-To de MSDN.
Cómo sabéis, la experiencia a la hora de determinar posibles problemas o errores que nos podamos encontrar en cualquiera de los servicios que forman parte del offering de Office 365 no es la misma que podamos tener en nuestro entorno On-Premise ya que no tenemos la posibilidad de acceder a la administración de los servicios o a los servidores en las mismas condiciones que en este último caso. Sin embargo, poco a poco van apareciendo pequeñas herramientas y utilidades que nos permiten hacer algo de troubleshooting como es el caso de esta herramienta disponible online: Office 365 Troubleshooting Tool. Como vemos:
-
El primer paso consiste en seleccionar el tipo de usuario y el plan de Office 365.
-
A continuación elegimos el servicio concreto de Office 365 sobre el que queremos obtener información (en mi caso he escogido SharePoint Online).
-
El siguiente paso consiste en seleccionar un área concreta del servicio (en mi caso he escogido Managing Lists).
-
A continuación se muestra un listado de posibles problemas para el área seleccionado. En mi caso, he escogido SharePoint Designer.
-
Finalmente se muestra una página con información sobre posibles soluciones.
Cada vez queda menos para tener disponible la versión RTM de la nueva versión de SQL Server denominada desde hace unas semanas SQL Server 2012…y como prueba de ello, Microsoft acaba de liberar la versión Release Candiate (RC) de SQL Server 2012 que podéis descargar desde este enlace. Os recomiendo también daros una vuelta por el sitio de SQL Server en Microsoft para acceder a más información.
Como comentaba en este artículo, desde hace unas semanas tenemos disponibles la primera serie de actualizaciones dentro de SharePoint Online en Office 365. Una de dichas actualizaciones es la incorporación a la arquitectura Multy-Tenancy de SharePoint Online del Secure Store Service (SSS o Servicio de Almacenamiento Seguro) que nos permite integrar datos de sistemas externos (servicios WCF, BD’s SQL Azure o incluso SQL Server On-Premise siempre y cuando en este caso el SQL Server esté expuesto de forma pública). Para el caso de una BD SQL Azure:
-
Para poder integrar datos de SQL Azure, necesitamos disponer de una cuenta de Windows Azure y tener creada la correspondiente BD de SQL Azure.
-
Una vez que disponemos de una BD SQL Azure con datos listos para ser integrados en SharePoint Online en Office 365, tenemos que configurar el SSS a través del Centro de Administración de SharePoint Online en Office 365. Pulsamos sobre el enlace “Administrar Servicio de almacenamiento seguro”.
-
En la página que se abre, pulsamos sobre “Nueva” para poder crear la correspondiente aplicación de destino que luego usaremos para modelar y crear el tipo de contenido externo correspondiente.
-
En la página que se abre, especificamos todos los parámetros de configuración para la aplicación de destino:
-
Id. de la aplicación de destino: BCS_SQL_Azure_App_ID.
-
Nombre para mostrar: BCS SQL Azure Application.
-
Correo electrónico del contacto: indicamos un correo electrónico.
-
En la sección “Campos de credenciales” cambiamos los textos “Usuario de Windows” y “Contraseña de Windows” por “Usuario” y “Contraseña” respectivamente.
-
Administradores de la aplicación destino: especificamos un usuario administrador del servicio de SharePoint Online.
-
Miembros: especificamos por simplicidad el mismo usuario anterior.
-
Realizadas todas las configuraciones, pulsamos “Aceptar” para guardar los cambios. De vuelta a la página con el listado de aplicaciones destino, lo siguiente que haremos es especificar las credenciales para la aplicación creada a través de la opción correspondiente de la Ribbon o mediante el menú contextual.
-
En la ventana que se abre especificamos el usuario y contraseña de la instancia de SQL Azure en la que reside la BD que vamos a integrar:
A partir de aquí, ya podríamos probar que la aplicación de destino creada nos permite modelar un tipo de contenido externo basado en una BD SQL Azure en SharePoint Designer 2010 (SPD 2010):
-
Abrimos SPD 2010 y especificamos como sitio de trabajo uno de SharePoint Online.
-
Nos vamos a la sección External Content Types y pulsamos sobre la opción “External Content Type” de la Ribbon.
-
En la pantalla relativa al diseñador de operaciones pulsamos sobre el botón “Add connection”. En la ventana que se abre especificamos que la conexión es de tipo SQL Server.
-
En la nueva ventana que se muestra definimos la conexión a nuestro SQL Azure especificando los parámetros siguientes:
-
Database Server: tcp:<Instancia_SQL_Azure>.database.windows.net
-
Database Name: El nombre de la BD (Customers en mi caso).
-
Como opción de autenticación especificamos “Connect with Impersonated Custom Identity” y añadimos el ID de aplicación creado en el SSS.
-
Si todas las configuaciones realizadas son correctas, en el momento en el que pulsemos “OK”, BCS intentará conectarte a SQL Azure y nos pedirá que indiquemos las credenciales configuradas en el SSS.
y hasta aquí llega este primer post sobre la configuración y uso del SSS en SharePoint Online.
Siguiendo con la serie de posts sobre como añadir propiedades a la toolpart de configuración de una WebPart, en esta ocasión vamos a complementar los artículos previos (en particular el primero de la serie) indicando que otros atributos tenemos disponibles para facilitar la adicción de nuevas propiedades de configuración. Pero antes de empezar, os dejo la referencia a los artículos previos de la serie:
Tal y como veíamos en el primer post de la serie, una primera técnica de añadir propiedades consiste en añadir a nuestro código una propiedad que decoremos con los atributos WebBrowsable y Personalizable…además de estos atributos, podremos añadir otros:
-
WebBrowsable, indica a la infraestructura de WebParts que la propiedad en cuestión tiene que estar accesible a través de su panel de configuración.
-
Personalizable, indica que esta propiedad se puede configurar de forma globa (para todos los usuarios) o de forma particular (por usuario). Para ello, se definen dos ámbitos de personalización: Shared vs User respectivamente.
-
Category, que permite añadir una categoría dentro del panel de configuración en la que se ubicará la nueva propiedad.
-
WebDisplayName, que permite especificar el título para la nueva propiedad a añadir.
Un ejemplo de uso de estos atributos en una WebPart de tipo clásico o visual es el que sigue:
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: using Microsoft.SharePoint.WebControls;
9:
10: namespace SPLINQWP.SPLINQToSPCRWP
11: {
12: [ToolboxItemAttribute(false)]
13: public class SPLINQToSPCRWP : WebPart
14: {
15: // Visual Studio might automatically update this path when you change the Visual Web Part project item.
16: private const string _ascxPath = @"~/_CONTROLTEMPLATES/SPLINQWP/SPLINQToSPCRWP/SPLINQToSPCRWPUserControl.ascx";
17:
18: [WebBrowsable(true)]
19: [Personalizable(PersonalizationScope.Shared)]
20: [Category("Datos de configuración adicionales")]
21: [WebDisplayName("Configuración adicional")]
22: [WebDescription("Propiedad Personalizada adicional")]
23: public string sMiPropiedadPersonalizada { get; set; }
24:
25: protected override void CreateChildControls()
26: {
27: Control control = Page.LoadControl(_ascxPath);
28: Controls.Add(control);
29: }
30: }
31: }
Y el resultado en la UI es el siguiente:
Más artículos
Página siguiente >