4.15.07.00 - Notas de lançamento do Apigee Edge para nuvem privada

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Na terça-feira, 8 de setembro de 2015, lançamos uma grande versão de recurso do Apigee Edge para clientes Google Cloud.

Desde o lançamento trimestral anterior do Edge for Private Cloud (4.15.04.00), as seguintes que ocorreram e estão incluídas neste lançamento trimestral:

• Google Cloud: 15.04.15, 15.04.29, 15.05.27, 15.06.10 e 15.06.24
• Nuvem privada: 4.15.04.01

Para quais versões do Edge é possível fazer upgrade 4.15.07.00

Dependendo da versão atual do Edge, é possível:

• Fazer upgrade diretamente para 4.15.07.00
• Upgrade incremental, ou seja, é necessário fazer upgrade da versão atual para outra e faça upgrade para a versão 4.15.07.00.

Para mais informações, consulte Para qual borda da versão da nuvem privada é possível fazer upgrade 4.15.07.00.

Antes de fazer upgrade da versão 4.15.01.x ou de uma versão anterior

1. Verifique a versão do Cassandra SSTable:
   1. Altere o diretório para /<install-root>/apigee4/data/cassandra/data.
   2. Execute um comando de localização,
      > localizar . -name *-ic-*
      Se você estiver executando o Cassandra 1 .2 SSTable, os resultados retornarão um conjunto de arquivos.db.
   3. Execute este comando de localização:
      > localizar . -name *-hf-*
      Os resultados devem estar vazios, o que significa que nenhum arquivo .db está no formato hf. Se você não vir arquivos na hf, terá e 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, precisará atualizar o SSTable como descrito no restante deste procedimento.
2. Se você encontrar arquivos *.db no formato hf, faça o upgrade de SSTable executando o seguinte comando em cada nó do Cassandra até que você tenha feito upgrade de todos os nós do Cassandra. nós:
   &gt; /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables Um
3. Repita a etapa 1 para verificar se todos os arquivos *.db estão no formato ic para o Cassandra 1.2. para a versão anterior.
4. Repita as etapas de 1 a 3 em cada nó do Cassandra na instalação do Edge.
5. Faça upgrade para o Edge 4.15.07.00.
6. Após o upgrade para a versão 4.15.07.00, verifique os arquivos *.db para ter certeza de que todos eles foram atualizados ao estilo C* 2.0 estável:
   &gt; cd /&lt;install-root&gt;/apigee4/data/cassandra/data
   &gt; localizar . -name *-json-*
   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 seletiva de componentes

Os scripts apigee-upgrade.sh e apigee-Uninstall.sh agora permitem selecionar os componentes do Edge atualizar ou desinstalar. Anteriormente, todos os componentes do nó eram atualizados ou desinstalados. (OPDK-1377, OPDK-1175)

Reversão de upgrade

Se o apigee-upgrade.sh falhar durante um upgrade, você poderá usar o apigee-rollback.sh para reverter o upgrade. Depois de corrigir os problemas de upgrade, você pode tentar novamente. (OPDK-1275)

Opções reduzidas de script do instalador

Os scripts de instalação não assumem mais a forma longa de opções, como --help. Eles só agora aceitar 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ê será solicitado a inserir o organização, ambiente e host virtual, o que garante a instalação do SmartDocs local esperado. Antes, esses valores eram codificados no script. (OPDK-1310)

Como executar update-cass-pwd-in-config.sh sem prompts

O script update-cass-pwd-in-config.sh poderá ser executado sem prompts se você definir o ENABLE_CASS_AUTH, CASS_USERNAME e CASS_PASSWORD. (OPDK-1309)

Plataforma de borda

Veja a seguir os novos recursos do Edge Platform incluídos nesta versão.

OpenJDK 1.7 compatível com a nuvem privada do Edge

Esta versão do Edge oferece suporte ao Oracle JDK 1.7 e OpenJDK 7 e removeu o suporte para JDK 1.6. (OPDK-1187)

Suporte a SO

O Apigee Edge para nuvem privada expandiu o suporte ao sistema operacional para incluir a 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 incluído no OPDK 15.07

Esta versão instala o Cassandra 2.0.15. Se você estiver fazendo upgrade para uma versão anterior, seus do Cassandra será atualizada. (OPDK-1197)

Suporte a SHA2 para hash de token OAuth

Para proteger melhor os tokens OAuth em caso de uma violação de segurança do banco de dados, o Edge oferece suporte ao SHA2 algoritmos para gerar hash de tokens OAuth (além do SHA1). Com o novo nível de organização é possível ativar e configurar o hash de novos tokens e manter o hash legado. em tokens que existiam antes desse novo recurso. Antes no Edge para a nuvem privada, chamada hash.oauth.tokens.enabled no arquivo keymanagement.properties (no seu servidor de gerenciamento e processadores de mensagens) ativou o hash SHA1 automático de tokens OAuth. Isso foi descontinuada.

Se você usou anteriormente a propriedade hash.oauth.tokens.enabled para ativar o hash SHA1, o o script de upgrade para esta versão gera automaticamente as novas propriedades no nível da organização para você. Para verificar após o upgrade, execute 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 "Tokens de hash no banco de dados" na seção Solicitar tokens de acesso tópico.
• Para informações sobre como gerar hash de tokens atuais, consulte o Edge for Private Cloud Guia de operações APIRT-1389

Estrutura de diretórios simples para arquivos de registro

Para configurar o Edge para armazenar arquivos de registro em uma estrutura de diretórios simples, defina propriedade enable.flat.directory.structure como verdadeira em message-logging.properties . Para mais informações, consulte a Política de registro de mensagens. APIRT-1394

Desempenho do cache do ambiente

Para melhor gerenciamento e utilização do cache na memória, a opção "Máximo de elementos na memória" configuração nos recursos de cache do ambiente foi descontinuada. O total de elementos presentes todos os recursos de cache (inclusive o cache padrão) dependem da memória total alocada ao cache. Por padrão, a memória total alocada para armazenamento em cache na memória de um determinado processador de mensagens representa 40% da memória total disponível, determinado pelas configurações de propriedade de cache na sua mensagem arquivo cache.properties do processador. Os elementos serão removidos do cache na memória somente quando houver memória cache insuficiente ou os elementos expiram.

Para voltar ao comportamento antigo de usar o "Máximo de elementos na memória" para de cache, defina a propriedade overrideMaxElementsInCacheResource=false no 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 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 de visão geral, todas as configurações na página de desenvolvimento, 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 textos e muito mais. (MGMT-2279)

Nova política de exclusão de informações do OAuth v2.0

Uma nova opção "Excluir informações do OAuth v2.0" permite excluir tokens de acesso e autorização do OAuth v2 e códigos personalizados. A política substitui a funcionalidade fornecida pela API de gerenciamento. Para mais da conta, consulte Excluir Política de informações do OAuthV2. (MGMT-2257)

Nova política de exclusão de informações do OAuth v1.0

Uma nova opção "Excluir informações do OAuth v1.0" permite excluir tokens de solicitação do OAuth v1.0, acessar tokens e códigos de verificador. A política substitui a funcionalidade fornecida pelo API de gerenciamento. Para mais informações, consulte Excluir 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 avaliações mais refinadas de endereços IP para a lista de permissões e de bloqueio quando os endereços IP estiverem contidos no Cabeçalho HTTP X-FORWARDED-FOR.

Com a verificação de múltiplos endereços IP ativada no cabeçalho (entre em contato com o suporte para definir os feature.enableMultipleXForwardCheckForACL), uma o novo elemento <ValidateBasedOn> na política permite verificar o primeiro ou 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 entidade de acesso

A política Access Entity fornece acesso às seguintes novas entidades: consumerkey-scopes, o código de autorização, o token de solicitação e o verificador. Para mais informações, consulte a Política de entidade de acesso.

Política do coletor de estatísticas: 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" &gt; coleta personalizada do Analytics), a variável do coletor (estatística) "Nome" deve estar em minúsculas. Se você inserir o nome com letras maiúsculas, a ferramenta converterá automaticamente o nome da estatística para 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 do Trace no editor de proxy de API passou da versão Beta para disponibilidade geral. Acesso ao trace clássico com a opção "Acessar a versão clássica do trace" não está mais disponível.

Acesso à comunidade Apigee no menu de ajuda da interface de gerenciamento

É possível acessar a comunidade da Apigee no menu de ajuda da interface de gerenciamento.

Mensagens de erro na interface de gerenciamento

Veja a seguir melhorias nas mensagens de erro na interface de gerenciamento:

• A interface de gerenciamento usada para agrupar e exibir todas as mensagens de erro na interface do sessão de login, a menos que você as tenha dispensado. Com essa atualização, as mensagens de erro vão ser apagadas automaticamente quando você sai da página em que elas ocorreram. (MGMT-2254)
• A interface de gerenciamento não suprime mais as mensagens de erro duplicadas. (MGMT-2242)

Desempenho da interface e melhorias de erro

Melhorias gerais foram feitas em diferentes áreas da interface de usuário de gerenciamento, incluindo a exibição de páginas o desempenho e a 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", na IU de gerenciamento (Administrador > Usuários da organização), a função de funções agora têm hiperlinks, o que permite navegar rapidamente pelas páginas das funções. (MGMT-1055)

Novas variáveis de destino no fluxo de mensagens

Novas variáveis em fluxos de mensagens fornecem informações de URL mais completas para endpoints de destino e servidores de destino:

• TargetEndpoint: request.url substitui target.basepath.with.query.
• TargetServer: loadbalancing.targetserver substitui targetserver.name. Além disso, target.basepath é preenchido apenas quando o elemento <Path> é usado no Elemento HTTPTargetConnection <LoadBalancer>.

Compatibilidade com a indicação de nome do servidor (SNI, na sigla em inglês)

O Edge oferece suporte ao uso da indicação de nome do servidor no limite sul (do processador de mensagens ao destino endpoints). Se você quiser usar a SNI, entre em contato com o suporte da Apigee.

O Java 1.7 é obrigatório.

Com o SNI, que é uma extensão do TLS/SSL, vários destinos HTTPS podem ser veiculados do mesmo 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 o sentido sul O Edge oferece suporte a SNI (a nuvem do Edge é por padrão).

O Edge extrai automaticamente o nome do host do URL da solicitação e o adiciona à solicitação de handshake de SSL. Por exemplo, se o host de destino for https://example.com/request/path, O Edge adiciona 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 "algoritmo de assinatura" foi adicionado aos detalhes do certificado SSL, visível na de gerenciamento (Administrador > Certificados SSL) e a API de gerenciamento (Obter detalhes de um certificado de um Keystore ou Truststore). O campo mostra "sha1WithRSAEncryption" ou "sha256WithRSAEncryption", dependendo do tipo de algoritmo de hash usado para gerar a certificado.

Mostrando certificados SSL que estão próximos da expiração

A página "Certificados SSL" na interface do usuário de gerenciamento (Administrador > Certificados SSL) indica quando Os certificados SSL expiram em 10, 15, 30 ou 90 dias, dependendo da sua seleção no novo campo da lista suspensa 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 HTTP 500 de erro interno do servidor e um código 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 configurar a organização propriedade features.isPolicyHttpStatusEnabled como verdadeira, o seguinte do comportamento do usuário:

• 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 resposta, as mensagens inválidas ainda retorna 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 vai estar disponível para clientes da nuvem privada do Edge nos próximos lançamento trimestral da nuvem privada.

Esquemas atualizados para endpoints, proxies e outras entidades

Os esquemas de referência foram atualizados para entidades sem política, como TargetEndpoint, ProxyEndpoint, APIProxy e muitos outros. Consulte https://github.com/apigee/api-platform-samples/tree/master/schemas. APIRT-1249

Serviços para desenvolvedores

Veja a seguir os novos recursos dos serviços para desenvolvedores incluídos nesta versão.

Disponibilidade geral do SmartDocs

O SmartDocs está passando da versão Beta para a disponibilidade geral. Atualizações e novos recursos incluem:

• Suporte para Swagger 2.0, incluindo importação por arquivo ou URL, incluindo suporte para objetos de segurança com nomes personalizados.
• Melhorias de design visual nos modelos que geram SmartDocs.
• Melhorias de usabilidade e fluxo de trabalho no Portal do desenvolvedor, disponíveis na seção "Conteúdo" &gt; Menu SmartDocs no Drupal.
• O que é conhecido como "Token personalizado" a autenticação agora é chamada de "chave de API".
• "Segurança" da autenticação objetos 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 são mais redefinidas as credenciais de cliente pré-configuradas do SmartDocs.

Para mais descrições de recursos, confira este blog post.

Para a documentação do SmartDocs, consulte Como usar SmartDocs para documentar APIs do Google.

Nome do app do desenvolvedor exibido na interface de gerenciamento

Os apps do desenvolvedor no Edge têm um nome interno que não muda e um nome de exibição que que podem ser alteradas. Na página do aplicativo do desenvolvedor na interface do usuário de gerenciamento (Publicar > Aplicativos do desenvolvedor > nome do app), o "Nome" interno do app é exibido junto com o "Nome de exibição", facilitando para identificar visualmente os apps pelos nomes internos a fim de resolver problemas e gerenciar 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 para dados preservados

Ao gerar relatórios de análise com a interface ou API de gerenciamento, os dados com mais de seis meses a partir da data atual não pode ser acessada por padrão. Se você quiser acessar dados com mais de seis meses, entre em contato com o suporte da Apigee.

Versão clássica dos relatórios personalizados sendo removida da interface de gerenciamento

A versão clássica opcional dos relatórios de análise personalizados não está mais disponível no interface de usuário de gerenciamento de projetos.

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 melhorar o desempenho.

Monetização

Confira a seguir os novos recursos de monetização incluídos nesta versão.

Notificações por e-mail do plano de tarifação

Um novo tipo de notificação por e-mail do plano de tarifação permite que você notifique os desenvolvedores quando eles alcançarem um determinado transação ou limite em dólar nos planos de tarifas com faixas de volume ou pacotes que compraram. Para detalhes, consulte Configurar notificações usando modelos.

Sincronização dos períodos de taxa recorrente e base de agregação

Em um plano de tarifas, havia dois períodos diferentes em vigor:

• Período da taxa recorrente, configurado na guia "Taxas" de um plano de tarifas, que determinou quando dos desenvolvedores era cobrada uma taxa recorrente.
• É o período de base de agregação, definido na tabela de preços para planos de pacotes ou por volume, que é determinado 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 um volume estão agrupados ou a tabela de preços por pacote existir em um plano de tarifas, o período da taxa recorrente será usado para ambos. Por exemplo: se houver uma taxa mensal recorrente, os pacotes da tabela de preços também serão redefinidos todo mês (por padrão, no início do mês).

Se não houver taxas recorrentes, os pacotes serão redefinidos com base na base de agregação definida no na tabela de preços. Por exemplo, se um desenvolvedor começa a usar uma tabela de preços no dia 19 do mês, e o A base da agregação é mensal, e o uso do pacote é redefinido um mês após o dia 19.

A base de agregação será descontinuada e será removida da monetização no futuro lançamento. Para mais informações, consulte Especificar o plano da tabela de preços detalhes.

Atributos personalizados nos relatórios resumidos de receita

As políticas de registro de transações permitem capturar dados de atributos personalizados do transações. Além disso, agora é possível incluir esses atributos personalizados de transação no resumo de receita e detecção de ameaças. Ao adicionar uma propriedade MINT.SUMMARY_CUSTOM_ATTRIBUTES à sua organização, é possível 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 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">[&quot;my_attribute_1&quot;,&quot;my_attribute_2&quot;]</Property>
        <Property name="features.topLevelDevelopersAreCompanies">false</Property>
    </Properties>
</Organization>"

A matriz de atributos personalizados na chamada de API é codificada para uso em URL.

Processo de upgrade do SmartDocs

Se você já estiver usando o SmartDocs durante o período beta, os novos recursos e funcionalidades na versão de disponibilidade geral exigem que você atualize o SmartDocs em sua conta no portal do Google Cloud.

As páginas do SmartDocs que já foram publicadas no portal do desenvolvedor continuarão a funcionam, mas é necessário seguir o processo de atualização antes de editar ou publicar alterações em ou novas páginas.

Lembre-se de que é possível renderizar e publicar SmartDocs no portal do desenvolvedor, Os SmartDocs são gerados a partir do modelo de API que reside no gerenciamento de APIs Edge da Apigee Serviços. Todas as alterações feitas em um modelo de API no Edge serão as mesmas em todo o Pantheon (semelhante à forma como os desenvolvedores existem em ambientes Pantheon).

Para fazer upgrade do SmartDocs Beta para disponibilidade geral

1. Atualize e teste a versão 15.05.27 no os ambientes dev ou test Panteão.
2. Crie um novo modelo para substituir qualquer outro que você esteja usando.
   • Se você estiver importando documentos Swagger ou WADL, importe-os novamente para um novo revisão.
   • Se você mantém seu modelo de API no módulo SmartDocs, exporte como SmartDocs JSON e importar para o novo modelo usando anexo de arquivo.
3. Defina as propriedades de segurança da revisão do seu modelo. Na página Conteúdo > SmartDocs > do Google, selecione Configurações de segurança.
   
4. Verifique as autenticações pré-configuradas na página de configurações do modelo (Conteúdo > SmartDocs) clicando em Configurações na seção "Operações" .
   
5. Atualize os modelos personalizados para usar a v6 dos recursos CSS e JS e faça as alterações necessárias novos nomes de objetos, como authSchemes e apiSchema. Para informações sobre como atualizar o SmartDocs modelos, consulte Usar SmartDocs para documentar APIs.
6. Renderize novamente e publique a revisão do modelo.
7. Depois de validar a nova documentação, atualize seu portal de production para a versão 15.05.27.

Se você for um cliente corporativo de borda e tiver dúvidas sobre o upgrade envie um e-mail para marsh@apigee.com e cnovak@apigee.com. Caso contrário, use a comunidade da Apigee para saber resposta.

Futuras alterações e melhorias de recursos

Esta seção mostra uma prévia das mudanças e melhorias esperadas nos recursos:

Alterar para Comportamento da política de cache de resposta

Em uma versão futura (a ser determinado), o comportamento padrão da &lt;ExcludeErrorResponse&gt; da política do cache de resposta será alterado.

Comportamento atual: o elemento <ExcludeErrorResponse> no política de cache de resposta é falsa por padrão. Isso significa que, por padrão, respostas com qualquer código de status HTTP possível (incluindo 3xx) são armazenados em cache pela política do cache de resposta.

Comportamento futuro: o elemento <ExcludeErrorResponse> no Por padrão, a política de cache de resposta será definida como verdadeira. Isso significa que, por padrão, somente as respostas com HTTP Os códigos de status 200 a 205 serão armazenados em cache. Para substituir esse comportamento e armazenar em cache as respostas de todas códigos de status, você terá que definir o elemento <ExcludeErrorResponse> para true explicitamente.

Solução alternativa atual: para a nuvem privada 4.15.07.00 e versões mais antigas, se você quiser armazenar em cache apenas as respostas com os códigos de status 200 a 205, deverá definir explicitamente o elemento <ExcludeErrorResponse> como verdadeiro.

Bugs corrigidos

Os bugs abaixo foram corrigidos nesta versão.

Problemas conhecidos

Esta versão tem os problemas conhecidos a seguir.

> source /{install-dir}/apigee4/bin/apigee-env.sh 

> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4` 

> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh 

> rm /install-dir/apigee4/share/monetization 

************************************** 
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 
************************************** 

connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32

<install_dir>/apigge4/bin/apigee-service message-processor restart