Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Todos los dispositivos POS tienen la capacidad de generar eventos o cambiar el estado independientemente de la aplicación. Por ejemplo, si un operador desconecta un dispositivo PinPad, la aplicación no puede detectar este cambio directamente de ninguna manera, ya que no es un cambio de estado solicitado por la aplicación. Un objeto de servicio debe tener alguna manera de alertar a la aplicación de estos cambios de estado.
Subprocesamiento múltiple
Dado que el hecho de que la aplicación sondee continuamente el estado actual del objeto de servicio resultaría demasiado caro, se necesita otra solución. Normalmente, la solución consiste en crear un subproceso en segundo plano para supervisar el dispositivo.
Como han demostrado otros ejemplos, la creación de un subproceso de lector siempre es necesaria para dispositivos de entrada como escáneres o lectores de bandas magnéticas. Sin embargo, en el caso de los dispositivos de salida, como las pantallas de línea y las impresoras, un segundo subproceso suele ser necesario para observar los cambios de estado, como la pérdida de energía o de conexión, y luego enviar un evento StatusUpdateEvent a la aplicación.
De este modo, el objeto de servicio puede responder a las solicitudes de la aplicación mientras supervisa de forma asincrónica el hardware.
Definición de eventos
Los eventos son el mecanismo por el que el objeto de servicio notifica a la aplicación un cambio de estado en el dispositivo o la llegada de nuevos datos.
En términos generales, un evento es una notificación entre un subproceso o proceso y otro para informar que ha ocurrido algo. En concreto, Microsoft Point of Service para .NET (POS para .NET) usa la característica de delegados de .NET para realizar entregas a la aplicación.
La especificación Punto de servicio unificado (UnifiedPOS) define un conjunto de cinco eventos: DataEvent, DirectIOEvent, ErrorEvent, OutputCompleteEvent y StatusUpdateEvent. Cada objeto de servicio solo puede admitir un subconjunto de estos. El contenido exacto de los datos también depende del tipo de objeto de servicio.
Colas de eventos
Cuando se crea una clase de objeto de servicio derivada de una de las clases Base de POS para .NET, los eventos no se envían directamente desde el objeto de servicio a la aplicación. En su lugar, los eventos se colocan en una cola administrada por la clase Base. Dado que hay condiciones que deben cumplirse antes de que se puedan entregar eventos a una aplicación, el código de la clase Base envía eventos solo cuando es apropiado. El objeto de servicio no necesita tener en cuenta la cola ni los requisitos que deben cumplirse antes de que se pueda desencadenar un evento. Esto facilita significativamente la carga del desarrollador de objetos de servicio.
La cola de eventos funciona de forma asincrónica mediante su propio subproceso. Esto significa que el objeto de servicio no espera la entrega real del evento.
Adición de eventos a la cola
Las clases base de POS para .NET proporcionan varias maneras de agregar un evento a la cola en función del objeto de servicio y del tipo de evento.
Muchas clases Base tienen métodos auxiliares para simplificar la puesta en cola de ciertos eventos; más habitualmente, eventos DataEvent. Por ejemplo, el método MsrBase.GoodRead se puede usar para poner en cola un evento DataEvent después de leer una tarjeta correctamente. Del mismo modo, PosKeyboard.KeyDown pone en cola un DataEvent que indica que se ha presionado una tecla.
La clase Base también puede poner en cola los eventos automáticamente cuando un estado determinado cambia. Por ejemplo, si un objeto de servicio ha establecido su propiedad Properties.CapPowerReporting, un elemento StatusUpdateEvent que indica un cambio de energía se puede enviar simplemente estableciendo la propiedad Properties.PowerState en el objeto de servicio.
Por último, si es necesario, un objeto de servicio puede poner en cola específicamente un evento mediante cualquiera de las invalidaciones QueueEvent. Esto puede usarse con más frecuencia para enviar un evento DirectIOEvent. Dado que los eventos DirectIOEvent son específicos del proveedor y del dispositivo, no se puede usar ningún mecanismo genérico para ponerlos en cola.
Entrada sincrónica
Aunque el objeto de servicio lee la mayoría de las entradas del dispositivo de forma asincrónica y, a continuación, se envían a la aplicación en forma de eventos, sin embargo, hay instancias donde la aplicación puede solicitar datos del objeto de servicio y no devolverlos hasta que los datos estén listos o se haya agotado el tiempo de espera. Para obtener más información sobre la entrada controlada por eventos, consulte Administración de eventos.
Consulte también
Tareas
Conceptos
Otros recursos
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
