Descripción #
El chofer saca la fotografía en la aplicación, AsistManager la recibe, la guarda y la reenvía a la compañía como un mensaje propio.
Cada adjunto es una petición independiente. Un mismo caso puede producir varios, y no llegan agrupados: llegan de a uno, correlacionados por el identificador del caso.
task, es un avance de caso; si trae data e index, es un adjunto. Un receptor escrito solo para avances va a fallar al procesar el primer adjunto, o va a descartarlo en silencio.Los dos cuerpos que llegan al mismo punto de acceso #
{
"source": "<clave de la compañía>",
"identifier": "20260917102415733",
"alias": "prestador",
"date": "2026-09-17T11:42:08.310000-03:00",
"task": { … }
}Este es el aviso de avance, descripto en Eventos de avance y coordenadas del móvil. Se reconoce por la presencia de task.
{
"fecha": "2026-09-17T11:43:20.000000-03:00",
"source": "core",
"worker": "movil-12",
"alias": "prestador",
"identifier": "20260917102415733",
"index": "arrive-0",
"type": "image",
"data": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQ… (recortado)"
}Se reconoce por la presencia de data e index. El contenido de data está recortado en el ejemplo: en el mensaje real son decenas de miles de caracteres.
Cómo discriminar los dos mensajes #
| Si el cuerpo trae… | Es… | Cómo se correlaciona |
|---|---|---|
task | Un avance de caso | Por identifier |
data e index | Un adjunto | Por identifier |
multipart y tampoco es una dirección de descarga. El campo data contiene la imagen completa como data URI en base64, y empieza con data:image/jpeg;base64,. Sobre los adjuntos recientes medidos, el cien por ciento son JPEG. Aun así, conviene leer el tipo declarado en el propio data URI en lugar de darlo por sentado.Campos del adjunto #
| Campo | Tipo | Obligatorio | Valores posibles | Descripción |
|---|---|---|---|---|
fecha |
string | Obligatorio | ISO 8601 en hora local | Momento en que AsistManager recibió el adjunto. No es el momento en que se sacó la foto: no existe un dato de captura en el mensaje. |
source |
string | Obligatorio | <code>core</code> | Vale literalmente core y no identifica a la compañía. A diferencia del aviso de avance, acá este campo no aporta información de origen: no lo use para enrutar, filtrar ni correlacionar. |
worker |
string | Obligatorio | — | Identificador del móvil que sacó la foto o cargó el dato. Es el mismo valor que llega en Movil dentro del aviso de avance. |
alias |
string | Obligatorio | — | El prestador que está atendiendo el servicio. |
identifier |
string | Obligatorio | — | El identificador del caso. Es la única clave de correlación: es lo que permite saber a qué servicio pertenece el adjunto. |
index |
string | Obligatorio | — | Dónde está codificado el paso al que corresponde el adjunto. No hay un campo aparte que lo indique. Los valores se detallan más abajo. |
type |
string | Obligatorio | <code>image</code> · <code>audio</code> · <code>text</code> · <code>field</code> | Qué clase de contenido trae data. No todo lo que se reenvía es una imagen. |
data |
string | Obligatorio | — | El contenido. Con type igual a image es un data URI en base64; con los demás tipos es texto plano. |
El paso está codificado en index #
El mensaje no tiene un campo que diga a qué momento del servicio corresponde la foto. Eso se lee del valor de index, que sigue cuatro formas.
Formas del campo index #
| Forma | Ejemplos | Qué es |
|---|---|---|
arrive-<n> | arrive-0 · arrive-1 | Fotografías del arribo. El número es el orden dentro de ese paso. |
finish-<n> | finish-0 · finish-1 | Fotografías del cierre del servicio. |
<evento>-<categoría>-<n> | arrive-portico-0 | Capturas exigidas por una regla de captura obligatoria, con la categoría en el medio. |
| Solo un número | 0 · 1 · 2 | Adjuntos del flujo anterior: no tienen paso asociado. Se siguen recibiendo y hay que contemplarlos. |
type igual a audio, text o field, el campo data trae texto plano y no un data URI de imagen. Un receptor que asuma que data siempre empieza con data:image/ va a romperse o va a guardar basura. Compruebe type antes de procesar el contenido.Tamaños #
Sobre los adjuntos medidos, la cadena en base64 va de 7 KB a 70 KB, con una mediana de 26 KB. Eso equivale aproximadamente a imágenes de 5 KB a 52 KB, porque el base64 agrega alrededor de un tercio al tamaño original.
AsistManager no impone un límite de tamaño ni una cantidad máxima de adjuntos por caso. El techo lo pone la aplicación, que comprime la imagen antes de subirla. Conviene dimensionar el receptor con esos valores como referencia, no como garantía contractual.
Entrega y reintentos #
Los adjuntos usan exactamente la misma política que los avisos de avance: éxito con HTTP 2xx, la misma cadencia de reintentos y caducidad a los 5 días. Está descripta en detalle en Entrega y reintentos, dentro del documento de eventos de avance. Vale también acá lo que se dice allí sobre los códigos 4xx: dos respuestas 4xx que no sean 408 ni 429 descartan el adjunto, mientras que un 5xx sostiene el reintento durante los cinco días.
Errores frecuentes #
Los reclamos más habituales sobre adjuntos se explican por alguno de estos puntos.
| Código | Qué se ve | Causa | Cómo se resuelve |
|---|---|---|---|
Error de análisis |
El receptor falla al procesar un mensaje en el punto de acceso de avances | Llegó un adjunto y el receptor esperaba task. |
Discriminar por presencia de clave: task es avance, data e index es adjunto. |
Adjuntos huérfanos |
Llegan adjuntos que no se pueden asociar a ningún caso | Se está intentando correlacionar por source, que vale siempre core. |
Correlacionar por identifier. Es la única clave válida para eso. |
Contenido ilegible |
Se guarda un archivo que después no abre | Se procesó como imagen un adjunto con type igual a text, audio o field, cuyo data es texto plano. |
Verificar type antes de decodificar, y leer el tipo declarado dentro del propio data URI. |
Fotos sin paso |
Algunos adjuntos no se pueden clasificar en arribo o cierre | El index trae solo un número. Son adjuntos del flujo anterior, sin paso asociado. |
Contemplar esa forma y clasificarlos como sin paso en lugar de rechazarlos. |
Horario que no cierra |
La hora del adjunto no coincide con la del arribo | fecha es el momento de recepción en AsistManager, no el de la captura. |
Usar los campos Hora* del caso para ubicar el momento operativo. No existe un dato de captura en el adjunto. |
Adjuntos perdidos |
Después de una caída propia faltan fotografías | El receptor respondió 4xx durante la caída y el adjunto se descartó. | Responder 5xx ante una falla temporal. Con 5xx se reintenta durante cinco días. |
Compatibilidad #
| Componente | Desde | Estado | Nota |
|---|---|---|---|
| Adjunto con imagen embebida en base64 | En producción |
vigente | El cien por ciento de los adjuntos recientes medidos son JPEG. |
| <code>index</code> con <code>arrive-<n></code> y <code>finish-<n></code> | En producción |
vigente | Es la forma habitual del flujo actual. |
| <code>index</code> con categoría intermedia | En producción |
vigente | Aparece cuando hay reglas de captura obligatoria definidas para el caso. |
| <code>index</code> con un número suelto | Histórico |
Deprecado | Flujo anterior, sin paso asociado. Se sigue recibiendo: hay que contemplarlo. |
| Adjuntos con <code>type</code> distinto de <code>image</code> | En producción |
vigente | Con audio, text y field el campo data es texto plano. |