← Blog técnico

SAP SuccessFactors Integration

SuccessFactors: OData, CompoundEmployee ou Integration Center para cada integração

Os três caminhos podem mover dados do SuccessFactors, mas não resolvem o mesmo problema. A escolha certa depende do contrato de dados, frequência, destino e responsabilidade operacional.

SuccessFactorsODataCompoundEmployeeIntegration Center

Projetos de integração de RH costumam começar pela ferramenta: “vamos usar OData” ou “vamos exportar um arquivo pelo Integration Center”. O problema surge quando essa escolha acontece antes de definir se o consumidor precisa de uma entidade, do registro hierárquico do colaborador ou de uma extração programada.

OData, CompoundEmployee e Integration Center também não são três produtos equivalentes. OData e CompoundEmployee são interfaces com contratos diferentes; Integration Center é uma capacidade guiada que usa o catálogo de dados do SuccessFactors para construir e operar integrações simples.

1) Defina o contrato antes de escolher a API

Documente primeiro cinco decisões: quais dados o destino precisa, se o fluxo lê ou escreve, qual latência aceita, como reconhecerá mudanças e quem atenderá falhas. Inclua cenários com datas efetivas, correções retroativas, recontratações, atribuições globais e desligamentos; no Employee Central, o registro “atual” raramente conta toda a história.

Regra prática: uma extração diária para folha, uma consulta pontual de cargo e uma atualização de objeto MDF não devem compartilhar um mecanismo apenas para reduzir o número de tecnologias.

2) OData: precisão por entidade e operações de API

As APIs OData do Employee Central expõem entidades de pessoa e emprego, foundation objects e objetos MDF. Elas são adequadas quando o consumidor conhece a entidade necessária, precisa de filtros e seleção de campos, navega relações controladas ou deve criar e atualizar dados onde a entidade permite.

Essa flexibilidade exige desenho. Expansões amplas podem gerar payloads caros; paginação, limites, permissões e comportamento de objetos com datas efetivas devem ser testados por entidade. Também não se deve assumir que uma regra da interface do usuário será executada da mesma forma em uma chamada API.

  • Use para: consultas dirigidas, integrações próximas de tempo real, objetos MDF, catálogos e write-back autorizado.
  • Evite como atalho para: reconstruir todo o registro laboral com dezenas de chamadas sem um modelo de consistência.

3) CompoundEmployee: replicação hierárquica do colaborador

CompoundEmployee é uma API SOAP desenhada para extrair dados mestres do Employee Central. Ela retorna a pessoa como nó raiz e agrupa segmentos suportados —emprego, dados pessoais, informações de cargo, remuneração e outros— em uma resposta XML hierárquica.

Sua força está na replicação para SAP HCM, folha, benefícios ou outros consumidores que precisam de uma visão composta do colaborador. Ela oferece modos snapshot e delta, e o consumo é desenhado em torno de query/queryMore, timestamps, action codes e time slices; não é uma API genérica de escrita.

  • Use para: replicação de employee master data e processamento consistente de mudanças efetivas ou retroativas.
  • Valide antes: segmentos e campos suportados, volume, janela de delta, paginação e como o destino tratará inclusões, mudanças e exclusões.

4) Integration Center: velocidade para cenários simples e programados

Integration Center permite construir, executar, programar e monitorar integrações simples por um fluxo guiado. É útil para extrações configuráveis para arquivos ou serviços, transformações leves e cargas CSV quando o caso não justifica desenvolver e operar um fluxo de middleware.

Velocidade não elimina limites. Várias fontes, orquestração, ramificações complexas, estado durável, alto volume, contratos versionados ou recuperação sofisticada pertencem a uma camada como SAP Integration Suite. A equipe também deve validar na documentação da versão quais protocolos, formatos e gerações de OData o Integration Center suporta.

5) Matriz de decisão

Necessidade dominanteOpção inicialRazão
Consultar ou atualizar uma entidade específicaODataContrato por entidade, filtros e operações API
Replicar employee master data hierárquicoCompoundEmployeeSegmentos relacionados, time slices e modos de transmissão
Exportação simples e programada para arquivo ou endpointIntegration CenterConfiguração guiada, agenda e monitoramento integrado
Orquestração entre sistemas e regras complexasMiddleware + API adequadaEstado, observabilidade, retentativas e governo fora do extrator
Cenário misto de RHCombinação deliberadaCada interface mantém uma responsabilidade limitada

6) Delta é mais do que um filtro de data

Um watermark de “última execução” é insuficiente se o processo ignora datas efetivas, mudanças futuras ou correções retroativas. O consumidor deve guardar evidência do intervalo processado, usar sobreposição controlada e ser idempotente para repetir uma janela sem duplicar efeitos.

CompoundEmployee oferece semântica específica de delta, enquanto a estratégia OData depende da entidade e de seus campos de modificação. A arquitetura também precisa de reconciliação: contagens, casos sem correspondência e uma forma de reconstruir o estado após perder uma janela. Veja o guia relacionado sobre deltas e idempotência no SuccessFactors.

7) Segurança e permissões mudam o resultado

A mesma consulta pode devolver dados diferentes conforme as permissões do usuário técnico. Use contas de integração, Role-Based Permissions de menor privilégio, rotação de credenciais e separação por ambiente; evite credenciais pessoais e payloads mais amplos que o contrato de negócio.

Um campo ausente nem sempre significa dado ausente: a interface escolhida pode não suportá-lo, a consulta pode não selecioná-lo ou as permissões podem ocultá-lo. O diagnóstico deve distinguir essas causas antes que alguém “corrija” o registro de origem.

8) Desenhe operação e testes antes do go-live

  1. Inventariar entidades, segmentos, campos sensíveis e sistemas de registro.
  2. Testar contratação, mudança futura, correção retroativa, desligamento e recontratação.
  3. Definir paginação, checkpoints, retentativas e idempotência.
  4. Registrar correlation ID, janela processada, resultado e motivo de rejeição.
  5. Conciliar totais e exceções com owner e SLA.
  6. Documentar quando executar uma recarga completa e como evitar efeitos duplicados.

9) Uma arquitetura pode usar as três opções

Não há vantagem em forçar todas as integrações por uma única interface. Uma empresa pode usar CompoundEmployee para replicar dados mestres para a folha, OData para consultar objetos específicos em uma aplicação e Integration Center para uma exportação programada de baixa complexidade.

Um desenho maduro mantém contratos pequenos e ownership visível. Se o landscape combina SuccessFactors, HCM, folha e aplicações externas, uma arquitetura de integração SuccessFactors deve declarar qual mecanismo responde por cada fluxo e como ele se recupera de falhas.

OData, CompoundEmployee ou Integration Center foram escolhidos por hábito?

Podemos revisar contratos, datas efetivas, volumes e operação para definir uma integração sustentável entre SuccessFactors, SAP HCM, folha e sistemas externos.

Revisar a arquitetura de RH