Esta página foi traduzida pela API Cloud Translation.

09/16/21 - Notas de lançamento do Apigee Edge para nuvem pública

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Na quinta-feira, 13 de outubro de 2016, começamos a lançar uma nova versão do Apigee Edge para nuvem pública.

Novos recursos e atualizações

Veja a seguir os novos recursos e atualizações desta versão.

Fluxos compartilhados e ganchos de fluxo para operacionalizar proxies de API (somente versão Beta mediante solicitação)

Um novo recurso "Fluxos compartilhados" permite operacionalizar funcionalidades em proxies de API. Ao combinar políticas e recursos condicionados em um fluxo compartilhado, é possível referenciá-lo em qualquer proxy de API para executar uma lógica reutilizável de origem única. Por exemplo, um fluxo compartilhado pode verificar a chave de API, proteger contra picos de solicitações e registrar dados.

Você define fluxos compartilhados na interface de gerenciamento (APIs > Fluxos compartilhados) e faz referência a eles de duas maneiras diferentes:

Com uma nova política de chamada de fluxo em um proxy de API
ou
Em um novo artefato chamado "Ganchos de fluxo", que estão nos seguintes locais:
- Solicitação: antes do PreFlow do ProxyEndpoint, depois do PostFlow do TargetEndpoint
- Resposta: antes do PreFlow do TargetEndpoint, depois do PostFlow do ProxyEndpoint
Esses pontos de vinculação permitem executar a lógica operacional antes ou depois dos principais pontos de fluxo do proxy individual. Você atribui fluxos compartilhados a esses locais de gancho de fluxo na UI de gerenciamento (APIs > Configuração do ambiente > Ganchos de fluxo).

Mapas de chave-valor criptografados

É possível criar mapas de chave-valor (KVMs) criptografados para armazenar informações sensíveis, como credenciais ou dados de PII/HIPAA. Esse recurso é diferente do repositório seguro do Edge (cofre) e foi projetado para substituí-lo, já que os valores do cofre só podem ser acessados com Node.js (além da API de gerenciamento). É possível acessar valores de KVM criptografados com Node.js ou a política de operações de mapa de chave-valor.

Como criar KVMs criptografadas

Use as APIs KVM atuais. Quando você inclui “encrypted”: “true” na definição de payload ao criar um KVM, o Edge criptografa o KVM e gera uma chave de criptografia com o mesmo escopo do KVM.
Não é possível usar a política de operações de mapa de chave-valor para criar um KVM criptografado.
Não é possível criptografar um KVM sem criptografia.

Como usar KVMs criptografadas

Use a política de operações de mapa de chave-valor para receber e atualizar valores de KVM criptografados.
Ao receber um valor de chave criptografado, adicione o prefixo "private." à variável para armazenar o valor. Por exemplo, <Get assignTo="private.secretVar">. Essa variável private.secretVar contém o valor descriptografado.
Ao atualizar um valor com a política, você não precisa fazer nada especial. O valor será criptografado automaticamente em KVMs criptografadas.
Você também pode acessar o valor descriptografado usando o módulo apigee-access no código Node.js. Use a função getKeyValueMap() para recuperar um KVM com base no nome e no escopo. Duas funções estão disponíveis no objeto retornado: getKeys(callback) para receber uma matriz de nomes de chaves e get(key, callback) para receber o valor de uma chave específica. Por exemplo:
```
var apigee = require('apigee-access');
  var encryptedKVM = apigee.getKeyValueMap('VerySecureKVM', 'apiproxy');
  encryptedKVM.get('secret1', function(err, secretValue) {
  // use the secret value here
});
```

(APIRT-1197)

Aviso:

Operações KVM PUT com chaves nulas

Se uma política de operações de mapa de chave-valor tentar inserir uma nova chave/valor em um mapa de chave-valor (KVM) usando uma chave nula, a seguinte chave será criada automaticamente: __$$_EDGE_KVM_EMPTY_KEY_$$__

Essa situação acontecerá, por exemplo, se você estiver preenchendo uma chave usando uma referência de variável nula. Como há uma tentativa de novos PUTs com chaves nulas, somente essa chave é usada. Portanto, os valores atuais dela poderão ser substituídos sempre que a política for executada.

O comportamento anterior para uma chave nula era que a chave/valor não era adicionada ao KVM. Em vez disso, a entrada permaneceu no cache na memória do processador de mensagens e ficou temporariamente disponível para operações Get subsequentes. Se a implementação da política de KVM depender do comportamento anterior, as operações "Get" em chaves nulas vão falhar porque não estão referenciando o novo nome de chave (acima) criado para chaves nulas. (APIRT-3530)

URLs de especificação OpenAPI incluídos nos metadados do proxy de API

Quando você cria um proxy de API com base em uma especificação OpenAPI, o local da especificação OpenAPI é armazenado nos metadados do proxy de API. Por exemplo, se você usar a API Management para receber os detalhes de uma revisão de proxy, os metadados vão incluir o caminho para a especificação OpenAPI no seguinte formato:

"spec" : "https://raw.githubusercontent.com/apigee/api-platform-samples/master/default-proxies/helloworld/openapi/mocktarget.yaml"

Esse aprimoramento é compatível com a versão de próxima geração do Edge, que vincula especificações da OpenAPI a proxies de API, produtos de API e documentos de referência de API no novo portal do desenvolvedor. (MGMT-2913)

Controle de IP do cliente com o Sense

Para controlar com mais precisão onde encontrar endereços IP para detecção de bots do Sense ao usar produtos de roteamento como a Akamai, o Sense permite definir a localização do IP do cliente com uma variável additionalIPVars. Por exemplo, é possível definir additionalIPVars para usar o cabeçalho true-client-ip, que contém o IP correto da Akamai para avaliação nas regras de bot. (APIRT-3332)

Bugs corrigidos

Os bugs a seguir foram corrigidos nesta versão. Esta lista é principalmente para usuários que verificam se os tíquetes de suporte foram corrigidos. Ela não foi projetada para fornecer informações detalhadas a todos os usuários.

ID do problema	Descrição
APIRT-3507	Erros intermitentes (como erros de SNI) em frases de destaque de serviço JavaScript
APIRT-3408	A versão 160817 do MP processa mensagens do módulo de análise apigee-access de maneira diferente
APIRT-3390	Mudança na resposta de falha retornada pela política de atualização do token de acesso Aviso:mudança no código de erro "invalid_client" do OAuthV2. Observe a seguinte mudança em um código de erro gerado pelas operações da política OAuthV2 GenerateAccessToken e RefreshAccessToken quando a propriedade <GenerateResponse> da política OAuthV2 está definida como false: `{"ErrorCode" : "invalid_client", "Error" :"Client identifier is required"}` mudou para: `{"ErrorCode" : "InvalidClientIdentifier", "Error" :"Client identifier is required"}` Recomendamos que você mude as condições da regra de falha que capturam "`invalid_client`" para capturar os códigos antigos e novos. Por exemplo, na sua regra de falha, mude: `(fault.name = "invalid_client")` para isto: `(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")`
APIRT-3389	Aviso:erro ao fazer upload de payloads do Node.js com mais de 25 KB Agora é permitido fazer upload de payloads do Node.js com mais de 25 KB.
APIRT-3381	Latências altas em proxies de produção do cliente
APIRT-3366	As políticas de JavaScript estão falhando em todas as novas organizações de teste
APIRT-3363	A análise de URL inválido retorna um status 500 com ApplicationNotFound
APIRT-3356	Mensagem de token inválido do OAuth
APIRT-3355	Erro 403 intermitente no proxy do OAuth
APIRT-3285	Aviso:expiração inconsistente do token OAuth2 Ao gerar um token OAuth usando a política do OAuth v2.0, é possível definir a expiração do token por referência ou por um padrão codificado. Por exemplo: `<ExpiresIn ref="kvm.oauth.expires_in">1800000</ExpiresIn>`. Na primeira vez que a expiração do token foi definida por referência, o Edge armazenou e usou esse valor para cada nova expiração de token. Esse bug foi corrigido para usar o valor de referência ou, se nenhum valor de referência for fornecido, a expiração padrão definida na política. Essa correção pode mudar a duração das expirações de token, e você pode ter efeitos colaterais, como mais erros de token inválido, o que pode exigir que você implemente atualizações de token mais frequentes ou mude a expiração padrão nas suas políticas do OAuth.
APIRT-3261	As credenciais são validadas em relação a outro app de desenvolvimento em produção
APIRT-3234	O app Node.js retorna NPE
APIRT-3223	Problema de cache desatualizado da Apigee
APIRT-3193	O servidor de destino do Node.js está travando após a migração para o ASG
APIRT-3152	A chamada de gerenciamento cachedlogs faz com que as mensagens de registro sejam divididas
APIRT-3117	O MP atingiu 100% de uso da CPU e parou de veicular tráfego
APIRT-3064	Roteador: mensagem de erro 503 personalizada do roteador
APIRT-2620	Pool de linhas de execução separado para algumas etapas de bloqueio e melhoria no processamento de carga
CORESERV-774	O acesso usando uma chave válida com uma referência de apiproduct inválida causa um erro interno do servidor