COM+ con VFP 7.0 - Parte 4

Publicado originalmente en FoxTalk

Traducción de Jorge Espinosa

 Descargue el código fuente (4 Kb).

En las primeras tres partes de esta serie hemos visto aplicaciones COM tradicionales, esto es, aplicaciones que trabajan con procesos sincrónicos. En estas aplicaciones sus programas llaman a componentes COM y esperan por una respuesta. ¿Pero que hace si procesar le lleva mucho tiempo para obtener una respuesta o carga mucho el servidor? La respuesta está en el uso de procesos asincrónicos.

---

¿Que es un Proceso asincrónico?

Un proceso asincrónico puede ser utilizado en distintos escenarios. El primero es el de usuarios desconectados. Podría tener vendedores que entran ingresan órdenes de venta en una computadora portátil. Cuando ellos se vuelven a conectar a la red corporativa , las órdenes de ventas son enviadas al Server central para procesarlas. También podría tener oficinas remotas, conectadas a través de líneas de alta velocidad a un muy alto costo, los datos pueden estar en el sitio remoto y por las noches pasarlos a bajo costo por líneas dial-up.

Otro uso común de procesos asincrónicos es para cambiar ciertos procesos en otros momentos del día. Por ejemplo, su departamento de ventas podría tener su hora pico de 10 AM a 2 PM. Si el departamento esta trabajando en esas horas, ejecutar un proceso podría causar una carga inaceptable para el servidor. Usando procesos asincrónicos puede cambiar los procesos enviados hacia horas de la noche, cuando la demanda del sistema debería estar baja.

Otra cosa que a muchas personas les molesta, es la espera a procesos que no le retorna valores a su aplicación. Usando componentes COM estándares, llama a un componente y espera por el retorno de un valor. La Figura 1 muestra una Aplicación COM típica, envolviendo varios procesos en una sola transacción. Con procesos asincrónicos envía mensajes al sistema. No recibe un valor del retorno. Esto significa que no puede usar procesos asincrónicos si debe obtener un valor de retorno.

Otra cosa para tener en cuenta es que todos los parámetros deben ser pasados por valor.

Porque usted no espera al componente COM para seguir corriendo la aplicación, y el hecho es que tampoco sabe cuando correrá, por lo tanto nunca debe pasar parámetros por referencia.

Introduciendo a Queued Component

Entonces, si no sabe cuando el componente correrá, ¿cómo lo llama?

Figura 1

Lo remito a lo dicho antes: use mensajería (messaging). Bajo Windows NT tenía que usar Microsoft Message Queue(MSMQ). Mientras MSMQ es una gran tecnología, tendría que usar su API, que es diferente de su componente.

Bajo windows 2000 y COM+ puede usar Queued Components, que usa MSMQ por debajo. La ventaja de Queued Components es que no tiene que aprender algo adicional a la API del MSMQ.

La Figura 2 muestra el trabajo de Queued Components. Su aplicación llama a un grabador. El propósito del grabador es generar un registro de la llamada y los parámetros y enviar esto al MSMQ.(Para mayor informacion de MSMQ, ver "MSMQ con Microsoft Visual Fox Pro 6.0" en http://msdn.microsoft.com/library/en-us/dnfoxgen/html/msmqwvfp6.asp). La aplicación no sabe esto. Es mas, hasta donde sabe, está llamando a su componente directamente.

Figura 2

MSMQ guarda las llamadas y los parámetros y espera que le hagan alguna consulta. Que es el propósito del listener. Este busca en la cola un mensaje particular. Cuando este encuentra el mensaje, lo pasa hacia otro reproductor que reproduce la llamada para su componente. Vería también que aquí hay tres transacciones: la llamada al grabador, al MSMQ y finalmente a la combinación de componentes reproductor / listeners.

Ahora veamos el código. Este ejemplo es una aplicación simple de una orden de entrada. Deberíamos comenzar con el componente. Para mantener esto simple, este debería escribir la información de la orden a un archivo de texto.

DEFINE CLASS Orders AS SESSION Olepublic

Procedure NewOrder (tcCustomerID as String, ;
tcItemId as String, tiQuantity as Integer) as Void

Local lcString
TEXT to lcString TEXTMERGE NOSHOW
Customer ID : < <tcCustomerID> > 
Item ID: < <tcItemID> > 
Quantity : <<TRANSFORM(tiQuantity, "99999")> > 
<<Chr(13)> > 
EndText 

STRTOFILE(lcString,  "C :\Orders.txt", 1)
ENDPROC
ENDDEFINE

No hay nada realmente especial acerca del código, excepto por la declaración de la Función. Esta es especificada AS VOID. Esto es porque no retorna ningún valor - esta no es llamada para retornar un valor . Debe compilar esto dentro de MTDLL y entonces crear una nueva aplicación COM+ denominada QC_Ordes. Instale el componente dentro de la aplicación y configure lo siguiente:

1. En Components Services seleccione QC_Orders
2. Click derecho sobre QC_orders, seleccione properties y luego el tab Queuing
3. Chequee ambos "Queued- This application can be reached by MSMQ queues" y " Listen- This application, when activated, will process messages that arrive on its MSMQ Queue" (Figura 3). Click en OK
4. Busque en la entrada del componente hasta que encuentre las interfaces
5. Botón derecho en Iorders y seleccione propiedades desde el menú, entonces seleccione el tab Queuing
6. Chequee "Queued " y click en OK (Figura 4)

El componente ahora está configurado como un "Queued Component" , ahora necesitamos su atención sobre el formulario de entrada de datos para ver como llamamos al componente. Este es el código del método click del botón grabar .

1. Local loCatalog, loOrder
2. WITH Thisform
3. loCatalog = CREATEOBJECT("COMAdmin.COMAdminCatalog")
4. loCatalog.Connect("")
5. loCatalog.StartApplication("QC_Orders")
6. loOrder = GetObject("queue: / new:OrderEntry.Orders")
7. loOrder.NewOrder(Alltrim(.txtCustomer.Value), ;
8. Alltrim(.txtItem.Value), spnQuantity.Value)
9. loCatalog.ShutDownApplication("QC_Orders")
10. loOrder = NULL
11. loCatalog = NULL
12. ENDWITH

Hemos agregado líneas numeradas para hacer mas fácil de seguir la explicación:

Línea 1 es un comando local estándar definiendo las variables necesitadas por el método.
Línea 2 referencias del formulario.
Línea 3 crea una instancia en COM+ Catalog Administration.
Línea 4 conecta a la computadora que ejecuta el componente. En este ejemplo estamos usando una Pc local, así es enviado un string vacío.
Línea 5 las salidas de la aplicación COM+ que creamos antes. Note que usamos el mismo nombre de la aplicación COM+.
Línea 6 crea una instancia de MSMQ queued que estamos usando. Vea que el nombre de la cola es el nombre del componente y el nombre de la clase es el creado anteriormente.
Línea 7-8 llama al componente, pasando los parámetros. Línea 9 cierra la aplicación.
Línea 10 destruye la instancia del queued.
Línea 11 destruye la instancia del catalogo.

Figura 3

Ahora estamos realmente listos para correr el formulario. Ingrese los valores y presione Click en el botón Grabar. (Figura 5)

El componente será instanciado y los valores escritos en C:\orders.TXT. Esto es porque habilitamos la opción Listening cuando configuramos el componente. Veamos que pasa cuando la opción Listening está deshabilitada. Este es el seteo que usted usaría para procesar los datos más tarde.

1. Cierre VFP.
2. En el Component Service Manager, click derecho en la aplicación QC_Orders y seleccione cerrar.
3. Nuevamente click derecho en QC_Orders, seleccione Properties y luego seleccione el tab Queuing. Desactive "Listen", y haga click en OK.


Figura 4


Figura 5

4. Reinicie VFP y ejecute el formulario. Ingrese los datos para su orden y oprima el boton Grabar. Ingrese varias órdenes. Cada orden que usted ingrese generará una entrada en la cola.
5. Para ver la cola, abra el snap in Computer Management.
6. Despliegue la opcion Message Queuing -> Private Queues -> Qc_Orders
7. Clic en Queue Messages. Vera una entrada por cada orden cargada (Figura 6)
8. Cierre VFP
9. 9. Para procesar las ordenes, vuelva a Component Services en la MMC
10. Abra la pagina Queuing, en la hoja de propiedades de la aplicación y seleccione el Listen CheckBox.
11. Click derecho sobre la aplicación y seleccione Start.

Figura 6

La cola se vaciará y cada mensaje será leído y procesado por el objeto COM. Ahora que ha visto como usar Queued Components, espero que encuentre en esto algo útil para mejorar sus aplicaciones y hacer mas simple la arquitectura y el código.

---

Craig Berntson es Microsoft Certified Solution Developer y fue nombrado cuatro veces Microsoft Most Valuable Profesional. Disertante de varias conferencias de FoxPro en todo EEUU y eventos de Microsoft en Salt Lake. Es Presidente del Salt Lake City Fox Users Group y actualmente ingeniero de software senior para 3m Health Information Systems.

Jorge A. Espinosa, Buenos Aires (Capital Federal), Argentina, es Analista Programador y MCP. Dedicado al desarrollo de sistemas desktop desde el año 1987; siempre en el entorno xBase y en Visual Fox Pro desde la version 3.0. Hoy Gerente de Sistemas en Droguería Saporiti SACIFIA.