As seções a seguir descrevem os problemas conhecidos do Apigee Edge. Na maioria dos casos, os problemas listados serão corrigidos em uma versão futura.
Problemas conhecidos do Edge
Confira nas seções a seguir alguns problemas conhecidos do Edge.
Área
Problemas conhecidos
A expiração do cache resulta em um valor cachehit incorreto
Quando a variável de fluxo cachehit é usada após a política LookupCache, devido à maneira como os pontos de depuração são enviados para comportamento assíncrono, o LookupPolicy preenche o objeto DebugInfo antes que a chamada de retorno seja executada, resultando em um erro.
Alternativa:repita o processo (faça a segunda chamada) novamente logo após a primeira chamada.
A configuração da política InvalidateCache
PurgeChildEntries como verdadeira não funciona corretamente
A definição de PurgeChildEntries na
política InvalidateCache precisa limpar apenas os valores do elemento KeyFragment, mas
limpa todo o cache.
Solução alternativa: use a
política KeyValueMapOperations
para iterar o controle de versões de cache e ignorar a necessidade de invalidação de cache.
Problemas conhecidos com a IU do Edge
As seções a seguir descrevem os problemas conhecidos com a IU do Edge.
Área
Problemas conhecidos
Não é possível acessar a página de administração da zona de SSO do Edge na barra de navegação após a organização ser mapeada para uma zona de identidade
Quando você conectar uma organização a uma zona de identidade, não poderá mais acessar a página de administração da zona SSO do Edge na barra de navegação à esquerda selecionando Administrador > SSO. Como solução alternativa, acesse a página diretamente usando o seguinte URL: https://apigee.com/sso (em inglês)
Problemas conhecidos com o portal integrado
As seções a seguir descrevem os problemas conhecidos do portal integrado.
Por exemplo, os recursos a seguir da especificação OpenAPI 3.0 ainda não são compatíveis:
Propriedades allOf para combinar e estender esquemas
Referências remotas
Se um recurso incompatível for referenciado na especificação OpenAPI, em alguns casos, as ferramentas ignorarão o recurso, mas ainda assim
renderizarão a documentação de referência da API. Em outros casos, um recurso não suportado causará erros que impedem a renderização bem-sucedida
da documentação de referência da API. Em ambos os casos, você precisará modificar a especificação OpenAPI para evitar o uso do recurso não compatível até que ele seja
compatível em uma versão futura.
Observação: como o editor de especificações é menos restritivo que o SmartDocs ao renderizar a documentação de referência da API, você pode encontrar resultados diferentes entre as ferramentas.
Ao usar o Testar esta API no portal, o cabeçalho Accept é definido como application/json, independentemente do valor definido para consumes na especificação OpenAPI.
Provedor de identidade SAML
O logout único (SLO) com o provedor de identidade SAML não é compatível com domínios personalizados. Para ativar um domínio personalizado com um provedor de identidade SAML, deixe
o campo URL de saída em branco
ao definir as configurações de SAML.
Administrador do portal
No momento, não há suporte para atualizações de portal simultâneas (como edições de página, tema, CSS ou script) de vários usuários.
Se você excluir uma página de documentação de referência da API do portal, não será possível recriá-la. será necessário excluir e adicionar novamente
o produto da API e gerar a documentação de referência da API novamente.
A pesquisa será integrada ao portal integrado em uma versão futura.
Problemas conhecidos com o Edge para nuvem privada
As seções a seguir descrevem os problemas conhecidos do Edge para nuvem privada.
Área
Problemas conhecidos
Vulnerabilidade de HTTP/2 da Apigee
Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias
implementações do protocolo HTTP/2 (CVE-2023-44487), inclusive na Apigee Edge para
nuvem privada. A vulnerabilidade pode levar a um ataque de negação de serviço (DoS) da funcionalidade de gerenciamento da API Apigee.
Veja mais detalhes no Boletim de segurança da Apigee GCP-2023-032.
Os componentes do roteador e do servidor de gerenciamento do Edge para nuvem privada estão expostos à
Internet e podem ficar vulneráveis. Embora o HTTP/2 esteja ativado na porta
de gerenciamento de outros componentes específicos do Edge para nuvem privada, nenhum desses componentes está
exposto à Internet. Em componentes que não são do Edge, como Cassandra, Zookeeper e outros,
o HTTP/2 não está ativado. Recomendamos que você siga
as etapas a seguir para solucionar a vulnerabilidade do Edge para a nuvem privada:
Reinicie o componente do processador de mensagens:
apigee-service edge-postgres-server restart
Atualização do Postgresql ao atualizar para a versão 4.52
O Apigee-postgresql está com problemas para fazer upgrade do Edge para nuvem privada
versão 4.50 ou 4.51 para a versão 4.52. Os problemas ocorrem principalmente
quando o número de tabelas é maior que 500.
Execute a consulta SQL abaixo para verificar o número total de tabelas no Postgres:
apigee-mirror não funciona no Red Hat Enterprise Linux (Ela) 8.0.
Solução alternativa:
como solução alternativa, instale o apigee-mirror em um servidor que execute uma versão anterior
do AOSP ou outro
sistema operacional compatível com a Apigee. Em seguida, é possível usar o espelho para
adicionar pacotes mesmo que você tenha instalado a Apigee nos servidores do RM 8.0.
Política LDAP
149245401: as configurações do pool de conexões LDAP para JNDI definidas por meio do
recurso LDAP
não são refletidas, e os padrões JNDI causam conexões de uso único todas as vezes.
Como resultado, as conexões estão sendo abertas e fechadas toda vez para uso único, criando um grande número de conexões por hora com o servidor LDAP.
Alternativa:
Para alterar as propriedades do pool de conexões LDAP, siga
as etapas a seguir para definir uma alteração global em todas as políticas de LDAP.
Crie um arquivo de propriedades de configuração se ele ainda não existir:
Adicione o seguinte ao arquivo (substitua os valores das propriedades de
nomenclatura e diretório de Java (JNDI, na sigla em inglês) com base no requisito de configuração de recursos LDAP).
Verifique se o arquivo
/opt/apigee/customer/application/message-processor.properties é
de propriedade de apigee:apigee.
Reinicie cada processador de mensagens.
Para verificar se as propriedades JNDI
do pool de conexões estão funcionando, execute um tcpdump para observar o comportamento do pool de conexões LDAP
ao longo do tempo.
Latência alta do processamento de solicitações
139051927: altas latências de processamento de proxy encontradas no processador de mensagens
estão afetando
todos os proxies de API. Os sintomas incluem atrasos de 200 a 300 ms nos tempos de processamento em relação aos tempos de resposta normais da API e podem ocorrer de forma aleatória, mesmo com TPS baixo. Isso pode ocorrer quando mais de 50 servidores
de destino em que um processador de mensagens faz conexões.
Causa-raiz:os processadores de mensagens mantêm um cache que mapeia o URL do servidor de destino para o objeto HTTPClient em
conexões de saída com os servidores de destino. Por padrão, essa configuração é definida como 50, o que pode ser
muito baixo para a maioria das implantações. Quando uma implantação tem várias combinações de organização/ambiente em uma configuração
e tem um grande número de servidores de destino que ultrapassam 50 no total, os URLs do servidor de destino
continuam sendo removidos do cache, causando latências.
Validação: para determinar se a remoção do URL do servidor de destino está causando o problema de latência, procure a palavra-chave "onEvict" ou "Remoção" no system.logs do processador de mensagens. Sua presença nos registros indica que os URLs do servidor de destino estão sendo removidos do cache HTTPClient porque o tamanho do cache é muito pequeno.
Solução alternativa: no Edge para nuvem privada versões 19.01 e 19.06, é possível editar e configurar o cache do HTTPClient, /opt/apigee/customer/application/message-processor.properties:
Em seguida, reinicie o processador de mensagens. Faça as mesmas mudanças em todos os processadores de mensagens.
O valor 500 é um exemplo. O valor ideal para a configuração precisa ser maior que
o número de servidores de destino aos quais o processador de mensagens se conectaria. Não há efeitos colaterais de aumentar essa propriedade, e o único efeito seria um tempo de processamento de solicitações de proxy do processador de mensagens melhorado.
Observação: o Edge para nuvem privada versão 50.00 tem a configuração padrão de 500.
Várias entradas para mapas de chave-valor
157933959: inserções e atualizações simultâneas no mesmo mapa de chave-valor (KVM) no escopo do
nível da organização ou do ambiente causam dados inconsistentes e perda de atualizações.
Observação:essa limitação só se aplica ao Edge para nuvem privada. O Edge para nuvem pública
e híbrido não têm essa limitação.
Para uma solução alternativa no Edge para nuvem privada, crie a KVM no
escopo apiproxy.