Uno de los clientes de 3Metas utiliza un conjunto importante de controles GridView de ASP.Net para su aplicación de misión crítica, por diferentes consideraciones de diseño estas grillas utilizan unas imágenes para indicar la modificación de registros, pero en vez de editar el registro en la grilla misma cuando se hace clic en el icono se dirige al usuario a un formulario con más validaciones e información, cuando finaliza la edición el usuario regresa a la grilla, muy elegante en términos de usabilidad y experiencia de usuario.

Para controlar el evento de edición y obtener el id del registro que se está modificando se hace uso del evento RowEditing del control. En las versiones 2 y 3.5 del framework este comportamiento funcionaba perfectamente, sin embargo al migrar la solución al framework 4.0 y visual studio 2010 este flujo de navegación dejo de comportarse de la forma acostumbrada, ahora cuando el usuario termina el proceso de edición y regresa a la página con el control GridView toda la grilla esta en modo de edición.

Este cambio introducido en el Framework 4.0 y que afecta muchas líneas de código ya construido está reportado en Connect y en el foro de ASP.Net, para nosotros la solución más rápida y que introducía menos problemas fue cancelar la edición del registro al terminar el método usando

e.cancel = true; //cancelar el proceso de edición por cambios en el comportamiento del framework 4.0

Probablemente la mejor forma de lograr este efecto de navegación no era precisamente utiliza el evento RowEditing, sino utilizar un link o image column template, incluso para procesar algo antes de navegar al formulario de edición se hubiera podido usar un button template o un template personalizado, pero la aplicación de nuestro cliente ya estaba así y no era viable realizar ese cambio.

Los servidores Team Foundation Server (TFS) de 3Metas están hospedados en la nube, para conectar VS2010 a los servidores TFS asegúrese de tener instalado Team Explorer (puede descargarlo de aquí) y los Services Pack de Visual Studio.

Abra VS2010, seleccione la opción View, Team Explorer en el menú principal de la aplicación.  En el panel que se abre seleccione el icono conectar a Team Project, se abrirá el cuadro de dialogo Conectar a Team Project, seleccione el botón servidores en el cuadro de dialogo de adicionar / remover servidores seleccione el botón Adicionar y diligencie la información de conexión al servidor TFS.

Seleccione el proyecto en el que desea trabajar de la lista de proyectos autorizados.

A partir de este momento VS2010 está conectado al servidor TFS de 3Metas.

Si tiene problemas con este procedimiento escribanos a tfs.support@3metas.com

Los servidores de Team Foundation Server (TFS) de 3Metas se encuentran hospedados en la nube y no están integrados con los directorios activos (LDAP) o sistemas de autenticación de los clientes lo que significa que las credenciales de la red o dominio local no son válidas y se hace obligatorio el uso del usuario asignado por 3Metas para acceder a los servicios de TFS, sin embargo resulta incómodo que cada vez que se abre Visual Studio se presenta la pantalla de autenticación.

Para evitar esta pantalla se puede ir al panel de control de la máquina del usuario (Sistemas basados en Windows), opción User Account and Family Safety, la opción Credential Manager, en esa pantalla se puede seleccionar Add Windows Credentials, se llena la información del servidor, usuario y contraseña y listo.

Ahora cada vez que se conecte al TFS no será necesario digitar la contraseña.

Si tiene problemas con este procedimiento escribanos a tfs.support@3metas.com

Los servidores Team Foundation Server (TFS) de 3Metas están hospedados en la nube posibilitando un modelo de trabajo distribuido entre equipos de desarrolladores en diferentes ubicaciones geográficas y husos horarios. Para conectarse desde VS2008, VS2010 o cualquier otro cliente a los servicios del TFS deben realizarse las siguientes verificaciones / modificaciones.

1. Verifique que no está bloqueado por la seguridad de la red la dirección 67.192.120.72
2. Si es posible, cree a nivel de DNS en la red local el host vmtfs01 apuntando a la dirección 67.192.120.72
3. Si no es posible modificar el DNS de la red local, puede modificar con permisos de administrador el archivo host de la maquina local, este archivo se encuentra ubicado en la dirección C:\Windows\System32\drivers\etc, adicione el registro correspondiente al servidor vmtfs01 apuntando a la dirección 67.192.120.72. Reinicie la máquina.
4. Para verificar que la maquina reconoce el nuevo host haga una prueba ping al host vmtfs01 o escriba el nombre del host en cualquier browser de internet, si el browser solicita autenticación ha podido resolver correctamente el nombre.

 Si tiene problemas con este procedimiento escribanos a tfs.support@3metas.com

Esta semana cuando uno de nuestros clientes estaba realizando las pruebas de un proyecto en asp.net que tenía un conjunto de reportes embebidos, las imágenes del toolbar del Crystal ReportViewer no se mostraban o se perdían.

Teniendo en cuenta la experiencia que habíamos tenido ya una en un cliente con algo parecido revisamos nuestro anterior post sobre: Como publicar un reporte embebiendo ReportViewer en una página aspx sobre IIS7, realizamos todos los pasos allí descritos, pero esto no solucionó el tema de las imágenes. Así que decimos investigar un poco más en internet y nos encontramos que este problema se presenta comúnmente cuando el sitio web se ha creado en una ruta de disco diferente a: ..\inetpub\wwwroot, debido a que la aplicación trata de buscar los recursos que corresponden al ReportViewer en la carpeta: ..\inetpub\wwwroot\aspnet_client\system_web\2_0_50727

Así que una solución muy útil y práctica para este caso fue copiar la carpeta aspnet_client dentro de la carpeta de la aplicación, de tal forma que ahora está también en una ruta como esta: D:\\MiAplicacionWeb\aspnet_client

El truco nos funcionó, pero de repente no es la solución no es la solución más idónea para el tema, así que si alguien conoce alguna otra forma de hacerlo, por favor ¡cuéntenos! nos gustaría mucho que la compartiera aquí.

Uno de los clientes de 3Metas tiene una base instalada muy importante de aplicaciones construidas en Visual Fox Pro 7, 8 y 9. Durante los últimos meses hemos trabajado en conjunto para desarrollar una estrategia de migración de estas aplicaciones hacia una arquitectura orientada a servicios (SOA) construida con WCF y el Framework 3.5 de .Net.

Uno de los aspectos claves de un proceso como estos consiste en evitar al máximo que se siga construyendo funcionalidad en Visual Fox Pro (VFP) así que el primer paso de la estrategia consiste en la integración de VFP con servicios de Windows Communication Foundation (WCF) de forma tal que las aplicaciones actuales se vean beneficiadas de las mejores en la lógica de negocios o de nuevas funcionalidades que se construyen con la última tecnología disponible.

1. Lo primero que debe hacerse es construir un servicio de WCF en lo que no profundizare especialmente.

2. En nuestro caso una vez que tuvimos construido el servicio construimos una fachada para su utilización desde VFP.

3. En esta fachada establecemos las referencias a los servicios por medio de la herramienta de Visual Studio, allí verificamos el tipo de conversión que se realizará sobre las colecciones genéricas. Como queremos proteger la inversión del cliente en este proyecto esta fachada deberá poderse usar desde VFP pero también desde aplicaciones desarrolladas con .Net hoy y en el futuro.

4. Creamos una clase que estará visibles por COM desde VFP y que será la fachada para esta herramienta.

5. Esta clase debe estar decorada como COM visible [ComVisible(true)] y para asegurar las opciones de Intellisense también agregamos la decoración de generación de la Interfaz [ClassInterface(ClassInterfaceType.AutoDual)]

6. Aunque visual Studio 2008 (VS2008) crea el constructor de forma predeterminada preferimos asegurarnos así que agregamos el constructor, tener presente aquí que el constructor no puede sobrecargarse ni recibir parámetros para evitar problemas en COM

7. Luego creamos los métodos que serán consumidos por VFP y se los decora como visibles para COM [ComVisible(true)].

8. En nuestro caso los métodos del servicio de WCF devuelven colecciones genéricas de tipos específicos, por ejemplo la colección de colores de la entidad color: [CollectionDataContract(Name = "Colores", Namespace ="http://myDomain.com/Data/2010/01")] public class Colores: Collection<ColorEntity> {}, para que estos métodos puedan ser consumidos desde VFP y teniendo en cuenta la restricción de COM para el manejo de genéricos se realiza una modificación al método para que no retorne la colección sino que retorno un arreglo de objetos que es algo que si puede ser manejado por VFP, la posibilidad de convertir la colección genérica en un arreglo se adiciono con LINQ, así que debe establecerse la referencia a LINQ en el proyecto y la clase, al final debe quedar algo como esto:

   1:  using System;

   2:  using System.Collections.Generic;

   3:  using System.Linq;

   4:  using System.Text;

   5:  using System.Runtime.InteropServices;

   6:  using ServicioProducto;

   7:  

   8:  namespace ServicesFacade

   9:  {

  10:  

  11:      [ComVisible(true)]

  12:      [ClassInterface(ClassInterfaceType.AutoDual)]

  13:      public class ProductoFacadeVFP

  14:      {

  15:          //default constructor

  16:          public ProductoFacadeVFP() {}

  17:  

  18:          /// <summary>    

  19:          /// Metodo trae los colores del Sistema

  20:          /// </summary>

  21:          /// <returns></returns>

  22:          [ComVisible(true)]

  23:          public Color[] GetColores()

  24:          {

  25:              Colores colores = null;

  26:  

  27:              try

  28:              {

  29:                  ServicioProductoClient srv = new ServicioProductoClient();

  30:                  colores = srv.GetColores();

  31:                  srv.Close();

  32:              }

  33:              catch (Exception ex)

  34:              {

  35:                  throw ex;

  36:              }

  37:  

  38:              return colores.ToArray();

  39:          }

  40:       }

  41:  }

9. Al compilar este proyecto se obtendrá una DLL y un archivo de configuración que corresponde a la forma como se establecerá la comunicación con el servicio (Address y Bindings), estos dos archivos son los que deben entregarse a los desarrolladores de VFP para que consuman los servicios.

Completada la fase de preparación y construcción de los servicios y su fachada los desarrolladores de VFP ya pueden integrar estos componentes en sus aplicaciones, para ello deben realizarse las siguientes actividades:

1. Registrar la Interfaz COM de la fachada de los servicios por medio del comando regasm, idealmente debería utilizarse el parámetro CODEBASE, la instrucción sería algo como esto si se corre desde el directorio del Framework 2.0 de .Net: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>RegAsm.exe “C:\3Metas\Clients\Cliente\Proyecto\ServiceFacade\ ServicesFacade.dll” /CODEBASE

2. Uno de los aspectos más importantes de WCF es la separación de la configuración del servicio del código, el address y el binding del servicio que están definidos en el archivo de configuración, este archivo de configuración se generó al compilar la fachada. Para cada proyecto en el que va a utilizarse la fachada se debe copiar el archivo de configuración del servicio en la misma ruta del ejecutable de la aplicación de VFP o para depuración en la ruta donde reside el proyecto, este archivo debe renombrarse con el nombre de la aplicación de VFP y la extensión .config, en nuestro caso queda algo como esto: aplicaciondelcliente.exe.config. Muchos de los errores que se pueden presentar al usar la fachada tienen que ver con el hecho de que la aplicación no encuentra el archivo de configuración.

3. Registrada la interfaz COM de la fachada y renombrado y ubicado correctamente el archivo de configuración del servicio ya está todo listo para que el desarrollador pueda utilizar los servicios desde VFP. Solo debe utilizar el método CREATEOBJECT con el nombre de la clase de la fachada. Por ejemplo:

   1:  LOCAL Colores

   2:  LOCAL MyColor as ServiceFacade.ServicioProducto.Color

   3:  LOCAL ProductoFacade as ServicesFacade.ProductoFacadeVFP

   4:  

   5:  ProductoFacade = CREATEOBJECT("ServicesFacade.ProductoFacadeVFP")

   6:  Colores = ProductoFacade.GetColores()

   7:  

   8:  OPEN DATABASE "C:\3Metas\Clients\Integration\sampledata" EXCLUSIVE

   9:  USE color IN 0 EXCLUSIVE ALIAS tblColor

  10:  ZAP

  11:  

  12:  FOR EACH Item IN Colores

  13:      INSERT INTO color (ColorId) VALUES (Item.ColorId)

  14:  ENDFOR

Listo, el equipo de desarrolladores de VFP está consumiendo servicios de WCF.

Aclaraciones importantes:

· Con Visual Fox Pro se pueden consumir servicios Web, así que si se exponen los servicios de WCF con un binding básico HTTP el servicio de WCF se ve exactamente igual que un servicio web y por tanto se consume sin problemas desde FoxPro, sin embargo desde la perspectiva técnica puede llegar a tener problemas con objetos de negocios que VFP no entienda o que el servicio de WCF este expuesto por otro binding lo que haría imposible consumirlo desde VFP nativo, en nuestro caso las aplicaciones no estaba construidas consumiendo servicios web y el cliente no quería invertir tiempo de los desarrolladores en que aprendieran a consumir servicios web desde VFP, de allí tenía sentido que ellos consumieran objetos COM que les son familiares.

Al crearse el proyecto de fachada podría configurarse por medio de VS2008 la conversión de las colecciones genéricas en arreglos (ARRAYS). Sin embargo, eso haría que la fachada perdiera tipos de datos que podrían ser utilizados por clientes de .Net

Complemento de otro post en el que Roberto Alvarado ya había hecho un abrebocas del tema.

En IIS7 se pueden usar otros bindings como por ejemplo net.tcp y named.pipes para acceder a servicios de WCF (en IIS6 sólo es posible usar http Binding, para usar uno de los otros se debe hostear el servicio en otro tipo de host como un servicio Windows o una aplicación de consola) y justo esto es una de las ventajas de IIS7, se utiliza todo lo bueno del mundo del IIS como el reciclaje de aplicaciones pero con protocolos muchos mejores para ciertos escenarios como net.tcp.

Para habilitar estos protocolos en IIS7 debe ir al panel de control, programs, turn Windows Features On/Off y verificar que tenga seleccionadas por lo menos las opciones que aparecen en la imagen, en especial lo que tiene que ver con la activación de servicios sobre protocolos no HTTP.

Con esta habilitado ya se puede ir al IIS y seleccionar los bindings y protocolos correctos como se muestra en las dos imágenes siguientes:

Ahora puede Hospedar servicios de WCF con bindings como net.tcp que se usa para escenarios de red de área local o named.pipes que se usa para comunicaciones interprocesos en la misma máquina.

En 3Metas utilizamos las últimas tecnologías en desarrollo de software, por eso muchas de nuestras aplicaciones trabajan bajo la arquitectura de servicios (SOA).  Por esta razón en uno de nuestros clientes usamos servicios de Windows Communication Foundation para compartir datos entre diferentes plataformas y aplicaciones como por ejemplo Windows Mobile, Aplicaciones WPF, Aplicaciones Silverlight y ASP.NET.

Una de las tareas que debemos realizar después de crear estos servicios es la publicación de los mismos en un servidor web para que sean expuestos y utilizados por las diferentes aplicaciones. En este pequeño tutorial publico los servicios en un servidor web IIS 7 con Windows Server 2008.

1. Se crea un sitio web, se le asigna un puerto específico, en el caso de nuestro cliente,  es el puerto 81 el que utilizan los servicios  WCF. Sin embargo podemos escoger cualquier puerto y verificar que este puerto este abierto en el firewall si los servicios van a  estar expuestos a internet.

2. Se copian los archivos publicados de la solución de los servicios en una carpeta específica, que es la misma que se ha definido al momento de crear el sitio web en el IIS.

3. Nos aseguramos que el namespace  ServiceModel este activo y registrado en nuestro servidor IIS, para ello abrimos la consola de comandos en modo administrador y ejecutamos el siguiente comando: “%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe” -r –y

4. La ejecución de este comando nos muestra unos resultados como parece en la siguiente figura

5. Se revisan los Handler Mappings como se ve en la figura:

6. Doble clic sobre Handler Mapping, aparece la siguiente pantalla:

7. En esta pantalla revisar si existen las entradas para la definición de los *.svc, ya que en nuestro caso los Hosting de los servicios WCF son en IIS con ASP.NET.

8. Para crear estos handlers hacemos clic derecho sobre la lista, nos muestra el siguiente menú:

9. Seleccionamos la primera opción  Add Managed Handler que nos muestra la siguiente pantalla en la cual colocamos los datos a ingresar:

8. Los valores a colocar para Request path: *.svc, Type: System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, Name: svc-Integrated. Las restricciones las dejamos por default. Este es el primer registro. Debemos colocar otros 2 registros.

9. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0. Las restricciones las dejamos por default. Este es el segundo registro.

10. Los valores a colocar para Request path: *.svc, Type: %SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll, Name: svc-ISAPI-2.0-64. Las restricciones las dejamos por default. Este es el tercer registro si es para un servidor de 64 bits.

11. Luego verificamos si nuestros servicios quedaron funcionando de manera correcta, en la pantalla siguiente:

12. Seleccionamos un servicio, como el que se muestra en la figura, clic derecho y en el menú que aparece le damos Browse, lo cual nos abre una ventana del explorador de internet para verificar si nuestro servicio está funcionando de manera correcta.

13. El explorador de internet nos debe mostrar una pantalla como la siguiente: indicando que el servicio está funcionando correctamente.

14. El siguiente paso es corregir en el web.config del sitio ASP.NET que hostea u hospeda  los servicios WCF, las cadenas de conexión a las bases de datos que utilizamos para que nuestros servicios puedan funcionar de manera correcta.

En nuestro caso verificamos la sección ConnectionStrings del web.config y colocamos los valores correctos:       <connectionStrings>

<add name=”XXXXXNETDB” connectionString=”Data Source=YYYYY;Initial Catalog=MiBaseDatos;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”XXXXXNETDBII” connectionString=”Data Source=YYYYY;Initial Catalog=MiOtraDB;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

<add name=”ZZZZDB” connectionString=”Data Source=YYYYY;Initial Catalog=JJJJJJ;User;Password=3Metas; Timeout=999999″ providerName=”System.Data.SqlClient” />

</connectionStrings>

15. El siguiente paso es ir a la solución que consume los servicios que estamos exponiendo en el IIS en nuestra solución ASP.NET a través de los archivos *.svc  y colocar la dirección correcta de cada uno de los servicios en el app.config si es una aplicación  Windows, o en el web.config si es una aplicación web.

Verificamos y cambiamos el endpoint de los Servicios WCF que estemos exponiendo en nuestra aplicación :

<endpoint address=”http://servidor:81/ServicioRendimientos.svc”

binding=”wsHttpBinding” bindingConfiguration=”WSHttpBinding_IServicioRendimientos”

contract=”ServicioRendimientosClient.IServicioRendimientos”

name=”WSHttpBinding_IServicioRendimientos”>

<identity>

<dns value=”localhost” />

</identity>

</endpoint>

16. Como podemos observar en el tag address=http://servidor:81/ServicioRendimientos.svc, hemos cambiado a servidor:81 que es el nombre del servidor y el puerto por donde definimos en el sitio que se va a exponer los servicios WCF.

17. Probar nuestra aplicación que consume los servicios para comprobar que todo esté funcionando como debe ser.

Bueno eso es todo por ahora, espero haber podido ayudarles en este proceso de instalación de los servicios WCF en un servidor IIS.

En 3metas estamos automatizando el sistema de post cosecha de una de las empresas floriculturas más grandes del país. Nuestro mayor reto ha sido crear un sistema que permita facilitar la transición del papel a un software a la medida que resulte fácil de usar para unos usuarios muy particulares: los empacadores de ramos. Usuarios cuyo contacto más cercano con la tecnología son sus celulares, usados casi estrictamente para recibir y hacer llamadas.

Hoy tenemos un inconveniente con ellos que afecta una parte del proceso. El caso es el siguiente: hay necesidad de leer un serial para lo cual cada usuario cuenta con un lector de seriales (como el de los supermercados) que le ayuda a ingresar los datos del producto. Estos seriales, como también ocurre en los supermercados, muchas  veces no alcanzan a ser leídos por las máquinas y hay que ingresarlos manualmente.

Allí radica nuestro problema, pues el sistema está compuesto por dispositivos móviles (PDA) que no cuentan con un teclado. Ergo, todo es touch screen y los teclados están incluidos, en digital, dentro del programa. Pensando en esto usamos el teclado alfanumérico, tipo qwerty que ven a continuación. Sin embargo en la práctica hemos notado una dificultad en los usuarios para encontrar las letras pues en su imaginario “están en desorden”. Nuestra primera conclusión es que los números junto con las letras generan ruido y esto hace que sea más difícil encontrar lo que se busca.

Por ellos pensamos usar un teclado qwerty normal como el del Iphone, pero esta solución no es viable porque todos los seriales están compuestos por números y letras, así que toma mucho tiempo cambiar repetidamente de teclado, uno para números y otro para letras. Hemos pensado dejar el teclado como está hoy y organizar las letras alfabéticamente, pero tenemos dudas de generar recordación de un teclado que sólo se usa para esto o crear más confusión a largo plazo cuando los usuarios tengan contacto con un computador y por ende con un teclado qwerty.

Sabemos que la situción tiene varios limitantes, pero creemos que reparar en estos detalles nos alimenta. Cuéntenos qué se les ocurre, qué soluciones le verían esto.

Esta semana realizando la migración de código de un sitio web en un cliente, en el cual dentro de los múltiples cambios modificamos la interfaz gráfica de la aplicación para que utilizara Ajax e integramos además un Master Page en el diseño. Esto no debería afectar la funcionalidad, pero en especial una de las páginas empezó a presentar un problema, el cual se presentaba cuando se enviaba a realizar una operación que tarda más de 2 minutos contra la base de datos.

El error era del tipo: Sys.WebForms.PageRequestManagerTimeoutException, y por ser un error de Ajax se presentaba en el cargue de la pagina para su respectiva actualización luego de la ejecución del evento. Para resolver entonces este problema se debe incrementar el timeout para la página, y para esto se debe adicionar la propiedad AsyncPostBackTimeout al control ToolkitScriptManager o al control ScriptManager, asignándole un valor en segundos que depende del tiempo necesario para la operación.

<AT:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server" EnablePartialRendering="true" AsyncPostBackTimeout="360000" ScriptMode="Release">