RESPOSTAS TÉCNICAS - OFÍCIO SBC

Premissas para as respostas específicas

Quebra de versão do SISBOV

• O Version Number em software geralmente segue o padrão de Versionamento Semântico (Semantic Versioning), representado por três números no formato MAJOR.MINOR.PATCH (por exemplo, 2.4.1). Nesse padrão, o MAJOR indica mudanças que quebram compatibilidade com versões anteriores, ou seja, quando APIs, contratos, estruturas de dados ou comportamentos são alterados de forma que clientes existentes podem deixar de funcionar sem adaptação; o MINOR é incrementado quando novas funcionalidades são adicionadas de forma retrocompatível, mantendo o funcionamento de integrações já existentes; e o PATCH representa correções de bugs ou ajustes internos que não alteram a interface pública do sistema. Assim, a alteração do MAJOR number sinaliza explicitamente aos consumidores da API ou biblioteca que houve uma descontinuidade de compatibilidade, justificando atualização controlada ou migração por parte dos integradores.

• O SISBOV 2.0 apresenta melhorias tecnológicas e de maior rigidez no cumprimento de regras descritas na IN51. Assim sendo, mesmo tendo portabilizado dados e processos por coerência estratégica, lógicas foram aprimoradas e fluxos de atividades foram incrementados ou alterados completamente. Em resumo muito do do legado funcionalmente foi portado, dados mantiveram-se imutáveis semântica e logicamente, porém a arquitetura de negócio se submete única e exclusivamente ao cumprimeto das regras da IN51 não mantendo compromisso operacional com a versão antecessora e, os usuários do SISBOV 2.0, web e API, devem adaptar-se ao novo cenário operacional definido e homologado pela SDA.

Utilização do UUID

• Não cabe dar nenhuma justificativa técnica sobre decisões arquiteturais tomadas pelo desenvolvimento.

• Tenha claro os níveis de normalização de dados em modelos de dados lógicos e físicos, chaves artificiais e naturais, conceitos básicos das cadeiras de Modelagem de Dados e Bancos de Dados.

• Escolha de tipo de chave primária artificial para entidades é uma decisão interna e irremediável.

• A chave natural de todas as entidades portadas do SISBOV 1 estão mantidas e é de conhecimento de todos os usuários da API.

  Entidade	Chave Natural
  Animal	numeroSISBOV
  Produtor	identificadorReceita(cpf ou cnpj)
  Desligamento	numeroSISBOV
  Usuario	cpf ou cnpj
  Propriedade	codigoEras
  Proprietario	identificadorReceita(cpf ou cnpj)
  GTA	numeroCompleto
  Certificadora	cnpj

• ABSOLUTAMENTE NENHUMA regra de negócio ou serviços de busca de dados baseados em chaves naturais foi substituído ou depreciado em detrimento à utilização de chaves artificiais.

• Alguns serviços foram implementados em duas versões(serviços simplificados com parâmetros que são chaves naturais) de forma a facilitar a utilização para quem não está ambientado ao uso de chaves artificiais.

• Todos os endpoints possuem serviço de busca pela chave natural e chave artificial

• Estratégia: A chave artificial é retornada em algumas das operações da API, quando esta for pré-requisito para utilização em outro serviço. É facultado à certificadora analisar se deseja armazenar ou não esta chave em seu banco de dados.

Documentação

• A documentação oficial, técnica e soberana é o swagger.

• Dediquem-se ao estudo/entendimento da API descrita no swagger pois neste encontram-se os serviços com seus PathParams, QueryParams e BodyPayload. O padrão REST/HTTP obriga a existência dos PathParams, uso opcional dos QueryParams e, o BodyPayload está descrito na sessão Schema. Parâmetros pré-fixados em Enums também encontram-se descritos na sessão Schema do Swagger ao fim da página.

• A documentação extendida da api está em constante evolução podendo haver inconsistências relativas ao swagger, devendo o entendimento deste último prevalecer sobre a documentação extendida. Inconsistências devem ser relatadas para que seja revisionada.

• Não será publicada uma documentação em formato de documento texto como aconteceu no legado.

Fluxos

• Os fluxos de execução de tarefas em alguns cenários foram mantidos e em outros extendidos, dependendo do novo modelo de fluxo operacional implementado a partir do irrigecimento da aplicação IN51.

Comparativo

• Na documentação extendida está disponibilizada uma página com elementos comparativos dos serviços entre os modelos SOAP/HTTP e REST/HTTP e, um mapeamento DE-->PARA funcional.

Ambiente

• Ambientes de hospedagem A STI diponibiliza 3 ambientes para acesso das certificadoras:

  • Homologação(vpn ou ip cadastrado)
    • API
    • WEB
  • Treinamento(Treinamento e ambientação dos usuários das certificadoras)
    • WEB
  • Produção
    • API
    • WEB

• Acesso O acesso à API é condicionado ao cadastramento de IP na whitelist do MAPA. Esta regra é um padrão adotado pela segurança da STI para TODOS os sistemas do MAPA. Caso a uma certificadora demande o acesso de N clients de aplicação ou desenvolvedores distribuídos, estes devem implementar uma estrutura de tunnel com a máquina que tem o seu IP de saída cadastrado na whitelist do MAPA.

Justificativas técnicas

A SDA e a STI não se sujeitam a dar "Justificativas Técnicas" requeridas e/ou requer aprovação dos usuários do SISBOV, sob qualquer perspectiva, sejam elas arquiteturais, negociais ou performáticas pois estes orgãos são os Detentores e Provedores da solução e não prestadores de serviço.

Tópico 1

Questão apresentada

Revisão do Processo SISBOV 2.0 em Conformidade com a IN 51
É fundamental que a Secretaria de Defesa Agropecuária (SDA), em conjunto com a Secretaria de
Inovação, Desenvolvimento Sustentável, Irrigação e Cooperativismo (SDI), realize uma avaliação
criteriosa das alterações implementadas no SISBOV 2.0 em relação aos processos operacionais
vigentes.
O sistema atual de rastreabilidade bovina opera de forma consolidada e funcional, sendo
integralmente baseado na Instrução Normativa nº 51. Este modelo já está absorvido pelas
certificadoras, produtores e demais agentes da cadeia produtiva.
Recomendação: Quanto mais próximo o SISBOV 2.0 estiver do processo atual já estabelecido e
funcional:
• Mais rápida será a implantação do novo sistema
• Menor será o custo de adaptação para as empresas certificadoras
• Menos impacto haverá nas operações diárias dos produtores rurais
• Maior será a taxa de adesão e sucesso na transição
Alterações significativas nos fluxos operacionais, sem justificativa técnica fundamentada, podem gerar resistência, atrasos na implantação e custos desnecessários para todos os envolvidos na cadeia de rastreabilidade.

Resposta

O processo funcional foi revisitado e tratado de forma a cumprir com mais rigidêz e complaince o estabelecido na IN51. Sua adoção é incondicional, aplacando-se os impactos e, não submetendo-se à preferência de operadores do protocolo, devendo-se estes submeterem-se ao homologado pela SDA.

Tópico 2

Questão apresentada

Ambiente de Homologação - Paridade com Produção
O servidor de homologação deve ser uma réplica fiel do ambiente de produção, garantindo que os testes realizados pelas certificadoras reflitam com precisão o comportamento do sistema em condições reais de operação.

Requisitos essenciais:
• Paridade de infraestrutura: Mesma arquitetura, configurações e capacidade do ambiente de produção
• Dados representativos: Volume de dados similar ao ambiente de produção para testes realistas
• Performance equivalente: Permitir simulação de cenários de carga e stress compatíveis com a operação real
• Validação de integrações: Possibilitar testes completos de ponta a ponta antes da entrada em produção

Justificativa: Sem um ambiente de homologação adequado, as certificadoras não conseguem:
• Validar a performance das integrações com volumes reais de dados
• Identificar gargalos e problemas de escalabilidade antes da produção
• Simular cenários críticos (picos de movimentação, operações em lote)
• Garantir a estabilidade das operações no momento da migração

Resposta

O ambiente de homologação foi dimensionado e alimentado com dados necessários para o fim de homologação funcional do SISBOV.
O volume de dados carregado neste ambiente é um recorte pretérito do ambiente produtivo, não contendo todos os dados atuais em produção por motivo de segurança e não sobrecarga de recursos.
Requisitos não-funcionais como performance, SLA e estabilidade das operações não são foco de atuação e críticas neste ambiente.
O dimensionamento deste ambiente é de única e exclusiva decisão e responsabilidade da infraestrutura da STI/MAPA, não sujeito à solicitações de operadores do sistema.

Pergunta 1

Questão apresentada

Obrigatoriedade do UUID como Identificador Principal do Animal

Contexto:
No sistema legado do SISBOV, cada animal possui um número único de identificação (número SISBOV) que segue dois padrões estabelecidos: 105 e 076. Esta numeração é o identificador oficial do animal em todo o sistema de rastreabilidade brasileiro e é o dado utilizado em todas as operações das certificadoras, além de ser um dado único que não se repete.
Na nova API do SISBOV 2, foi introduzido um novo identificador no formato UUID (Universally Unique Identifier) para cada animal. Este UUID passou a ser obrigatório em todas as operações da API em todas as demais operações de consulta e atualização

Problema Identificado:

1. O UUID é um dado inexistente no sistema legado do SISBOV.
2. O UUID é um dado inexistente nos sistemas das certificadoras.
3. Nenhum animal na base de dados das certificadoras possui este identificador UUID.
4. O número SISBOV (105/076) continua sendo o identificador oficial do animal para fins de rastreabilidade.
5. Para qualquer operação, a certificadora precisará primeiro consultar o UUID através do
   número SISBOV, gerando:
6. Requisições adicionais à API (uma consulta prévia para cada operação)
7. Aumento de latência nas operações
8. Necessidade de manter cache/mapeamento local de UUID ↔ Número SISBOV
9. Complexidade adicional na integração

Pergunta:
Solicitamos uma resposta técnica e fundamentada sobre:
1. Qual a justificativa técnica para a criação do UUID como novo identificador do animal?
2. Por que o UUID foi tornado obrigatório em todas as operações, em vez do número SISBOV já existente e consolidado?
3. Foi considerado o impacto para as certificadoras que não possuem este dado em suas bases?
4. Existe algum plano de migração ou fornecimento de mapeamento UUID ↔ Número SISBOV para as certificadoras?
5. É possível disponibilizar endpoints que aceitem o número SISBOV (105/076) como parâmetro alternativo ao UUID?
6. Qual a estratégia recomendada para as certificadoras realizarem a transição, considerando
que precisarão obter o UUID de milhões de animais já cadastrados?

Resposta

• Não cabe dar nenhuma justificativa técnica sobre decisões arquiteturais tomadas pelo desenvolvimento.
• Escolha de tipo de chave primária artificial para entidades é uma decisão interna e irremediável.
• A chave natural(e única) de todas as entidades portadas do SISBOV 1 estão mantidas e é de conhecimento de todos os usuários da API.
• A chave natural do Animal é:
  • numeroSISBOV
  • tipo STRING
• Todos os endpoints possuem serviço de busca pela chave natural e chave artificial
• Estratégia: A chave artificial é retornada em algumas das operações da API, quando esta for pré-requisito para utilização em outro serviço. É facultado à certificadora analisar se deseja armazenar ou não esta chave em seu banco de dados.

Pergunta 2

Questão apresentada

Alteração da Regra de Negócio para Identificação de Produtor e Propriedade

Contexto:
No sistema legado do SISBOV, a identificação de produtores e propriedades seguia uma regra de negócio consolidada e amplamente utilizada:
• Produtor: Identificado pelo CPF/CNPJ (identificadorReceita)
• Propriedade: Identificada pelo Código ERAS (Estabelecimento Rural Aprovado no SISBOV)
O Código ERAS é o identificador oficial da propriedade rural no sistema de rastreabilidade brasileiro,
sendo a chave primária que vincula a propriedade ao SISBOV. Esta regra de negócio estava consolidada e funcionava adequadamente no sistema antigo.
Na nova API do SISBOV 2, foi implementada uma alteração significativa nesta regra:
• Produtor: Passou a utilizar UUID como identificador principal, com referência ao código OESA
• Propriedade: Passou a utilizar UUID como identificador principal

Problemas Identificados:
1. Quebra de compatibilidade: A regra de negócio anterior (CPF/CNPJ + ERAS) foi substituída por UUIDs inexistentes nos sistemas das certificadoras
2. Código ERAS vs OESA:
- O Código ERAS é o padrão oficial do SISBOV para identificação de propriedades
- Foi introduzido o código OESA como referência, sem clareza sobre sua relação com o ERAS
- Não está documentado se OESA substitui, complementa ou coexiste com o ERAS
3. Impacto operacional:
- Todas as certificadoras possuem em suas bases o CPF/CNPJ dos produtores e o Código ERAS das propriedades
- Nenhuma certificadora possui os UUIDs dos produtores e propriedades
- Para qualquer operação, será necessário consultar previamente os UUIDs
4. Inconsistência conceitual:
- Se o sistema é o SISBOV, o Código ERAS deveria continuar sendo a chave da propriedade
- A introdução de um novo identificador (UUID) sem justificativa técnica gera confusão

Pergunta:
Solicitamos uma explicação técnica e fundamentada sobre:
1. Qual a justificativa técnica para alterar a regra de negócio que já funcionava no sistema antigo,
baseada em CPF/CNPJ (produtor) + Código ERAS (propriedade)?
2. Por que o Código ERAS deixou de ser a chave principal da propriedade, considerando que estamos falando do SISBOV?
3. Qual a definição e finalidade do código OESA? Qual sua relação com o Código ERAS?
4. O código OESA substitui o ERAS, complementa ou são dados distintos?
5. Os endpoints que utilizam ERAS como parâmetro de busca (/propriedade/byEras/{eras}) continuarão funcionando? O ERAS ainda é um dado válido no sistema?
6. Foi considerado o impacto para as certificadoras que terão que adaptar seus sistemas para uma nova regra de negócio?
7. Existe documentação oficial que explique a mudança conceitual de ERAS para OESA/UUID?
8. É possível manter a compatibilidade com a regra anterior, aceitando CPF/CNPJ e ERAS como parâmetros nas operações?

Resposta

• Não cabe dar nenhuma justificativa técnica sobre decisões arquiteturais tomadas pelo desenvolvimento.

• A escolha de tipo de chave primária artificial para entidades é uma decisão interna e irremediável.

• A chave natural de todas as entidades portadas do SISBOV 1 estão mantidas e é de conhecimento de todos os usuários da API.

• A chave natural do Produtor é:

  • identificadorReceita(CPF ou CNPJ)

  • tipo STRING

• A chave natural da Propriedade é:

  • codigoERAS

  • tipo INT

• O código OESA foi incorporado no vínculo entre Produtor e Propriedade para garantir a compatibilidade com a base de dados da PGA que por sua vêz gerência a numeração 076.

• Todos os endpoints possuem serviço de busca pela chave natural e chave artificial

• Estratégia: A chave artificial é retornada em algumas das operações da API, quando esta for pré-requisito para utilização em outro serviço. É facultado à certificadora analisar se deseja armazenar ou não esta chave em seu banco de dados.

Pergunta 3

Questão apresentada

Fragmentação e Complexidade do Processo de Movimentação de Animais

Contexto:
No sistema legado da BND (Base Nacional de Dados), o processo de movimentação de animais era
realizado de forma simplificada, em um único processo com aproximadamente 13 campos.
No SISBOV 2.0, este mesmo processo foi fragmentado em 6 etapas distintas, exigindo múltiplas
chamadas à API, envio repetido de informações e inclusão de novos campos obrigatórios (como os
UUIDs mencionados nas perguntas anteriores).

Comparativo do Processo:

• Screenshot 2026-03-10 at 13.56.31.png

Problemas Identificados:
1. Aumento de complexidade: O processo que era único agora requer 6 chamadas sequenciais à API
2. Redundância de dados: Campos são repetidos entre GTA e Movimentação, gerando retrabalho e possibilidade de inconsistências
3. Dependência de UUIDs: A etapa 4 exige o UUID de cada animal, dado inexistente nos sistemas das certificadoras
4. Maior latência: 6 requisições HTTP em vez de 1, aumentando significativamente o tempo total da operação
5. Maior risco de falhas: Com 6 etapas dependentes, a falha em qualquer uma compromete todo o processo. Não está claro:
- Como tratar rollback em caso de falha parcial?
- Qual o estado da movimentação se falhar na etapa 5?
- Como recuperar uma movimentação incompleta?
6. Movimentação entre certificadoras - INVIABILIDADE TÉCNICA:
- Em casos de movimentação para propriedade de outra certificadora (situação comum no dia a dia) - É necessário conhecer o UUID do produtor e da propriedade de destino - Estes UUIDs pertencem a outra certificadora e não são acessíveis - Pergunta crítica: Como realizar movimentação para terceiros sem acesso aos UUIDs de destino?

Pergunta:

Solicitamos uma explicação técnica e fundamentada sobre:
1. Qual a justificativa técnica para fragmentar um processo que funcionava em uma única etapa em 6 etapas distintas?
2. Por que há repetição de campos entre GTA e Movimentação? Não seria possível inferir esses dados automaticamente?
3. Qual o ganho operacional ou técnico que justifica o aumento de 13 para 39 campos?
4. Como deve ser tratado o rollback em caso de falha em uma das 6 etapas?
5. Existe um endpoint unificado (ou está previsto) que permita realizar toda a movimentação em uma única chamada, similar ao processo legado?
6. Movimentação entre certificadoras: Como realizar movimentação de animais para propriedades de outras certificadoras, considerando que:
- A certificadora de origem não tem acesso aos UUIDs da certificadora de destino
- O CPF/CNPJ e Código ERAS eram suficientes no sistema legado
- Qual o fluxo esperado para este cenário?
- É possível que a API aceite o Código ERAS e CPF/CNPJ como parâmetros de destino,
realizando internamente a resolução dos UUIDs?
- Qual a documentação disponível sobre o fluxo completo de movimentação, incluindo
tratamento de erros e cenários de exceção?

Resposta

• Os fluxos de execução de tarefas em alguns cenários foram mantidos e em outros extendidos, dependendo do novo modelo de fluxo operacional implementado a partir do irrigecimento da aplicação IN51.

• A GTA é um documento obrigatório na movimentação

  • Deve ser declarado

  • Obrigatóriamente anexada cópia

• O fluxo sistêmico obrigatório de uma Movimentação é

  • Declarar e anexar GTA's

  • Cadastrar uma Movimentação, anexando suas GTA's

  • Adicionar animais à Movimentação

  • Iniciar a Movimentação(ação da origem)

  • Finalizar a Movimentação(ação do destino)

• Caso não seja de prática do operador, faço saber:

  • Em um sequência de operações REST/HTTP atômicas, o operador deve ter atenção ao HTTP Return Code, verificando se o mesmo está dentro da faixa 200 à 206, o que significa que a operação foi realizada com o sucesso esperado. Caso o retorno exceda esta faixa[200-206] a próxima operação em sequência deve ser cancelada.

  • Operações Atômicas não permitem ROLLBACK TRANSACTION

  • Todas as fases possuem o seu cancelamento ou exclusão para efeito de rollback

• A repetição de dados entre GTA's e Movimentação é intencional, buscando conformidade entre elas, outrossim retrata inconsistência.

• Não é necessário saber id's do destino, basta utilizar as chaves naturais

  • identificadorReceita para Produtor

  • codigoEras para Propriedade

  • numeroSISBOV para Animal

  • numeroCompleto para GTA

  • CNPJ ou SIF para Frigorífico

Pergunta 4

Questão apresentada

Degradação Crítica de Performance na Inclusão de Animais

Contexto:

No sistema legado do SISBOV, a inclusão de animais em lote é uma operação otimizada que permite
o cadastro de grandes volumes de forma eficiente. Este é um cenário comum e crítico para as
certificadoras, que frequentemente precisam registrar milhares de animais.

Comparativo de Performance:

Cenário Sistema Legado SISBOV 2.0 Diferença
Inclusão de 10.000 animais 35 minutos 25 horas 4.186% mais lento
Tempo por animal ~0,21 segundos 9 segundos 43x mais lento

Cálculo Detalhado - SISBOV 2.0:
10.000 registros × 9 segundos = 90.000 segundos
90.000 segundos ÷ 60 = 1.500 minutos
1.500 minutos ÷ 60 = 25 horas

Problemas Identificados:
1. Inviabilidade operacional: Uma operação que leva 35 minutos no sistema legado passa a
levar 25 horas no SISBOV 2.0 - tornando a funcionalidade praticamente inutilizável
2. Impacto no negócio:
- Certificadoras realizam inclusões em lote diariamente
- Eventos de identificação em fazendas podem gerar centenas ou milhares de animais
- Operações que precisam ser concluídas em um turno de trabalho passariam a exigir
dias
3. Escalabilidade comprometida:
- 10.000 animais = 25 horas
- 50.000 animais = 125 horas (~5 dias)
- 100.000 animais = 250 horas (~10 dias)
4. Possíveis causas técnicas (a confirmar):
- Processamento síncrono individual em vez de batch
- Validações excessivas por registro
- Falta de endpoint de inclusão em lote (bulk insert)
- Overhead de autenticação/autorização por requisição

Pergunta:

Solicitamos uma explicação técnica e fundamentada sobre:

1. Qual a justificativa técnica para uma degradação de performance de 4.186% (de 35 minutos
   para 25 horas) na inclusão de 10.000 animais?
2. O tempo de 9 segundos por animal é esperado/aceitável pela equipe de desenvolvimento? Se
   sim, qual a justificativa?
3. Existe um endpoint de inclusão em lote (bulk insert) que permita enviar múltiplos animais
   em uma única requisição? Se não, está previsto?
4. Quais otimizações estão planejadas para tornar a operação de inclusão de animais viável para
   cenários de produção?
5. O sistema atual suporta processamento assíncrono para inclusões em lote? (Ex: enviar lote,
   receber ID de processamento, consultar status)
6. Qual o volume máximo de animais que a API consegue processar de forma aceitável (ex:
   menos de 1 hora para X animais)?
7. A equipe de desenvolvimento realizou testes de carga/stress para validar a capacidade da API
   em cenários reais de produção?
8. Existe uma alternativa ou workaround recomendado enquanto a performance não é otimizada?
9. Qual o volume máximo de animais que a API consegue processar de forma aceitável (ex:
   menos de 1 hora para X animais)?
10. A equipe de desenvolvimento realizou testes de carga/stress para validar a capacidade da API em cenários reais de produção?
11. Existe uma alternativa ou workaround recomendado enquanto a performance não é otimizada?

Impacto: CRÍTICO - Esta degradação de performance inviabiliza a operação das certificadoras em cenários de produção. A funcionalidade de inclusão de animais é essencial para o funcionamento do sistema.

Resposta

• Não cabe dar nenhuma justificativa técnica sobre decisões arquiteturais tomadas pelo desenvolvimento.

• A SDA e a STI não se sujeitam a dar "Justificativas Técnicas" requeridas e/ou requer aprovação dos usuários do SISBOV, sob qualquer perspectiva, sejam elas arquiteturais, negociais ou performáticas pois estes orgãos são os Detentores e Provedores da solução e não prestadores de serviço.

• A perfomance de cada chamada depende do seu payload e das regras aplicadas.

• A proposta de carga em lote(bulk) foi considerada e está em análise.