El WSAA es el web service de autorización y acceso. Aunque la interfaz WSAFIPFE gestiona automáticamente la conexión a este web service y en principio no es necesario conocer su funcionamiento es importante conocer los fundamentos de este web service para poder optimizar y mejor el código que usa la interfaz. Como todos los web service de AFIP el WSAA tiene 2 modos: real y prueba. Esta documentación vale para los dos modos.
El objetivo del WSAA es que al conectarse este devuelve (luego de verificar los datos del CUIT emisor, certificado, fecha, web service a usar, etc) un "ticket" o "token" que no es más que una cadena de texto encriptado que da acceso a los otros web service (por cierto tiempo generalmente 12 horas).
Entonces cuando se ejecuta el método "f1obtenerticketacceso" (o cualquiera de sus equivalentes: xobtenerticketacceso, fxobtenerticketacceso, etc) la interfaz conecta con el WSAA (enviando los datos correspondientes: CUIT emisor, certificado, fecha, web service a usar) y obtiene el "ticket" o "token" que es guardado en una propiedad de la interfaz ("f1token" o sus equivalentes).
Luego, cuando se ejecuta cualquiera de los métodos de la interfaz, el control usa el ticket obtenido previamente (guardado en la propiedad correspondiente: "f1token" o similar) para conectar al web service (WSFEv1, WSFEX, etc).
Aunque todo esto es transparente al manejar la interfaz, de esta aquitectura puede deducirse que:
La sentencia f1obtenerticketacceso (o similares) implica una doble conexión, primero al WSAA y luego al web service normal de factura elecrónica (WSFEv1, WSFEX, etc).
Como al obtener ticket, este es guardado por la interfaz, es posible ejecutar la sentencia "f1obtenerticketacceso" una sola vez, y luego seguir ejecutando los métodos comunes sin volver a obtener ticket. Ya que el ticket obtenido generalmente es válido por varias horas (12 por lo general). la propiedad "f1tickethoravencimiento" o "f1ticketesvalido" indican si el ticket actual aún es válido.
Cuando la interfaz se descarga (por cerrarse el formulario o la aplicación que la contiene) el ticket se pierde y es necesario volver a obtenerlo (cuando sería más optimo guardar el ticket obtenido para luego restaurarlo y asi evitar la doble conexión).
De la misma forma, si se está trabajando en red, sería más optimo que solo una pc ejecute la sentencia obtener ticket acceso y luego (por algún archivo intermedio) comparta el ticket obtenido con las otras pc, para asi evitar la doble conexión.
Si se solicitan más de un ticket de acceso (estando vigente el anterior) el sevidor de AFIP puede rechazar el pedido devolviendo el error "El CEE ya posee un TA valido para el acceso al WSN solicitado"
Por los 2 últimos puntos la interfaz (desde la versión 10.6 o superior) incorpora dos métodos para guardar el ticket obtenido (como una cadena o string común) y luego restaurarlo, sin necesidad de conexión al WSAA. Estas sentencias (en lenguaje genérico, adaptar al lenguaje correspondiente) son:
strCadena (declarar como variable tipo string)
strCadena = fe.f1GuardarTicketAcceso()
guardar strCadena en un archivo temporal
fe.f1RestaurarTicketAcceso(strCadena)
Es decir el método GuardarTicketAcceso (o f1GuardarTicketAcceso, xGuardarTicketAcceso, etc) devuelve una cadena con el ticket actual y luego esa cadena puede ser restaurada con RestaurarTicketAcceso (o f1RestaurarTicketAcceso, etc) (ya sea más adelante en la misma u otra pc) para poder ejecutar los métodos habituales sin perder tiempo obteniendo ticket de acceso. Recordar que en cualquier caso (obtenerticketacceso o restaurarticketacceso) el ticket es válido por cierto tiempo, indicado por "f1ticketesvalido" o bien "f1tickethoravencimiento" (o sus equivalentes f1TicketEsvalido, xTicketEsvalido, etc). Teniendo en cuenta que estas propiedades (f1ticketesvalido y similares) solo tienen un valor significativo luego de restaurar u obtener ticket de acceso. El método "iniciar" inicializa todos las propiedades a cero o falso.
Estos métodos son implementados en las planilla de test desde donde pueden verse como trabajan.