180202 - Notas de lançamento do Apigee Edge para nuvem pública

Os hosts virtuais de autoatendimento e o TLS já estão disponíveis para todos os usuários

Para detalhes de uso, consulte Sobre hosts virtuais e TLS/SSL.

Otimizações de importação/atualização de pacotes de proxy

O Edge vai realizar uma validação mais rigorosa nos pacotes de proxy de API no momento da implantação. Essa atualização ajuda a garantir implantações mais rápidas, além de reduzir falhas de implantação e corrupção de pacotes quando mais de um usuário importa o mesmo pacote ao mesmo tempo. Confira as mudanças e os comportamentos importantes:

• Cada pacote precisa ter uma raiz do sistema de arquivos de /apiproxy.
• O Edge não tenta mais ignorar caminhos na pasta de recursos de um pacote de proxy de API. Por exemplo, o Edge não ignora mais diretórios .git ou .svn.
• Se um pacote tiver uma configuração inválida de mais de um arquivo de configuração XML de proxy de API (por exemplo, apiproxy/proxy1.xml e apiproxy/proxy2.xml), não há garantia de qual configuração será usada para o proxy de API.

Validações de implantação

Até essa versão, o Edge verificava passivamente as implantações de proxy de API em busca de erros de validação específicos e notificava as organizações pela ferramenta Advisory sobre as correções necessárias. Esses avisos, descritos em Avisos de erro de implantação, foram criados para dar tempo aos usuários de corrigir problemas que resultariam em erros de implantação quando a validação fosse ativada no produto. Com essa versão, o Edge agora realiza essas validações e gera erros de implantação de acordo com isso.

Política de Detenção de pico compatível com escalonamento automático

Um novo elemento <UseEffectiveCount> na política de detenção de pico permite distribuir automaticamente as contagens de detenção de pico entre os processadores de mensagens. Quando definido como "true", cada processador de mensagens divide o limite de taxa de pico permitido pelo número de processadores de mensagens ativos, ajustando o limite de taxa conforme os processadores de mensagens são adicionados ou removidos. O valor padrão é falso quando o elemento é omitido da política.

Para mais informações, consulte o tópico Política de Spike Arrest.

Melhoria no registro de MP devido a falha de conectividade

Fazer upgrade do Rhino para a versão 1.7.8 e do Trireme para a versão 0.9.1

Definir o tempo limite padrão da API para todos os proxies como 55 segundos para evitar que o roteador expire antes

Adicionar evento de geração de registros para implantações canário

Permitir verificações de integridade HTTPS autoassinado

A resolução de DNS do MP precisa usar um pool de linhas de execução assíncrona

Melhorias na segurança do produto de API

Uma nova propriedade no nível da organização, features.keymanagement.disable.unbounded.permissions, fortalece a segurança dos produtos de API na verificação de chamadas de API. Quando a propriedade é definida como "true" (o padrão para organizações criadas após essa versão), os recursos a seguir são aplicados.

Criação de apps

Ao criar um app de desenvolvedor ou empresa, a API de gerenciamento exige que o app seja associado a um produto de API. A interface de gerenciamento já aplica isso.

Configuração do produto de API

Para criar ou atualizar um produto de API, ele precisa incluir pelo menos um proxy de API ou um caminho de recurso na definição.

Segurança do ambiente de execução

As chamadas de API são rejeitadas por um produto de API nas seguintes situações:

• Um produto de API não inclui pelo menos um proxy de API ou caminho de recurso.
• Se a variável flow.resource.name na mensagem não incluir um caminho de recurso que o produto de API possa avaliar.
• Se o app que faz a chamada de API não estiver associado a um produto de API.

Para organizações existentes, o valor da propriedade é falso e precisa ser alterado explicitamente por um usuário com permissões de administrador do sistema. Isso significa que os clientes da Public Cloud precisam entrar em contato com o suporte da Apigee para mudar o valor da propriedade.

A comunicação entre roteador e processador de mensagens é segura por padrão

Correção da classificação incorreta de erros de script do Node.js

Política AccessControl de IP confiável

Política MessageLogging para resolver o DNS novamente em intervalos regulares

Validação da cadeia de certificados TLS

Ao criar um alias de keystore usando uma cadeia de certificados, separe os certificados na cadeia com uma nova linha. O Edge agora gera uma solicitação 400 inválida na criação de alias se a cadeia de certificados não atender a esse requisito.