02 agosto, 2011

Cambiar el aspecto de Project Server 2010

Si necesitas cambiar el aspecto básico y típico de Project Server 2010, tendrás que hacer 2 cosas:
1. Habilitar el código servidor en las páginas de SharePoint (http://www.projectserver2010blog.com/2010/01/project-server-2010-changing-master.html)
2. Habilitar la caractarística de publicación de Site Collection (Site Settings)
3. Hacer una solución para desplegar la masterPage que quieres poner

A partir de ahí verás que cuando pones la masterpage de publicación, te habilitará las secciones de SharePoint únicamente. Si luego lo configuras de manera que la misma masterpage también actúe como MasterPage de sistema funcionará, pero cuando se abran cuadros de diálogo tendrás un problema....

Hay varias opciones, pero una muy sencilla es incorporar un Control de Usuario que, agregado a la MasterPage, inserte un CSS que oculte todas las secciones que no queremos visualizar en las lightbox que muestra SharePoint.

Siguiendo con los pasos:

4. Crear un UserControl que en el RenderWebpart(...) tenga un código parecido al siguiente:

protected override void Render(HtmlTextWriter writer)
{
base.Render(writer);

if (Page.Request.QueryString["IsDlg"] != null && Page.Request.QueryString["IsDlg"] != string.Empty && Page.Request.QueryString["IsDlg"] == "1")
{
Page.Response.Output.WriteLine("




");
}
}

5. Desplegamos la solución con el UserControl que hemos creado y lo registramos en la masterpage. Para éste último paso os facilito una referencia muy útil:
http://2010help.wordpress.com/2011/02/16/add-a-custom-user-control-to-a-sharepoint-2010-master-page/

No deja de ser una imitación de un cambio real de masterpage, aunque fijaros que podemos ocultar sólo parte de la masterpage customizada, que eso sí suele resultar útil.

Si preferís cambiar la masterpage en tiempo de ejecución deberéis hacerlo en el PreInit de la página, cosa que en SharePoint no estña soportada po rlo que deberéis interceptar vía HttpModule el evento y sobreescribir el código que ejecuta.

Project Server 2010 una herramienta que no es para todos

Desde la primera de mis experiencias con Project Server ya ha pasado tiempo.

Actualmente la pelea sigue y éta vez con un producto libiano, montado sobre una plataforma colaborativa como es SharePoint 2010 Enterprise.

¿Porqué escoger Project Server?

Porqué es una herramienta completa para la gestión Integral de proyectos totalmente pensada para configurarse y entrar en funcionamiento desde el minuto 1.

De igual forma, no es recomendable caer en el error de que ésta plataforma ofrece la versatilidad de una solución genérica como es SharePoint, por lo que sería erróneo verla como una solución a medida.

La solución Enterprise Project Management de Microsoft, en su versión 2010, consiste en la unión de dos productos diseñados para gestionar los proyectos empresariales:

- Project Professional 2010
- Project Server 2010



Os recomiendo que visitéis éste producto en su site oficial y que os intereséis en descubrirla.
Tal y como apunta el estudio de Gartner, es la solución líder del mercado en gestión integral de proyectos.

23 diciembre, 2010

Nintex y Sharepoint 2010

Nintex, software para desarrollar VISUALMENTE workflows complejos totalmente integrado con Sharepoint 2010. Es una herramienta que permite de manera simple el desarrollo de workflows complejos sobre Sharepoint 2010. Personalmente, lo clasifica entre las posibilidades que ofrece Sharepoint Designer y las capacidades de Workflow Foundation.

Una imagen vale más que mil palabras:



La creación/edición del anterior workflow se realiza directamente desd ela própia librería de infopath. Configuración --> Manage Workflows [opción que está disponible después de desplegar Nintex].

En el WF anterior se han utilizado actividades de muchas clases:
- Tareas de aprobación con reminders
- Tareas de revisión
- Notificaciones vía mail
- Asignación de valores a campos
- Lookup's a listas
- Cambios de estado en la maquina de estados
- Condicionales
- etc.

Recomiendo la utilización de dicha herramienta, dado que es de fácil instalación, y su potencia es muy notable.

Particularidades como "Lazy Approval" (responder al mail de notificación de aprobación con un "aprobado" automaticamente aprueba la tarea), conexiones con sistemas externos (CRM, ERP's), personalización de los mails de notificaciones, delegación de tareas o incluso de rol (vacaciones, p.e.) hacen de ésta herramienta una opción muy interesante cuando, por ejemplo, no se tiene acceso al servidor o ni tan solo a la Site collection.

Podéis empezar viendo e investigando a través de la web del fabricante: http://www.nintex.com/en-US/Products/Pages/NintexWorkflow2010.aspx

14 diciembre, 2010

Lync & Office 365

El mes pasado estuve en el C.E.U.S VI, donde se pudieron ver dos nuevas tecnologías que Microsoft está promocionando: Lync y Office 365.



Lync es la evolución de Office Communicator Server (OCS 2007 R2) a un sistema orientado a la comunicación unificada entre equipos de trabajo, todo de una manera completamente descentralizada y remota. Reuniones online, meetings, ponencias, compartición de información, discusiones en tiempo real, son algunas de las muchas prestaciones de Lync.

El nombre de Lync proviene de la unión de Synch junto con Link, que vendría a ser enlace sincronizado.

Una referencia exquisita de Lync la encontramos en su página oficial: http://lync.microsoft.com/es-es/Paginas/default.aspx

Office 365: La era de la nube es como le llaman al nuevo producto renombrado como BPOS en su versión anterior. Tendremos suite de office online, servicios de Exchange, mensajerís instantánea (Lync Cloud) y Sharepoint Online.
El producto verá la luz a mediados de 2011 y se plantea como la revolución de las soluciones Cloud del momento.
Para los existentes en BPOS, la migración la realiza Microsoft con incluso un tiempo récord de corte de conexión (segundos).



Para más información, no dudéis en consultar: http://office365.microsoft.com/en-US/online-services.aspx

27 octubre, 2010

Pensar en motivación es pensar en SCRUM

Recientemente, estuve en una formación sobre una metodología que, curiosamente, se hacia llamar ágil. Ante la sorpresa de haber sido víctima, en pasadas ocasiones, de dicho modo de trabajo, descubrí una, entre muchas, metodología que SI creo sinceramente que lleva al éxito una empresa mediana-grande dedicada al desarrollo de software i consultoría. Sorprende pero es así.

La formación me sirvió para entender el fundamento teórico y el pensamiento que hay detrás de una metodología "ágil".

SCRUM viene de una postura que adoptan los jugadores de rugby en forma de muralla que les permite absorver todo el impacto del equipo contrario.
No es casualidad dicho nombre, ya que las bases del scrum se fundamentan en ésto:
  • Equipo
  • Cohesión
  • Ambición
  • Objetivo único
  • Seguridad y firmeza
La primera reflexión que debemos hacer es analizar la situación actual del mundo de la informática. Desgaste, Estrés, Exceso de dedicación,... pérdida clara de motivación.. y por último, pérdida clara de productividad.
Está probado que el humano, bajo una situación cómoda y apta para concentrarse, es capaz de rendir hasta 6 horas de las 8 que componen una jornada laboral. NO más.

Señores, entonces, porqué nuestra única preocupación es ver como teclea el analista o detectar el intruso que se levanta de la silla a las 19:00 de la tarde...?

No,no,... no estamos entendiendo nada.. Tenemos un problema, y éste se sirve con el nombre de Motivación.

Debemos centrar nuestros esfuerzos en la pérdida de motivación que sufren los empleados de nuestro sector, y la mejor solución no es apretar, sino preparar el mejor ambiente, para que rindan al máximo!

¿Porqué SCRUM? Porqué nos ayudará a mejorar la motivación de la gente y ese será la solución a la rotación de personal, los malos resultados de rendimiento y finalmente, a dedicar menos horas para hacer lo mismo MUCHO mejor.

Espero que os haya despertado el interés. Para dar el último "toque" os facilito a continuación la presentación de la ponencia que realicé. Espero vuestros más sinceros comentarios.

09 mayo, 2010

Exprimiendo MOSS 2007

Desde hace unos meses que no dedicaba un momento a mi blog personal, para compartir con todos vosotros algunas de mis experiencias.

He estado distraido con un proyecto en el que se ha tocado una parte de la extensibilidad de Sharepoint, que no había palpado con tanta profundidad. Hablo de Infopath junto con Workflow Foundation y todo bajo Sharepoint 2007.

No voy a escribir un relato técnico, sólo quiero compartir porqué escogería o no ésta combinación de tecnologías.

MOSS 2007 + WF 3.5 + Infopath 2007:

Infopath se integra perfectamente con Sharepoint, y presenta una combinación atractiva para realizar formularios de peticion o solicitud de cualquier tipo, amigable y atractivo para el usuario. De hecho, Infopath tiene sus própias plantillas, muy útiles para los procesos de negocio típicos (compras, vacaciones, viajes, etc etc.).
Es una tecnología que considero muy útil para utilizarla "out of the box", de manera que le modifiquemos lo mínimo a los formularios desarrollados.

Soportar los procesos de negocio, con los formularios de infopath, con Workflow Foundation prácticamente podria decir que es un error... Alta complejidad, problemas de despliegue de las soluciones restantes, y un desarollo realmente pesado convierte ésta convinación en innecesária y desestimable.

Lógicamente, es la combinación más potente, pero no por ello debemos elegirla.

Tal como apuntan las nuevas soluciones de Sharepoint 2010, la creación de flujos de trabajo se podrá incluso crear a partir de un visio (en su version 2010, claro).

Qué propondría en su lugar? ASP.NET 3.5 + Workflows de SPD + MOSS2007 / MSS 2010

Por mi experiéncia, os puedo asegurar que si disponemos de unos controles Telerik adecuados, podemos conseguir un resultado mucho más controlado y potente del que Infopath nos ofrece, y como he adelantado antes, desestimaria los workflows del framework para decantarme por los de Sharepoint Designer.

Si ya tenemos Infopath, qué hacemos? el cliente ya está acostumbrado...

No reinventes la rueda, digue con Infopath, y explota al màximo su potencial.
- Utiliza el Code Behind
- Que no te asuste desplegar un formulario. Si lo empaquetas con un WSP, y dentro todo lo que necesita (dlls externas) funcionará bien.
- Modula todo lo que puedas
- EMPAQUETA, sino te pasará factura.

Por último, os dejo algunos links que creo interesantes de Infopath 2007 junto con MOSS y WF:
Video oficial de creación, desarrollo, y despliegue de un formulario de flujo de trabajo, un formulario de tarea y un Workflow:
http://msdn.microsoft.com/es-es/library/cc296354.aspx
(recomendado para tener un overview)

Triquiñuelas y puntos interesantes del Code Behind de un formulario Infopath:

http://panvega.wordpress.com/2009/02/16/how-to-access-infopath-fields-with-codebehind/

Consejos en la publicación de formularios. Diferentes maneras de hacer-lo:


http://geeks.ms/blogs/ciin/archive/2009/08/23/moss-como-automatizar-la-publicaci-243-n-de-formularios-infopath-iii.aspx

18 enero, 2010

Integration Services - SSIS

Comparto mi iniciación en el mundo de SSIS, en motivo de migrar una base de datos antigua a una nueva bajo una estructura diferente y con ampliaciones añadidas.

Hes estado echando un ojo por internet y he comprobado como es sencillo crear un proyecto de Integration SErvices y empezar a toquetear.

Una vez hayamos instalado nuestro SQL Server, los componentes de cliente nos convertirán nuestro visual estudio en una plataforma apta para el desarrollo de proyectos de Analisys Services, Integration Services, BI,... por lo que ya podremos empezar a toquetear.

A partir de ahí os recomiendo ésta guia muy básica que nos da una noción rápida del producto: http://mciacci.blogspot.com/2008/03/ssis-ejemplo-de-package-con-origen-de.html

Enlace interesante: SQL_Server_Integration_Services - Wikipedia

15 enero, 2010

Force to implement a function with a default behaviour

Hoy, mientras refactorizava una parte de un código, he llegado a un punto en el que necesitaba crear una función en una clase, la cual tenia que ser de implementación obligada, pero sólo una parte de su código.
Añadido, necesitaba que se hiciera ésta implementación tipificada, dado que ese desarrollo tenían que implementar-lo muchas clases distintas.

Resumiendo:
- Necesitaba una clase base
- Un código que se forzada su implemnetación en sus hijos
- Permitir añadir código a la clase base, de manera que no tuviera que modificar las hijas.

¿Cómo? (cuando descubro ésta parte es cuando entiendo porqué la arquitectura de software puede encajar mágicamente tantas piezas y comportamientos)

abstract class BotellaFundamentals
{
public virtual void AbrirBotella()
{
// Espacio para un futuro
// Si ésta clase fuera real, probablemente sería mucho más genérica,
//por lo que previamente se realizaría un acceso a un controlador: ControlladorInstrumentos de Ibotella...

AbrirTapón();

// Espacio para cambiar en un futuro si se precisa
}

abstract protected void AbrirTapon();
}

class Botella : BotellaFundamentals
{
protected override void AbrirTapon()
{
// Implementación de abrir el tapon de la botella, o sea, ABRIR LA BOTELLA
}
}

Ventajas:
- Todo el mundo puede pedir que se abra la botella.
- Nadie sabe que se consigue abriendo el tapón, simplemente
- Si un dia inventan botellas con 5 tapones, el público no se va enterar, ya que todo el mundo llama a AbrirBotella();
Los cambios que supondrá será que sus clases hijas OBLIGATORIAMENTE deberán implementar la apertura de los otros 4 tapones.

Creo que es un apunte muy simple y aporta muchísimo a una solución.

14 enero, 2010

Entity Framework Design Model First - Framework 4.0

Hace unos días comentaba las carencias con las que me había encontrado trabajando con EF. Siguiendo con la idea de que EF es una plataforma que está naciendo, a pesar de tener por detrás una idea realmente interesante, quiero añadir un par de conceptos que mejoran, en su nueva versión sobre Visual Studio 2010, la potencia del producto.

El método de crear un modelo conceptual EDMX, en Visual Studio 2008 SP1, era crear la BBDD en SQL Server y luego generar el modelo a partir de ella.
Luego, una vez generado el modelo, hay que retocar las herencias y relaciones N-N para que EF entienda al 100% nuestro modelo.
Ello conlleva que un cambio en Base de datos nos obliga a rehacer el modelo y con ello rehacer la configuración de todas las herencias y las relaciones N - N.

En VS2010 y Framework 4.0, EF evoluciona y nos permite crear el modelo conceptual y partiendo de él, generar la base de datos. Es el proceso inverso, y lógico, de como lo hacía VS2008 SP1.


"Create Database From Model..."


Puede parecer un simple cambio de método, pero éste cambio nos EVITA rehacer relaciones y herencias cada vez que haya un cambio.

Es una evolución notable en el framework.

Referencias:
http://blogs.msdn.com/adonet/archive/2009/05/12/sneak-preview-model-first-in-the-entity-framework-4-0.aspx

03 enero, 2010

Entity Framework

El último proyecto en el que estamos trabajando consiste, a grandes rasgos, en el desarrollo de un aplicativo a medida con presentación web, tecnologia ASP.NET 3.5, bajo una arquitectura 3 capas y una vertical en forma de fachada en la que definimos toda la sintaxis de los esquemas que se utilizaran en el sistema.

¿Qué es?

La capa de acceso a datos se realiza a través de Entity Framework. Es una plataforma pensada para abstraer el esquema de base de datos y redefinirlo para ser visualizado desde nuestra capa de negocio como un modelo conceptual de "diseño".

La idea es realmente buena, aunque no está suficientemente depurada. Hay funcionalidades como que una columna sea FK y PK a la vez, que no se nos permitirá realizar.

Permite explicitar la herencia, las referecias de * a * o las 1 a * sin ningún problema.

Es muy interesante para modelos "simples" que cada una de sus tables se identifiquen por un PKID, no por claves compuestas y referenciadas a la vez.

Otro punto a mejorar es la actualización de cambios en la base de datos. El refresco es automático, pero te deshace cualquier asociación que hayas modificado en el modelo, tras la importación.

Ello dificulta mucho la actualización de estructura de BBDD al modelo EDMX (Entity Framework).

Cabe decir que el modelo EDMX no es más que un XML, que mapea y genera relaciones entre las entidades.

¿Qué ventajas ofrece?

A parte de las mencionadas anteriormente, la má simportante es que nos ofrece un canal vía LINQ para el acceso a los objetos y sus relaciones, como si de la navegación dentro de un OO se tratara. Simplemente con:

context.AddToClient(account);

context.SaveChanges();

puedo grabar una entidad cliente. A fin y al cabo, no deja de ser LINQ que va por detrás. Lo más interesante es que del "client" que acabo de guardar antes, puedo, por ejemplo:

List contactsClient = account.Contacts.TransformToIContact();

convertir las referencias del cliente, a Entidades de mi modelo de objetos.

Es una herramienta interesante para abstraer una relación N - N, dado que si trabajaramos directamente sobre la base de datos, deberíamos mantener nosotros la tabla intermedia que proporciona la carinalidad N - N.

Con Entity Framework, de eso nos libramos.

Modelo EDMX en VS 2008: