Mudanças no Edge para nuvem privada 4.53.01

Visão geral das mudanças

O Edge para nuvem privada 4.53.01 apresenta várias mudanças que melhoram a postura de segurança da plataforma e incorporam versões atualizadas de softwares e bibliotecas necessários. Essas mudanças afetam os seguintes tipos de política:

• Política de validação da OAS (especificação OpenAPI)
• Políticas que aceitam consultas JSONPath
• Políticas de callout do Java que dependem de bibliotecas descontinuadas.
• OpenLDAP
• Mudanças no provedor de criptografia

Você também pode usar a ferramenta de detecção de mudanças para identificar alterações nos proxies, fluxos compartilhados ou outros artefatos no cluster que podem causar interrupções como resultado desse upgrade.

Descrição detalhada das mudanças

Esta seção descreve as mudanças introduzidas na versão 4.53.01 que podem interromper seus fluxos de trabalho durante ou após o upgrade. Também abordamos métodos para identificar possíveis áreas problemáticas e metodologias de mitigação ou soluções alternativas.

Política de validação da especificação OpenAPI (OAS)

Contexto

A política de validação do OAS valida solicitações ou respostas recebidas de acordo com as regras definidas na especificação OpenAPI 3.0 (JSON ou YAML). O Edge para nuvem privada 4.53.01 oferece melhorias na política OAS (especificação OpenAPI), com foco em uma validação mais rigorosa e precisa dos corpos de resposta da API.

Mudanças

O Edge para nuvem privada 4.53.01 introduz duas mudanças importantes na forma como a política OAS valida respostas da API, garantindo um alinhamento mais próximo com sua especificação OpenAPI:

• Cenário 1:
  • Comportamento anterior:se a especificação OpenAPI exigisse um corpo de resposta, mas a resposta real da política de destino ou upstream não incluísse um, a política não sinalizaria isso como um erro de validação.
  • Comportamento atual: agora, a política retorna corretamente um erro de validação (por exemplo, defines a response schema but no response body found) nesse cenário, indicando uma incompatibilidade entre a resposta esperada e a real.
• Cenário 2:
  • Comportamento anterior:se a especificação OpenAPI declarasse explicitamente que nenhum corpo de resposta era esperado, mas a resposta real da política de destino ou upstream incluísse um corpo, a política não resultaria em uma falha.
  • Comportamento atual:agora, a política vai resultar em uma falha (exemplo: No response body is expected but one was found) nesse cenário, garantindo que as respostas sigam estritamente o esquema especificado.

Mitigação

Identifique os proxies ou fluxos compartilhados que podem ser afetados pelo upgrade usando a ferramenta de detecção de mudanças ou por revisão manual. Procure proxies em que uma das seguintes condições esteja presente:

• A política de validação do OAS é configurada com um conjunto de tags Source definido como response.
• A política de validação do OAS está validando uma resposta de qualquer outra política que gere uma resposta.

Se você estiver usando a ferramenta, ela vai gerar a saída no formato abaixo:

Para uma explicação detalhada das colunas na tabela de saída, consulte a seção Entender a saída da ferramenta.

Depois de identificar um proxy ou fluxo compartilhado, verifique se a resposta e a especificação do OAS estão alinhadas quanto à presença ou ausência de um corpo de resposta. Use o rastreamento padrão da Apigee para analisar seus padrões de tráfego. Se o destino estiver retornando uma resposta de forma intermitente, use outras políticas para validar a resposta antes que ela seja transmitida à política de validação do OAS.

• Se o arquivo de especificação OAS definir um corpo de resposta, a resposta da política de destino ou upstream sempre vai precisar fornecer um.
• Se o arquivo de especificação da OAS não definir um corpo de resposta, a política de destino ou upstream não poderá enviar um.

Atualize a política de validação do OAS ou o comportamento de destino conforme necessário antes de tentar fazer upgrade para a nuvem privada 4.53.01. Primeiro, valide esses fluxos de trabalho identificados nos seus ambientes de não produção para minimizar o risco de interrupções durante o upgrade do cluster de produção.

Caminho JSON

Contexto

O Edge para nuvem privada 4.53.01 introduziu mudanças na forma como as expressões de caminho JSON são usadas em várias políticas. As expressões JSONPath podem ser usadas em políticas como ExtractVariable, RegularExpressionProtection e Mascaramento de dados para analisar conteúdo JSON ou armazenar valores em variáveis. As expressões JSONPath também podem ser usadas no modelo de mensagens geral para substituir variáveis por valores dinamicamente durante a execução do proxy. As novas expressões e formatos JSONPath seguem os padrões mais recentes de expressões JSON.

Mudanças

É importante analisar os proxies de API/fluxos compartilhados atuais para políticas que usam expressões JSONPath. Isso inclui, entre outras, a política de extração de variáveis, a política de proteção de expressão regular ou qualquer política com modelo de mensagem usando JSONPath.

A entrada JSON abaixo é usada para explicar as mudanças:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}

1. Mudança no comportamento do caractere curinga [*] do JSONPath para valores de objeto

   O comportamento do caractere curinga [*] foi alterado quando usado para acessar todos os valores imediatos de um objeto JSON. Antes, $.object[*] retornava os valores imediatos envolvidos em um único objeto JSON. Com as bibliotecas atualizadas, a saída agora é uma matriz que contém esses valores.

   Por exemplo, $.store[*]:

   Comportamento anterior:

   {
     "bicycle": {
       "color": "red",
       "book": [{"author": "Abc"}]
     },
     "book": [
       {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
       {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
       {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
     ]
   }
   

   Comportamento atual:

   [
     [
       {"category": "reference", "author": "Nigel Rees", "price": 8.95},
       {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
       {"category": "fiction", "author": "Herman Melville", "price": 8.99}
     ],
     {
       "color": "red",
       "book": [{"author": "Abc"}]
     }
   ]
   

   Ação:

   Mude a expressão JSONPath para segmentar apenas o objeto pai (exemplo: $.store) e segmentar diretamente os itens recuperados anteriormente.

2. O ponto final (.) do JSONPath em caminhos causa erro

   Há uma validação mais rigorosa para expressões JSONPath. Antes, os caminhos que terminavam com um ponto final inválido (por exemplo, $.path.to.element.) eram ignorados silenciosamente, e a consulta ainda retornava um resultado se o segmento de caminho válido anterior correspondesse. Com a nova versão, esses caminhos malformados agora são identificados corretamente como inválidos e resultam em um erro.

   Por exemplo, $.store.book..

   Comportamento anterior:

   [
     {"price":8.95,"category":"reference","author":"Nigel Rees"},
     {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
     {"price":8.99,"category":"fiction","author":"Herman Melville"}
   ]
   

   Comportamento atual:

   ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'
   

   Todas as políticas atuais que usam expressões JSONPath com um ponto final não intencional vão falhar com um InvalidPathException.

   Ação:

   Remova o ponto final de qualquer expressão JSONPath que termine com um. Por exemplo, mude $.store.book. para $.store.book.

3. Mudança na estrutura de saída do (..) de descida recursiva do JSONPath

   Há mudanças na forma como os resultados são retornados ao usar o operador (..) (descida recursiva) para localizar todas as ocorrências de um elemento nomeado. Antes, todos os elementos encontrados eram nivelados em uma única lista. As bibliotecas atualizadas agora retornam uma lista de listas, preservando a estrutura de agrupamento original em que os elementos foram encontrados, em vez de uma única lista simples.

   Por exemplo, $..book.

   Comportamento anterior:

   [
     {"price":8.95,"category":"reference","author":"Nigel Rees"},
     {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
     {"price":8.99,"category":"fiction","author":"Herman Melville"},
     {"author":"Abc"}
   ]
   

   Comportamento atual:

   [
     [
       {"category":"reference","author":"Nigel Rees","price":8.95},
       {"category":"fiction","author":"Evelyn Waugh","price":12.99},
       {"category":"fiction","author":"Herman Melville","price":8.99}
     ],
     [
       {"author":"Abc"}
     ]
   ]
   

   Ação:

   Atualize a lógica de processamento downstream para considerar a nova estrutura de matriz aninhada. Provavelmente, você vai precisar iterar pelo JSONArray externo e, em seguida, por cada JSONArray interno para acessar os elementos individuais.

4. Indexação JSONPath após seleção de vários itens ou filtro retorna matriz vazia

   Há uma mudança no comportamento quando um índice (exemplo: [0]) é aplicado imediatamente após um seletor de vários itens (como [*]) ou um filtro ([?(condition)]). Antes, essas expressões tentavam selecionar o item no índice especificado dos resultados combinados. Com a nova versão, essas expressões vão retornar uma matriz vazia ([]).

   Por exemplo, $.store.book[*][0].

   Comportamento anterior:

   {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
   

   Comportamento atual:

   []
   

   Ação:

   Se for necessário filtrar e depois extrair um item específico do conjunto filtrado, processe a matriz filtrada retornada pelo JSONPath, por exemplo, $..book[?(@.category == 'fiction')], e extraia [0] do resultado anterior.

5. Mudança na saída de segmentação de matriz negativa do JSONPath

   A nova versão modificou o comportamento do corte de matrizes negativas (exemplo: [-2:], [-1:]). Antes, ao aplicar um corte negativo a uma matriz (indicando elementos do final da matriz), a versão antiga retornava incorretamente apenas um único item desse corte. A nova versão agora retorna corretamente uma lista (matriz) com todos os elementos que estão dentro do intervalo negativo especificado.

   Por exemplo $.store.book[-2:]

   Comportamento anterior:

   {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
   

   Comportamento atual:

   [
     {"category":"fiction","author":"Evelyn Waugh","price":12.99},
     {"category":"fiction","author":"Herman Melville","price":8.99}
   ]
   

   Ação:

   A lógica de processamento downstream precisa ser atualizada para iterar pela matriz JSON retornada e gerar a saída desejada.

6. Ponto precedente mais estrito do JSONPath

   Há uma aplicação mais rigorosa da sintaxe para elementos acessados diretamente da raiz. Quando os elementos são acessados diretamente da raiz sem um ponto anterior (exemplo: $propertyelement), essa sintaxe agora é considerada um erro e impede a implantação do proxy.

   Por exemplo, $store,

   {
     "bicycle": {
       "color": "red",
       "book": [{"author": "Abc"}]
     },
     "book": [
       {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
       {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
       {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
     ]
   }
   

   Comportamento atual:

   Proxy will fail to deploy.

   Ação:

   Mude seu JSONPath para incluir o ponto: $.propertyName (exemplo: $.store). Isso vai segmentar e recuperar o valor corretamente.

7. Expressões JSONPath dinâmicas

   Preste atenção às políticas em que a própria expressão JSONPath é fornecida por uma variável (exemplo: {myJsonPathVariable} ou {dynamicPath}). O valor dessas variáveis também precisa ser verificado em relação às possíveis mudanças de comportamento descritas acima.

Mitigação

Identifique os proxies ou fluxos compartilhados que podem ser afetados pelo upgrade usando a ferramenta de detecção de mudanças ou revisando manualmente os proxies de API para procurar os padrões descritos. Se você usar a ferramenta, a saída vai identificar o proxy ou fluxo compartilhado afetado, a política relevante e os caminhos JSON problemáticos, conforme mostrado no exemplo de saída abaixo:

Para uma explicação detalhada das colunas na tabela de saída acima, consulte a seção Entender a saída da ferramenta.

Para mitigar, é necessária uma estratégia abrangente. Esse processo envolve decidir o caminho de atualização adequado e aplicar a correção necessária para as expressões JSONPath detectadas.

Escolha o método de upgrade que funciona melhor para você:

• Migração sem inatividade

  Essa estratégia envolve a aquisição de um ou mais ambientes novos para que você possa conectar nós separados do processador de mensagens a eles. Esses nós de processador de mensagens podem ser configurados para instalar a versão 4.53.01 e ter proxies com expressões JSONPath modernas. Eles podem ser usados durante o upgrade e desativados após a conclusão. Essa estratégia é perfeita, mas envolve a aquisição temporária de nós extras de processador de mensagens para oferecer suporte a uma atualização tranquila. Detalhes abaixo:

  • Crie um novo ambiente e adicione novos nós de processador de mensagens da versão 4.53.01 a esse novo ambiente.
  • Faça upload do pacote de proxy para os proxies afetados no novo ambiente, aplique as correções necessárias explicadas na seção de correção e implante o pacote de proxy atualizado no novo ambiente.
  • Redirecione o tráfego para o novo ambiente e cancele a implantação dos proxies afetados no ambiente antigo.
  • Faça upgrade dos nós originais do processador de mensagens para a versão 4.53.01. Implante proxies com correções para JSONPath no ambiente original.
  • Mude o tráfego de volta para o ambiente antigo, que agora tem processadores de mensagens na versão 4.53.01 e um proxy modernizado para novas expressões jsonpath.
  • Exclua e desative o novo ambiente e os nós associados.
• Tempo de inatividade e upgrade

  Essa estratégia envolve a aquisição de tempo de inatividade para proxies de API usando expressões de caminho JSON com falha. Não é necessário adquirir mais nós de processador de mensagens, mas isso causa interrupção no tráfego da API para proxies afetados.

  • Identifique os proxies e as políticas afetadas e gere uma nova revisão para todos os proxies afetados.
  • Aplique as correções necessárias implementando as correções explicadas na seção de correção em uma nova revisão do proxy. Não implante ainda.
  • Procure um tempo de inatividade para o proxy ou os proxies afetados.
  • Faça upgrade de todos os processadores de mensagens para a versão 4.53.01 do Edge para nuvem privada. Os proxies atuais podem falhar nos processadores de mensagens recém-atualizados.
  • Depois que todos os processadores de mensagens forem atualizados para a versão 4.53.01 do Edge para nuvem privada , implante a revisão de proxy recém-criada com a expressão JSONPath corrigida.
  • Retome o tráfego nesses proxies.
• Redesenhar o proxy antes do upgrade

  É possível redesenhar o proxy antes de fazer upgrade para o Edge para nuvem privada 4.53.01. Em vez de usar expressões de caminho JSON específicas, você pode ter o mesmo resultado usando um método diferente.

  Por exemplo, se você estiver usando uma política de extração de variáveis com um caminho JSON, poderá substituir a política por uma política JavaScript que extraia dados semelhantes antes de fazer upgrade para a versão mais recente. Depois que o upgrade for concluído, você poderá mudar o proxy de volta para usar caminhos JSON com formatos mais recentes.

Mudanças no JavaCallout

Contexto

O Edge para nuvem privada 4.53.00 e versões anteriores continha um diretório chamado deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) com várias bibliotecas JAR. Essas bibliotecas estavam disponíveis para uso em código Java na política JavaCallout e podiam ser usadas pelo seu código Java personalizado direta ou indiretamente.

Mudanças

O diretório descontinuado foi removido da versão 4.53.01 do Edge para nuvem privada. Caso seu código Java dependa dessas bibliotecas, os proxies que usam essas chamadas Java vão falhar quando os processadores de mensagens forem atualizados para a versão 4.53.01. Para evitar essas falhas, siga as etapas de mitigação abaixo antes de fazer upgrade dos processadores de mensagens para a versão 4.53.01.

Mitigação

1. Analise suas políticas de chamada Java e os jars associados usando a ferramenta de detecção de mudanças ou manualmente. Verifique se alguma das políticas faz referência a bibliotecas presentes no diretório "deprecated" dos seus processadores de mensagens atuais.

   Se você estiver usando a ferramenta fornecida pela Apigee para as detecções acima, ela vai gerar um relatório conforme mostrado na tabela a seguir . Especificamente, ele tem como destino políticas que referenciam JARs encontrados no diretório $APIGEE_ROOT/edge-message-processor/lib/deprecated de versões mais antigas do Edge for Private Cloud.

   A ferramenta vai gerar relatórios no seguinte formato:

   Organização	Ambiente	Nome do artefato	Tipo de artefato	Revisão	Nome da política	Tipo de política	Tipo de impacto	Campo específico de impacto	Certeza de impacto	Documentação
   org1	Nenhum	Nenhum	org-level-jar	Nenhum	Nenhum	java-callout	biblioteca descontinuada detectada para simple-javacallout-o1-jar-1.jar	['Detected use of class org.apache.commons.io.FileUtils from commons-io-2.5.jar, 'Detected use of class org.apache.commons.io.input.XmlStreamReaderException from commons-io-2.5.jar']	Alta	Mudanças no JavaCallout
   org3	env3	Nenhum	env-level-jar	Nenhum	Nenhum	java-callout	biblioteca descontinuada detectada para fat-javacallout-e3-jar-1.jar	['Uso detectado da classe org.apache.http.impl.auth.NTLMSchemeFactory de httpclient-4.5.2.jar']	Alta	Mudanças no JavaCallout
   org1	env1	p1	proxy-level-jar	1	Nenhum	java-callout	biblioteca descontinuada detectada para simple-javacallout-p1-jar-1.jar	['Detected use of class org.apache.commons.lang3.builder.ToStringBuilder from commons-lang3-3.4.jar', 'Detected use of class org.apache.commons.lang3.Validate from commons-lang3-3.4.jar']	Alta	Mudanças no JavaCallout

   Para uma explicação detalhada das colunas na tabela de saída acima, consulte a seção Entender a saída da ferramenta.

2. Depois de identificar essas bibliotecas descontinuadas , siga um dos métodos abaixo para mitigar o problema.
   • Posicionamento de recursos (recomendado se você tiver um pequeno número de jars / bibliotecas do diretório descontinuado que estão sendo referenciados pelos jars de destaque do Java)
     • Faça upload dos jars descontinuados identificados como um recurso no nível desejado: revisão do proxy de API, ambiente ou organização.
     • Continue com o upgrade do software da Apigee normalmente.
   • Posicionamento manual (recomendado se você tiver um grande número de jars / bibliotecas referenciados pelos jars de callout do Java)
     • Em cada nó do processador de mensagens, crie um diretório chamado external-lib no caminho $APIGEE_ROOT/data/edge-message-processor/.
     • Copie os JARs identificados para o diretório external-lib do diretório descontinuado: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
     • Verifique se o diretório e os jars subjacentes podem ser lidos pelo usuário da Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
     • Continue com o upgrade do software da Apigee normalmente.

Mudança no OpenLDAP

Contexto

O OpenLDAP pode ser usado na nuvem privada do Edge para autenticação e autorização. No Edge para nuvem privada 4.53.01, o software OpenLDAP enviado pela Apigee foi atualizado da versão 2.4 para a 2.6.

Mudanças

No OpenLDAP 2.6, o nome distinto relativo (RDN) é limitado a aproximadamente 241 bytes/caracteres. Essa limitação é um limite máximo imposto e não pode ser modificada.

• Falhas de replicação ou importação ocorrem para entradas com RDNs excessivamente grandes.
• A tentativa de criar entidades como organizações,ambientes, papéis personalizados, permissões etc. pode resultar na mensagem de erro: "message": "[LDAP: error code 80 - Other]".
• Qualquer DN com mais de 241 bytes no LDAP da Apigee é afetado. Esses DNs impedem o upgrade do software OpenLDAP do Apigee, e você precisa seguir estratégias de mitigação para esses itens antes de continuar com o upgrade.

Em geral, no LDAP da Apigee, os DNs longos estão relacionados a permissões, já que são criados concatenando várias entidades. Essas entradas de permissão são especialmente propensas a problemas de upgrade.

Por exemplo,

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

Normalmente, os nomes de organização, ambiente e função têm tamanhos que fazem com que os RDNs no LDAP sejam menores que 241 bytes.

Mitigação

Antes do upgrade para a versão 4.53.01:

As etapas a seguir ajudam a verificar a presença de RDNs longos no cluster LDAP 2.4 atual.

1. Extrair dados do LDAP

Use o comando ldapsearch para encontrar o nome distinto (dn) e redirecione a saída para um arquivo:

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

Verifique se o arquivo DN.ldif acima tem entradas LDAP.

#2: identifique RDNs longos

A ferramenta de detecção de mudanças usa um arquivo LDIF gerado para identificar RDNs LDAP que excedem 241 bytes/caracteres.

A ferramenta vai gerar relatórios no seguinte formato:

Para uma explicação detalhada das colunas na tabela de saída acima, consulte a seção Entender a saída da ferramenta.

Se o comando acima não produzir saída, nenhum RDN na configuração LDAP atual excederá 241 bytes/caracteres. Você pode continuar com o upgrade normalmente.

Se o comando acima gerar uma saída, isso indica a presença de RDNs que excedem 241 bytes/caracteres. Para esses itens, siga as etapas de mitigação descritas na etapa 3 antes de continuar com o upgrade do Edge para nuvem privada 4.53.01.

Nº 3: processar RDNs longos

Se você receber uma saída da etapa 2, isso indica a presença de RDNs com mais de 241 bytes/caracteres. Siga as etapas de mitigação abaixo:

Revise as entradas LDAP que excedem 241 bytes.

• Se for o nome da função personalizada, do app, do produto da API ou de outras entidades que é o principal fator para o RDN ser longo, migre para usar uma entidade alternativa com um nome mais curto.
• Se o nome da organização ou do ambiente for o principal contribuinte para o RDN longo, migre para outra organização ou ambiente com um nome mais curto.

Repita as etapas acima até que seu LDAP não tenha RDNs maiores que 241 bytes. Quando você atingir esse estado, continue com o upgrade da versão da nuvem privada normalmente.

Mudanças no provedor de criptografia

Contexto

Essa mudança é uma transferência do Edge para nuvem privada 4.53.00. No Edge para nuvem privada 4.53.00, o provedor de criptografia interna foi atualizado do Bouncy Castle (BC) para o Bouncy Castle FIPS (BCFIPS) para ativar a compatibilidade com FIPS.

Mudanças

Se as políticas JavaCallout dependerem do uso do provedor BC original, especialmente ao usar funcionalidades de segurança reforçadas no provedor BCFIPS (por exemplo, usando um par de chaves comum para criptografia e assinatura), essas políticas JavaCallout precisarão ser modernizadas. As políticas JavaCallout que tentam carregar o provedor de criptografia Bouncy Castle usando o nome BC podem falhar porque o provedor padrão mudou. Essas políticas que usam o provedor BC podem falhar posteriormente. Todas as implementações personalizadas que dependem do provedor BC antigo não estarão mais acessíveis e precisarão ser revisadas e reimplementadas.

Mitigação

A solução alternativa recomendada é usar o provedor BCFIPS. As implementações personalizadas de JavaCallout que dependiam do provedor antigo precisam ser revisadas e reimplementadas usando o provedor Bouncy Castle FIPS, que pode ser acessado usando a string "BCFIPS".

Ferramenta de detecção de mudanças

Uma ferramenta de detecção de mudanças foi criada para identificar proxies, políticas e fluxos compartilhados do Apigee que podem ser afetados durante e após a transição para o Edge para nuvem privada 4.53.01. Essa ferramenta gera um relatório detalhando proxies implantados, fluxos compartilhados e OpenLDAP afetados pelas mudanças, além de fornecer instruções para guias e estratégias específicas relevantes para os proxies ou fluxos compartilhados identificados.

Pré-requisitos

1. É necessário ter uma máquina baseada no RHEL para executar essa ferramenta.
2. O JRE 8 precisa estar instalado e configurado corretamente na máquina virtual host para permitir a execução dos scripts da ferramenta.
3. A ferramenta exige o endpoint (URL) correto do servidor de gerenciamento e credenciais administrativas válidas para autenticação e recuperação de dados.
4. A ferramenta precisa de acesso a um diretório de trabalho designado (por exemplo, /tmp) para extrair pacotes, gerar registros e armazenar a saída. Verifique se esse diretório tem espaço em disco suficiente e permissões de leitura/gravação adequadas.
5. A ferramenta exige o arquivo LDIF usando o comando ldapsearch na seção OpenLDAP change - Extract LDAP data para detectar RDNs longos com mais de 241 caracteres / bytes.

Como executar a ferramenta

Depois de atender a todos os pré-requisitos listados acima, faça o download da ferramenta e forneça o nome de usuário e a senha da Apigee que você usa para acessar o repositório da Apigee. Depois de fazer o download, extraia o arquivo.

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.0.zip -o /tmp/change-detector-for-4.53.01_1.0.0.zip

unzip /tmp/change-detector-for-4.53.01_1.0.0.zip

Quando o download for concluído, execute o comando a seguir para conferir todas as opções disponíveis da ferramenta:

./change-detector --help

Para executar a ferramenta, use o seguinte comando e substitua os marcadores pelas suas informações:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

Para detectar as entradas LDAP RDN grandes, execute o seguinte comando:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

A ferramenta gera resultados em formato JSON ou CSV que podem ser consumidos diretamente ou importados para uma ferramenta legível por humanos, como as Planilhas Google.

Entender a saída da ferramenta

Organização

Ele aponta para o nome da organização em que o artefato está localizado. Para a mudança do OpenLDAP, será None.

Ambiente

O ambiente específico (por exemplo, desenvolvimento, teste, produção) na organização. Para a mudança do OpenLDAP, será None.

Para mudanças de chamada em Java, se "Artifact Type"=env-level-jar, este campo será None.

Nome do artefato

Este campo informa o nome do proxy/fluxo compartilhado. Para mudanças no OpenLDAP, esse campo mostra a entidade LDAP do RDN.

Para mudanças de chamada em Java, se Artifact Type=env-level-jar ou org-level-jar, este campo será None.

Tipo de artefato

• Para mudanças em OAS e JSON, essa coluna especifica o tipo de artefato, proxy ou fluxo compartilhado.
• Para a mudança de callout do Java, essa coluna fornece detalhes sobre o local ou nível em que o jar afetado é enviado. Os recursos (JARs) podem ser armazenados em um de três níveis: org-level, env-level e proxy-level.
• Para a mudança do OpenLDAP, esse campo indica o arquivo LDIF usado na ferramenta.

Revisão

Ele aponta para a revisão implantada do proxy/fluxo compartilhado afetado. Para a mudança do OpenLDAP, será None.

Nome da política

O nome da política específica identificada como um possível problema. Para a mudança do OpenLDAP, será None.

Tipo de política

Ele aponta para o tipo da política. Para a mudança do OpenLDAP, será None.

Tipo de impacto

• Este campo descreve o tipo específico de mudança detectada em um proxy/fluxo compartilhado.
• Para a mudança de JavaCallout, detecções de mudanças relacionadas a java-callouts, a ferramenta aponta para o java-callout afetado que tem referências aos JARs presentes no diretório $APIGEE_ROOT/edge-message-processor/lib/deprecated de versões mais antigas do Edge para nuvem privada da seguinte maneira nesta coluna específica.

deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR

• Para a mudança do OpenLDAP, esse campo mostra se o RDN de alguma entidade LDAP excedeu mais de 241 bytes ou caracteres.

Campo de impacto específico

• Para a mudança de OAS, esse campo é o nome da variável usada na tag Origem da política.
• Para mudanças em JSON, esse campo mostra a expressão ou o elemento JSONPath exato que foi sinalizado como um possível problema.
• Para a mudança de Java Callout, esse campo tem os detalhes das classes exatas e o nome do JAR correspondente (presente no diretório $APIGEE_ROOT/edge-message-processor/lib/deprecated de versões mais antigas da nuvem privada) usado/referenciado pelo jar JavaCallout afetado, o que vai causar falhas ao fazer upgrade para a versão 4.53.01 se não for mitigado.

 ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
    Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
  .. , .. , ]

• Para a mudança do OpenLDAP, esse campo mostra o RDN da entidade LDAP, que excede 241 bytes ou caracteres.

Certeza do impacto

• Esse campo informa o grau de certeza com que a ferramenta detectou um item específico. Os valores dessa coluna podem ser Alto ou Médio. Mais valores podem ser adicionados depois.

  Um valor Alto significa que a ferramenta determinou que há uma probabilidade muito alta de que o item cause a falha do aplicativo após o upgrade para a versão 4.53.01. Um valor Médio indica que a ferramenta não tem certeza sobre a detecção e que mais estratégias seriam necessárias para tomar uma decisão. Por exemplo, capture um rastreamento para observar variáveis resolvidas durante a execução do proxy.

• As detecções relacionadas a mudanças no JavaCallout e no OpenLDAP sempre terão o valor Alto nas colunas de certeza do impacto.

Documentação

Essa coluna fornece um hiperlink para a documentação do Apigee (seções relevantes deste artigo) que explica o problema e as etapas de mitigação.