Integrando Visual FoxPro con Windows Communication Foundation

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 mejoras 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:WINDOWSMicrosoft.NETFrameworkv2.0.50727>RegAsm.exe
«C:3MetasClientsClienteProyectoServiceFacade 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:3MetasClientsIntegrationsampledata" 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.

 

Juan Peláez

CTO

3Metas Corp.

 

 

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

 

Referencias:

http://www.dotnet247.com/247reference/msgs/15/75021.aspx
http://www.west-wind.com/presentations/VfpDotNetInterop/DotNetFromVFP.asp
http://www.west-wind.com/presentations/dotnetfromVfp/DotNetFromVfp_ComplexObjects.asp
http://blogs.msdn.com/calvin_hsia/archive/2005/09/02/460206.aspx

Publicidad

Migrando aplicaciones de visual fox pro a .net? tratando de establecer una
politica o un proceso de desarrollo para sus aplicaciones legacy? contactenos a
sales@3metas.com, nuestro equipo tiene la
experiencia y las habilidades necesarias para tener resultados exitosos.