Skip to main content
El informe de procesamiento empresarial muestra qué tan bien se procesan los documentos y proporcionan trazabilidad de las transacciones de extremo a extremo para fines de auditoría. El Warehouse registra todas las transacciones (completadas y en curso) para su análisis y visualización en herramientas de inteligencia de negocios. Los datos se conservan durante 12 meses, lo que permite el análisis y la auditoría en períodos de tiempo definidos. Se realiza un seguimiento de los siguientes datos:
  • ID de transacción.
  • ID y versión de la skill.
  • Ruta de procesamiento por pasos:
    • Tipos de paso
    • Nombres
    • Fecha y hora de inicio y finalización del paso
    • Duración (en segundos)
  • Nombre y correo electrónico del operador de revisión manual.
  • Parámetros de registro del documento y de la transacción.
El Warehouse no almacena información sobre eventos de procesamiento de documentos en actividades que nunca se ejecutan según su configuración. Por ejemplo, la configuración Assemble by files corresponde al comportamiento predeterminado de Vantage, por lo tanto, el procesamiento de documentos en esta actividad se omitirá en el flujo de trabajo.

​
Diferencias de comportamiento entre v1 y v2

Antes de migrar, es importante entender que v1 y v2 difieren en algo más que la estructura de la API: por diseño, definen el período de generación de informes de forma distinta. Al comparar ambas versiones, espere totales diferentes, no solo un formato de solicitud/respuesta distinto. v1 filtra por transacción y luego devuelve todos los pasos de esas transacciones. Si alguno de los pasos de una transacción se solapa con la ventana de filtro startDate/endDate, se devuelven todos sus pasos, incluidos los completados semanas antes de startDate o después de endDate. v2 filtra por paso. Solo se devuelven los pasos individuales cuya marca de tiempo CompletedUtc esté dentro de la ventana startDate/endDate; se excluyen los demás pasos de la transacción, incluso si otros pasos de esa misma transacción están dentro de la ventana.

​
Solicitudes síncronas frente a asíncronas

v1 consiste en una única llamada síncrona: se envía una solicitud GET con parámetros de consulta y los datos del informe se reciben directamente en la respuesta. En cambio, v2 utiliza un modelo asíncrono: se envía una solicitud, se consulta su estado y, a continuación, se descargan los resultados una vez que el informe está listo. Este cambio permite que v2 gestione solicitudes de datos mucho mayores sin que se agote el tiempo de espera. v1 está en desuso, pero los clientes pueden seguir utilizándola; actualmente no hay una fecha prevista para su retirada.

​
Alcance del período de generación de informes

Los endpoints v1 y v2 definen el período de generación de informes de forma diferente. Este comportamiento es el esperado, no un error, pero implica que los totales de ambos endpoints (o de informes v2 con intervalos de fechas distintos) no son directamente comparables.
  • v1 devuelve todos los pasos que pertenecen a cualquier transacción que estuvo activa durante el período solicitado, incluidos los pasos que tuvieron lugar fuera de las fechas de inicio y fin del período. Por ejemplo, si una transacción comenzó antes del inicio del período o finalizó después de su término, v1 sigue devolviendo todos los pasos de esa transacción.
  • v2 devuelve solo los pasos que realmente tuvieron lugar dentro del período solicitado. Se excluyen los pasos que quedan fuera del intervalo startDate/endDate, incluso si pertenecen a una transacción que se encuentra parcialmente dentro del período.
Por lo tanto, la migración de v1 a v2 puede generar totales inferiores o diferentes para el mismo intervalo de fechas nominal, ya que v2 deja de incluir los pasos que quedan fuera del intervalo.
Como v2 filtra según el valor de CompletedUtc de cada paso, cada paso pertenece exactamente a una ventana temporal, independientemente de cómo se divida el intervalo: un conjunto de informes diarios sumará el mismo total que un informe que cubra el intervalo equivalente de varios días. Esto supone una mejora importante con respecto a v1, donde la inclusión de un paso depende de si su transacción estuvo activa durante la ventana, y no de la hora de finalización del propio paso. Por ello, no se garantiza que los totales de v1 sumen lo mismo al dividir el intervalo de distintas maneras. Un aspecto que debe tener en cuenta con v2 es que, si los pasos de una transacción abarcan el límite entre dos días, aparecerán en dos informes diarios distintos, uno por cada día, en lugar de aparecer todos juntos en uno de ellos.

​
El filtrado por fecha se basa en completedUtc

En el endpoint v2, tanto startDate como endDate filtran en función de la marca de tiempo CompletedUtc de cada paso, no de ninguna hora de inicio o finalización a nivel de transacción. Como cada paso de una transacción (por ejemplo, Input, Classification, Extraction, revisión manual, Actividad Output) tiene su propio valor CompletedUtc, los pasos de una misma transacción pueden abarcar distintas fechas. Cada paso se evalúa y se incluye o excluye de forma independiente, basándose únicamente en su propia hora de finalización. Si un paso de una transacción se reprocesa, se corrige, vuelve a pasar por revisión manual o se reintenta por cualquier motivo, su CompletedUtc se actualiza con la nueva hora de finalización. En v2, esto solo afecta a los resultados cuando endDate de la consulta está en el futuro; es decir, cuando el intervalo sigue abierto. Una vez que endDate de una consulta está en el pasado, sus resultados son estables: el reprocesamiento asigna a un paso la hora actual, que por definición es posterior a un intervalo ya cerrado, por lo que no puede incluirse ni excluirse retroactivamente de ese informe.

​
En los resultados de v2 solo aparecen los pasos completados

Una exportación de v2 devuelve únicamente los pasos que se han completado. Un paso que aún está en curso, como uno con el estado Processing, no tiene valor de CompletedUtc, por lo que la exportación lo omite. El paso aparecerá en una exportación posterior cuyo rango de fechas incluya su hora de finalización. v1 devuelve todos los pasos de una transacción que estuvo activa durante el período, por lo que un informe de v1 puede seguir incluyendo pasos en curso. En un informe de v1, compruebe el Status de cada paso antes de considerarlo completado. Un caso de uso habitual es generar informes sobre las transacciones del día anterior. Para ello, use v2, con startDate y endDate establecidos en el intervalo UTC de 00:00:00–23:59:59 del día anterior. Dado que v2 filtra según el CompletedUtc de cada paso, devuelve exactamente los pasos que se completaron ese día, lo que permite obtener totales diarios claros y coherentes. Evite usar v1 para este fin. Como v1 devuelve todos los pasos de cualquier transacción que estuvo activa durante el intervalo, una transacción con pasos completados semanas antes o después del día objetivo se devuelve íntegramente, incorporando pasos no relacionados a cifras que deberían corresponder a un único día. Tenga en cuenta una contrapartida del enfoque v2: los pasos de una transacción que abarque la medianoche se dividirán entre dos informes diarios, uno para cada día, en lugar de aparecer íntegramente en uno de ellos. Esto es lo esperado; consulte el alcance del período de generación de informes anterior. Siempre que endDate corresponda a un día que ya haya finalizado por completo, el informe será estable y reproducible: volver a ejecutar la misma consulta más adelante devolverá los mismos resultados. En cambio, si consulta un intervalo que incluya el día actual, que aún está en curso, los resultados pueden cambiar entre ejecuciones a medida que se completen más pasos (consulte El filtrado por fecha se basa en CompletedUtc anterior).

​
Migración de v1 a v2

​
¿Qué hay de nuevo?

En la solicitud (/api/reporting/v2/exports/transaction-steps):
  • Los filtros se han trasladado de los parámetros de consulta al cuerpo de la solicitud (objeto JSON filters).
  • startDate, especificado dentro del objeto filters, ahora es obligatorio.
  • Campo nuevo: sendEmailNotification (true/false): envía un correo electrónico al usuario que solicitó el informe cuando el informe esté listo para descargar.
En los archivos CSV descargados del resultado final (/api/reporting/v2/exports/transaction-steps/{{requestId}}/result/{fileIndex}), se han añadido dos columnas:
  • DocumentsCount: el número de documentos procesados en una transacción.
  • PagesCount: el número de páginas procesadas en una transacción.

​
Diferencias en el uso de la API

v1 utiliza una única solicitud GET con parámetros de consulta y devuelve el informe directamente. v2 traslada los filtros al cuerpo de una solicitud POST y divide el proceso en tres llamadas: solicitar el informe, consultar su estado y descargar los resultados cuando esté listo. Continúe leyendo para obtener más información sobre cómo funciona el endpoint v2.

​
Descarga de un informe de datos

Solo los usuarios con los roles de Tenant Administrator y Processing Supervisor pueden descargar un informe de datos desde Warehouse. Para obtener más información, consulta la sección Control de acceso basado en roles.
Puedes obtener datos de Warehouse en un archivo CSV mediante la Vantage API. Para hacerlo, envía una solicitud POST al siguiente recurso: El cuerpo de la solicitud debe incluir las siguientes propiedades dentro de un objeto filters:
  • skillId. El ID de la skill cuyas transacciones se deben descargar. Opcional.
  • transactionId. El ID de la transacción por la que se debe filtrar. Opcional.
  • startDate. El primer día del período (formato de ejemplo: 2022-01-07T13:03:38, la hora debe estar en UTC) para el cual se deben descargar las transacciones. Filtra según la marca de tiempo CompletedUtc de cada Step. Obligatorio.
  • endDate. El último día del período (formato de ejemplo: 2022-09-07T13:03:38, la hora debe estar en UTC) para el cual se deben descargar las transacciones. Filtra según la marca de tiempo CompletedUtc de cada Step. Opcional.
  • sendEmailNotification. Enviar un correo electrónico al usuario que creó la solicitud de informe para informarle que el informe está listo para descargar. Opcional.
Las solicitudes de informes se procesan de forma asíncrona, por lo que la respuesta devuelve un requestId que se utiliza para comprobar el estado de la solicitud. Resultado:
Para consultar el estado del informe, incluya el requestId en la solicitud GET: Consulte este endpoint hasta que el valor de status sea Succeeded, Failed o Cancelled. El valor de status puede ser uno de los siguientes: Vantage procesa una sola solicitud de exportación por tenant a la vez. Si envía varias solicitudes, cada una permanece en New hasta que finalicen las anteriores, por lo que puede tardar más en pasar a Processing. Si necesita varios informes, envíe cada solicitud cuando haya finalizado la anterior. Vantage cancela las solicitudes que permanecen en un mismo estado más tiempo del indicado a continuación: Si el valor de status es Failed o Cancelled, envíe una nueva solicitud más tarde. La respuesta de estado también incluye un correlationId. Indíquelo si se pone en contacto con el soporte de ABBYY por una solicitud fallida o cancelada. Cuando el valor de status es Succeeded, totalFileCount muestra el número de archivos disponibles para descargar:
Para descargar los archivos de informes resultantes, realice una solicitud GET a la siguiente dirección, pasando de nuevo el requestId y agregando el fileIndex, que es el índice del archivo (empezando por cero). Por ejemplo, si "totalFileCount": 3, los índices de archivo disponibles serán 0, 1 y 2. A continuación se muestra un ejemplo de la respuesta en formato CSV:

​
Estructura de la respuesta

Cada fila de un archivo CSV es una operación realizada sobre una transacción. Por ejemplo, la importación de documentos, el reconocimiento o la revisión manual. Para cada operación en el Warehouse, sus detalles se almacenan en columnas: Vantage conserva los archivos de resultados durante 14 días una vez completada la solicitud. Transcurrido ese plazo, elimina los archivos y la solicitud, que deja de aparecer en la lista de solicitudes de informes. Los datos obtenidos en formato CSV pueden analizarse posteriormente en cualquier herramienta de BI.

​
Recuperar una lista de solicitudes de informes

Para recuperar la lista de solicitudes de informes realizadas dentro de un período de tiempo determinado, realice una solicitud GET al siguiente endpoint, donde createdFrom y createdTo representan el intervalo de fechas y statusFilter es uno de los siguientes valores: New,Queued,Processing,Succeeded,Failed, o Cancelled. Esto es útil en caso de extravío de identificadores de solicitud. La respuesta incluye una matriz de solicitudes de generación de informes.