Você está lendo a documentação do Apigee Edge.
Acesse a documentação da
Apigee X. info
Na terça-feira, 8 de setembro de 2015, lançamos uma versão principal de recursos do Apigee Edge para Private Cloud.
Desde a versão trimestral anterior do Edge para nuvem privada (4.15.04.00), as seguintes versões foram lançadas e estão incluídas nesta versão trimestral:
Para quais versões do Edge é possível fazer upgrade 4.15.07.00
Dependendo da sua versão atual do Edge, você pode:
- Fazer upgrade direto para a versão 4.15.07.00
- Faça um upgrade incremental, ou seja, da versão atual para outra versão do Edge e, em seguida, para a 4.15.07.00.
Para mais informações, consulte Quais versões do Edge para nuvem privada podem ser atualizadas para 4.15.07.00.
Antes de fazer upgrade da versão 4.15.01.x ou de uma versão anterior
- Verifique a versão da SSTable do Cassandra:
- Mude o diretório para /<install-root>/apigee4/data/cassandra/data.
- Execute um comando de pesquisa,
> find . -name *-ic-*
Os resultados vão retornar um conjunto de arquivos .db se você estiver executando o SSTable do Cassandra 1.2. - Execute este comando de pesquisa:
> find . -name *-hf-*
Os resultados precisam estar vazios, o que significa que não há arquivos .db no formato hf. Se você não encontrar arquivos no formato hf, o processo está concluído e você pode fazer upgrade para a versão 4.15.07.00.
O formato hf é para SSTables do Cassandra 1.0. Se você tiver arquivos *.db no formato hf, será necessário fazer upgrade da SSTable conforme descrito no restante deste procedimento.
- Se você encontrar arquivos *.db no formato hf, faça upgrade da SSTable
executando o seguinte comando em todos os nós do Cassandra até que todos os nós
sejam atualizados:
> /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -a - Repita a etapa 1 para verificar se todos os arquivos *.db estão no formato ic para a versão 1.2 do Cassandra.
- Repita as etapas de 1 a 3 em todos os nós do Cassandra na instalação do Edge.
- Faça upgrade para o Edge 4.15.07.00.
- Após o upgrade para a versão 4.15.07.00, verifique se todos os arquivos *.db foram atualizados
para o sstable no estilo C* 2.0:
> cd /<install-root>/apigee4/data/cassandra/data
> find . -name *-jb-*
Esse comando vai retornar um conjunto de arquivos .db se você estiver executando o Cassandra 2.0.
Novos recursos e melhorias
Confira a seguir os novos recursos e melhorias desta versão.
Instalação e upgrade
Upgrade e desinstalação seletiva de componentes
Os scripts apigee-upgrade.sh e apigee-uninstall.sh agora permitem selecionar os componentes do Edge para fazer upgrade ou desinstalar. Antes, ele fazia upgrade ou desinstalava todos os componentes no nó. (OPDK-1377, OPDK-1175)
Reversão de upgrade
Se o apigee-upgrade.sh falhar durante um upgrade, agora você poderá usar o script apigee-rollback.sh para reverter o upgrade. Depois de corrigir os problemas, tente fazer o upgrade novamente. (OPDK-1275)
Opções de script do instalador abreviadas
Os scripts de instalação não usam mais a forma longa de opções, como "--help". Agora, eles só aceitam opções de uma única letra, como -h. (OPDK-1356)
Instalação do SmartDocs
Ao instalar o SmartDocs com o script setup-smartdocs.sh, você precisa inserir a organização, o ambiente e o host virtual, o que garante que o SmartDocs seja instalado no local esperado. Antes, esses valores eram codificados no script. (OPDK-1310)
Executar update-cass-pwd-in-config.sh sem solicitações
O script update-cass-pwd-in-config.sh pode ser executado sem solicitações se você definir as variáveis de ambiente ENABLE_CASS_AUTH, CASS_USERNAME e CASS_PASSWORD. (OPDK-1309)
Plataforma de borda
Confira a seguir os novos recursos da plataforma Edge incluídos nesta versão.
OpenJDK 1.7 compatível com a nuvem privada do Edge
Esta versão do Edge é compatível com o Oracle JDK 1.7 e o OpenJDK 7, e removeu o suporte para o JDK 1.6. (OPDK-1187)
Suporte a SO
O Apigee Edge para nuvem privada ampliou a compatibilidade com sistemas operacionais para incluir o Red Hat Enterprise Linux 6.6 e 7.0 (64 bits), o CentOS 6.5, 6.6 e 7.0 (64 bits) e o Oracle Linux 6.5.
Cassandra 2.0.15 incluído no OPDK 15.07
Esta versão instala o Cassandra 2.0.15. Se você estiver fazendo upgrade de uma versão anterior, a versão do Cassandra será atualizada. (OPDK-1197)
Suporte a SHA2 para hash de token OAuth
Para proteger melhor os tokens do OAuth em caso de violação de segurança do banco de dados, o Edge é compatível com algoritmos SHA2 para hash de tokens do OAuth (além do SHA1). Com as novas propriedades no nível da organização, é possível ativar e configurar o hash para novos tokens, além de manter o hash legado em tokens que existiam antes desse novo recurso. Antes, no Edge for Private Cloud, uma propriedade chamada hash.oauth.tokens.enabled no arquivo keymanagement.properties (no servidor de gerenciamento e nos processadores de mensagens) permitia o hash SHA1 automático de tokens OAuth. Essa propriedade foi descontinuada.
Se você usou a propriedade hash.oauth.tokens.enabled para ativar o hash SHA1, o script de upgrade desta versão vai gerar automaticamente as novas propriedades no nível da organização. Para verificar após o upgrade, faça um GET como administrador do sistema com esta API: https://{host}:{port}/v1/o/{your_org}.
- Para informações sobre como ativar o hash de token na sua organização com as novas propriedades, consulte "Gerar hash de tokens no banco de dados" no tópico Solicitar tokens de acesso.
- Para informações sobre como fazer hash em massa de tokens atuais, consulte o Guia de operações do Edge para nuvem privada. (APIRT-1389)
Estrutura de diretório simples para arquivos de registro
É possível configurar o Edge para armazenar arquivos de registro em uma estrutura de diretório simples definindo uma nova propriedade
enable.flat.directory.structure como "true" no arquivo message-logging.properties. Para mais informações, consulte a política de geração de registros de mensagens.
(APIRT-1394)
Performance do cache de ambiente
Para melhorar o gerenciamento e a utilização do cache na memória, as configurações de "Número máximo de elementos na memória" nos recursos de cache do ambiente foram descontinuadas. O total de elementos presentes em todos os recursos de cache (incluindo o cache padrão) depende da memória total alocada para o cache. Por padrão, a memória total alocada para o cache na memória em um determinado processador de mensagens é 40% da memória total disponível, determinada pelas configurações de propriedade do cache no arquivo cache.properties do processador de mensagens. Os elementos só serão removidos do cache na memória quando houver memória de cache insuficiente ou quando os elementos expirarem.
Para voltar ao comportamento antigo de usar a propriedade "Maximum Elements in Memory" para gerenciamento de cache, defina a propriedade overrideMaxElementsInCacheResource=false no arquivo cache.properties. (APIRT-1140)
Serviços da API
Confira a seguir os novos recursos dos Serviços de API incluídos nesta versão.
Novo Editor de proxy como padrão
O novo editor de proxy de API é ativado por padrão na interface de gerenciamento. O novo editor inclui muitas melhorias de usabilidade, incluindo visualizações mais abrangentes de fluxos condicionais e endpoints na página "Visão geral", toda a configuração na página "Desenvolver", adição mais intuitiva de fluxos condicionais, endpoints e políticas, visualizações XML mais completas em vez de pequenos snippets, pesquisa que rastreia nomes de arquivos e texto, entre outros. (MGMT-2279)
Nova política de exclusão de informações do OAuth v2.0
Uma nova política "Excluir informações do OAuth v2.0" permite excluir tokens de acesso e códigos de autorização do OAuth v2. A política substitui a funcionalidade fornecida anteriormente pela API de gerenciamento. Para mais informações, consulte Excluir a política de informações do OAuthV2. (MGMT-2257)
Nova política de exclusão de informações do OAuth v1.0
Uma nova política "Excluir informações do OAuth v1.0" permite excluir tokens de solicitação, tokens de acesso e códigos de verificação do OAuth v1.0. A política substitui a funcionalidade fornecida anteriormente pela API de gerenciamento. Para mais informações, consulte Excluir a política de informações do OAuth V1. (APIRT-1351)
Política de controle de acesso
A política de controle de acesso foi aprimorada para permitir uma avaliação mais refinada de endereços IP
para listas de permissão e de bloqueio quando os endereços IP estão contidos no
cabeçalho HTTP X-FORWARDED-FOR.
Com a verificação de vários endereços IP ativada no cabeçalho (entre em contato com o suporte para definir o
feature.enableMultipleXForwardCheckForACL), um
novo elemento <ValidateBasedOn> na política permite verificar o primeiro IP, o último IP ou todos os IPs no cabeçalho. Para mais informações, consulte a política de controle de acesso.
Novas entidades na política de acesso à entidade
A política "Access Entity" fornece acesso às seguintes novas entidades: consumerkey-scopes, authorizationcode, requesttoken e verifier. Para mais informações, consulte Política de acesso a entidades.
Política Statistics Collector: conversão automática do nome das estatísticas para letras minúsculas
Ao criar um conjunto de análises personalizadas no editor de proxy de API (página "Desenvolver" > "Ferramentas" > "Conjunto de análises personalizadas"), a variável de coleta (estatística) "Nome" precisa estar em letras minúsculas. Se você inserir o nome com letras maiúsculas, a ferramenta vai converter automaticamente o nome da estatística para minúsculas na política do Coletor de estatísticas. (MGMT-740)
Remoção do rastreamento clássico no editor de proxy de API
A versão mais recente da funcionalidade de rastreamento no editor de proxy de API passou da versão Beta para a disponibilidade geral. O acesso ao "rastreamento clássico" com o link "Acessar a versão clássica do rastreamento" não está mais disponível.
Acesso à comunidade Apigee no menu de ajuda da interface de gerenciamento
Acesse a Comunidade Apigee no menu "Ajuda" da interface de gerenciamento.
Mensagens de erro na interface de gerenciamento
Confira a seguir as melhorias nas mensagens de erro na interface de gerenciamento:
- A interface de gerenciamento usada para agrupar e mostrar todas as mensagens de erro na interface durante toda a sessão de login, a menos que você as tenha dispensado. Com essa atualização, as mensagens de erro são limpas automaticamente quando você sai da página em que elas ocorreram. (MGMT-2254)
- A interface de gerenciamento não suprime mais mensagens de erro duplicadas. (MGMT-2242)
Melhorias no desempenho e nos erros da interface
Melhorias gerais foram feitas em diferentes áreas da interface de gerenciamento, incluindo desempenho de exibição de página e limpeza de mensagens de erro.
Hiperlinks de papéis na página "Usuários da organização" na interface de gerenciamento
Na página "Usuários da organização" da interface de gerenciamento (Administrador > Usuários da organização), os nomes dos papéis agora têm hiperlinks, permitindo que você navegue rapidamente até as páginas de papéis. (MGMT-1055)
Novas variáveis de destino no fluxo de mensagens
Novas variáveis nos fluxos de mensagens fornecem informações mais completas de URL para endpoints e servidores de destino:
-
TargetEndpoint:
request.urlsubstituitarget.basepath.with.query. -
TargetServer:
loadbalancing.targetserversubstituitargetserver.name. Além disso,target.basepathsó é preenchido quando o elemento<Path>é usado no elemento<LoadBalancer>HTTPTargetConnection do TargetEndpoint.
Compatibilidade com a indicação de nome do servidor (SNI)
O Edge oferece suporte ao uso da indicação de nome do servidor (SNI) no sentido sul (do processador de mensagens para os endpoints de destino). Se quiser usar o SNI, entre em contato com o suporte do Apigee Edge.
O Java 1.7 é obrigatório.
Com o SNI, que é uma extensão do TLS/SSL, vários destinos HTTPS podem ser veiculados no mesmo endereço IP e porta sem exigir que todos esses destinos usem o mesmo certificado.
Não é necessário fazer nenhuma configuração específica do Edge. Se o ambiente estiver configurado para SNI de saída (o padrão é a nuvem de borda), o Edge vai oferecer suporte a ele.
O Edge extrai automaticamente o nome do host do URL da solicitação e o adiciona à solicitação de handshake SSL. Por exemplo, se o host de destino for https://example.com/request/path, o Edge vai adicionar a extensão server_name, conforme mostrado abaixo:
Para mais informações sobre SNI, consulte http://en.wikipedia.org/wiki/Server_Name_Indication.
"Algoritmo de assinatura" nos detalhes dos certificados SSL
Um novo campo "Algoritmo de assinatura" foi adicionado aos detalhes do certificado SSL, que podem ser vistos na interface de gerenciamento (Administrador > Certificados SSL) e na API de gerenciamento (Receber detalhes do certificado de um keystore ou truststore). O campo mostra "sha1WithRSAEncryption" ou "sha256WithRSAEncryption", dependendo do tipo de algoritmo de hash usado para gerar o certificado.
Mostrar certificados SSL que estão perto do vencimento
A página "Certificados SSL" na interface de gerenciamento (Administrador > Certificados SSL) indica quando os certificados SSL vão expirar em 10, 15, 30 ou 90 dias, dependendo da sua seleção no novo campo suspenso de expiração.
Configuração de erro da proteção contra ameaças
Por padrão, o Edge gera um código de status HTTP 500, "Erro de servidor interno" e um erro "ExecutionFailed"
se uma mensagem não passar por uma política de proteção contra ameaças JSON ou XML. É possível alterar
esse comportamento de erro com uma nova propriedade no nível da organização. Ao definir a propriedade
organizacional features.isPolicyHttpStatusEnabled como "true", o seguinte
comportamento ocorre:
- Solicitação: com uma política de proteção contra ameaças anexada a qualquer fluxo de solicitação, mensagens inválidas retornam um código de status 400 com uma mensagem de erro de política correspondente.
- Resposta: com uma política de proteção contra ameaças anexada a qualquer fluxo de respostas, mensagens inválidas ainda retornam um código de status 500, e uma das mensagens de erro de política correspondentes é gerada (em vez de apenas ExecutionFailed).
Os clientes do Cloud precisam entrar em contato com o suporte do Apigee Edge para definir a propriedade da organização. Esse recurso vai estar disponível para clientes da nuvem privada do Edge na próxima versão trimestral da nuvem privada.
Esquemas atualizados para endpoints, proxies e outras entidades
Os esquemas de referência foram atualizados para entidades não relacionadas a políticas, como TargetEndpoint, ProxyEndpoint, APIProxy e muitas outras. Consulte https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)
Serviços para desenvolvedores
Confira a seguir os novos recursos dos Serviços para desenvolvedores incluídos nesta versão.
Disponibilidade geral do SmartDocs
Os SmartDocs estão saindo da versão Beta para a disponibilidade geral. As atualizações e os novos recursos incluem:
- Suporte para Swagger 2.0, incluindo importação por arquivo ou URL, além de suporte para objetos de segurança com nomes personalizados.
- Melhorias no design visual dos modelos que geram o SmartDocs.
- Melhorias na usabilidade e no fluxo de trabalho no portal do desenvolvedor, disponíveis no menu Conteúdo > SmartDocs no Drupal.
- O que era conhecido como autenticação "Custom Token" agora é chamado de "API Key".
- Objetos de "segurança" de autenticação definidos no nível da revisão.
- Configuração da autenticação do cliente no nível do modelo. As novas revisões não redefinem mais as credenciais de cliente do SmartDocs pré-configuradas.
Para mais descrições de recursos, consulte esta postagem do blog.
Para conferir a documentação do SmartDocs, consulte Usar o SmartDocs para documentar APIs.
Nome do app do desenvolvedor exibido na interface de gerenciamento.
Os apps de desenvolvedores no Edge têm um nome interno que não muda e um nome de exibição que pode ser alterado. Em uma página de app do desenvolvedor na interface de gerenciamento (Publicar > Apps do desenvolvedor > nome do app), o "Nome" interno do app é mostrado junto com o "Nome de exibição", facilitando a identificação visual dos apps pelos nomes internos para solução de problemas e gerenciamento de API.
Serviços de análise
Confira a seguir os novos recursos dos Serviços do Google Analytics incluídos nesta versão.
Limite de tempo dos dados preservados
Ao gerar relatórios de análise com a API ou a interface de gerenciamento, os dados com mais de seis meses a partir da data atual não podem ser acessados por padrão. Se você quiser acessar dados com mais de seis meses, entre em contato com o suporte do Apigee Edge.
Remoção da versão clássica dos relatórios personalizados da interface de gerenciamento
A versão clássica opcional dos relatórios de análise personalizada não está mais disponível na interface de gerenciamento.
Performance do widget de engajamento do desenvolvedor
O widget de funil no painel principal de análise (seção "Engajamento do desenvolvedor") foi aprimorado para oferecer melhor desempenho.
Monetização
Confira a seguir os novos recursos de monetização incluídos nesta versão.
Notificações por e-mail sobre planos de tarifa
Um novo tipo de notificação por e-mail do plano de tarifas permite avisar os desenvolvedores quando eles atingem um determinado limite de transação ou de valor em dólar nos planos de tarifas por faixa de volume ou pacote que compraram. Para mais detalhes, consulte Configurar notificações usando modelos de notificação.
Sincronização dos períodos de taxa recorrente e base de agregação
Em um plano de tarifas, havia potencialmente dois períodos diferentes em vigor:
- Período da taxa recorrente, configurado na guia "Taxas" de um plano de tarifas, que determinava quando os desenvolvedores recebiam uma cobrança recorrente.
- Período da base de agregação, definido na tabela de preços para planos de faixa de volume ou pacotes, que determinou quando o uso do pacote foi redefinido para os desenvolvedores.
Esses dois períodos agora estão sincronizados. Quando uma taxa recorrente diferente de zero e uma tabela de preços por volume ou pacote existem em um plano de preços, o período da taxa recorrente é usado para os dois. Por exemplo, se houver uma taxa mensal recorrente, os pacotes da tabela de preços também serão redefinidos mensalmente (por padrão, no início do mês).
Se não houver uma taxa recorrente, os pacotes serão redefinidos com base na base de agregação definida na tabela de preços. Por exemplo, se um desenvolvedor começar a usar uma tabela de preços no dia 19 do mês, e a base de agregação for mensal, o uso do pacote será redefinido um mês após o dia 19.
A base de agregação será descontinuada e removida da monetização em uma versão futura. Para mais informações, consulte Especificar detalhes do plano de tabela de preços.
Atributos personalizados nos relatórios de resumo da receita
As políticas de registro de transações permitem capturar dados de atributos personalizados de transações, e agora é possível incluir esses atributos nos relatórios de receita resumida. Ao adicionar uma propriedade MINT.SUMMARY_CUSTOM_ATTRIBUTES à sua organização, você pode indicar quais atributos personalizados são adicionados às tabelas de banco de dados para uso em relatórios.
Os clientes do Apigee Edge para nuvem privada podem definir a flag com a seguinte chamada de API e credenciais de administrador do sistema.
curl -u email:password -X PUT -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \ "<Organization type="trial" name="MyOrganization"> <Properties> <Property name="features.isMonetizationEnabled">true</Property> <Property name="MINT.SUMMARY_CUSTOM_ATTRIBUTES">["my_attribute_1","my_attribute_2"]</Property> <Property name="features.topLevelDevelopersAreCompanies">false</Property> </Properties> </Organization>"
A matriz de atributos personalizados na chamada de API é codificada em URL.
Processo de upgrade do SmartDocs
Se você já usava o SmartDocs durante o período Beta, os novos recursos e funcionalidades da versão de disponibilidade geral exigem que você faça upgrade do SmartDocs no portal do desenvolvedor.
As páginas do SmartDocs já publicadas no portal do desenvolvedor vão continuar funcionando, mas você precisa seguir o processo de atualização antes de editar ou publicar mudanças em páginas novas ou atuais.
Embora seja possível renderizar e publicar o SmartDocs no portal de desenvolvedores, ele é gerado com base no modelo de API que fica nos serviços de gerenciamento de API do Edge da Apigee. Todas as mudanças feitas em um modelo de API no Edge serão as mesmas em todos os ambientes do Pantheon, assim como os desenvolvedores.
Para fazer upgrade da versão Beta do SmartDocs para a disponibilidade geral
- Atualize e teste a versão 15.05.27 nos ambientes dev ou test no Pantheon.
- Crie um modelo para substituir qualquer modelo de API que você esteja usando.
- Se você estava importando documentos Swagger ou WADL, importe-os novamente para uma nova revisão.
- Se você estiver mantendo seu modelo de API pelo módulo SmartDocs, exporte como JSON do SmartDocs e importe para o novo modelo usando o anexo de arquivo.
- Defina as propriedades de segurança da revisão do seu modelo. Na página Conteúdo > SmartDocs > modelo, selecione Configurações de segurança.
- Verifique qualquer autenticação pré-configurada na página de configurações do modelo (Conteúdo >
SmartDocs) clicando em Configurações na coluna
"Operações".
- Atualize todos os modelos personalizados para usar a v6 dos recursos de CSS e JS e faça mudanças para refletir todos os novos nomes de objetos, como authSchemes e apiSchema. Para informações sobre como atualizar modelos do SmartDocs, consulte Usar o SmartDocs para documentar APIs.
- Renderize e publique novamente a revisão do modelo.
- Depois de validar a nova documentação, atualize seu portal de produção para a versão 15.05.27.
Se você for um cliente corporativo do Edge e tiver dúvidas ou preocupações sobre o processo de upgrade, envie um e-mail para marsh@apigee.com e cnovak@apigee.com. Caso contrário, use a Comunidade da Apigee para receber a melhor resposta.
Mudanças e melhorias futuras nos recursos
Esta seção mostra uma prévia das mudanças e melhorias esperadas para os recursos futuros:
Mudança no comportamento da política de cache de resposta
Em uma versão futura (a ser determinada), o comportamento padrão do elemento <ExcludeErrorResponse> da política de cache de resposta vai mudar.
Comportamento atual:o elemento <ExcludeErrorResponse> na política de cache de resposta é "false" por padrão. Isso significa que, por padrão, as respostas com qualquer código de status HTTP possível (incluindo 3xx) são armazenadas em cache pela política de cache de resposta.
Comportamento futuro:o elemento <ExcludeErrorResponse> na política de cache de resposta vai usar "true" como padrão. Isso significa que, por padrão, apenas as respostas com códigos de status HTTP 200 a 205 serão armazenadas em cache. Para substituir esse comportamento e armazenar em cache respostas para todos os códigos de status, defina o elemento <ExcludeErrorResponse> como true de maneira explícita.
Solução alternativa atual : para o Private Cloud 4.15.07.00 e versões mais antigas, se você quiser armazenar em cache respostas apenas com os códigos de status 200 a 205, defina explicitamente o elemento <ExcludeErrorResponse> como "true".
Bugs corrigidos
Os bugs abaixo foram corrigidos nesta versão.
| ID do problema | Descrição |
|---|---|
| OPDK-1521 | Problema de criptografia de senha |
| OPDK-1201 | Não foi possível restaurar os dados da interface |
| OPDK-1112 | A política de senhas LDAP personalizada não está sendo aplicada ao usuário administrador da Apigee |
| OPDK-1097 | Exceção de keyspace durante o upgrade do OPDK |
| OPDK-1068 | Capacidade de mudar a senha de administrador se ela falhar durante a instalação |
| OPDK-1053 | O Zookeeper está sendo executado como raiz |
| OPDK-967 | Ao definir o OpenLDAP para iniciar automaticamente usando set-autostart.sh, all-status.sh o informa como inativo |
| OPDK-905 | O Smartdocs prod já está registrado no grupo axgroup001 |
| OPDK-899 | Erro durante a integração |
| OPDK-847 | O usuário criado durante a integração não recebe um e-mail para redefinir a senha |
| OPDK-817 | Os scripts init.d geram um erro |
| OPDK-815 | O script ax-purge.sh exige a remoção das tabelas de amostragem |
| MGMT-2246 | A página "Criar relatório personalizado" não está sendo mostrada corretamente na interface de gerenciamento |
| MGMT-2235 | Para certificados SSL expirando, o tempo relativo de expiração pode ser arredondado de forma confusa Para certificados SSL expirando, o tempo relativo da data de expiração é sempre mostrado em dias em vez de ser arredondado para meses, quando o certificado expira em 90 dias ou menos. |
| MGMT-2193 | Spinner de carregamento ao editar uma API |
| MGMT-2173 | A interface do usuário de rastreamento não permite URLs válidos Agora, a interface do usuário de rastreamento permite enviar solicitações com valores de parâmetros de consulta que contêm parâmetros de consulta aninhados. |
| MGMT-2162 | Problema de compilação do JavaScript |
| MGMT-2124 | As permissões da função do cliente são redefinidas ao salvar as permissões na interface |
| MGMT-2114 | Um IP Syslog inválido na política MessageLogging precisa gerar um erro adequado durante a implantação |
| MGMT-2067 | Rastreamento: se a revisão do proxy de API for implantada em dois ambientes, a seleção da revisão e do ambiente não funcionará corretamente |
| MGMT-2061 | A opção "Esqueci a senha" só envia e-mails para usuários registrados O link "Esqueci a senha?" na página de login da interface de gerenciamento só envia e-mails para usuários registrados do Apigee. |
| MGMT-2048 | Usuário com função personalizada que limita as permissões de implantação a um ambiente pode implantar em outros |
| MGMT-2041 | Remover o elemento FaultRules do modelo de vinculação padrão O elemento FaultRules, que não é usado em políticas ou etapas de proxy de API, não é mais adicionado automaticamente quando você cria proxies de API ou adiciona políticas. |
| MGMT-2034 | A busca de WSDL retorna falha: "Erro ao buscar WSDL: erro ao processar WSDL" |
| MGMT-1986 | Erro de interface ao adicionar um desenvolvedor |
| MGMT-1983 | Receber um código de autorização do OAuth 2.0. A API retorna o status errado |
| MGMT-1962 | Erro ao fazer login na interface de gerenciamento com uma senha forte O login na interface com determinados caracteres especiais, como o sinal de porcentagem, não falha mais. |
| MGMT-1947 | Funções não intuitivas na interface de gerenciamento Se um usuário não tiver permissão para criar ou editar uma política de gravação de transações, os botões da interface para criar e editar uma política de gravação de transações agora serão desativados. |
| MGMT-1899 | Caminhos de recursos excluídos após salvar as configurações do produto Ao editar um produto de API, os caminhos de recursos dele podiam ser excluídos se o usuário clicasse duas vezes no botão "Salvar". Esse problema foi corrigido. |
| MGMT-1894 | A página "Apps do desenvolvedor" nunca termina de carregar na coluna "Desenvolvedor" |
| MGMT-1882 | O novo proxy de API do WSDL mostra apenas os detalhes do último parâmetro |
| MGMT-1878 | Se várias revisões forem implantadas em um ambiente, o Trace vai mostrar apenas uma delas. |
| MGMT-1872 | Não é possível baixar relatórios personalizados |
| MGMT-1863 | Não é possível ver os registros do Node.js na interface de gerenciamento |
| MGMT-1843 | O proxy de API não abre |
| MGMT-1833 | O usuário sysadmin não deve ter a opção de mudar a senha na interface da OPDK. |
| MGMT-1825 | Bugs de scripting em vários locais (XSS) |
| MGMT-1824 | Erro ao buscar WSDL ao importar um arquivo WSDL com extensão .xml |
| MGMT-1812 | Adicionar validação de TargetEndpoint durante a importação Semelhante ao ProxyEndpoint, o TargetEndpoint será validado para o esquema adequado e expressões usadas nas condições durante a importação do proxy de API. |
| MGMT-1804 | A API Node.js está enviando JSON inválido em alguns casos A tela de registros do Node.js mostrava registros não formatados se os dados JSON tinham caracteres inválidos. Esse problema foi corrigido nesta versão, e a interface agora mostra registros do node.js bem formatados. |
| MGMT-1802 | URL de redefinição de senha nº 118 Se a interface de gerenciamento estiver atrás de um servidor de encerramento SSL, ela vai gerar corretamente um e-mail de redefinição de senha com um link para um URL HTTPS em vez de HTTP. |
| MGMT-1799 | Solicitação de envio de vulnerabilidade de segurança da interface no Trace |
| MGMT-1777 | Não é possível adicionar um usuário com um endereço de e-mail que tenha um TLD .acn |
| MGMT-1735 | Branding "Erro ao buscar W" Removemos imediatamente o suporte a branding personalizado no Edge OPDK. Sabemos que isso pode decepcionar os poucos clientes que estavam usando o recurso, mas ele não melhora diretamente os recursos do Edge em relação ao gerenciamento de APIs. |
| MGMT-1569 | Problema ao anexar um proxy de API a um produto de API existente Foi corrigido o problema de anexar um proxy de API a um produto de API na interface de gerenciamento quando o proxy de API tinha um recurso para o caminho "/". |
| MGMT-1563 | O botão "Enviar" no rastreamento permanece desativado se encontrar um erro |
| MGMT-1362 | O e-mail "Esqueci a senha" não funciona se o endereço de e-mail contiver
'_' Corrige o problema de redefinição de senha no OPDK com endereços de e-mail que contêm um sublinhado. |
| MGMT-1345 | A importação de WSDL com vários namespaces resulta em uma etapa de build SOAP incorreta |
| MGMT-1193 | Salvar o proxy como uma nova revisão muda inesperadamente a regra de rota |
| MGMT-1061 | SmartDocs: a descrição do parâmetro de tipo de corpo na definição do Swagger não aparece na interface do usuário do documento |
| MGMT-800 | Criar um recurso com o nome "default" resulta em uma interface corrompida |
| MGMT-787 | Problema de usabilidade do alerta da interface Na interface de gerenciamento, quando você clica em + Proxy de API e a caixa de diálogo "Novo proxy de API" aparece, é possível pressionar Esc para dispensar a caixa de diálogo. |
| MGMT-619 | Ativar a paginação na página da interface do usuário do proxy de API |
| MGMT-602 | Visualização de desenvolvimento do proxy de API: adicione uma política de cache de resposta quando o endpoint não tiver PreFlow/PostFlow causa erro |
| MGMT-460 | Renomear a política resulta em comportamento instável e duplicação, o que não pode ser removido |
| DEVRT-1644 | Pesquisa de notificações por nome causando o envio de e-mail errado |
| DEVRT-1583 | A interface de monetização mostra o selo "Futuro" para um plano de taxas atual |
| DEVRT-1546 | Os limites do plano não estão funcionando |
| DEVRT-1511 | Erro mint.resourceDoesNotExist para um desenvolvedor atual |
| CORERT-639 | TCPSysLogSocket precisa ser assíncrono |
| CORERT-613 | Falhas no handshake de SSL devido a "unrecognized_name" |
| AXAPP-1728 | Ignorar variáveis de monetização na análise |
| AXAPP-1708 | A API Analytics parece gerar números diferentes para a mesma estatística, dependendo de como eu pergunto |
| AXAPP-1707 | Melhorar o desempenho da análise de podcasts sem custo financeiro |
| AXAPP-1690 | "Erro de API inválido" em relatórios personalizados |
| AXAPP-1533 | O mapa geográfico do Analytics gera um erro de chamada de API inválida |
| AXAPP-1493 | Estatísticas de desempenho do cache incorretas |
| APIRT-1436 | Criar ferramenta/script para fazer hash de tokens sem hash |
| APIRT-1425 | O atributo "continueOnError" não tem efeito na política JavaCallout quando definido como "true" |
| APIRT-1346 | OAuth2.0: o valor hash é retornado na resposta do token de acesso quando hash.oauth.tokens.enabled é "true" |
| APIRT-1206 | target_ip não é registrado na tabela de fatos para erros 503 e a maioria dos 504 |
| APIRT-1170 | A falta de um arquivo de recurso impediu que o MP carregasse um ambiente |
| APIRT-1148 | GET da variável {message.version} em ResponseFlow para um destino Node.js gera NPE |
| APIRT-1054 | O registro de mensagens falha ao tentar registrar em um diretório diferente do padrão |
| APIRT-387 | Fazer o OrganizationService ser executado na variante "outros" no MP |
| APIRT-67 | A política OAuth GenerateAccessToken não define a variável oauthV2.failed corretamente |
| APIRT-52 | Relatórios personalizados: o código de status da resposta de muitas APIs é nulo |
Problemas conhecidos
Esta versão tem os seguintes problemas conhecidos.
| ID do problema | Descrição |
|---|---|
| OPDK-1586 |
O portal do API BaaS não é iniciado se o suporte a IPV6 não estiver ativado
|
| OPDK-1785 |
Instale o componente de monetização no ambiente atualizado do Edge
A solução alternativa é definir a versão correta da monetização no arquivo apigee-env.sh
antes de tentar instalar a monetização. Para conferir a versão da monetização em 4.15.07
(depois de fazer upgrade para o Edge 4.15.07), execute:
> source /{install-dir}/apigee4/bin/apigee-env.sh
> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4`
Por padrão, install-dir é /opt.
O valor de VER acima precisa ser definido em apigee-env.sh:
> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh
Se você tentou instalar a monetização sem seguir as etapas acima, a
instalação vai falhar, e provavelmente há um symlink inativo no diretório de compartilhamento. Remova o link simbólico:
> rm /install-dir/apigee4/share/monetization
Depois de remover o link simbólico, siga as etapas acima para definir a versão da monetização e tente instalar de novo.
|
| OPDK-1857 |
Versão 2.6 do Python codificada no bin/qpid-stat.sh e
bin/qpid-config.sh No CentOS e no RedHat 7.0, vários scripts em bin/qpid-stat.sh e bin/qpid-config.sh são codificados para usar a versão 2.6 do Python. A solução alternativa para esse problema é mudar a linha que exporta o PYTHONPATH em qpid-stat.sh e qpid-config.sh no diretório apigee4/bin.
Para determinar a versão do Python no seu sistema, verifique o diretório /opt/apigee4/share/apache-qpid/lib. O diretório provavelmente é python2.7. Em seguida, atualize a configuração PYTHONPATH em qpid-stat.sh e qpid-config.sh com o caminho correto. Exemplo:
|
| DEVRT-1574 | Saldo e uso inconsistentes para desenvolvedores com vários planos de taxas ativos Na monetização, se um desenvolvedor estiver ativo em mais de um plano de taxas com cobranças por chamada de API, o uso do saldo monetário poderá ser inconsistente. |
| APIBAAS-1647 | Depois de fazer login como administrador do sistema, a interface do BaaS emite a mensagem "Erro ao receber funções" Essa mensagem de erro aparece no primeiro login no sistema pelo administrador do sistema após fazer upgrade da versão 4.15.01 para a 4.15.07. Você pode ignorar esta mensagem. |
| DEVRT-1834 |
Upgrade da monetização para 4.15.07 O script apigee-upgrade.sh mostra a seguinte mensagem no final, pedindo que você execute outro script: ************************************** In order to complete the monetization upgrade please run: sudo /opt/apigee4/share/monetization/schema/migration/MOPDK4.15.04.00/ 365-create-notification-condition.sh ************************************** Você pode ignorar esta mensagem. Esse script não é necessário e não pode ser executado. |
| DEVRT-1951 |
Notificações de configurações ausentes na instalação nova da monetização
Em uma nova instalação do Apigee Edge para nuvem privada versão 4.15.07.00, as
configurações a seguir para notificações de monetização estão ausentes. Eles correspondem
aos tipos de notificação na página "Administrador" > "Notificações" na interface de gerenciamento.
mint.scheduler.${ORG_ID}.adhocnotify@@@management
mint.scheduler.${ORG_ID}.expiringrateplannotify@@@management
mint.scheduler.${ORG_ID}.newpkgnotify@@@management
mint.scheduler.${ORG_ID}.newproductnotify@@@management
mint.scheduler.${ORG_ID}.newrateplannotify@@@management
mint.scheduler.${ORG_ID}.tncacceptancenotify@@@management
Para contornar esse problema, siga estas etapas. Você vai precisar do endereço IP da sua instância do Cassandra. Para encontrar, procure em
<installation-root>/apigee4/conf/cassandra/cassandra.yaml ou
<installation-root>/apigee4/conf/cassandra/cassandra-topology.properties.
|
| DEVRT-1952 |
Upgrade de monetização da versão 4.14.07.00 sem configurações de notificação
Em uma atualização do Apigee Edge para nuvem privada da versão 4.14.07.00 para a 4.15.07.00, as
configurações a seguir para notificações de monetização estão ausentes, o que faz com que
os relatórios de monetização funcionem incorretamente.
mint.scheduler.${ORG_ID}.chargedaily@@@management
mint.scheduler.${ORG_ID}.chargehourly@@@management
Para contornar esse problema, siga estas etapas. Você vai precisar do endereço IP da sua instância do Cassandra. Para encontrar, procure em
<installation-root>/apigee4/conf/cassandra/cassandra.yaml ou
<installation-root>/apigee4/conf/cassandra/cassandra-topology.properties.
|
| OPDK-1878 | Não é possível definir o nome do pod em uma instalação de vários datacenters O guia de instalação do Edge especifica que os nomes do pod sejam definidos como "gateway-1" e "gateway-2" nos arquivos de instalação silenciosa para uma instalação de vários datacenters. No entanto, renomear o pod impede que os roteadores e processadores de mensagens sejam registrados corretamente e fiquem acessíveis. Esse problema também impede que o script setup-org.sh encontre processadores de mensagens disponíveis. A solução alternativa é definir o nome do pod, usando a propriedade MP_POD, como "gateway" no arquivo de instalação silenciosa para os dois data centers. |
| OPDK-1886 |
O nó não pode acessar endereços IP locais, como 192.168.x.y connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32Em seguida, reinicie os nós do processador de mensagens: <install_dir>/apigge4/bin/apigee-service message-processor restart |
| OPDK-1958 | Ao fazer upgrade, todos os nós vão precisar de acesso à porta 8080 no servidor de gerenciamento Em tempo de execução, os seguintes componentes precisam de acesso à porta 8080 no servidor de gerenciamento: roteador, processador de mensagens, UI, Postgres e Qpid. No entanto, ao fazer upgrade, todos os nós vão precisar de acesso à porta 8080 no servidor de gerenciamento, incluindo os nós do Cassandra e do Zookeeper. |
| OPDK-1962 | É necessário reconfigurar o SSL para a API do Edge após o upgrade Se você configurou a API do Edge para usar SSL antes de fazer upgrade para a versão 4.15.07.00, será necessário reconfigurar o SSL após o upgrade. Consulte o guia de operações do Edge para conferir o procedimento de configuração do SSL para a API Edge. |