July 2009 - Artículos
Como sabéis, algo fundamental para evitarnos problemas es asegurarnos que dentro de nuestra granja de SharePoint todos nuestros servidores tienen la misma versión instalada (Os recomiendo este post de mi compañero Pablo Sousa sobre el tema). Además, es conveniente actualizarla con los últimos parches, hotfixes y service packs (siempre transcurrido un tiempo desde su disponibilidad para curarnos en salud). El caso es que, después de casi 3 años desde que SharePoint 2007 viera la luz, han llovido numerosos parches, hotfixes y un par de services packs en SharePoint por lo que no está de más tener a mano la versión correspondiente a cada una de estas actualizaciones:
- Cumulative update de junio de 2009: 12.0.0.6510
- Cumulative update de abril de 2009: 12.0.0.6504
- Service Pack 2: 12.0.0.6421
- Cumulative update de febrero de 2009: 12.0.0.6341
- Cumulative update de agosto de 2009: 12.0.0.6327
- Actualización de infraestructura: 12.0.0.6318
- Post-SP1 hotfix: 12.0.0.6303
- Post-SP1 hotfix: 12.0.0.6301
- Post-SP1 hotfix: 12.0.0.6300
- Service Pack 2: 12.0.0.6219
- Public Update de octubre de 2007: 12.0.0.6039
- Hotfix package de agosto de 2007: 12.0.0.6036
- RTM: 12.0.0.4518
- Beta 2 TR: 12.0.0.4407
- Beta 2: 12.0.0.4017
- Office 12 (pre-beta): 12.0.0.3111
Os recuerdo que para conocer la versión de SharePoint tenéis que:
Otras dos formas de obtener la versión instalada de SharePoint son:
Fuente: http://msfarmer.blogspot.com/2009/07/sharepoint-versions.html
Parece que, por cortesía de Lenovo, ya hay circulando con una semana de antelación una versión RTM de Windows 7 Ultimate con clave de activación incluida. Podéis acceder al detalle en esta noticia en The Inquirer. Pues nada, el que tenga prisa por probar la RTM y no tenga una suscripción MSDN, ya sabe lo que tiene que hacer ;-).
La verdad es que Codeplex es una fuente ingente de proyectos destinados a mejorar plataformas y tecnologías existentes o en ciernes. Esto no es una excepción en el caso de SharePoint y el último proyecto con el que me he encontrado: SharePoint Action Framework (SAF). Este proyecto ofrece la posibildiad de automatizar y repetir cambios de configuración en SharePoint a través de acciones. Estas acciones se pueden agrupar en un archivo XML y ser ejecutadas a través de una feature de SharePoint, un comando STSADM, MSBuild o un servicio WCF. El proyecto, desarrollado desde Collaboris tienen muy buena pinta tal y como podéis ver en este pequeño Quick Start sobre el mismo.
Apenas han pasado dos meses desde la disponibilidad de Visual Studio 2010 y .NET Framework 4.0 Beta 1, y ya tenemos mejoras para este último de la mano de STM.NET. Se trata de una versión mejorada de .NET Fx 4.0 Beta 1 (podéis ver los detalles del anuncio en el blog de Soma Segar) que habilita el uso de memoria transaccional en nuestros desarrollados. Tal y como nos indica Soma, esta tecnología libera a los desarrolladores de tener que preocuparse de implementar mecanismos granulares para el bloqueo y sincronización en aplicaciones multi-hilo. Para ello, STM.NET proporciona una semántica transaccional para lecturas y escrituras en memoria de forma que los desarrolladores se centren en la lógica de la aplicación en lugar de los detalles de entrada / salida de memoria cuando implementan aplicaciones mono-núcleo o multi-núcleo.
STM.NET facilita la declaraciones de regiones atómicas de código al más puro estilo de las transacciones atómicas en base de datos. De esta forma, el bloque de código definido como atómico se ejecuta de forma aislada con respecto a otros bloques y en caso de que se ejecute con errores, se genera el correspondiente roll back. Y todo ello sin que como desarrolladores tengamos que hacer bloqueos explícitos de nuestro código. Sin duda, interesante esta mejora para .NET Fx 4.0. Os dejo varios enlaces de interés:
Si hace unos días os hablaba de distintas soluciones de antivirus para SharePoint, hoy toca hablar de un bug que Microsoft ha identificado a comienzos de mes en ForeFront para SharePoint. Básicamente, el bug en cuestión puede producir el borrado de datos (algo que sólo debería ocurrir en el caso de que se haya encontrado un virus) y fugas de memoria en el caso de que se realice escaneo manual de documentos mediante ForeFront para SharePoint. Podéis leer más información en este post del equipo de Forefront. Microsoft está trabajando en hotfix que solucione este importante bug, mientras tanto no es recomendable realizar escaneos manuales para evitar la pérdida de información.
Siguiendo con la serie de post sobre automatización en la publicación de formularios Infopath (puedes ver la parte I en este enlace), en esta ocasión os voy a mostrar como podemos actualizar o borrar formularios Infopath que ya hemos desplegado en MOSS de una forma automática. Como siempre, la clave está en la herramienta de administración de SharePoint por línea de comandos: STSADM. Empecemos.
Actualización de una plantilla de formulario ya publicado
Para actualizar un formulario Infopath ya publicado, no tenemos más que ejecutar la siguiente secuencia de comandos:
| echo Actualizando formulario Infopath... ::Revisar que los path estén correctos SET STSADM=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe SET FormPath=C:\Documents and Settings\Administrator\Desktop\Demos Workshop\ExprensesReportForm.xsn SET SiteUrl=http://litwaredemo "%STSADM%" -o DeActivateFormTemplate -url %SiteUrl% -filename "%FormPath%" "%STSADM%" -o verifyformtemplate -filename "%FormPath%" "%STSADM%" -o UpgradeFormTemplate -filename "%FormPath%" "%STSADM%" -o execadmsvcjobs "%STSADM%" -o ActivateFormTemplate -url %SiteUrl% -filename "%FormPath%" echo Actualización terminada... |
Como vemos:
-
A través de DeActivateFormTemplate desactivamos el formulario ya publicado.
-
Verificamos que la plantilla a actualizar es correcta con verifyformtemplate.
-
Actualizamos la plantilla existente con la nueva a través de UpgradeFormTemplate.
-
Ejecutamos los Timer Jobs de SharePoint.
-
Activamos la plantilla con ActivateFormTemplate.
Desinstalando una plantilla de formulario
Desinstalar una plantilla de formulario ya publicada implica ejecutar los siguientes comandos:
| echo Desinstalando formulario Infopath... ::Revisar que los path estén correctos SET STSADM=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe SET FormPath=C:\Documents and Settings\Administrator\Desktop\Demos Workshop\Infopath Deploy\STSADM\ExpensesReportFormTemplate_v3.xsn SET SiteUrl=http://litwaredemo "%STSADM%" -o DeActivateFormTemplate -url %SiteUrl% -filename "%FormPath%" "%STSADM%" -o RemoveFormTemplate -filename "%FormPath%" "%STSADM%" -o execadmsvcjobs echo Desinstalación terminada... |
- Como vemos, en primer lugar desactivamos la plantilla de formulario utilizando DeActivateFormTemplate.
- A continuación eliminamos la plantilla mediante RemoveFormTemplate.
- Finalmente ejecutamos los Timer Jobs de SharePoint.
Y hasta aquí llega el segundo post de la serie sobre automatización en la publicación de formularios Infopath en SharePoint. Espero que el post os haya resultado interesante.
En muchas ocasiones, nos encontramos conque los principales problemas de las aplicaciones viene dado por el uso incorrecto uso que de ellas hacen los usuarios. SharePoint no es una excepción y nos podemos encontrar conque páginas de web parts que funcionan correctamente un día, no lo hacen al día siguiente porque alguna web part está dando problemas y no se han cerrado de forma correcta, hay algún error de JavaScript, etc. El caso es qué este tipo de problemas relacionados con web parts lo podemos solucionar de forma sencilla a través de la página de mantenimiento de web parts. Para abrir está página, no tenemos más que añadir a la url de la página actual lo siguiente: ?contents=1. De esta forma, podremos eliminar las web parts causantes de los problemas que se está produciendo:
Hace poco más de un mes os comentaba que tenemos disponibles las primeras guías de migración hacia WF 4.0. El caso es que Microsoft ha seguido trabajando en este sentido y ya tenemos disponibles nuevas guías de migración hacía WF 4.0 (añadidas a las ya comentadas). Podéis acceder a las guías de migración en este enlace. El listado de guías de migración disponible ahora mismo es:
- WF Migration Best Practices
- WF Migration Cookbook Custom Activities
- WF Migration Cookbook Workflows
- WF Migration Overview
- WF4 Rules Guidance
- WF4 State Machine Guidance
- WF4 Workflow Services Guidance
Ayer tuve la oportunidad de participar en un webcast introductorio sobre plataforma SharePoint organizado por el club .NET de la Universidad Oberta de Catalunya (UOC), del que soy miembro como estudiante de la misma. Personalmente, creo que cumplí con el objetivo de dar una idea clara de lo que permite la plataforma, algo complicado teniendo en cuenta que el webcast duró 2,5 horas…pero bueno, como siempre el truco es hacer demos chulas y olvidarse de la presentación, excepto de la parte relativa a SharePoint 2010 ;-). Bueno, el caso es que ya están disponibles para descarga los materiales del webcast, vídeo incluido:
-
-
El vídeo podéis descargarlo directamente desde
este enlace.
Finalmente, me gustaría agradecer a Jesús Bosch su invitación para realizar este webcast.
Como sabéis, una de las capacidades que vienen de serie con la versión empresarial de MOSS es la de los llamados e-forms, o lo que es lo mismo, publicar formularios Infopath en MOSS de manera que se pueda interactuar con ellos directamente a través del navegador gracias a los Infopath Forms Services de MOSS. Hace un tiempo os comenté como se realiza el proceso de publicación de estos formularios:
En estos posts veíamos como publicar los formularios de una forma manual y en total dependencia con un servidor de SharePoint concreto. Pero, ¿cómo podemos automatizar la publicación de estos formularios independientemente del servidor de SharePoint destino? La idea de este posts y los siguientes es valorar las algunas posibilidades que tenemos a la hora de automatizar la publicación de formularios Infopath. Empecemos.
Diseño del formulario
Como siempre, el primer paso que tenemos que realizar es diseñar el formulario Infopath. Por ejemplo, podéis seguir el paso a paso de este post. Una vez que tenemos diseñado el formulario, tenemos que realizar lo siguiente:
-
Comprobar la compatibilidad del formulario diseñado con Infopath Forms Services. Para ello, no tenemos más que pulsar la opción Change Compatibility Settings en el panel Design Checker de Infopath. En la ventana que se abre (sección Compatibility), especificamos la url del servidor de MOSS contra el que vamos a comprobar que el formulario se puede visualizar de forma correcta en el navegador.
- Definir el nivel de seguridad confianza del formulario a publicar.
- Deshabilitar la opción ‘Enable form merging’.
- Tras pulsar OK, simplemente comprobamos que el formulario no presenta ningún error de compatibilidad.
Publicación del formulario en una carpeta
Una vez que tenemos listo el formulario para su publicación, procedemos a realizar los siguientes pasos:
-
A través del menú File, seleccionamos la opción Publish.
-
Si no hemos guardado la plantilla del formulario, el asistente de publicación nos pedirá que guardemos dicha plantilla como paso previo.
-
Una vez guardada la plantilla, en la siguiente pantalla del asistente seleccionamos la opción To a network location.
-
En la siguiente pantalla, especificamos el nombre y path de la plantilla a publicar en Infopath Form Services.
-
La siguiente pantalla simplemente pulsamos Next (Nota: Dejad vacía la caja de texto).
-
En la siguiente pantalla pulsamos Publish, y en la pantalla final simplemente pulsamos Close.
Publicación del formulario en SharePoint
Una vez que ya tenemos publicado el formulario Infopath en la carpeta, para automatizar su publicación a cualquier servidor de SharePoint no tenemos más que ejecutar los siguientes comandos STSADM (cambiando los path según necesitemos):
|
echo Instalando formulario Infopath...
::Revisar que los path estén correctos
SET STSADM=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe
SET FormPath=C:\Documents and Settings\Administrator\Desktop\Demos Workshop\Infopath Deploy\STSADM\ExpensesReportFormTemplate_v3.xsn
SET SiteUrl=http://litwaredemo
"%STSADM%" -o verifyformtemplate -filename "%FormPath%"
"%STSADM%" -o UploadFormTemplate -filename "%FormPath%"
"%STSADM%" -o execadmsvcjobs
"%STSADM%" -o ActivateFormTemplate -url %SiteUrl% -filename "%FormPath%"
echo Instalacion terminada...
|
Básicamente, lo que estamos haciendo es lo mismo que podemos hacer desde la administración central de SharePoint, pero de una forma automatizada:
-
Verificamos que el formulario Infopath está listo para poder usarlo con Infopath Form Services a través de verifyformtemplate.
-
Subimos el formulario a la galería de formularios accesible desde la administración central de SharePoint.
-
Ejecutamos los timer jobs de SharePoint.
-
Activamos el formulario a una colección de sitios concreta.
Finalmente, si todo ha ido bien no tenemos más que comprobar que:
-
La nueva plantilla aparece en la galería de plantillas de formularios de la administración central.
-
La nueva plantilla aparece en la biblioteca de formularios asociada al sitio donde la hemos activado.
-
Se ha creado un nuevo tipo de contenido asociado a esta plantilla.
Y hasta aquí llega este primer post sobre como automatizar la publicación de formularios Infopath. Espero que os haya resultado interesante.
Parece que, aunque muy poco a poco, seguimos conociendo algunas novedades que traerá SharePoint 2010. en concreto, las dos últimas novedades que han aparecido por la comunidad, siempre evitando violar el NDA que nos ata a todos .-(. En esta ocasión, la novedad la tenemos en el post Creación de flujos de trabajo para SharePoint 2010 utilizando Visio 2010 por Witor Wilén. Por supuesto, el amigo Witor Willen no afirma nada, sino que hace predicciones de por dónde irán los tiros en lo que a creación de flujos de trabajo en SharePoint 2010 se refiere.
Pues eso, y esta vez no creo que sea una broma sobre todo por la fuente en la que podéis leer el titular tan “sensacionalista” que he puesto como título del post. Y es que ya podemos afirmar que los cerdos vuelan ahora que Microsoft acaba de liberar 20.000 líneas de código para Linux…nunca pensé que pondría una imagen como la siguiente en un post ;-)
Hace unos meses escribía un primer post sobre ADO.NET Data Services 1.5 CTP1 en el que os comentaba algunas de las novedades que trae la primera CTP, así como una forma de consumir el servicio desde una aplicación cliente. En este segundo post os voy a detallar algunas novedades que trae a la hora de facilitar la consulta de datos del modelo a través de una serie de nuevos operadores, un mejor tratamiento de los streams BLOBs o feeds más amigables. Empecemos.
Nuevos operadores en ADO.NET Data Services 1.5 ( 2.0, a ver que nombre se le queda)
Trabajo con BLOB Streams
ADO.NET Data Services 1.5 introduce mejoras en lo que al tratamiento de streams BLOB se refiere:
Y hasta aquí llega este segundo post sobre ADO.NET Data Services 1.5. Espero que os haya resultado interesante.
Cómo sabéis, una característica de MOSS es la de los perfiles de usuario que nos permiten almacenar la información de todos los usuarios de una organización de manera manual o automática definiendo un origen de importación que puede ser un DA, un recurso de DA, un directorio LDAP o bien un Business Data Catalog (BDC). Cuando hablamos de los User Profiles de MOSS el primer punto a tener en cuenta es que MOSS tiene definida esta característica dentro de los Shared Services Providers (SSP), y en concreto el SSP referente a User Profiles.
Ahora bien definir un origen de importación de los perfiles de usuario de MOSS es a priori un proceso sencillo, pero ¿Cómo podemos actualizar ciertas propiedades de los perfiles que no estén en el origen de importación? Básicamente, imaginaros ante un caso en el que los perfiles de usuario están en un DA, pero hay ciertas propiedades que se encuentran en una aplicación de RRHH (p.e). Para actualizar las propiedades de los perfiles de usuario con la información contenida en este sistema, tenemos las siguientes opciones:
- Manualmente, opción nada atractiva y recomendable si estamos hablando de un número elevado de perfiles de usuario cargados en MOSS.
-
-
Aprovechando que podemos definir un nuevo pérfil de importación utilizando el BDC. En este caso, os recomiendo leer
este estupendo artículo elaborado por Tood Baginski en el que detalla paso a paso como actualizar los perfiles de usuario a partir de información contenida en una BD SQL Server definiendo un perfil de importación de tipo BDC. Como veréis, la clave está en definir en la fuente auxiliar de información un campo de información que se relacione con uno ya existente en los perfiles de usuario para actualizar las propiedades correspondientes.
Y hasta aquí llega lo que os quería contar sobre como actualizar los perfiles de usuario de MOSS con información procedente de fuentes diversas.
Siguiendo con la serie de posts sobre Velocity que comencé con la parte relativa a la descripción de Velocity y la sencillez de instalación, en esta ocasión voy a dar unas pequeñas pinceladas de lo fácil que es usar la API de Velocity para trabajar con los datos que tengamos en caché. Para estas pruebas he utilizado Visual Studio 2008 SP1 y la CTP de abril de Velocity:
-
Como siempre, el primer paso es crear nuestro proyecto (en mi caso, se trata de una simple aplicación de consola.
-
Una vez creado el proyecto, tenemos que añadir las referencias a los ensamblados de Velocity necesarios para trabajar con el sistema de caché: CacheBaseLibrary.dll y ClientLibrary.dll
-
Una vez añadidas las referencias, tenemos que crear un archivo de configuración XML en el que especificamos los parámetros de la estructura de caché de Veolcity: el host, el puerto utilizado, el TTL, etc.
|
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<!--configSections must be the FIRST element -->
<configSections>
<!-- required to read the <dataCacheClient> element -->
<section name="dataCacheClient"
type="Microsoft.Data.Caching.DataCacheClientSection,
CacheBaseLibrary"
allowLocation="true"
allowDefinition="Everywhere"/>
</configSections>
<!-- routing client-->
<dataCacheClient deployment="routing">
<!-- (optional) specify local cache -->
<localCache
isEnabled="true"
sync="TTLBased"
objectCount="100000"
ttlValue="300" />
<!--(optional) specify cache notifications poll interval
<clientNotification pollInterval="300" />
-->
<!-- cache host(s) -->
<hosts>
<host
name="localhost"
cachePort="22233"
cacheHostName="DistributedCacheService"/>
</hosts>
</dataCacheClient>
</configuration>
|
- Para trabajar con la caché de Velocity el código necesario es el siguiente:
|
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
//Namespace needed for caching
using Microsoft.Data.Caching;
namespace Velocity_Sample
{
class Program
{
static void Main(string[] args)
{
//Cache factory object -> Different algorithms for working with the cache
DataCacheFactory dcfFactory =
new DataCacheFactory();
//Cache object for putting and retrieving data
DataCache dcCache =
dcfFactory.GetDefaultCache();
//Putting data into the cache
dcCache.Put("CHI1", "JcGonzalez");
//Getting data from the cache
Console.WriteLine("Valor en caché {0}",dcCache.Get("CHI1"));
Console.WriteLine();
try
{
dcCache = dcfFactory.GetCache("Inventario");
}
catch (Exception ex)
{
(ex.Message);
}
Console.ReadLine();
}
}
}
|
- Cómo veis, para poder trabajar con la caché de Velocity:
-
Definimos en primer lugar una instancia de DataCacheFactory que es la que nos marca como obtener acceso a los datos de la caché.
-
Definimos una instancia de DataCache que es la que nos permite leer / escribir en la caché. Esta instancia la inicializamos a partir del método GetDefaultCache que nos permite acceder a la caché por defecto de Velocity (default).
-
A partir de aquí, escribir datos en la caché y leerlos es tan sencillo como llamar a los métodos Put() y Get() del objeto DataCache definido.
- Sin más, probamos que efectivamente hemos escrito un dato en la caché.
- Si tratamos de acceder a una caché no creada, tendremos el correspondiente error.
- Finalmente comentaros que podemos monitorizar el contenido de la caché desde la herramienta PowerShell de administración. Podemos ver cual es el contenido de la caché con el comando Get-CacheStatistics.
Y hasta aquí llega este segundo post sobre Velocity. Espero que os haya resultado interesante.
Poco a poco se siguen conociendo algunas novedades, eso sí de manera indirecta, de SharePoint 2010. En este caso, a través del último post publicado por el equipo de Infopath no sólo podemos conocer algunas de las novedades de Infopath 2010, sino también algunas novedades en lo que a la relación de SharePoint 2010 e Infopath 2010 se refiere:
-
Nuevos controles, incluido el Person / Group Picker que pasa a ser un control de “primera clase” en lo que a a controles de Infopath se refiere.
-
Creación de formularios para listas de SharePoint, con Infopath 2010 se podrá extender y mejorar los formularios de creación, edición y visualización de un ítem de lista de SharePoint. A través de la nueva Ribbon que incorpora SharePoint 2010 podremos personalizar el formulario y generar uno similar a los que tienen por defecto las listas de SharePoint pero basados en Infopath 2010 (se entiende que en la versión de formularios en el servidor).
-
Creación de aplicaciones SharePoint, mediante Infopath 2010, SharePoint 2010 y SharePoint Designer 2010 podremos crear aplicaciones empresariales o departamentales sobre SharePoint:
-
Aplicaciones basadas en formularios, utilizando formularios Infopaht que integren componentes como workflows, informes, páginas web personalizas,…
-
Diseño de formularios de inicio y de trabajo con tareas para flujos de trabajo de SharePoint 2010.
-
Diseñar formularios que permitan crear, leer, actualizar o borrar datos de negocio de sistemas Back-End mediante los Businesss Connectivity Services (BCS).
-
Integración con SharePoint Workspace 2010, ya que Infopath 2010 es la tecnología de formularios usada para crear y completar formularios en SharePoint Workspace 2010.
-
Administración y gestión de Infopath Form Services, se ha mejorado notablente con vistas a facilitar la administración de Infopath Forms Services como un componente más de SharePoint 2010.
Y estas son las novedades de Infopath 2010 relacionadas con SharePoint 2010…para el resto de novedades de Infopath 2010 en sí, os remito al post publicado por el equipo de Infopath.
Una de las nuevas características que más me gusta de .NET Framework 4.0 es el Managed Extensibility Framework o MEF que habilita escenarios de re-utilización de aplicaciones y componentes, haciendo posible que aplicaciones .NET compiladas de forma estática puedan ser compuestas de forma dinámica. MEF está pensado para escenarios en los que se está implementando aplicaciones y frameworks extensibles o bien extensiones para aplicaciones. El caso es que ya tenemos disponible en Codeplex la preview 6 de MEF que trae como gran novedad el soporte para Silverlight….sin duda una más que interesante capacidad.
El resumen de las novedades en la preview 6 es el siguiente:
- Silverlight support
- Lazy<T> replaces Export<T>
- Collection import changes
- Inheritance changes
- Export attribute is unsealed
- Stable Composition makes its debut
Fuente: Blog de Brad Abrams.
Aunque a cuentagotas, poco a poco Microsoft va liberando información adicional en torno a SharePoint 2010. En este caso le ha tocado a la documentación preliminar de protocolos y de desarrollo de la plataforma:
Si hace unas horas os anunciaba la disponibilidad de los primeros vídeos y recursos “visibles” en torno a a la Technical Preview de SharePoint 2010, ahora le toca el turno a la suite de Office 2010. En este caso tenemos disponibles una serie de vídeos y capturas de pantalla de cada uno de los productos que componen Microsoft Office 2010. Podéis acceder a estos recursos desde este enlace.
Por fin tenemos algunos detalles más de SharePoint 2010 en la forma de una serie de vídeos en la que podemos ver a cuentagotas algunas de las novedades de la nueva versión de SharePoint. Además, el equipo de SharePoint acaba de hacer oficial que el desarrollo de la nueva versión de SharePoint ha alcanzado la categoría de Technical Preview. Seguramente a algunos os parezca que en los vídeo se cuentan muchas cosas nuevas, sin embargo os puedo decir que sólo suponen un 1 % de lo que se destapará sobre SharePoint 2010 en la SharePoint Conference 2009 en Las Vegas. Es aquí dónde se verá toda la potencia e SharePoint 2010.
En concreto, y volviendo al tema del post, los primeros detalles los tenemos gracias a una serie de vídeos (en concreto 3) que ha grabado el equipo de SharePoint y que tenéis accesibles en este enlace. Los vídeos son:
-
-
La incorporación de la ribbon, completamente personalizable, a la interfaz de usuario de SharePoint (aunque siempre podemos volver a un estilo SharePoint 2007).
-
Mejoras en el trabajo con documentos:
-
Multiselección de documentos.
-
Nueva experiencia de trabajo con documentos a través de ventanas en modo pop-up.
-
No hay postback al servidor cuando trabajamos con los documentos gracias al nuevo mecanismo de sincronización implementando en SharePoint 2010.
-
Drag & Drop de documentos (esto lo veréis en el video para Developers).
-
Mejoras en la edición de páginas, de manera que el proceso de edición se simplifica.
-
- Web Parts Silverlight out-of-the-box por lo que no necesitamos ningún tipo de configuración extra. Estas web parts nos permiten añadir contenido multimedia de forma sencilla a nuestras páginas de SharePoint.
-
Nuevo selector de web parts, más integrado en los sitios de SharePoint.
-
Soporte mejorado de la visualización de sitios SharePoint en FireFox.
-
Nueva forma de cambiar el look & feel de SharePoint mediante temas al estilo del cambio de temas en PowerPoint.
-
- Nueva experiencia de búsquedas con la incorporación de FAST como motor de búsqueda en SharePoint 2010.
-
Integración de SharePoint 2010 con Visio 2010 (impresionante!):
-
Publicación de diagramas Visio a SharePoint.
-
Los clientes no necesitan instalar Visio gracias a los Visio Services.
-
Capacidad de Zoom It y Zoom Out.
-
Por supuesto, si los datos en los que se basa el diagrama Visio cambian, se podrán refrescar.
-
SharePoint Designer:
-
Business Conectivity Services (BCS), o la evolución del catálogo de datos profesionales (BDC):
-
Capacidades de de lectura y escritura en todas las entidades que definamos.
-
Trabajo con las entidades del BCS desde SharePoint Designer (Gustavo, lo siento ;-)) de manera que podremos conectarnos a los sistemas LOB desde Designer, crear de forma efectiva tipos de contenido con datos de negocio, …
-
Completa integración con los clientes Office, de manera que podemos completar documentos Office (en base a una plantilla) de forma automática a partir de datos del BCS.
-
Sincronización de información de SharePoint con nuestros equipos a través de SharePoint 2010 WorkSpace (antes Groove) que pasa a convertirse en el cliente rico de SharePoint y que nos permite incluso trabajar con datos de negocio.
-
Video Tools en Power Point, de manera que podremos ejecutar un vídeo en power point que puede estar almacenado en SharePoint.
Y hasta aquí lo “poco” que se puede contar sobre SharePoint 2010 de momento y hasta la SharePoint Conference de Las Vegas. Espero que lo disfrutéis.
Más artículos
Página siguiente >