As oito perguntas que um FSD nunca responde

Um documento de especificação funcional de integração raramente está errado. O problema é outro: ele está incompleto de um jeito que não se vê. As dez páginas descrevem o objetivo, os sistemas, a frequência, a volumetria e uma tabela de mapeamento de campos. Tudo verdadeiro. E ainda assim, entre o documento aprovado e o iFlow funcionando existe uma dúzia de decisões que alguém vai tomar sozinho, no teclado, sem registrar.

Essas decisões são a origem da maior parte do retrabalho de um projeto de integração. Não porque foram mal tomadas — em geral são razoáveis — mas porque foram tomadas por quem não tinha a informação, e ninguém soube que elas foram tomadas.

As oito lacunas

A lista abaixo é o que aparece com mais frequência quando se lê um FSD procurando pelo que não está lá. Use como roteiro de leitura antes da primeira linha de configuração.

1. Qual o mecanismo de autenticação de cada ponta?

O documento diz “consumir a API OData do SuccessFactors” e “enviar via SOAP para o S/4HANA”. Não diz se é OAuth2 com SAML Bearer, Basic, certificado de cliente ou token gerenciado. Cada resposta muda o adapter, o material de segurança a ser criado no tenant e quem precisa ser acionado do lado do cliente — normalmente uma pessoa diferente, com prazo próprio.

2. Qual o critério de seleção na origem?

“Enviar os colaboradores a cada hora” não diz se são todos, apenas os modificados desde a última execução, ou os de um conjunto específico. Se for delta, falta dizer com base em quê: um campo de data de modificação, um status, uma tabela de controle. Sem isso não é possível montar a query OData nem garantir que a mesma mensagem não será reprocessada.

3. Como tratar o volume?

“Até 2.000 registros por execução” é volumetria, não estratégia. Falta dizer se vai tudo num payload só, se há paginação na origem, se o destino aceita lote e de que tamanho. Um splitter acrescentado depois muda o desenho do fluxo inteiro, não é um ajuste de parâmetro.

4. Qual é o contrato exato do destino?

“Serviço SOAP de Employee Replication” é um rótulo funcional. O que se precisa é do WSDL, do nome da operação e do endpoint — e da resposta esperada. Sem o contrato, o mapeamento é feito contra uma estrutura imaginada, e a primeira execução real vira uma rodada de correção de nomes de campo.

5. O que significa “campo não usado” no mapeamento?

Tabelas de mapeamento trazem linhas marcadas com NA, - ou “não usado”. Ambíguo: o campo deve ser descartado na transformação, ou enviado vazio ao destino? São comportamentos diferentes, e o destino costuma tratar ausência e vazio de formas diferentes também.

6. O que a coluna de observação quer dizer, tecnicamente?

“Formato YYYY-MM-DD”, “concatenar com o sobrenome”, “somente quando status = ativo”. Essas notas descrevem transformações que ninguém especificou como implementar — e que costumam ser esquecidas porque parecem detalhe de formatação. Cada uma precisa virar uma regra explícita no XSLT ou no mapeamento, com origem declarada.

7. O que acontece quando a política de retry se esgota?

“Retry 3x com intervalo de 5 minutos” descreve metade do comportamento. Falta a outra metade: depois da terceira tentativa, retorna erro HTTP ao chamador? Persiste em Data Store para reprocessamento manual? Manda para uma fila morta? Notifica? Sem essa resposta, o que se entrega é um fluxo que desiste em silêncio.

8. Quem recebe o alerta — e a partir de qual severidade?

“Notificar por e-mail em caso de erro” não diz quem, nem se toda falha vira e-mail. Uma integração de 2.000 registros por hora com alerta por mensagem transforma a caixa de entrada do time em ruído em uma semana, e o alerta perde a função exatamente quando começa a importar.

Por que as lacunas passam

Não é desleixo de quem escreve. Um FSD é escrito por quem conhece o processo de negócio, e as oito perguntas acima são de arquitetura técnica. Quem redige descreve corretamente o que a empresa precisa; as decisões que faltam simplesmente não fazem parte do vocabulário do documento.

O ponto de falha é a passagem de bastão. O documento é aprovado como “completo” porque está completo no plano dele, e a etapa seguinte começa tratando-o como especificação técnica, que ele nunca foi.

O que fazer, na prática

A intervenção que mais rende é barata: separe o que está escrito do que foi inferido, por escrito, antes de começar.

• Monte a lista de campos e, ao lado de cada um, a origem da informação: a linha do documento de onde ela saiu. O que não tiver origem não é requisito, é suposição sua.
• Liste as perguntas em aberto explicitamente, no mesmo lugar do escopo — não num e-mail, não numa conversa. Elas vão sobreviver à troca de consultor.
• Para cada pendência, decida o que fazer enquanto não houver resposta: parâmetro externalizado é quase sempre melhor que valor cravado, porque troca sem novo deploy.
• Reapresente a lista ao autor do FSD. O objetivo não é cobrar; é colocar a decisão na mão de quem tem a informação.

Nenhuma dessas etapas exige ferramenta. O que uma ferramenta muda é o custo: fazer isso à mão para um workbook com dezenas de abas é trabalhoso o bastante para ser pulado sob pressão de prazo — que é exatamente quando pular custa mais caro.

Onde isso encosta no que construímos

A importação de FSD do iFlowMind lê o documento — Word, PDF, Markdown ou planilha, aba por aba — e devolve o escopo com duas coisas ao lado de cada informação: a citação do trecho de onde ela saiu, e a lista do que o documento não responde. Em um FSD real de replicação de colaboradores, essa lista tem oito itens — coincidentemente, os mesmos oito acima.

O que a ferramenta deliberadamente não faz é preencher a lacuna. Um campo sem origem no documento não aparece preenchido; uma pendência vira parâmetro externalizado e fica visível na tela. É a mesma disciplina descrita aqui — só que sem depender de alguém ter tempo de aplicá-la.

Leia também: A falha silenciosa: quando o iFlow não erra, apenas para.