Você está vendo a documentação do Apigee Edge.
Consulte a documentação do Apigee X.
Na terça-feira, 8 de setembro de 2015, lançamos um lançamento de recurso importante do Apigee Edge para nuvem privada.
Desde o lançamento trimestral anterior do Edge para nuvem privada (4.15.04.00), os lançamentos a seguir ocorreram e estão incluídos nesta versão trimestral:
Quais versões do Edge podem ser atualizadas para 4.15.07.00
Dependendo da versão atual do Edge, você pode:
- Upgrade direto para 4.15.07.00
- Upgrade incremental, o que significa que você precisa fazer upgrade da versão atual para outra versão do Edge e, em seguida, fazer upgrade para a 4.15.07.00.
Para mais informações, consulte Quais versões do Edge para nuvem privada você pode atualizar 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 do Cassandra SSTable:
- Altere o diretório para /<install-root>/apigee4/data/cassandra/data.
- Execute um comando de localização,
> find . -name *-ic-*
Os resultados retornarão um conjunto de arquivos .db se você estiver executando o SSTable do Cassandra 1.2. - Execute este comando de localização:
> find . -name *-hf-*
Os resultados precisam estar vazios, o que significa que não há arquivos .db no formato hf. Caso você não veja arquivos no formato hf, o processo foi concluído e será possível fazer upgrade para a versão 4.15.07.00.
O formato hf é para SSTables do Cassandra 1.0. Se você tiver algum arquivo *.db no formato hf, terá que fazer upgrade do SSTable conforme descrito no restante deste procedimento.
- Se você encontrar arquivos *.db no formato hf, faça upgrade do SSTable executando o seguinte comando em cada nó do Cassandra até fazer upgrade de todos os nós do Cassandra:
> /<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 do Cassandra 1.2.
- Repita as etapas de 1 a 3 em cada nó do Cassandra na instalação do Edge.
- Faça upgrade para o Edge 4.15.07.00.
- Após o upgrade 4.15.07.00, verifique os arquivos *.db para garantir que todos tenham sido atualizados para o estilo estável do C* 2.0:
> cd /<install-root>/apigee4/data/cassandra/data
> find . -name *-jb-*
Esse comando retornará um conjunto de arquivos .db se você estiver executando o Cassandra 2.0.
Novos recursos e melhorias
Veja a seguir os novos recursos e melhorias desta versão.
Instalação e upgrade
Upgrade e desinstalação de componentes selecionados
Os scripts apigee-upgrade.sh e apigee-uninstall.sh agora permitem que você selecione os componentes do Edge para fazer upgrade ou desinstalar. Anteriormente, ela fazia upgrade ou desinstalava todos os componentes do nó. (OPDK-1377 e 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 de upgrade, você pode tentar novamente. (OPDK-1275)
Opções de script do instalador encurtadas
Os scripts de instalação não assumem mais a forma longa de opções, como --help. Agora, eles só aceitam opções de letra única, como -h. (OPDK-1356)
Instalação do SmartDocs
Ao instalar o SmartDocs com o script setup-smartdocs.sh, você é solicitado a inserir a organização, o ambiente e o host virtual, o que garante que o SmartDocs esteja instalado no local esperado. Anteriormente, esses valores eram codificados no script. (OPDK-1310)
Como executar update-cass-pwd-in-config.sh sem solicitações
O script update-cass-pwd-in-config.sh poderá 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
Veja 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 foi removida do JDK 1.6. (OPDK-1187)
Suporte a SO
A Apigee Edge para nuvem privada expandiu a compatibilidade do sistema operacional para incluir Red Hat Enterprise Linux 6.6 e 7.0 (64 bits), CentOS 6.5, 6.6 e 7.0 (64 bits) e Oracle Linux 6.5.
Cassandra 2.0.15 incluso no OPDK 15.07
Esta versão instala o Cassandra 2.0.15. Se você estiver fazendo upgrade para uma versão anterior, sua versão do Cassandra será atualizada. (OPDK-1197)
Compatibilidade com SHA2 para hash de token OAuth
Para proteger melhor os tokens OAuth em caso de violação de segurança do banco de dados, o Edge é compatível com algoritmos SHA2 para hash de tokens 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 qualquer token existente antes desse novo recurso. Antes, no Edge para nuvem privada, uma propriedade chamada hash.oauth.tokens.enabled no arquivo keymanagement.properites (no servidor de gerenciamento e processadores de mensagens) permitia o hash SHA1 automático de tokens OAuth. O uso dessa propriedade foi suspenso.
Se você já usou a propriedade hash.oauth.tokens.enabled para ativar o hash SHA1, o script de upgrade desta versão gerará automaticamente as novas propriedades no nível da organização. Para verificar após o upgrade, faça o download do GET como administrador do sistema com esta API: https://{host}:{port}/v1/o/{sua_org}.
- Para informações sobre como ativar o hash de token na sua organização com as novas propriedades, consulte "Como gerar hash de tokens no banco de dados" no tópico Como solicitar tokens de acesso.
- Para informações sobre como gerar hash em massa de tokens existentes, consulte o Guia de operações do Edge para nuvem privada. (APIRT-1389)
Estrutura de diretório simples para arquivos de registros
É possível configurar o Edge para armazenar arquivos de registros 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 Política de registro de mensagens.
(APIRT-1394)
Desempenho do cache do ambiente
Para melhor utilização e gerenciamento do cache de memória, o uso das configurações de "Elementos máximos na memória" nos recursos de cache do ambiente foi suspenso. O total de elementos presente 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 armazenamento em cache na memória em um determinado processador de mensagens é 40% da memória total disponível, determinada pelas configurações da propriedade de cache no arquivo cache.properties do processador de mensagens. Os elementos serão removidos do cache na memória apenas quando não houver memória de cache insuficiente ou quando os elementos expirarem.
Para voltar ao comportamento antigo de uso da propriedade "Elementos máximos na memória" para gerenciamento de cache, defina a propriedade overrideMaxElementsInCacheResource=false no arquivo cache.properties. (APIRT-1140)
Serviços da API
Veja a seguir os novos recursos dos serviços de API incluídos nesta versão.
Novo Proxy Editor como padrão
O novo editor de proxy de API é ativado por padrão na IU de gerenciamento. O novo editor inclui muitas melhorias de usabilidade, incluindo visualizações mais abrangentes dos 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 de XML mais completas em vez de pequenos snippets, pesquisa que rastreia nomes de arquivo e texto e muito mais. (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 os tokens de acesso e os 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 política de informações 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 inclusão na lista de permissões e proibições quando os endereços IP estiverem 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 que você verifique
o primeiro IP, o último IP ou todos os IPs no cabeçalho. Para mais informações, consulte Política de controle de acesso.
Novas entidades na política de entidade de acesso
A política de entidade de acesso fornece acesso às seguintes novas entidades: consumerkey-scopes, authorizationcode, requesttoken e verificador. Para mais informações, consulte Política de acesso a entidades.
Política do coletor de estatísticas: conversão automática do nome das estatísticas em letras minúsculas
Ao criar um conjunto de análises personalizadas no editor de proxy de API (página "Desenvolver" > "Ferramentas" > "Conjunto personalizado de análises"), a variável do coletor (estatística) "Nome" precisa estar em letras minúsculas. Se você inserir o nome com letras maiúsculas, a ferramenta converterá automaticamente o nome da estatística em minúsculas na política do coletor de estatísticas. (MGMT-740)
Remoção do Trace clássico no editor de proxy de API
A versão mais recente da funcionalidade Trace no editor de proxy de API foi movida da versão Beta para a disponibilidade geral. O acesso ao "Trace clássico" com o link "Acessar a versão clássica do trace" não está mais disponível.
Acesso à comunidade da Apigee no menu de ajuda da IU de gerenciamento
É possível acessar a comunidade da Apigee no menu de ajuda da IU de gerenciamento.
Mensagens de erro na IU de gerenciamento
Veja a seguir melhorias na mensagem de erro na IU de gerenciamento:
- A IU de gerenciamento usada para agrupar e exibir todas as mensagens de erro na IU de toda a sessão de login, a menos que você as dispense. Com essa atualização, as mensagens de erro são apagadas automaticamente quando você sai da página em que ocorreram. (MGMT-2254)
- A IU de gerenciamento não suprime mais mensagens de erro duplicadas. (MGMT-2242)
Desempenho da IU e melhorias de erro
Melhorias gerais foram feitas em diferentes áreas da IU de gerenciamento, incluindo o desempenho de exibição da página e a limpeza da mensagem de erro.
Hiperlinks de papéis na página "Usuários da organização" na IU de gerenciamento
Na página "Usuários da organização" na interface do usuário de gerenciamento (Administrador > Usuários da organização), os nomes de papéis agora recebem 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 de URL mais completas para endpoints e servidores de destino:
-
TargetEndpoint:
request.urlsubstituitarget.basepath.with.query. -
TargetServer:
loadbalancing.targetserversubstituitargetserver.name. Além disso,target.basepathé preenchido somente quando o elemento<Path>é usado no elemento<LoadBalancer>HTTPTargetConnection do TargetEndpoint.
Suporte a indicação de nome do servidor (SNI, na sigla em inglês)
O Edge aceita o uso da indicação de nome do servidor na borda sul (do processador de mensagens aos endpoints de destino). Se você quiser usar a SNI, entre em contato com o suporte da Apigee.
O Java 1.7 é obrigatório.
Com a SNI, que é uma extensão do TLS/SSL, vários destinos HTTPS podem ser atendidos pelo mesmo endereço IP e porta, sem exigir que todos esses destinos usem o mesmo certificado.
Nenhuma configuração específica do Edge é necessária. Se o ambiente estiver configurado para SNI de borda sul (a nuvem do Edge é por padrão), ele é compatível.
O Edge extrai automaticamente o hostname do URL da solicitação e o adiciona à solicitação de handshake do SSL. Por exemplo, se o host de destino for https://example.com/request/path, o Edge adicionará a extensão server_name conforme mostrado abaixo:
Para mais informações sobre a SNI, consulte http://en.wikipedia.org/wiki/Server_Name_Indication.
"Algoritmo de assinatura" nos detalhes dos certificados SSL
Um novo campo "Signature Algorithm" foi adicionado aos detalhes do certificado SSL, visível na IU de gerenciamento (Administrador > Certificados SSL) e na API de gerenciamento (Ver 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.
Mostrando certificados SSL prestes a expirar
A página "Certificados SSL" na IU de gerenciamento ("Administrador > Certificados SSL") indica quando os certificados SSL expiram em 10, 15, 30 ou 90 dias, dependendo da seleção no novo campo suspenso de expiração.
Configuração de erro da proteção contra ameaças
Por padrão, o Edge lança um código de status de erro HTTP 500 do servidor interno e um erro ExecutionFailed se uma mensagem não passar de 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 verdadeira, ocorre o seguinte comportamento:
- Solicitação: com uma política de proteção contra ameaças anexada a qualquer fluxo de solicitação, as 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, as 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 da Apigee para definir a propriedade da organização. Esse recurso estará disponível para os clientes da nuvem privada do Edge na próxima versão trimestral da nuvem privada.
Esquemas atualizados de endpoints, proxies e outras entidades
Os esquemas de referência foram atualizados para entidades sem política, como TargetEndpoint, ProxyEndpoint, APIProxy e muitas outras. Consulte https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)
Serviços do desenvolvedor
Veja a seguir os novos recursos dos serviços para desenvolvedores incluídos nesta versão.
Disponibilidade geral do SmartDocs
O SmartDocs está mudando da versão Beta para a disponibilidade geral. As atualizações e os novos recursos incluem:
- Suporte para o Swagger 2.0, incluindo importação por arquivo ou URL, incluindo suporte para objetos de segurança com nome personalizado.
- Melhorias no design visual dos modelos que geram SmartDocs.
- Aprimoramentos de usabilidade e fluxo de trabalho no Portal do desenvolvedor, disponíveis no menu "Content > SmartDocs" no Drupal.
- O que era conhecido como autenticação de "token personalizado" agora é chamado de "Chave de API".
- Autenticação de objetos de "segurança" definidos no nível de revisão.
- Configuração da autenticação do cliente no nível do modelo. As novas revisões não redefinem mais as credenciais do cliente SmartDocs pré-configuradas.
Para ver mais descrições de recursos, consulte esta postagem do blog.
Para a documentação do SmartDocs, consulte Como usar o SmartDocs para documentar APIs.
Nome do app do desenvolvedor exibido na IU de gerenciamento
Os aplicativos de desenvolvedor 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 do aplicativo para desenvolvedores na IU de gerenciamento (Publicar > Aplicativos do desenvolvedor > nome do aplicativo), o "Nome" interno do aplicativo é exibido junto com o "Nome de exibição", facilitando a identificação visual dos aplicativos pelos nomes internos para solução de problemas e gerenciamento de APIs.
Serviços de análise
Veja a seguir os novos recursos dos serviços do Google Analytics incluídos nesta versão.
Limite de tempo de dados preservados
Ao gerar relatórios de análise com a IU ou a API de gerenciamento, os dados com mais de seis meses a partir da data atual não são acessíveis por padrão. Se você quiser acessar dados com mais de seis meses, entre em contato com o suporte da Apigee.
A versão clássica dos relatórios personalizados está sendo removida da IU de gerenciamento
A versão clássica opcional dos relatórios de análise personalizados não está mais disponível na IU de gerenciamento.
Desempenho do widget de engajamento do desenvolvedor
O widget de funil no painel de análise principal (seção "Engajamento do desenvolvedor") foi aprimorado para fornecer um melhor desempenho.
Monetização
Veja a seguir os novos recursos de monetização incluídos nesta versão.
Notificações por e-mail do plano de tarifas
Um novo tipo de notificação por e-mail do Plano de tarifação permite que você notifique os desenvolvedores quando eles atingirem determinado limite de transação ou de dólar nos planos de taxa de pacotes ou bandas adquiridas. 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 tarifa, poderia haver dois períodos diferentes em vigor:
- Período da taxa recorrente, configurado na guia "Taxas" de um plano de tarifas, que determina quando os desenvolvedores recebem uma cobrança recorrente.
- Período da base de agregação, definido na tabela de preços dos planos de banda volumétrica ou de pacotes, que determina quando o uso do pacote é redefinido para os desenvolvedores.
Esses dois períodos agora estão sincronizados. Quando há uma taxa recorrente diferente de zero e uma tabela de preços de Bandas de volume ou de pacote em um plano de tarifas, o período de taxa recorrente é usado para ambos. Por exemplo, se houver uma taxa mensal recorrente, os pacotes de tabelas de preços também serão redefinidos por padrão (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 todo mês, o uso do pacote será redefinido um mês após o dia 19.
A base de agregação está sendo suspensa e será 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 em relatórios de receita resumidas
As políticas de registro de transações permitem que você capture dados de atributos personalizados das transações. Agora, é possível incluir esses atributos nos relatórios de receita resumidos. Ao adicionar uma propriedade MINT.SUMMARY_CUSTOM_ATTRIBUTES à sua organização, você pode indicar quais atributos personalizados são adicionados às tabelas do banco de dados para uso em relatórios.
Os clientes do Apigee Edge para nuvem privada podem definir a sinalização com as seguintes chamadas 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 da API é codificada pelo URL.
Processo de upgrade do SmartDocs
Se você já usa o SmartDocs durante o período Beta, os novos recursos na versão de disponibilidade geral exigem o upgrade do SmartDocs no portal do desenvolvedor.
Todas as páginas do SmartDocs que já foram publicadas no portal do desenvolvedor continuarão funcionando, mas você precisa seguir o processo de atualização antes de editar ou publicar qualquer alteração nas páginas existentes ou novas.
Lembre-se de que, enquanto é possível renderizar e publicar os SmartDocs no portal do desenvolvedor, eles são gerados a partir do modelo de API que reside nos serviços de gerenciamento da API Edge da Apigee. Todas as alterações feitas em um modelo de API no Edge serão as mesmas em todos os ambientes do Pantheon, da mesma forma que os desenvolvedores usam nos ambientes do Pantheon.
Fazer upgrade da versão Beta do SmartDocs para disponibilidade geral
- Atualize e teste a versão 15.05.27 nos seus ambientes dev ou test no Pantheon.
- Crie um novo modelo para substituir qualquer modelo de API que você esteja usando.
- Se você estiver importando documentos Swagger ou WADL, importe-os novamente para uma nova revisão.
- Se você mantiver seu modelo de API por meio do módulo SmartDocs, exporte-o como JSON do SmartDocs e importe-o para o novo modelo usando o anexo de arquivo.
- Defina as propriedades de segurança da revisão do 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 os modelos personalizados para usar a v6 dos recursos CSS e JS e faça alterações para refletir os novos nomes de objeto, como authSchemes e apiSchema. Para informações sobre como atualizar os modelos do SmartDocs, consulte Como usar o SmartDocs para documentar APIs.
- Renderize novamente e publique 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 de borda e tiver dúvidas 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.
Futuras alterações e melhorias de recursos
Esta seção mostra as futuras mudanças e melhorias esperadas nos recursos:
Alteração no comportamento da política de cache de resposta
Em uma versão futura (a ser determinado), o comportamento padrão do elemento <ExcludeErrorResponse> da política de cache de resposta será alterado.
Comportamento atual: o elemento <ExcludeErrorResponse> na política de cache de resposta é falso 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 terá o valor "true" por padrão. Isso significa que, por padrão, apenas respostas com os códigos de status HTTP 200 a 205 serão armazenadas em cache. Para substituir esse comportamento e armazenar as respostas em cache para todos os códigos de status, você precisará definir explicitamente o elemento <ExcludeErrorResponse> como "true".
Solução alternativa atual: para a versão de nuvem privada 4.15.07.00 e anteriores, se você quiser armazenar em cache as respostas somente 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 IU |
| OPDK-1112 | A política de senha 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 | É possível alterar a senha do administrador se ela falhar durante a instalação |
| OPDK-1053 | O Zookeeper está em execução como raiz |
| OPDK-967 | Ao definir o OpenLDAP para início automático usando set-autostart.sh, todos os status são informados como inativos |
| OPDK-905 | A produção do Smartdocs já foi registrada no grupo axgroup001 |
| OPDK-899 | Erro durante a integração |
| OPDK-847 | O usuário criado durante a integração não recebe o e-mail para redefinir a senha |
| OPDK-817 | Os scripts init.d geram um erro |
| OPDK-815 | O script ax-purge.sh requer a limpeza das tabelas de amostra |
| MGMT-2246 | A página "Criar relatório personalizado" não está sendo exibida corretamente na IU de gerenciamento |
| MGMT-2235 | Para certificados SSL que expiram, o tempo relativo de expiração pode ser arredondado de maneira confusa Para certificados SSL que expiram, o horário relativo da data de validade é sempre mostrado em dias, em vez de ser arredondado para até meses, quando o certificado expira em 90 dias ou menos. |
| MGMT-2193 | Como carregar o controle giratório ao editar uma API |
| MGMT-2173 (em inglês) | A IU do Trace não permite URLs legais A IU do Trace agora permite enviar solicitações com valores de parâmetro de consulta que contêm parâmetros de consulta aninhados. |
| MGMT-2162 | Problema de compilação em JavaScript |
| MGMT-2124 | As permissões do papel do cliente são redefinidas ao salvar as permissões na IU |
| GMT 2114 | O IP syslog inválido na política do MessageLogging precisa gerar o erro correto durante a implantação |
| MGMT-2067 | Trace: se a revisão do proxy de API foi implantada em dois ambientes, selecionar a revisão e o ambiente não funcionará corretamente |
| MGMT-2061 | Esqueci a senha e só enviaria e-mails para usuários registrados O link "Esqueceu a senha?" na página de login da IU de gerenciamento só envia e-mails para usuários registrados da Apigee. |
| MGMT-2048 | O usuário com papel personalizado que limita as permissões de implantação a um ambiente pode implantar em outros |
| MGMT-2041 | Remover o elemento FaultRules do modelo de anexo 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 | Buscar WSDL retorna falha: "Erro de busca de WSDL: erro ao processar WSDL." |
| MGMT-1986 | Erro de IU ao adicionar o desenvolvedor |
| 1983 | Receber uma API de código de autorização OAuth 2.0 com status incorreto |
| MGMT-1962 | Erro ao fazer login na IU de gerenciamento com uma senha forte O login na IU com determinados caracteres especiais, como o sinal de porcentagem, não falha mais. |
| MGMT-1947 | Papéis não intuitivos na IU 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 IU para criar e editar uma política de gravação de transações 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 do produto podem ser excluídos se o usuário clicar duas vezes no botão "Salvar". Esse problema foi corrigido. |
| MGMT-1894 | A página "Apps do desenvolvedor" nunca termina de carregar para a coluna do desenvolvedor |
| MGMT-1882 | O novo proxy de API da WSDL mostra somente os detalhes do último parâmetro |
| MGMT-1878 | Se várias revisões forem implantadas em um ambiente, o Trace mostrará apenas uma delas |
| MGMT-1872 | Não é possível fazer o download de relatórios personalizados |
| MGMT-1863 | Registros do Node.js não visíveis na IU de gerenciamento |
| MGMT-1843 | O proxy de API não abre |
| MGMT-1833 | O usuário sysadmin não pode ter a opção de alterar a senha na IU do OPDK |
| MGMT-1825 | Bugs de scripting em vários locais (XSS) |
| MGMT-1824 | Erro ao buscar o arquivo WSDL ao importar o arquivo WSDL com a extensão .xml |
| MGMT-1812 | Adicionar validação de TargetEndpoint durante a importação Semelhante ao ProxyEndpoint, o TargetEndpoint será validado para o esquema e as expressões adequados usados 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 usada para mostrar registros não formatados se os dados json tiverem caracteres inválidos. Isso foi corrigido nesta versão, e a IU agora mostra registros bem formatados de node.js. |
| MGMT-1802 | URL de redefinição de senha no 118 Se a IU de gerenciamento estiver protegida por um servidor de terminações SSL, a IU de gerenciamento agora gerará corretamente um e-mail de redefinição de senha com um link para um URL https em vez de um URL http. |
| MGMT-1799 | Solicitação de envio de vulnerabilidade de segurança da IU no Trace |
| MGMT-1777 | Não é possível adicionar um usuário com um endereço de e-mail que tenha um domínio TLD ".acn" |
| MGMT-1735 | Erro de marca ao buscar W" Remoção imediata do suporte à marca personalizada no Edge OPDK. Embora saibamos que isso pode decepcionar os poucos clientes que a utilizavam, esse não é um recurso que melhora diretamente os recursos do Edge em relação ao gerenciamento de APIs. |
| MGMT-1569 | Problema ao anexar proxy de API a um produto de API existente Correção de anexação de um proxy de API a um produto de API na IU de gerenciamento quando o proxy de API tinha um recurso para o caminho "/". |
| MGMT-1563 | O botão "Enviar" no Trace permanece desativado se encontrar um erro |
| MGMT-1362 | O e-mail "Esqueci a senha" não funciona quando o endereço de e-mail contém "_". Corrija o problema de redefinição de senha no OPDK com endereços de e-mail que contenham sublinhado. |
| MGMT-1345 | A importação de WSDL com vários namespaces resulta na criação incorreta da etapa SOAP |
| MGMT-1193 | Salvar o proxy como nova revisão muda inesperadamente a regra de rota |
| MGMT-1061 | SmartDocs: descrição do parâmetro de tipo de corpo na definição do Swagger não mostrada na IU do documento |
| MGMT 800 | Criar um recurso com o nome "default" resulta na falha da IU |
| MGMT 787 | Problema de usabilidade de alerta da IU Na IU de gerenciamento, ao clicar em "+ Proxy de API" e a caixa de diálogo "Novo proxy de API" for exibida, pressione Esc para dispensar a caixa de diálogo. |
| MGMT 619 | Ativar a paginação na página da IU do proxy de API |
| MGMT 602 | Visualização de desenvolvimento do proxy de API: adição de uma política de cache de resposta quando o endpoint não tem um erro "PreFlow/PostFlow" |
| MGMT-460 | A renomeação da política resulta em comportamento incorreto, não é possível remover a política duplicada |
| DEVRT-1644 | A busca de notificações por nome faz com que o e-mail errado seja enviado |
| DEVRT-1583 | A IU de monetização mostra o selo "Futuro" para um plano de tarifas atual |
| DEVRT-1546 | Os limites do plano não funcionam |
| DEVRT-1511 | Erro mint.resourceDoesNotExist para um desenvolvedor existente |
| CORERT-639 | O TCPSysLogSocket precisa ser assíncrono |
| CORERT-613 | Falhas no handshake de SSL devido a "unrecognize_name" |
| AXAPP-1728 | Ignorar variáveis de monetização no Analytics |
| AXAPP-1708 | A API Analytics parece produzir números diferentes para a mesma estatística, dependendo de como eu perguntar |
| AXAPP-1707 | Melhore o desempenho da análise sem custo financeiro de pods |
| AXAPP-1690 | "Erro de API inválido" nos relatórios personalizados |
| AXAPP-1533 | O Geomap do Google 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 gerar hash de tokens sem hash |
| APIRT-1425 | O atributo continueOnError quando definido como "true" não afeta a política JavaCallout |
| APIRT-1346 | OAuth2.0: o valor com hash é retornado na resposta do token de acesso quando hash.oauth.tokens.enabled é verdadeiro |
| APIRT-1206 | target_ip não é registrado na tabela de fatos para a maioria dos 503s |
| APIRT-1170 | O arquivo de recurso ausente causou uma falha ao carregar um ambiente no MP |
| APIRT-1148 | GET da variável {message.version} no ResponseFlow, para um destino Node.js, gera NPE |
| APIRT-1054 | O Message Logging falha ao tentar fazer login em um diretório diferente do padrão |
| APIRT-387: | Fazer o OrganizationService funcionar para outros tipos de MP |
| APIRT-67 | A política GenerateAccessAccess do OAuth não define a variável oauthV2.failed corretamente |
| APIRT-52 | Relatórios personalizados: o código de status da resposta para muitas APIs é nulo |
Problemas conhecidos
Esta versão tem os seguintes problemas conhecidos.
| Id do problema | Descrição |
|---|---|
| OPDK-1586 |
O portal BaaS da API não será iniciado se o suporte ao IPV6 não estiver ativado
|
| OPDK-1785 |
Instalar o componente de monetização no ambiente instalado do Edge atualizado
A solução alternativa é definir a versão de monetização correta no arquivo apigee-env.sh antes de tentar instalar a monetização. Para instalar a versão da Monetização na 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 executar as etapas acima, a instalação falhará e provavelmente há um link simbólico inativo no diretório de compartilhamento. Você precisa remover esse link simbólico:
> rm /install-dir/apigee4/share/monetization
Depois de remover o symlink, siga as etapas acima para definir a versão da monetização e tente instalar a monetização novamente.
|
| OPDK-1857 |
Versão codificada em Python 2.6 em 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 o Python versão 2.6. A solução para esse problema é alterar 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 a versão do Python no diretório /opt/apigee4/share/apache-qpid/lib. O diretório provavelmente é o python2.7. Em seguida, você precisa atualizar a configuração PYTHONPATH em qpid-stat.sh e qpid-config.sh com o caminho correto. Por exemplo:
|
| DEVRT-1574 | Saldo e uso inconsistentes para desenvolvedores com vários planos de tarifas ativos Na monetização, se um desenvolvedor estiver ativo em mais de um plano com tarifas de chamada por API, o uso do saldo monetário às vezes poderá ser inconsistente. |
| APIBAA-1647 | Após o login como administrador do sistema, a IU do BaaS emite a mensagem "Erro ao acessar os papéis" Essa mensagem de erro aparece no primeiro login no sistema pelo administrador do sistema após o upgrade de 4.15.01 para 4.15.07. Você pode ignorar esta mensagem. |
| DEVRT-1834 |
Upgrade da monetização para a versão 4.15.07 O script apigee-upgrade.sh imprime a seguinte mensagem no final, solicitando 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 é obrigatório e não pode ser executado. |
| DEVRT-1951 |
Nova instalação de monetização sem configurações de notificação
Em uma nova instalação do Apigee Edge para nuvem privada versão 4.15.07.00, as seguintes configurações de notificações de monetização estão ausentes. Elas correspondem aos tipos de notificação na página Administrador > Notificações na IU 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 solucionar esse problema, siga estas etapas. Você precisará do endereço IP da sua instância do Cassandra. Para encontrá-lo, acesse <installation-root>/apigee4/conf/cassandra/cassandra.yaml ou
<installation-root>/apigee4/conf/cassandra/cassandra-topology.properties.
|
| DEVRT-1952 |
Upgrade da monetização do 4.14.07.00 sem configurações de notificação
Em um upgrade do Apigee Edge para nuvem privada da versão 4.14.07.00 para 4.15.07.00, as seguintes configurações de 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 solucionar esse problema, siga estas etapas. Você precisará do endereço IP da sua instância do Cassandra. Para encontrá-lo, acesse <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 várias instalações de data center No guia de instalação do Edge, é possível definir os nomes dos pods como "gateway-1" e "gateway-2" nos arquivos de instalação silenciosa para uma instalação de vários data centers. No entanto, renomear o pod impede que os roteadores e os processadores de mensagens sejam registrados corretamente e fiquem acessíveis. Esse problema também impede que o script setup-org.sh seja capaz de encontrar 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/32
Em 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 precisarão de acesso à porta 8080 no servidor de gerenciamento No ambiente de execução, os seguintes componentes exigem acesso à porta 8080 no servidor de gerenciamento: roteador, processador de mensagens, IU, Postgres e Qpid. No entanto, ao fazer upgrade, todos os nós precisarão 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 Edge após o upgrade Se você configurou a API Edge para usar SSL antes de fazer upgrade para 4.15.07.00, reconfigure o SSL após o upgrade. Consulte o Guia de operações do Edge para ver o procedimento para configurar o SSL para a API Edge. |