Por mariogarcia El síntoma: clientes que faltaban
El proyecto era sincronizar clientes de Salesforce hacia JD Edwards cada noche. La primera versión funcionaba… a medias. Ventas empezó a reportar clientes que existían en Salesforce pero no aparecían en JDE. No todos, solo algunos. Sin patrón aparente. Ese tipo de fallo intermitente es el peor de resolver, porque el primer instinto es dudar de los datos, no de la integración. 
Causa raíz #1: la paginación de Salesforce
La API REST de Salesforce no te devuelve todo de una vez. Te da un primer lote de registros y un puntero (nextRecordsUrl) para pedir el siguiente. Mi primer Custom Request solo estaba leyendo ese primer lote y dando el resultado por completo. Si el batch de clientes nuevos era pequeño, coincidía por casualidad con el tamaño de una sola página y todo cuadraba. Si era grande, se quedaba fuera todo lo que venía después de la primera página, sin que la orquestación reportara ningún error -porque, para ella, la llamada había sido un éxito total.
El intento de arreglo: la orquestación recursiva
La solución evidente era que la orquestación se llamara a sí misma mientras Salesforce siguiera devolviendo un nextRecordsUrl. La construí, la probé en el diseñador, funcionaba. El problema llegó al intentar compartirla como UDO.
Causa raíz #2: el bucle que no me dejaba guardar
Al añadir las dependencias del objeto para poder compartirlo, la orquestación se referenciaba a sí misma como parte de su propio árbol de dependencias. El proceso de resolución de dependencias entró en un bucle infinito -no en tiempo de ejecución, sino al intentar guardar y compartir el objeto-. La pantalla se quedaba colgada calculando dependencias que nunca terminaban de resolverse. No pude compartir la orquestación aunque funcionara perfectamente en pruebas. El problema real ya no era la paginación: era que Orchestrator no sabe manejar una orquestación que se referencia a sí misma dentro de su propia lista de dependencias.
La solución real: array en Groovy + iteración de Rule
Descarté la recursividad por completo. En su lugar:
- Se realiza la primera llamada que nos regresa el total faltante.
- Un Custom Java en Groovy lee el total de registros y el tamaño de página, y calcula de antemano cada URL de página exacta que hay que cuantas veces hay que llamar -sin depender de que la propia orquestación siga su propio rastro.
- Ese cálculo se entrega como un array simple
- Una Rule con iteración nativa recorre ese array y hace cada llamada a la API en su turno, acumulando los resultados.
Sin recursividad no hay autorreferencia, y sin autorreferencia no hay bucle de dependencias que resolver. La orquestación se guarda y se comparte sin problema, y de paso el número de llamadas queda fijo y calculado antes de la primera petición real.
El impacto en negocio
Antes de esto, alguien en ventas revisaba manualmente Salesforce contra JDE dos o tres veces por semana para detectar clientes faltantes -unas 3-4 horas semanales, y aun así se escapaban casos hasta que un pedido fallaba por cliente inexistente. Hoy la sincronización corre cada noche, trae el cien por cien de los clientes nuevos o modificados, y nadie tiene que cruzar listas a mano.
La lección
Cuando algo no funciona en Orchestrator, hay que separar dos preguntas que se sienten como una sola: ¿falla al ejecutarse, o falla al intentar guardarse/compartirse? Son dos clases de error completamente distintas, y confundirlas te hace perseguir la causa equivocada durante días.