Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Migrar desde TomTom Search
TomTom Search aparece con mucha frecuencia en software de automoción, gestión de flotas y navegación, sectores en los que la precisión de la geocodificación a lo largo de una ruta importa tanto como la simple coincidencia de direcciones. Su clave de API se envía como parámetro de consulta, y sus respuestas de geocodificación llegan como un array results con un objeto position y un bloque address que contiene campos como freeformAddress y municipality.
El software de este sector suelen crearlo equipos que no eligieron TomTom a la ligera; la decisión normalmente vino ya acompañada de una evaluación frente a alternativas, lo que significa que una migración posterior suele estar motivada por el coste, la planificación de redundancia o un esfuerzo más amplio de consolidación de proveedores, más que por insatisfacción con los datos en sí. Ese contexto importa a la hora de definir el alcance de una migración: rara vez es urgente, y suele haber tiempo para probar como es debido.
El host de compatibilidad de TomTom de My Geocode reproduce el array results, el objeto position y los campos de dirección exactamente como los devuelve TomTom, y los textos de copyright, términos y privacidad son la única diferencia. La referencia de campos está documentada en /compatibility/tomtom/. El código construido en torno a results[0].position.lat y results[0].address.freeformAddress debería seguir funcionando una vez que cambien el host y la clave.
En el caso concreto del software de flotas y automoción, conviene revisar dos veces algunas cosas antes de que el cambio pase a producción:
- Cualquier trabajo de geocodificación por lotes que se ejecute de forma programada, ya que son un buen primer objetivo para probar un nuevo host sin tocar las llamadas en tiempo real de cara al cliente
- La lógica de reintentos y tiempos de espera ajustada a los tiempos de respuesta concretos de TomTom, ya que estos valores suelen fijarse de forma empírica en lugar de documentarse y puede que haya que reajustarlos
- Cualquier código que lea campos de confianza o de calidad de coincidencia específicos de TomTom, que merecen una comparación lado a lado con los equivalentes documentados del host de compatibilidad
La autenticación admite una cabecera X-API-Key, una cabecera Authorization: Bearer, la autenticación HTTP Basic o un parámetro de consulta, lo que cubre la forma en que tu cliente actual de TomTom envía hoy su clave.
En cuanto al coste, la estructura elimina el habitual paso de negociación empresarial: 2.500 solicitudes al día son gratuitas sin necesidad de clave, y cada clave añade sus propias 2.500 solicitudes gratuitas al día, contadas por red. Superada esa cuota, se usa crédito prepago a 0,0001 € por solicitud o una clave Unlimited a 50 € al mes, y todos los endpoints, incluido este host de compatibilidad, tienen exactamente el mismo precio. Para una operación de flotas que realiza geocodificación a un volumen considerable, tener una única tarifa plana en lugar de un acuerdo empresarial por niveles simplifica bastante la previsión de costes.
Si tu uso de TomTom también incluye datos de rutas o de tráfico además de la geocodificación, esa parte de la pila queda fuera del alcance de una migración solo de geocodificación y puede seguir en TomTom mientras las llamadas de búsqueda de direcciones se trasladan de forma independiente. Dividir una migración siguiendo límites claros entre funciones, como en este caso, suele reducir más el riesgo que intentar moverlo todo en una sola versión.