SuccessFactors Employee Central: deltas e idempotência para integrações estáveis

Employee Central é um sistema com datas efetivas. Isso muda o design: puxar o “estado atual” não basta. Você precisa de uma estratégia consistente de deltas, idempotência e reconciliação.

1) Defina o contrato: o que “delta” significa na sua integração

Em projetos reais, “delta” costuma significar coisas diferentes para cada pessoa. Deixe explícito:

Delta por entidade: quais objetos entram (empregado, job info, comp info, dependentes etc.).
Delta por tempo: janela (por exemplo, mudanças desde o último corte) e como lidar com retroativos.
Ordem: se o target exige sequência (por exemplo, admissões antes de movimentos).

Sem contrato, o time “corrige casos” e o custo aparece em suporte, não na entrega.

2) Datas efetivas: não perca mudanças futuras ou retroativas

Mudanças futuras e correções retroativas são normais em RH. O design precisa responder:

O que acontece com movimentos futuros: você replica imediatamente, ou mantém pendente até a vigência?
Como tratar correções retroativas: sobrescrever, emitir um ajuste, ou recalcular fora do middleware?
Que evidência mínima você guarda para explicar por que o target mudou?

Regra prática: se você não consegue explicar recontratações, desligamentos futuros e ajustes retroativos, a integração ainda não está pronta para produção.

3) Idempotência: seguro contra duplicados em retentativas e replay

Em produção, você vai retentar. Também vai fazer replay por correções ou incidentes. Para evitar duplicados, desenhe uma chave de idempotência reprodutível:

Chave estável: employeeId + entidade + data efetiva + tipo de operação (conforme o contrato).
Estado mínimo: o que já foi aplicado e com qual versão do payload (hash/fingerprint sem dados sensíveis).
Comportamento: quando chega um evento repetido, descarta, compara ou atualiza?

No SAP Integration Suite / CPI, isso normalmente vira um passo de deduplicação antes de chamar o target e um padrão de replay controlado com evidências claras.

4) Reconciliação: seu plano de suporte, não um “relatório final”

Reconciliação não deveria ser uma planilha no fim do projeto. Deve ser operacional:

Contagens por entidade e por faixas de datas efetivas.
Diferenças por chaves (faltantes/sobrando) e por status.
Um caminho de correção: retentar, replay ou ajuste manual com evidência.

5) Governança mínima: o que documentar para que suporte não dependa de “uma pessoa”

Para cada integração, mantenha evidência mínima:

Contrato de delta (o que muda e como).
Chave de idempotência e comportamento para duplicados.
Runbook: monitoramento, erros comuns, retentativas e replay.
Reconciliação: o que comparar e com que frequência.

Isso não substitui ferramentas SAP de lifecycle, transport management ou monitoramento runtime. É governança de middleware focada em operabilidade.