SkunkWorks

Programar Manejadores de Eventos para SharePoint 2007 es fácil: un par de renglones de código, el ensamblado en el GAC, algo de registración y listo…

Pero lo fácil es difícil. Esta semana he estado luchando a brazo partido con algo que debería ser sencillo. Los requisitos: un usuario necesita subir archivos desde su Windows Explorer a un sitio determinado de WSS usando la Vista de Explorador de una Lista, y el sistema tiene que cambiar el nombre del archivo agregándole un código único al final; cuando oyes lo que te piden haces cuentas de cuánto tiempo va a costarte: Una hora para tomar café y pensar como lo vas a hacer, media hora preparando e iniciando maquinas virtuales, creando un proyecto de Visual Studio, y pensando como lo vas a hacer, 10 minutos programando los 10 renglones de código necesarios, 10 segundos compilando e instalando, una hora para tomar café y pensar cómo vas decirle al cliente que algo así cuesta ocho horas de trabajo… en total: ocho horas de trabajo.

Pero como lo fácil es difícil, los problemas empiezan inmediatamente al tratar de instalar todo en un sistema de prueba (por supuesto todo ha sido probado en tu sistema de desarrollo y funciona como un sueño).

1 – Todo el código (los 10 renglones) los metes en un try/catch para atrapar los errores que, por supuesto, nunca van a ocurrir. Sorpresa: en el servidor recibes un mensaje que el usuario no tiene derechos para escribir en el EventLog… después de horas de andar buscando porqué, encuentras que Windows R2 tiene pólizas muy estrictas, solamente algunos usuarios pueden escribir en el. Un Manejador de Eventos ejecuta en el contexto del usuario que ejecuta el Grupo de Trabajo de IIS, que, por supuesto, no tiene derechos suficientes.

2 – Ningún problema, piensas: como no me dejan subirle los derechos a esa cuenta, simplemente tiro los mensajes a un archivo de texto. Sorpresa: la cuenta tampoco tiene derechos para escribir en ningún lado.

3 – Un Impersonador para poder escribir en algún lado. Los Impersonadores de SharePoint 2003 no funcionan con SharePoint 2007, y los Impersonadores incluidos con SharePoint 2007 no funcionan con Manejadores de Eventos, fantástico. Otro par de horas creando un Impersonador que funcione con SharePoint 2007 Y con Manejadores de Eventos…

4 – Todo funciona bien ahora… hmmmm… no, nada funciona. O mejor dicho, funciona en el sistema de desarrollo, pero no en el de producción. Te sale un vago error («The file «http://bla-bla/file.xxx» is checked out or locked for editing by SERVIDORgustavo») que, como todos los errores de SharePoint, no dice nada: El usuario es un administrador y tiene todos los derechos para hacer lo que quiera, y el archivo lo ha subido el mismo, así que no puede estar bloqueado por sí mismo (Gustavo no puede bloquear archivos de Gustavo). Esto lo puedo solucionar fácilmente, piensas (por eso de que nunca aprendes que lo fácil en SharePoint es difícil): antes de hacer los cambios, simplemente haces un CheckIn. None… te sale otro error «El archivo ha sido modificado por Gustavo», y no sucede nada.

5 – Muchas gracias, eso ya lo sabía, yo estoy modificando mis propios archivos, pero cuénteme porque no lo cambia en lugar de estar hablando idioteces… Dos días he dado el asunto por perdido, hasta que hoy, por eso de lo de cabezadura, le he medido otras cuatro horas pensando que podía pasar: hmmmm de nuevo…, el primer error me dice que está bloqueado… SharePoint tiene dos bloqueos de archivos, uno de larga duración (cuando el usuario hace un CheckOut del documento) y otro de corta duración (en el momento que aprietas «Guardar», SharePoint bloquea el archivo por unos cuantos segundos para evitar que dos usuarios guarden cosas al mismo tiempo). El primero no es, pues el documento apenas se está subiendo, y ya intente hacer un CheckIn sin resultado, así que tiene que ser el segundo. Qué pasa si le pones un delay? BINGO, funciona. Con un retraso de 5 segundos no pasa nada, con 8 tampoco, con 10 segundos funciona!

Después de todo, algo que debería haber costado máximo una hora de trabajo ha costado más o menos dos días, por eso de que lo fácil es difícil…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Un pequeño comentario para hacerle notar a toda(o)s los fans de SharePoint (?) la existencia del portal para desarrolladores de Microsoft Office Live: http://msdn2.microsoft.com/en-us/office/aa905514.aspx

Como todo el mundo sabe (y si no lo saben, aquí se los cuento), Office Live es construido sobre la base de Windows SharePoint Services 3.0. Por lo tanto, usuarios de Office Live pueden utilizar todos los trucos que WSS acepta, como la creación de plantillas y soluciones personalizadas de InfoPath, asi como el uso de sus WebServices para interactuar programáticamente con el sistema.

En el sitio pueden encontrar el nuevo SDK para Live Office así como crear una cuenta de prueba por 30 días para ensayar cómo funciona el sistema.

El unico «problema» con todo el asunto es que la gran mayoría del trabajo de desarrollo que se puede hacer hay que realizarlo con el SharePoint Designer, pero esa es otra historia…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Una compañía canadiense, D-Wave Systems (http://www.dwavesys.com/) ha anunciado el primer computador quántico comercial (http://www.dwavesys.com/index.php?mact=News,cntnt01,detail,0&cntnt01articleid=4&cntnt01origid=15&cntnt01returnid=21).

Para los que no se acuerdan qué es esto, aunque las partes más finas se me escapan porque mi ignorancia es tan grande como mi falta de conocimientos, les puedo recordar que un computador quántico funciona con «qubits» en lugar de «bits». Como todos sabemos, un bit tiene dos estados definidos; un qubit puede estar en cualquier cantidad de estados superpuestos al mismo tiempo (no me pregunten cómo es eso posible, solamente les cuento lo poco que me acuerdo de mis clases cuando era un adolecente). Esto significa que con un par de qubits (300, si no me acuerdo mal) se puede crear una memoria más grandes que todos los átomos existentes en nuestro universo.

Pues bien, una de las ventajas de un computador quántico es que hace (o podría hacer, mejor dicho) cálculos más rápidamente de lo que cualquiera de nuestros computadores actuales puede hacer, con mucho menos consumo de energía. Si es cierto lo que asegura esta compañía, dentro de poco nuestros computadores de silicio estarían listos para el basurero. Una desventaja computadores quántico es que probablemente solamente se podrían usar para resolver problemas de manipulación de datos en grandes volúmenes, así que no serian apropiados para crear interfaces de usuarios.

Viendo el sitio de D-Wave Systems me ha dado por pensar como sería una instalación de SharePoint en un computador quántico. Teniendo en cuenta que para el mayor sistema de SharePoint existente en el momento (la intranet de Microsoft, 12 Terabytes y 350.000 sitios) se usa una granja de casi 30 servidores en total, que necesitaríamos si usáramos un computador quántico? Un solo servidor, que consume la electricidad de una lámpara de escritorio? No estaría mal del todo…

Mi sueño siempre ha sido tener un servidor personal basado en un modesto Cray XD1 (http://www.cray.com/products/xd1/index.html), que produce un moderado 106 GFlops, pero estoy dispuesto a cambiar mis sueños, si es que se puede ordenar uno de estos computadores. Por supuesto que sueños, sueños son, pues de todas formas no lo podría pagar, pero que me divertiría un montón programando un bicho de este tipo, de eso no hay duda…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Pequeño pero intrigante artículo que me encontré esta mañana en Internet: «SharePoint: The next big ‘operating system’ from Microsoft?» …

Todo comenzó con una pregunta que alguien le hizo a Steve Ballmer, el CEO de Microsoft: «Con toda la propaganda que está recibiendo SharePoint los últimos tiempos, es correcto pensar en él como si fuera casi un Sistema Operativo?»

Y la respuesta de Ballmer: «SharePoint es la plataforma o Sistema Operativo definitivo para la capa intermedia (middle tier)» (traducción libre al español)…

SharePoint como plataforma de desarrollo ya la conocemos desde la versión 2001 (aunque nadie estuvo tan loco como para desarrollar algo para esa versión). Entre otras cosas, es con lo que nos ganamos el pancito de cada día muchos de nosotros: haciendo que cosas raras funcionen dentro de SharePoint. Si pensamos en Windows como una plataforma de desarrollo, que sirve como base para todo el software que creemos, entonces SharePoint es por definición un Sistema Operativo, y Ballmer tiene razón.

Pero si pensamos que SharePoint utiliza mucha de la infraestructura que Windows provee (piensen nada mas en todo el DotNet FrameWork), entonces no es un OS…

O, visto desde otra perspectiva, de pronto SharePoint es un Sistema Operativo que necesita otro Sistema Operativo para funcionar… Algo así como las muñecas de madera rusas, que caben una dentro de la otra, dentro de la otra, dentro de la otra.

En cualquier caso, es una idea intrigante pensar en SharePoint como un Sistema Operativo, y, con toda seguridad puede ayudar para entender algunos de sus conceptos: siempre me ha costado trabajo explicarle a personas que no saben nada de software, como es posible integrar aplicaciones en SharePoint. Utilizando el paradigma del Sistema Operativo, será mucho más fácil decirles: de tal forma que un programador crea un programa «Hola Mundo» en Windows, puede crear un «Adiós Mundo» dentro de SharePoint…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

La primera lección de Teoría de la Información, mi primer día en la Universidad a la primera hora de la mañana, uno de los profesores que alcanzaría un puesto distinguido en mi seleccionado grupo de profesores preferidos comenzó su clase diciendo: «Demasiada información es desinformación…»

En estas últimas semanas, trabajando en un implementación de MOSS con bastantes WebParts, Manejadores de Eventos y cosas de esas, me he acordado constantemente de él viendo el horrible trabajo que Microsoft ha hecho en la creación del nuevo SDK (Software Development Kit), tanto de WSS como de MOSS.

Se supone que un SDK es la biblia de un desarrollador: allí se encuentra no solamente información sobre QUE son las cosas, sino también COMO se usan, es decir una guía para convertirse en un buen ciudadano del mundo del software. Un buen SDK incluye toda la información que sea necesaria sobre los NameSpaces, Clases, Métodos, Propiedades, Eventos que componen el Modelo de Objetos, ejemplos de cómo utilizarlos, «buenas prácticas» para meter las de andar lo menos posible, en fin, después de un par de meses de estar trabajando con un SDK en la mano, acabas aprendiéndotelo de memoria, y lo puedes recitar de atrás para delante en los pocos momentos de descanso que te queden, si es que te queda alguno.

El SDK de SharePoint 2003 (WSS y SPS) no era conocido por la buena información que proporcionaba, pero se podía confiar en él, y en más de una ocasión saco a más de uno de problemas. El SDK de SharePoint 2007 se divide en dos partes:

– Información sobre cosas que son iguales a SharePoint 2003
– Información sobre cosas que son nuevas

En el primer caso, la información es exactamente igual a la del SDK 2003
En el segundo caso, no hay información (y si por casualidad hay algo, está llena de errores, http://geeks.ms/blogs/gvelez/archive/2007/01/29/cuantos-errores-se-pueden-cometer-en-15-l-neas-de-c-digo.aspx)

Un ejemplo entre miles y miles que se pueden citar: si quieres copiar el valor de un campo de la Base de Datos de Perfiles de un usuario a otro usuario, lo más indicado seria poder usar el método «CopyTo» de la clase «PropertyCollection» en el NameSpace «Microsoft.SharePoint.Portal.UserProfiles», o me equivoco? Pues bien, el SDK nos dice muy claramente (http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.portal.userprofiles.propertycollection.copyto.aspx) que el uso es:

public void CopyTo (
Array array,
int index
)

Y la explicación sobre los parámetros es:

Parameters
array
index

Simplemente brillante… muchas gracias por la información… si no entiende la explicación tan detallada, es porque su capacidad mental alcanza escasamente el nivel del de una cucaracha, o su formación profesional deja bastante que desear. Pero, además, dentro de la plétora a información que se nos ofrece, nos dicen muy claramente al principio que:

PropertyCollection.CopyTo Method — Obsolete.

De nuevo, muchas gracias por la información… pero si no es mucha molestia, le podrían contar a esta cucaracha cual método se debe utilizar? De cual Clase? O es mucho pedir?

Volviendo a mi profesor, ahora que ya tengo la edad para mirarlo cara a cara y no de abajo hacia arriba, si me lo volviera a encontrar le diría: «sí señor, tiene mucha razón, pero ninguna información es un desastre!»

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Uno de los grandes dramas de SharePoint 2003 era instalar código personalizado en otros servidores fuera de las maquinas de desarrollo. Las opciones estaban limitadas a dos: copiar todos los archivos a mano desde un servidor a otro, con todos los peligros que eso conlleva, o hacer un instalador especial (un programa que copie todo en el lugar correcto).

La primera opción en realidad no era una opción. Cuantas veces me ha pasado (y no solamente a mi) que le enviabas toda la retahíla da archivos al cliente, con instrucciones detalladas sobre que archivos en que directorios había que copiar, para luego recibir un teléfono de un cliente enojado porque el asunto no funcionaba (o es que solamente yo tengo clientes disléxicos, eso también puede ser). Luego de perder un montón de tiempo en ir personalmente a ver qué estaba sucediendo, revisar la instalación localmente en los servidores de producción y comprobar que, por supuesto, las cosas no habían sido copiadas correctamente, se venía el trabajo de explicarle muy cuidadosamente al susodicho cliente que simplemente tenía que regresar a la escuela elemental a que le enseñaran a leer de nuevo…

La segunda opción, aunque más segura, también costaba tiempo y esfuerzo… y ponerse a programar aplicaciones de Windows, algo que no se te ocurría hacer desde el tiempo de los dinosaurios…

Los chicos inteligentes de Microsoft se pusieron las pilas y crearon las «Solutions», una verdadera solución para el problema. Para que después vengan a decir que Microsoft no escucha los clamores de sus pobres usuarios. Si escuchan, sí que lo hacen, créanme, lo único es que son sordos selectivos, que solamente escuchan lo que les interesa, pero que escuchan, escuchan…

Una «Solución» de SharePoint no es más que un archivo comprimido (.wsp) con todos los archivos que quieres instalar metidos en él, y otro archivo «Manifest.xml» que le cuenta a SharePoint a donde tiene que ir a parar cada uno de ellos. Además de que todo va en un solo archivo, el administrador de SharePoint solamente tiene que ejecutar un comando en la herramienta de administración stsadm para instalarlo, y desde la pantalla de Administración Central de SharePoint puede activar la Solución, desactivarla, instalar otra igual con una versión diferente y controlar su uso, todo sin que tenga que copiar archivos independientes.

La Solución principalmente puede copiar archivos a sus sitios correctos (Características, WebParts, Recursos, Site Definitions, etc) e instalar dll’s en el GAC o en un directorio Bin; es posible hacer otras cosas con ellas, como definir las pólizas de seguridad y el registro de controles seguros, pero esto es otra historia.

Volviendo al título, un archivo wsp no es más que un archivo cab con otra extensión. Si no me creen, búsquense algún archivo wsp en el directorio de SharePoint, cámbienle le extensión a cab, y verán que bonito esta por dentro (o sino, léanse el SDK, también está allí explicado). Archivos cab son muy simpáticos, pero no son divertidos para hacer. Desde el sitio de Microsoft se puede descargar el «Cab SDK», con información sobre como compilar archivos CAB, y un par de herramientas de comando para hacerlos. Pero si tienes que crear una Solución con bastantes archivos, que tienen que ir a parar a diferentes directorios de SharePoint, el comando se convierte en algo así como:

CABARC.EXE -p -P ProjectsTestSolution n C:Solution_Test.wsp C:ProjectsTestSolutionISAPI*.* C:ProjectsTestSolutionManifest.xml C:ProjectsTestSolutionTestWebPart1.dll

(Y esto para solo tres archivos a comprimir). Así que, siguiendo el leitmotiv de «Un buen herrero hace sus propias herramientas», me he hecho un programa estupendo («SharePoint Solution Builder», por eso de que en ingles suena más complicado) que me evita todo el trabajo de pensar (para evitar que se me gasten las pocas células grises que me quedan), y en donde solamente tengo que escoger los archivos, indicar a que directorio tienen que ir, contarle el sitio en donde quiero la solución y él realiza todo el trabajo para mí. El programa lo pueden bajar desde el sitio de descargas de SkunkWorks, http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=5&itm=431.

A propósito, cuando estaba haciendo el programa y rompiéndome la cabeza tratando de usar el «cabinet.dll» que viene con todos los Windows y se encarga de hacer el trabajo, al intentar desensamblarlo sin fortuna, me he dado cuenta que es (probablemente) una aplicación de 16 bits, del año de upa. Aunque, siendo honrados, funciona como un tren, y comprime mucho mejor que zip o rar, así que si no se ha roto, no hay razón para repararlo.

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Hace ya más de un año que escribí algo sobre el SharePoint Designer (http://blogs.clearscreen.com/skunkworks/archive/2006/01/21/2693.aspx), pero no me aguanto las ganas de volver a escribir algo sobre el tema.

Para los que no andan muy metidos en el mundo de SharePoint, les cuento que hace años existió un producto de Microsoft que consiguió todos los premios que se le pueden conceder al software malo: un Oscar a la peor producción, un Emmy al peor rendimiento y un premio Nobel al peor producto que ninguna compañía en todo el mundo alguna vez ha programado. Ese producto tenía el infame nombre de FrontPage, y para quitarse el estigma de encima, y no molestar a los 3 inútiles que lo utilizaban regularmente, Microsoft le cambio el nombre a «SharePoint Designer», y nos lo está metiendo por las narices como LA herramienta para trabajar con SharePoint.

Con la versión pasada de SharePoint y FrontPage Microsoft ya había empezado a caminar por el mal camino con este producto. Si tenias deseos de arruinar una instalación de SharePoint de uno de esos clientes molestos que no hacen más que quejarse sin pagar un centavo, les aconsejabas que utilizaran FrontPage para hacer los cambios que querían. Luego, a los seis meses o algo así, cuando te volvían a llamar para quejarse (por supuesto) de que el sistema no funcionaba, simplemente les decías que qué querían, si se habían cargado todo el asunto con FrontPage… perfecto…

Ahora, con la nueva versión de Frontp… perdón del SharePoint Designer, el camino sigue tortuoso y mal pavimentado. Ya no solamente se pueden arruinar Sitios («Ghost» y «UnGhost», se acuerdan?), sino que también se pueden masacrar Paginas Maestras.

Esta semana tenía que hacer un par de Paginas Maestras para un nuevo proyecto de MOSS, y, por eso de darle una segundo oportunidad a todo el mundo, me dio por ver cómo funcionaba el asunto con el Designer. Hasta ahora, era poco lo que había hecho con Paginas Maestras para SharePoint 2007, solamente un par de cambios por aquí y por allá a la pagina por defecto; pero ahora se trataba de crear un Layout desde cero y completamente diferente al diseño por defecto de MOSS. Lleno de buenos deseos comencé a usar el Designer, y la primera impresión fue: arrancar el programa una vez por día, pues cuando lo inicias, te puedes ir a tomar café, porque se demora media hora en cargar. Y se come la mitad de la memoria del servidor, así que si lo utilizas, olvídate de usarlo junto con Visual Studio o algo por el estilo…

Pero bueno, la idea era dejar los prejuicios a un lado, y darle la oportunidad al producto de mostrar lo que podía. Después de tomar el café correspondiente, la impresión siguiente fue: hmmmm… yo no soy un gran amigo de programas wysiwyg, pero este no parece tan malo… puedes seleccionar algo en la pantalla grafica, y te lo señala en el código… puedes cambiar cosas en un lado y en el otro y todo se sincroniza bien… no está mal…

La sorpresa vino cuando aplique los cambios en un Sitio de SharePoint: no se parecía ni remotamente con lo que mostraba el Designer. Cuando quieres usar Paginas Maestras en SharePoint, primero tienes que subir la pagina a una Librería especial en el sistema, y desde este momento MOSS comienza a utilizar la copia de la Base de Datos, no la copia física (el Designer modifica la copia virtual). Así que mi siguiente paso fue crear una copia física de regreso para buscar que era lo que no funcionaba. La segunda sorpresa fue aun mejor: una Pagina Maestra original de 17 Kb se había convertido en 82 Kb después de ser modificada por el Designer. Y cuando la abrí con un editor ASCII, la sorpresa fue aun mejor: el código estaba absolutamente lleno de código extraño que probablemente el Designer necesita para hacer todos los trucos del wysiwig…

La reacción después de media hora fue inmediata, y no muy difícil de imaginar. A la basura con este desastre. Alguien que intente crear código de una manera un poquito decente no utiliza basura de este tipo. Punto. Ya no solamente puedes arruinar la presentación de SharePoint técnicamente, sino también físicamente.

Las Paginas Maestras del susodicho proyecto fueron hechas finalmente en dos días, con un editor común y corriente (EditPlus, mi favorito), y a mano limpia, como los puros machos. Lo único aburrido de hacerlo de esta forma es que cada vez que modificas algo en la Pagina Maestra tienes que hacer cuatro cosas para poder ver los cambios en pantalla: pasar el Sitio a la Pagina Maestra por defecto, eliminar tu pagina de la galería, volverla a subir a la galería, y volverla a acoplar al Sitio. Como buen desarrollador, me hice en diez minutos un programita que hace todo el trabajo usando solamente un botón: el «Master Page Refresher». Para los que quieran trabajar con Paginas Maestras como se debe, pueden bajar el programa del sitio de SkunkWorks directamente (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=5&itm=426).

Al final, solo me queda repetir las últimas palabras del pasado artículo sobre el tema, por eso de que todavía siguen siendo verdaderas: «Es como dice un amigo mío: ‘si eres mal programador, te cambian el titulo a ‘Director de Proyecto’ y te suben el sueldo, así que tenemos que hacer más errores cuando estamos programando…’. A FrontPage le cambiaron el titulo, no tengo ni idea si le aumentaron el sueldo.»

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Pregunta recurrente cuando una empresa empieza a pensar en utilizar SharePoint: «… y el sistema será capaz con la carga de todos mis empleados?». La respuesta es siempre la misma: «si, por supuesto, es posible». No importa si la preguntan es 10, 10.000 o un millón de usuarios.

Por pura casualidad, esta mañana me he encontrado un artículo de Microsoft sobre el diseño de www.microsoft.com, el sitio corporativo de la empresa. Desde hace un tiempo se podía ver que lo estaban remodelando, pero lo que no es muy conocido es que desde hace algunos meses todo el sistema funciona basado en SharePoint 2007 (vea el articulo para mas detalles: «About the new Microsoft.com home page«).

El sitio de Microsoft es «solamente» el quinto sitio más visitado de Internet, y contiene «cientos de miles» de páginas (probablemente Microsoft mismo no sabe cuántas con seguridad) y «millones de usuarios»; si esto es posible de hacer con SharePoint, con absoluta certeza la próxima vez que nos pregunten si es posible hacer que 100 usuarios utilicen el sistema empresarial al mismo tiempo, la respuesta será «SI«.

Además, la Intranet de Microsoft ha sido migrada hace un par de meses a SharePoint 2007 (desde 2003). En el momento es también la mayor Intranet instalada en el mundo bajo tecnología SharePoint, con 350.000 sitios y 12 Terabytes en información, con algo así como 100.000 usuarios cotidianos repartidos por todo el mundo.

Razones suficientes para contestar con toda tranquilidad: «… si, es más que posible…»

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Depende… aunque probablemente sí lo es en muchos casos…

Microsoft ha dado a conocer (finalmente) la lista de precios de SharePoint 2007; aunque, como lo dicen en el sitio mismo (http://office.microsoft.com/en-us/sharepointserver/FX102176831033.aspx) es un precio estimado, y dentro de los Estados Unidos:

– SharePoint 2007 (supongo que es la versión de búsqueda)   $4.424
– SharePoint 2007 Standard   $8.213   (CAL [Client Access Licence]   $94)
– SharePoint 2007 Enterprise $57.670  (CAL $54)
– SharePoint 2007 para sitios de Internet (solamente para uso en Internet, no se puede usar por empleados en la Intranet, funcionalidad equivalente a la versión Enterprise, precio por servidor)   $40.943

(No he podido entender bien lo que dicen sobre las CAL, pero si no me equivoco, es necesario tener las CAL de Standard Y Enterprise para poder usar la versión Enterprise)

Lo que me llama la atención es la gran diferencia entre el Standard y el Enterprise (7 veces). De hecho, la diferencia entre los dos es el Business Data Catalog y el Servicio de Excel, dos cosas nuevas y bastante útiles, pero no tanto como para justificar un incremento de 700% en el precio. Además, no es posible hacer una instalación mixta, en donde parte de los usuarios usan la Standard y otros cuantos la Enterprise, así que hay que ir por la una o por la otra.

Por otro lado, el precio de la versión Standard es razonable, e incluso, mas barato que el de SPS 2003. Teniendo en cuenta el precio de Windows 2003 (R2), SQL 2005 y hardware, una instalación completa de MOSS para unos 10.000 usuarios saldría por el millón de dólares, o 3 dólares por usuario por mes (depreciando a 3 años), lo que no es exagerado, aunque si un montón de dinero.

Lo que no acabo de entender es que haya que pagar 187 dólares por el SharePoint Designer. Aunque es algo mejor que su predecesor, el infame FrontPage, si estás dispuesto a pagar un millón de dólares por una instalación de SharePoint, lo menos que Microsoft podría hacer es regalártelo, pienso yo…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

Los últimos dos días de la Primera Conferencia Europea sobre SharePoint estuvieron dedicados a Groove. Este es el producto posicionado por Microsoft como el visor Off-line de SharePoint. Groove fue una empresa independiente que hace año y medio fue adquirida por Microsoft para fortalecer la posición de SharePoint.

Toda la información estructurada y no estructurada de una empresa se encuentra disponible en un sitio central, SharePoint, pero hay una desventaja: para tener acceso a ella es necesario tener una conexión abierta con los servidores (internet, intranet, VPN). Si se desea utilizar la información de una forma desconectada, es necesario crear copias locales de los documentos, perdiendo las ventajas de mantener versiones, proteger y desproteger, etc., y sin posibilidades de manipular los elementos de Listas (fuera de exportarlos e importarlos de nuevo por medio de Excel o Access). Groove ofrece la posibilidad de crear un deposito local con la información necesaria, permitiendo manipular la información y haciendo una sincronización automática la próxima vez que se detecte una conexión viva con los servidores de SharePoint.

Desafortunadamente el producto tiene bastantes cosas que no funcionan de una forma simple:

– Cliente: Groove se puede usar como cliente solamente (por medio de los servidores de relay de Microsoft). En este caso, solamente se pueden intercambiar documentos y listas entre los diferentes clientes (un sistema «Peer-To-Peer»), y no se tiene acceso al depósito empresarial de SharePoint. Groove Client es parte del paquete Office 2007 (solamente en la versión empresarial, la más costosa). La Interface es completamente extraña a la forma de trabajo de SharePoint, por lo que los usuarios acostumbrados a SharePoint no tienen ningún punto de referencia conocido

– Servidor: Si se desea instalar el servidor para que interactúe con el SharePoint local se necesitan tres servidores separados (no es posible instalarlo todo en un solo computador), y tienen que ser servidores de 64 bytes. La instalación es de todo menos fácil, y la configuración es aun menos sencilla.

– Programación: prácticamente inexistente. El servidor provee algún WebService que entrega algo de información al mundo exterior, y ahí se detiene el asunto. Visual Studio para Aplicaciones se puede utilizar para automatizar un poco el Cliente (macros), pero no tiene un Modelo de Objetos utilizable para interactuar con la Interface o con los servidores

– Búsqueda: Inexistente

En general, mi impresión sobre todo el asunto es que Microsoft tienen bastante terreno que recorrer antes de que Groove sea realmente utilizable. La idea es muy buena, pero la integración con SharePoint es muy básica, y la Interface es miserable. Hay que concederle a Microsoft que no tuvieron tiempo de crear una integración decente con SharePoint 2007 por pura cuestión de tiempo. Probablemente con la próxima versión de SharePoint tendremos algo con lo que realmente se pueda trabajar desconectadamente, pero por el momento, Groove no es realmente groovy…

Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…