Consideraciones para iniciar el desarrollo sobre SharePoint 2010

A estas alturas muchos desarrolladores seguramente ya estarán pensando en migrar o actualizar su ambiente de desarrollo para trabajar con SharePoint 2010 y en ese sentido hay algunas consideraciones que merece la pena evaluar.

  1. Clases y métodos caducados. Seguramente tendrás por ahí algunos manejadores de eventos, flujos de trabajo, WebParts y ensamblados, entre otros que has desarrollado con el tiempo y que buscarías llevarte a SharePoint 2010, la mayoría de las soluciones SharePoint 2007 seguirán soportándose en SharePoint 2010 sin trabajo adicional y podrán ser migradas fácilmente, sin embargo, algunas otras tendrán que re fabricarse para su compatibilidad con SharePoint 2010, sucede que con el tiempo algunos tipos del modelo de objetos de SharePoint quedan obsoletos, esto lo vimos de 2003 a 2007 y sin duda ahora en 2010 habrá algunos más. Aquí dejo la lista de clases y métodos que han caducado. Microsoft SharePoint Server 2010: Deprecated Types and Methods.
  2. Equipo y ambiente de desarrollo. SharePoint 2010 corre bajo plataforma 64 bit y no se soporta 32bit. Se tiene que evolucionar y pues con algunos otros productos como Exchange la historia ha sido igual. Desde el punto de vista desarrollador el Service Pack 2 de MOSS cuenta con una herramienta llamada Upgrade Checker que nos permite validar y revisar nuestro ambiente actual para identificar cualquier aspecto de configuración que pudiera afectarnos en una futura actualización a SharePoint 2010. Así mismo actualizar nuestro Visual Studio 2008 a 2010 será relevante ya que VS2010 cuenta con plantillas de proyecto y soporte directo para trabajar con SharePoint 2010. Otra consideración es que SharePoint 2010 funcionara con navegadores Internet Explorer 7 o mayor. Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008
  3. Mecanismo de despliegue. EL uso de archivos WSP es un deber en SharePoint. Los archivos WSO son paquetes que auto contienen características de funcionalidad que se pueden aprovisionar en SharePoint de una manera dinámica y flexible. Si de pura casualidad y coincidencia la forma de instalar en tus granjas funcionalidad personalizada es manual mediante la modificación de archivos dentro de la carpeta 12 hive, entonces, amigo mío sería bueno primeramente asegurarte de empaquetar en archivos WSP la funcionalidad. Los archivos WSP son aprovisionados en SharePoint el cual a la vez re aprovisiona en todos los servidores que constituyen nuestra granja. Herramientas como WSPBuilder y/o las extensiones de SharePoint para Visual Studio 2008 versión 1.2 y 1.3 han sido diseñadas especialmente para generar archivos WSP y facilitar la creación de características de sitios. Asegúrate de contabilizar tus componentes funcionales y empaquetar debidamente. El uso de herramientas de terceros como http://www.avepoint.com/ puede auxiliar.
  4. Capacítate. De que nos sirve tener SharePoint 2010 si aún no sabemos que tenemos y podemos hacer con él. EL uso de Silverlight y LINQ son estratégicos para sacar mayor ventaja de la plataforma SharePoint. Así mismo SharePoint Designer 2010 es una fenomenal herramienta para producir aplicaciones SharePoint fácilmente. Mi recomendación aquí es tratar de conocer todas las nuevas características de funcionalidad que los programadores tenemos disponibles, no olvides que SharePoint es una aplicación con gran funcionalidad disponible sino también es una plataforma de aplicación para el desarrollo de soluciones.Aqui dejo Recursos de Entrenamiento en SharePoint 2010 y unas presentaciones avanzadas sobre desarrollo SharePoint. SharePoint Server 2010: Advanced Developer Training Presentations

SharePoint 2010 representa una gran inversión y esfuerzo de ingeniería y comunidad en donde desde el año 2001 se ha venido consolidando una plataforma aplicativa para la empresa web de hoy. La gran variedad de propuestas de funcionalidad pre fabricada es enorme y combinado con las posibilidades de personalización y desarrollo nuestro alcance es sin precedentes. Sugiero planees y tomes el debido tiempo de forma racional para ir asimilando como, cuando y donde genera más valor basar nuestras soluciones de negocio sobre plataforma SharePoint 2010.

Originalmente publicado en msmvps.com

Configurando controles ASPXGridView de DevExpress en SharePoint

Sabemos que SharePoint está construido sobre ASP.NET 2.0 y esto nos da una gran cantidad de ventajas disponibles para utilizar componentes de terceros ricos en funcionalidad. Tal es el caso de los componentes de DevExpress empresa de Mark Miller un pionero en la construcción de herramientas de productividad para el desarrollador Delphi y .NET.

En el último proyecto donde participe como programador tuve la oportunidad de implementar la Suite de controles ASPXGridView de DevExpress para soportar un escenario el despliegue de datos de manera jerárquica y la flexibilidad de agrupación dinámica sobre SharePoint.

Utilice el ASPXTreeList y el ASPXGridView, a continuación los pasos para configurar y usar estos objetos. La misma suite tiene archivos WSP para implementar sobre SharePoint los controles, estos WSP automáticamente configuran todo lo necesario para poder usarlos. Sin embargo, aquí dejo los pasos manuales.

Registrar en el Global Assembly Cache los componentes de DevExpress.

  • DevExpress.Data.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Data.v9.3.Linq, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Utils.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Web.ASPxEditors.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Web.ASPxGridView.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Web.ASPxHtmlEditor.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Web.ASPxSpellChecker.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Web.ASPxThemes.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Web.ASPxTreeList.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a
  • DevExpress.Web.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a

Manipular archivos web.config de nuestra aplicación web donde estaremos usando estos componentes y dentro de <SafeControls> agregar lo siguiente:

  • <SafeControl Assembly="DevExpress.Data.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" Namespace="DevExpress.Data" TypeName="*" Safe="True" />
  • <SafeControl Assembly="DevExpress.Web.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" Namespace="DevExpress.Web" TypeName="*" Safe="True" />
  • <SafeControl Assembly="DevExpress.Web.ASPxEditors.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" Namespace="DevExpress.Web.ASPxEditors" TypeName="*" Safe="True" />
  • <SafeControl Assembly="DevExpress.Web.ASPxSpellChecker.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" Namespace="DevExpress.Web.ASPxSpellChecker" TypeName="*" Safe="True" />
  • <SafeControl Assembly="DevExpress.Web.ASPxHtmlEditor.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" Namespace="DevExpress.Web.ASPxHtmlEditor" TypeName="*" Safe="True" />

Dentro de <httpHandlers> agregar:

  • <add type="DevExpress.Web.ASPxClasses.ASPxHttpHandlerModule, DevExpress.Web.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" verb="GET" path="DX.ashx" validate="false" />

Dentro de <httpModules> agregar:

  • <add type="DevExpress.Web.ASPxClasses.ASPxHttpHandlerModule, DevExpress.Web.v9.3, Version=9.3.3.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" name="ASPxHttpHandlerModule" />

Originalmente publicado en msmvps.com

VSeWSS Import Tool para migrar proyectos VSeWSS 1.3 a Visual Studio 2010

En esta semana me preguntaron cómo sería la migración de un desarrollo SharePoint 2007 a SharePoint 2010. Y bueno, comente sobre algunas de las opciones disponibles en Visual Studio 2010. Aquí dejo una herramienta más que nos podrá asistir en estos requerimientos.

Se llama VSeWSS Import Tool para migrar proyectos VSeWSS 1.3 a Visual Studio 2010.

http://code.msdn.microsoft.com/VSeWSSImport

Originalmente publicado en msmvps.com

Consideraciones para acercamos al tomador de decisiones de un proyecto SharePoint

Hoy quiero platicar de algo un tanto distinto de lo que acostumbro publicar en mi blog. Para aquellas personas que son consultores SharePoint o ingenieros de Pre Venta de soluciones de colaboración en algún momento del ciclo de vida de venta se requiere de nuestra intervención para identificar las necesidades de negocio y dimensionamiento técnico necesario para poder plasmar en una propuesta comercial nuestro alcance técnico y enfoque humano que será necesario constituir para auxiliar a nuestro cliente.

Sin duda, existen muchas formas de hacer el acercamiento sin embargo aquí dejo algunas de las preguntas que acostumbro hacer cuando estoy en reunión con el cliente final, esto no es una guía simplemente es lo que he probado con el tiempo.

  1. Cuál es el problema actual que desea resolver. La intención de esta pregunta es identificar que es lo que el cliente considera problema a resolver. La idea es ponernos en los zapatos del cliente y entender en primera instancia el problema en general y aquellas razones subyacentes que lo justifican. En ocasiones es importante preguntar él porque considera que con SharePoint podría obtener la solución.
  2. Cuál es la situación deseada. Es importante identificar de manera preliminar la visión final que tiene el cliente de lo que considera puede ser la solución que podríamos plantear. Es muy importante separar el tema técnico del tema de negocio. Lo que hay que indagar aquí es desde el punto de vista de negocio cuales son los entregables, métricas y por qué no las fechas en las que el cliente desea verse avante respecto a la solución requerida. No hay que perder de vista lo que el cliente cree que necesita y que considera una situación ideal, al final del día, buscamos satisfacer y exceder las necesidades de nuestro cliente y quien mejor que nos pueda dar una visión de lo que se considera satisfactorio.
  3. Cuál es la prioridad para la organización o departamento de implementar la solución. Es crítico desde el punto de vista comercial identificar que esta oportunidad tiene una alta probabilidad de concretarse. Así mismo desde el punto de vista dimensionamiento hay que tener en cuenta las implicaciones positivas y negativas de alinearnos a las fechas idóneas para el cliente y como estas tienen nos impactan.
  4. Nombre de las áreas involucradas en la solución. En el afán de poder visualizar a quien estaría tocando nuestra solución es importante desde una primera etapa identificar que otras áreas de la organización infieren en el proceso que se busca automatizar. En cierta medida el valor que una solución aporta al negocio deja un precedente importante de evaluar. También nunca hay que dejar de ver si la solución que estamos entendiendo es de misión crítica para el negocio y/o de alto impacto. Por misión critica nos referimos a lo estratégico y operativo de la solución, lo crucial que esta es para el proceso y para el negocio. Por alto impacto, lo entendemos como el grado en que la gente estará expuesta a la solución y que tanto esta influirá en la cultura de la organización de forma positiva “cuando esta sea innovadora y funcional” y negativa “cuando esta falle”.
  5. Un aproximado de usuarios finales que estarían usando la solución. En estos tiempos donde tenemos una gran necesidad de procesamiento de datos y donde ahora tenemos arquitectos de software es necesario dimensionar el posible nivel de demanda de procesamiento que la solución potencialmente requerirá con el objeto tener en cuenta y hacerle ver al cliente las implicaciones de hardware y de software que tendrá que contemplar como parte de la solución que estaremos planteando. El tema de la conectividad, trafico, disponibilidad, seguridad, escalabilidad, desempeño y crecimiento exponencial de los datos entre otros son aspectos que se tienen que contemplar desde la etapa comercial para poder establecer y acordar los supuestos para la optima implementación de nuestra solución. Además, cuando construimos una solución tenemos que anticiparnos y ver los costos aproximados de carga y mantenimiento a corto, mediano y largo plazo. Personalmente creo que un cliente aprecia el poder decirle como vemos a 2 o 4 años que se comportara nuestra solución.
  6. Que esfuerzos se han realizado en el pasado para resolver el problema. Uno nunca sabe que cosas puedes encontrar y que ideas valiosas se pueden re utilizar de aquellos esfuerzos o experiencias pasadas respecto a la solución. En cierta forma hay que ser afines a la inversión en tiempo y dinero que nuestro cliente ha hecho en el pasado para poder re utilizar lo que se pueda en todos los sentidos cuando esto coadyuva y aporta. Así mismo, identificar si es posible con que otros proveedores o colegas han colaborado con la finalidad de encontrar alguna relación positiva o visualizar alguna amenaza potencial. En mi experiencia me he encontrado con empresas y colegas que recomiendan los servicios.
  7. Actualmente en cuanto tiempo se realiza el proceso en cuestión y en cuanto tiempo seria lo óptimo. Sinceramente esta pregunta personalmente me parece importante. El poder detectar como opera hoy un proceso y cuantificarlo en tiempo, dinero o esfuerzo deja un indicador contra el cual podremos evaluarnos en el futuro para poder afirmar con datos concretos que fue un éxito nuestra intervención. Parte del orgullo del trabajo que hacemos se sustenta en el indicador. Proveedores de tecnología como Microsoft está siempre muy sensible a estos temas ya que dejan un antecedente favorable que en términos de mercadotécnica tiene un valor e impacto. Sin duda entender lo que considera éxito nuestro cliente nos dará la pauta de cómo proceder. Otro punto que en ocasiones he aplicado es acerca uno o dos años después justamente para ver indicadores y ahorros, en alguna ocasión en un proyecto fueron millones de pesos que se ahorraron en papel y el cambio cultural vino a elevar el nivel de calidad de los trabajadores del conocimiento. De verdad, este punto es un indicador estratégico.
  8. Cuenta con plataforma Microsoft y porque la usa. Esta pregunta nos permite saber la postura de nuestro cliente respecto a las propuestas de Microsoft lo cual es importante ya que con esto podremos compartir libremente como algunas tecnologías y productos podrían integrarse para resolver distintas necesidades. Por ello, si la posición es a favor sabemos que podemos aportar mucho más, si la posición es neutral o no a favor nos mantenemos al margen y alerta para posicionar productos o tecnologías cuando sea pertinente o nos pregunten.
  9. Cuenta con esquema de licenciamiento Microsoft. El tema de licenciamiento siempre ha sido algo crítico y delicado. Si nuestro cliente cuanto con algún acuerdo empresarial o esquema de licenciamiento buscamos nosotros tratar de utilizar donde haga sentido aquellos productos que se tengan licenciados como OCS, RMS, Exchange, Office, etc. Además, siempre es de vital importancia para el presupuesto de un proyecto el contemplar el licenciamiento desde una etapa temprana. En ciertas ocasiones cuando el esquema de licenciamiento esta por expirar aquí podría ser conveniente integrar a la subsidiaria local de Microsoft en el proceso para apalancar una renovación de contrato y por parte de Microsoft en ocasiones financiar nuestra solución. Todos ganamos.
  10. Cuenta con directorio activo y que tanto representa su jerarquía organizacional. Para proyectos de colaboración con SharePoint el tema del uso de directorio activo toma relevancia ya que aporta parte del esquema de seguridad que podríamos manejar en nuestra solución. Además de la integración de otras tecnologías. En alguna ocasión un representante de ventas “account manager” de la subsidiaria local de Microsoft especializado en Information Worker me dijo, aportamos valor para este cliente solo si tiene directorio activo y Exchange.
  11. Cuenta con equipo de desarrollo de software, en caso de que si, en que tecnología desarrollan. En el caso de nuestro cliente tenga algún programador o algún equipo de desarrollo es importante identificar que plataforma de desarrollo utilizan y ese sentido cual es su visión. La idea aquí es el poder alinear nuestra solución a desarrollar con el estándar o metodología de nuestro cliente en caso de existir, si no se cuenta, entonces involucrarlos y transferir nuestro proceso a ellos. Así mismo, dado el contexto del equipo de desarrollo en ocasiones conviene incluir en nuestra propuesta servicios u horas de capacitación técnica o transferencia de conocimiento para que el equipo de desarrollo de nuestro cliente pueda recibir y certificar nuestro trabajo. Además de que es parte de nuestra naturaleza influir o divulgar lo nuevo en tecnología de desarrollo Microsoft.
  12. Que versión de Office System usan los usuarios finales. Office 2007 aporta una gran capacidad de conectividad con SharePoint 2007, la sincronización que actualmente se tiene es una fundación con la cual podemos construir soluciones personalizadas usando de capa de presentación los mismos productos cliente de la familia Office. Si nuestro nos indica que se usa Office 2000 y Office 2003, es importante tomar en cuenta en nuestro dimensionamiento y diseño general de nuestra solución este punto ya que  Office 2003 no cuenta con tantas características de sincronización con SharePoint y hay que asegurarnos de comunicar a nuestro las expectativas y posibilidades de las tecnologías con las que cuenta. Uno nunca sabe y quizás seamos el detonador para actualizar los escritorios por nuevas versiones de Office.
  13. Se cuenta con presupuesto. En mi experiencia dependiendo de la región en donde hagas negocio esta pregunta puede incomodar, así que toma en cuenta eso. Desde el punto de vista comercial es muy importante poder sentir al cliente en este tema. El saber que se cuenta con presupuesto asignado o que se está en pláticas de asignarlo nos da un alto nivel de probabilidad de cierre del proyecto y por ello podemos entonces empezar con un alto nivel de certeza a coordinar la logística y agenda de los consultores que estarán involucrados. Sin mencionar lo que representa financieramente.
  14. Cuando se ve arrancando este proyecto. Esta pregunta también nos deja ver cómo y cuándo debemos empezar a coordinar con el área de operación de nuestra empresa la logística y asignación de recursos humanos, técnicos y físicos. Empezamos a ponerle fechas a nuestros planes generales de venta y hacer nuestra planeación de la operación.
  15. Hay algún procedimiento requerido para darnos de alta como proveedor. Esta pregunta nos permite saber cómo podemos iniciar con el procedimiento de alta como proveedor para que el tema de las políticas de pago nos impacte tanto. No hay nada mejor que estar debidamente registrado y alineados con nuestro cliente para que al momento de cerrar los compromisos contractuales estemos preparados.

Bueno, estas fueron algunas de las preguntas que se dan en los primeros acercamientos y que considero importante hacer durante algún proceso de visita con el cliente tomador de decisiones. Sin duda, hay muchas mas que seria valioso compartas en este espacio. Estas preguntas, NO son una guía sino lo que a mí bajo ciertos contextos de negocio me ha funcionado y hoy quiero compartir con la comunidad SharePoint.

Suerte y tu que preguntas haces?

Originalmente publicado en msmvps.com