En proyectos de recursos humanos es común empezar por la herramienta: “hagámoslo con OData” o “saquemos un archivo desde Integration Center”. El problema aparece cuando esa elección se toma antes de definir si el consumidor necesita una entidad puntual, el expediente jerárquico del empleado o una extracción programada.
OData, CompoundEmployee e Integration Center tampoco son tres productos equivalentes. OData y CompoundEmployee son interfaces con contratos distintos; Integration Center es una capacidad guiada que utiliza el catálogo de datos de SuccessFactors para construir y operar integraciones sencillas.
1) Primero define el contrato, no la API
Antes de elegir, documenta cinco decisiones: qué datos necesita el destino, si la integración lee o escribe, qué latencia acepta, cómo reconocerá cambios y quién atenderá fallas. Agrega escenarios de fechas efectivas, correcciones retroactivas, recontrataciones, asignaciones globales y bajas; en Employee Central, el registro “vigente” rara vez cuenta toda la historia.
2) OData: precisión por entidad y operaciones API
Las APIs OData de Employee Central exponen entidades de persona, empleo, foundation objects y objetos MDF. Son adecuadas cuando el consumidor conoce la entidad que necesita, requiere filtros y selección de campos, navega relaciones controladas o debe crear y actualizar datos donde la entidad lo permite.
Su flexibilidad exige diseño. Consultas con expansiones amplias pueden producir payloads costosos; la paginación, los límites, los permisos y el comportamiento de objetos con fechas efectivas deben probarse por entidad. Tampoco se debe asumir que una regla de interfaz de usuario se ejecutará igual durante una llamada API.
- Úsalo para: consultas dirigidas, integraciones cercanas a tiempo real, objetos MDF, catálogos y write-back autorizado.
- Evítalo como atajo para: reconstruir todo el expediente laboral con decenas de consultas sin un modelo claro de consistencia.
3) CompoundEmployee: replicación jerárquica del empleado
CompoundEmployee es una API SOAP orientada a extraer datos maestros de Employee Central. Devuelve a la persona como nodo raíz y agrupa segmentos relacionados —empleo, información personal, puesto, compensación y otros datos soportados— en una respuesta XML jerárquica.
Su fortaleza está en la replicación hacia SAP HCM, nómina, beneficios u otros consumidores que necesitan una vista compuesta del empleado. Soporta modos snapshot y delta, y el consumo se diseña alrededor de query/queryMore, marcas de tiempo, action codes y time slices; no es una API genérica de escritura.
- Úsalo para: replicación de employee master data y procesamiento coherente de cambios efectivos o retroactivos.
- Valida antes: segmentos y campos soportados, volumen, ventana de delta, paginación y cómo procesará el destino altas, cambios y eliminaciones.
4) Integration Center: velocidad para escenarios simples y programados
Integration Center permite construir, ejecutar, programar y monitorear integraciones sencillas mediante un flujo guiado. Resulta útil para extracciones configurables hacia archivos o servicios, transformaciones ligeras y cargas CSV cuando el caso no justifica desarrollar y operar un flujo de middleware.
La rapidez no elimina límites. Cuando hay varias fuentes, orquestación, ramas complejas, estado duradero, alto volumen, contratos versionados o una recuperación sofisticada, conviene trasladar la responsabilidad a una capa como SAP Integration Suite. También se debe validar en la documentación de la versión qué protocolos, formatos y generaciones de OData soporta Integration Center.
5) Matriz de decisión
| Necesidad dominante | Opción inicial | Razón |
|---|---|---|
| Consultar o actualizar una entidad específica | OData | Contrato por entidad, filtros y operaciones API |
| Replicar employee master data jerárquico | CompoundEmployee | Segmentos relacionados, time slices y modos de transmisión |
| Exportación simple y programada a archivo o endpoint | Integration Center | Configuración guiada, agenda y monitoreo integrado |
| Orquestación entre varios sistemas y reglas complejas | Middleware + API adecuada | Estado, observabilidad, reintentos y gobierno fuera del extractor |
| Escenario mixto de HR | Combinación deliberada | Cada interfaz conserva una responsabilidad acotada |
6) El delta no es sólo un filtro de fecha
Un watermark de “última ejecución” no basta si el proceso ignora fechas efectivas, cambios futuros o correcciones retroactivas. El consumidor debe guardar evidencia del intervalo procesado, definir solapamiento controlado y ser idempotente para repetir una ventana sin duplicar movimientos.
CompoundEmployee ofrece semántica de delta específica, mientras que con OData la estrategia depende de la entidad y sus campos de modificación. La arquitectura debe incluir reconciliación: conteos, casos sin correspondencia y una forma de reconstruir el estado cuando se pierde una ventana. Este tema se desarrolla en deltas e idempotencia en SuccessFactors.
7) Seguridad y permisos cambian el resultado
El mismo query puede devolver resultados diferentes según los permisos del usuario técnico. Usa cuentas de integración, Role-Based Permissions de mínimo privilegio, rotación de credenciales y separación por ambiente; evita credenciales personales y payloads más amplios de lo necesario.
La ausencia de un campo no siempre significa que no exista: puede no estar soportado por la interfaz elegida, no estar seleccionado o quedar fuera del alcance de permisos. Esa distinción debe formar parte del diagnóstico para no convertir un problema de autorización en una “corrección” de datos.
8) Diseña operación y pruebas antes del primer go-live
- Inventariar entidades, segmentos, campos sensibles y sistema de registro.
- Probar contratación, cambio futuro, corrección retroactiva, terminación y recontratación.
- Definir paginación, checkpoints, reintentos e idempotencia.
- Registrar correlation ID, ventana procesada, resultado y causa de rechazo.
- Conciliar totales y excepciones con un owner y SLA.
- Documentar cuándo ejecutar una recarga completa y cómo evitar dobles efectos.
9) Una arquitectura puede usar las tres opciones
No existe premio por estandarizar todas las integraciones en una sola interfaz. Una empresa puede usar CompoundEmployee para replicar el maestro hacia nómina, OData para consultar objetos específicos desde una aplicación e Integration Center para una exportación programada de baja complejidad.
La decisión madura mantiene contratos pequeños y ownership visible. Si el landscape ya mezcla SuccessFactors, HCM, payroll y aplicaciones externas, una arquitectura de integración SuccessFactors debe hacer explícito qué mecanismo responde por cada flujo y cómo se recupera cuando algo falla.