4.15.07.00 - Note di rilascio di Apigee Edge per Private Cloud

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Martedì 8 settembre 2015 abbiamo rilasciato un'importante release di funzionalità di Apigee Edge per il cloud privato.

Dalla precedente release trimestrale di Edge per Private Cloud (4.15.04.00), si sono verificate le seguenti release, incluse in questa release trimestrale:

• Cloud: 15.04.15, 15.04.29, 15.05.27, 15.06.10 e 15.06.24
• Cloud privato: 4.15.04.01

Versioni di Edge di cui puoi eseguire l'upgrade alla 4.15.07.00

A seconda della versione corrente di Edge, puoi:

• Direttamente l'aggiornamento a 4.15.07.00
• Upgrade in modo incrementale, il che significa che devi eseguire l'upgrade dalla versione attuale a un'altra versione di Edge per poi eseguire l'upgrade alla versione 4.15.07.00.

Per maggiori informazioni, consulta Quali versioni di Edge per Cloud privato puoi eseguire l'upgrade alla versione 4.15.07.00.

Prima di eseguire l'upgrade dalla versione 4.15.01.x o da una versione precedente

1. Controlla la versione SSTable di Cassandra:
   1. Cambia la directory in /<install-root>/apigee4/data/cassandra/data.
   2. Esegui un comando "find",
      > trova . -name *-ic-*
      I risultati dovrebbero restituire un insieme di file .db se utilizzi Cassandra 1.2 SSTable.
   3. Esegui questo comando "find":
      > trova . -name *-hf-*
      I risultati dovrebbero essere vuoti, vale a dire che nessun file .db è in formato hf. Se non vedi file nel formato hf, significa che hai finito e puoi eseguire l'upgrade alla versione 4.15.07.00.
      
      Il formato hf è per le SSTables Cassandra 1.0. Se disponi di file *.db nel formato hf, devi eseguire l'upgrade di SSTable come descritto nel resto della procedura.
2. Se trovi file *.db nel formato hf, esegui l'upgrade di SSTable eseguendo il comando seguente su ogni nodo Cassandra fino a quando non avrai eseguito l'upgrade di tutti i nodi Cassandra:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradestables -a
3. Ripeti il passaggio 1 per verificare che tutti i file *.db siano nel formato ic per la versione Cassandra 1.2.
4. Ripeti i passaggi da 1 a 3 su ogni nodo Cassandra nell'installazione di Edge.
5. Esegui l'upgrade a Edge 4.15.07.00.
6. Dopo l'upgrade 4.15.07.00, controlla i file *.db per assicurarti che siano stati tutti aggiornati allo sstable in stile C* 2.0:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . -name *-jb-*
   Questo comando dovrebbe restituire un insieme di file .db se utilizzi Cassandra 2.0.

Nuove funzionalità e miglioramenti

Di seguito sono riportate le nuove funzionalità e i miglioramenti di questa release.

Installazione ed upgrade

Upgrade e disinstallazione di componenti selettivi

Gli script apigee-upgrade.sh e apigee-apigee.sh consentono ora di selezionare i componenti Edge da eseguire l'upgrade o la disinstallazione. In precedenza, eseguiva l'upgrade o la disinstallazione di tutti i componenti sul nodo. (OPDK-1377, OPDK-1175)

Rollback dell'upgrade

Se apigee-upgrade.sh ha esito negativo durante un upgrade, ora puoi utilizzare lo script apigee-rollback.sh per eseguirne il rollback. Dopo aver risolto eventuali problemi di upgrade, puoi riprovare a eseguirlo. (OPDK-1275)

Opzioni abbreviate per lo script del programma di installazione

Gli script di installazione non assumono più la forma estesa di opzioni, come --help. Ora possono utilizzare solo opzioni con una sola lettera, ad esempio -h. (OPDK-1356)

Installazione SmartDocumenti

Quando installi SmartDocumenti con lo script setup-smartdocs.sh, ti viene richiesto di inserire l'organizzazione, l'ambiente e l'host virtuale, in modo che SmartDocumenti sia installato nella posizione prevista. In precedenza, questi valori erano hardcoded nello script. (OPDK-1310)

Esecuzione di update-cass-pwd-in-config.sh senza prompt

Lo script update-cass-pwd-in-config.sh può essere eseguito senza prompt se imposti le variabili di ambiente ENABLE_CASS_AUTH, CASS_USERNAME e CASS_PASSWORD. (OPDK-1309)

Piattaforma perimetrale

Di seguito sono riportate le nuove funzionalità della piattaforma Edge incluse in questa release.

OpenJDK 1.7 supportato da Edge Private Cloud

Questa release di Edge supporta Oracle JDK 1.7 e OpenJDK 7 e ha rimosso il supporto per JDK 1.6. (OPDK-1187)

Supporto per sistemi operativi

Apigee Edge per il cloud privato ha esteso il supporto del sistema operativo per includere Red Hat Enterprise Linux 6.6 e 7.0 (64 bit), CentOS 6.5, 6.6 e 7.0 (64 bit) e Oracle Linux 6.5.

Cassandra 2.0.15 incluso in OPDK 15.07

Questa release installa Cassandra 2.0.15. Se esegui l'upgrade per una release precedente, la versione di Cassandra verrà aggiornata. (OPDK-1197)

Supporto SHA2 per l'hashing dei token OAuth

Per proteggere meglio i token OAuth in caso di violazione della sicurezza del database, Edge supporta gli algoritmi SHA2 per l'hashing dei token OAuth (oltre a SHA1). Con le nuove proprietà a livello di organizzazione, puoi attivare e configurare l'hashing per i nuovi token, nonché mantenere l'hashing precedente su tutti i token esistenti prima di questa nuova funzionalità. In precedenza, in Edge per Cloud privato, una proprietà chiamata hash.oauth.tokens.enabled nel file keymanagement.properties (sul server di gestione e sui processori dei messaggi) abilitava l'hashing SHA1 automatico dei token OAuth. Questa proprietà è ora deprecata.

Se in precedenza hai utilizzato la proprietà hash.oauth.tokens.enabled per abilitare l'hashing SHA1, lo script di upgrade per questa release genera automaticamente le nuove proprietà a livello di organizzazione. Per verificare dopo l'upgrade, esegui una richiesta GET come amministratore di sistema con questa API: https://{host}:{port}/v1/o/{your_org}.

• Per informazioni sull'abilitazione dell'hashing dei token nella tua organizzazione con le nuove proprietà, consulta la sezione "Hashing dei token nel database" nell'argomento Richiesta di token di accesso.
• Per informazioni sull'hashing in blocco dei token esistenti, consulta la guida operativa di Edge per Cloud privato. (APIRT-1389)

Struttura della directory piatta per i file di log

Puoi configurare Edge per l'archiviazione dei file di log in una struttura di directory semplice impostando una nuova proprietà enable.flat.directory.structure su true nel file message-logging.properties. Per maggiori informazioni, consulta la sezione Criterio di logging dei messaggi. (APIRT-1394)

Prestazioni della cache dell'ambiente

Per migliorare la gestione e l'utilizzo della cache in memoria, l'impostazione "Numero massimo di elementi in memoria" sulle risorse della cache dell'ambiente è stata ritirata. Gli elementi totali presenti in tutte le risorse della cache (inclusa la cache predefinita) dipendono dalla memoria totale allocata alla cache. Per impostazione predefinita, la memoria totale allocata per la memorizzazione nella cache in memoria su un determinato processore di messaggi è pari al 40% della memoria totale disponibile, determinata dalle impostazioni delle proprietà della cache nel file cache.properties del processore di messaggi. Gli elementi verranno rimossi dalla cache in memoria solo se la memoria cache è insufficiente o se scadono.

Per ripristinare il comportamento precedente di utilizzo della proprietà "Numero massimo di elementi in memoria" per la gestione della cache, imposta la proprietà overrideMaxElementsInCacheResource=false nel file cache.properties. (APIRT-1140)

Servizi API

Di seguito sono riportate le nuove funzionalità dei servizi API incluse in questa release.

Nuovo editor proxy predefinito

Il nuovo editor proxy API è abilitato per impostazione predefinita nell'interfaccia utente di gestione. Il nuovo editor include molti miglioramenti di usabilità, tra cui visualizzazioni più complete di flussi ed endpoint condizionali nella pagina Panoramica, tutta la configurazione nella pagina Sviluppo, aggiunta più intuitiva di flussi condizionali, endpoint e criteri, visualizzazioni XML più complete anziché piccoli snippet, ricerca che esegue la scansione di nomi file e testo e altro ancora. (MGMT-2279)

Nuovo criterio di eliminazione delle informazioni OAuth v2.0

Il nuovo criterio "Elimina informazioni OAuth v2.0" consente di eliminare i token di accesso e i codici di autorizzazione OAuth v2. Il criterio sostituisce la funzionalità precedentemente fornita dall'API di gestione. Per maggiori informazioni, consulta la sezione Eliminare i criteri relativi alle informazioni OAuthV2. (MGMT-2257)

Nuovo criterio di eliminazione delle informazioni OAuth v1.0

Il nuovo criterio "Elimina informazioni OAuth v1.0" consente di eliminare token di richiesta OAuth v1.0, token di accesso e codici di verifica. Il criterio sostituisce la funzionalità precedentemente fornita dall'API di gestione. Per maggiori informazioni, consulta l'articolo Eliminare i criteri relativi alle informazioni OAuth V1. (APIRT-1351)

Criterio di controllo dell'accesso

Il criterio di controllo dell'accesso è stato migliorato per consentire una valutazione più granulare degli indirizzi IP per l'inserimento nella lista consentita e nella lista bloccata quando gli indirizzi IP sono contenuti nell'intestazione HTTP X-FORWARDED-FOR.

Con il controllo multiplo di indirizzi IP abilitato nell'intestazione (contatta l'assistenza per impostare feature.enableMultipleXForwardCheckForACL), un nuovo elemento <ValidateBasedOn> nel criterio consente di eseguire il confronto rispetto al primo IP, all'ultimo IP o a tutti gli IP nell'intestazione. Per ulteriori informazioni, vedi Criterio di controllo dell'accesso.

Nuove entità nel criterio delle entità di accesso

Il criterio dell'entità di accesso consente di accedere alle seguenti nuove entità: ambito consumerkey, codice di autorizzazione, token di richiesta e verificatore. Per ulteriori informazioni, consulta la pagina relativa ai criteri relativi alle entità di accesso.

Criterio del raccoglitore statistiche: conversione automatica del nome delle statistiche in minuscolo

Quando crei una raccolta di analisi personalizzata nell'editor proxy API (pagina Sviluppo > Strumenti > Raccolta personalizzata di Analytics), il "Nome" della variabile del raccoglitore (statistica) deve essere minuscolo. Se inserisci il nome con lettere maiuscole, lo strumento converte automaticamente in minuscolo il nome delle statistiche nel criterio del raccoglitore di statistiche. (MGMT-740)

Rimozione della traccia classica nell'editor proxy API

La versione più recente della funzionalità Trace nell'editor proxy API è passata dalla versione beta alla disponibilità generale. L'accesso alla "traccia classica" con il link "Accedi alla versione classica della traccia" non è più disponibile.

Accesso alla community Apigee dal menu Guida dell'interfaccia utente di gestione

Puoi accedere alla community Apigee dal menu Guida dell'interfaccia utente di gestione.

Messaggi di errore nell'interfaccia utente di gestione

Di seguito sono riportati i miglioramenti ai messaggi di errore nell'interfaccia utente di gestione:

• La UI di gestione utilizzata per raggruppare e visualizzare tutti i messaggi di errore nella UI per l'intera sessione di accesso, a meno che tu non li abbia ignorati. Con questo aggiornamento, i messaggi di errore vengono cancellati automaticamente quando esci dalla pagina in cui si sono verificati. (MGMT-2254)
• L'interfaccia utente di gestione non elimina più i messaggi di errore duplicati. (MGMT-2242)

Prestazioni dell'interfaccia utente e miglioramenti degli errori

Sono stati apportati miglioramenti generali a diverse aree dell'interfaccia utente di gestione, tra cui le prestazioni di visualizzazione delle pagine e la pulizia dei messaggi di errore.

Link ipertestuali dei ruoli nella pagina Utenti dell'organizzazione nell'interfaccia utente di gestione

Nella pagina Utenti dell'organizzazione nell'interfaccia utente di gestione (Amministratore > Utenti dell'organizzazione), i nomi dei ruoli sono ora collegati come link ipertestuale per consentirti di passare rapidamente alle pagine dei ruoli. (MGMT-1055)

Nuove variabili di destinazione nel flusso dei messaggi

Le nuove variabili nei flussi di messaggi forniscono informazioni URL più complete per gli endpoint e i server di destinazione:

• TargetEndpoint: request.url sostituisce target.basepath.with.query.
• TargetServer: loadbalancing.targetserver sostituisce targetserver.name. Inoltre, target.basepath viene compilato solo quando l'elemento <Path> viene utilizzato nell'elemento HTTPTargetConnection <LoadBalancer> di TargetEndpoint.

Supporto per SNI (Server Name Indication)

Edge supporta l'utilizzo dell'indicazione del nome del server in direzione sud (dal processore di messaggi agli endpoint di destinazione). Se desideri utilizzare SNI, contatta l'assistenza Apigee.

È richiesto Java 1.7.

Con SNI, che è un'estensione di TLS/SSL, più destinazioni HTTPS possono essere pubblicate sullo stesso indirizzo IP e sulla stessa porta senza che tutte le destinazioni utilizzino lo stesso certificato.

Non è richiesta alcuna configurazione specifica per Edge. Se il tuo ambiente è configurato per SNI in direzione sud (per impostazione predefinita il cloud Edge è configurato), Edge lo supporta.

Edge estrae automaticamente il nome host dall'URL della richiesta e lo aggiunge alla richiesta di handshake SSL. Ad esempio, se l'host di destinazione è https://example.com/request/path, Edge aggiunge l'estensione server_name come mostrato di seguito:

Per ulteriori informazioni su SNI, visita la pagina http://en.wikipedia.org/wiki/Server_Name_Indication.

"Algoritmo di firma" nei dettagli dei certificati SSL

Ai dettagli dei certificati SSL è stato aggiunto un nuovo campo "Algoritmo di firma", visibile nell'interfaccia utente di gestione (Amministratore > Certificati SSL) e nell'API di gestione (Ottenere dettagli certificati da un archivio chiavi o un archivio attendibilità). Il campo mostra "sha1WithRSAEncryption" o "sha256WithRSAEncryption", a seconda del tipo di algoritmo di hashing utilizzato per generare il certificato.

Visualizzazione dei certificati SSL prossimi alla scadenza

La pagina Certificati SSL nell'interfaccia utente di gestione (Amministratore > Certificati SSL) indica quando i certificati SSL scadono entro 10, 15, 30 o 90 giorni, a seconda della selezione nel campo del nuovo menu a discesa della scadenza.

Configurazione degli errori di protezione dalle minacce

Per impostazione predefinita, Edge genera un codice di stato di errore HTTP 500 interno del server e un errore ExecutionFailed se un messaggio non supera un criterio di protezione dalle minacce JSON o XML. Puoi modificare questo comportamento di errore con una nuova proprietà a livello di organizzazione. Quando la proprietà dell'organizzazione features.isPolicyHttpStatusEnabled viene impostata su true, si verifica il seguente comportamento:

• Richiesta: con un criterio di protezione dalle minacce associato a qualsiasi flusso di richiesta, i messaggi non validi restituiscono un codice di stato 400 e un messaggio di errore del criterio corrispondente.
• Risposta: con un criterio di protezione dalle minacce associato a qualsiasi flusso di risposta, i messaggi non validi restituiscono comunque un codice di stato 500 e viene visualizzato uno dei messaggi di errore del criterio corrispondenti (anziché solo ExecutionFailed).

I clienti Cloud devono contattare l'assistenza Apigee per impostare la proprietà dell'organizzazione. Questa funzionalità sarà disponibile per i clienti di Edge Private Cloud al prossimo rilascio trimestrale di Private Cloud.

Schemi aggiornati per endpoint, proxy e altre entità

Gli schemi di riferimento sono stati aggiornati per entità diverse dai criteri, come TargetEndpoint, ProxyEndpoint, APIProxy e molte altre. Consulta https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Servizi per gli sviluppatori

Di seguito sono riportate le nuove funzioni dei Servizi per gli sviluppatori incluse in questa release.

Disponibilità generale di SmartDocumenti

SmartDocumenti sta passando dalla versione beta alla disponibilità generale. Gli aggiornamenti e le nuove funzionalità includono:

• Supporto per Swagger 2.0, inclusa l'importazione per file o URL, incluso il supporto per oggetti di sicurezza con nomi personalizzati.
• Miglioramenti del design visivo nei modelli che generano SmartDocumenti.
• Miglioramenti a livello di usabilità e del flusso di lavoro nel Portale per gli sviluppatori, disponibili tramite il menu Contenuti > SmartDocumenti in Drupal.
• L'autenticazione nota come "token personalizzato" ora si chiama "Chiave API".
• Oggetti di "sicurezza" di autenticazione definiti a livello di revisione.
• Configurazione dell'autenticazione client a livello di modello. Le nuove revisioni non reimpostano più le credenziali client SmartDocumenti preconfigurate.

Per ulteriori descrizioni delle funzionalità, consulta questo post del blog.

Per la documentazione di SmartDocuments, vedi Utilizzare SmartDocs per documentare le API.

Nome dell'app sviluppatore visualizzato nell'interfaccia utente di gestione

Le app per sviluppatori in Edge hanno un nome interno che non cambia e un nome visualizzato modificabile. Nella pagina App sviluppatore nell'interfaccia utente di gestione (Pubblica > App sviluppatore > Nome app), viene mostrato il "Nome" interno dell'app insieme al "Nome visualizzato", in modo da poter identificare più facilmente le app in base ai loro nomi interni per la risoluzione dei problemi e la gestione delle API.

Servizi di analisi

Di seguito sono riportate le nuove funzionalità di Analytics Services incluse in questa release.

Limite di tempo per i dati conservati

Quando generi report di analisi con l'interfaccia utente o l'API di gestione, i dati che risalgono a più di sei mesi prima della data corrente non sono accessibili per impostazione predefinita. Se desideri accedere a dati risalenti a più di sei mesi fa, contatta l'Assistenza Apigee.

Rimozione della versione classica dei report personalizzati dall'interfaccia utente di gestione

La versione classica facoltativa dei report di analisi personalizzati non è più disponibile nella UI di gestione.

Rendimento del widget Coinvolgimento degli sviluppatori

Il widget della canalizzazione nella dashboard di analisi principale (sezione Coinvolgimento degli sviluppatori) è stato migliorato per fornire prestazioni migliori.

Monetizzazione

Di seguito sono riportate le nuove funzioni per la monetizzazione incluse in questa release.

Notifiche via email relative al piano tariffario

Un nuovo tipo di notifica via email relativo al piano tariffario consente di avvisare gli sviluppatori quando raggiungono un determinato limite di transazioni o di dollari nei piani tariffari con volume o bundle che hanno acquistato. Per maggiori dettagli, consulta Configurare le notifiche utilizzando i modelli di notifica.

Sincronizzazione dei periodi tariffa ricorrente e base di aggregazione

In un piano tariffario, potenzialmente, erano in vigore due diversi periodi di tempo:

• Periodo tariffa ricorrente, configurato nella scheda Tariffe di un piano tariffario, che determinava quando agli sviluppatori veniva addebitata una commissione ricorrente.
• Periodo di base di aggregazione, definito nel tariffario per i piani con banda a volume o con pacchetti, che ha determinato quando è stato reimpostato l'utilizzo del bundle per gli sviluppatori.

Questi due periodi sono ora sincronizzati. Quando in un piano tariffario sono presenti sia una tariffa ricorrente diversa da zero sia un tariffario con fasce di volume o un bundle, per entrambi viene utilizzato il periodo della tariffa ricorrente. Ad esempio, se è prevista una tariffa mensile ricorrente, anche i pacchetti di tariffari vengono reimpostati mensilmente (per impostazione predefinita all'inizio del mese).

Se non esiste una tariffa ricorrente, i pacchetti vengono reimpostati in base alla base di aggregazione definita nel tariffario. Ad esempio, se uno sviluppatore inizia a utilizzare un tariffario il 19 del mese e la base di aggregazione è ogni mese, l'utilizzo del bundle viene reimpostato un mese dopo il giorno 19.

La base di aggregazione è in fase di ritiro e verrà rimossa dalla monetizzazione in una release futura. Per ulteriori informazioni, consulta Specificare i dettagli del piano tariffario.

Attributi personalizzati nei report riepilogativi sulle entrate

Le norme di registrazione delle transazioni consentono di acquisire facoltativamente dati sugli attributi personalizzati delle transazioni e ora puoi includere questi attributi personalizzati nei report riepilogativi sulle entrate. Aggiungendo una proprietà MINT.SUMMARY_PERSONAL_ATTRIBUTES alla tua organizzazione, puoi indicare quali attributi personalizzati vengono aggiunti alle tabelle di database da utilizzare nei report.

I clienti di Apigee Edge per il cloud privato possono impostare il flag con la chiamata API e le credenziali di amministratore di sistema seguenti.

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

Tieni presente che l'array di attributi personalizzati nella chiamata API è codificato nell'URL.

Processo di upgrade di SmartDocumenti

Se hai già utilizzato SmartDocumenti durante il periodo beta, le nuove funzionalità e caratteristiche nella versione di disponibilità generale richiedono l'upgrade di SmartDocumenti nel tuo portale per gli sviluppatori.

Tutte le pagine SmartDocumenti già pubblicate nel tuo portale per gli sviluppatori continueranno a funzionare, ma devi seguire la procedura di aggiornamento prima di modificare o pubblicare eventuali modifiche a pagine nuove o esistenti.

Tieni presente che anche se puoi eseguire il rendering e la pubblicazione di SmartDocumenti all'interno del tuo portale per gli sviluppatori, gli SmartDocuments vengono generati dal modello API che si trova all'interno dei servizi di gestione delle API Edge di Apigee. Le modifiche apportate a un modello API in Edge saranno le stesse in tutti gli ambienti Pantheon (in modo simile a come esistono gli sviluppatori negli ambienti Pantheon).

Per eseguire l'upgrade dalla versione beta di SmartDocumenti alla disponibilità generale

1. Aggiorna e testa la release 15.05.27 nei tuoi ambienti dev o test su Pantheon.
2. Crea un nuovo modello per sostituire l'eventuale modello API esistente che utilizzi.
   • Se stai importando documenti Swagger o WADL, importali di nuovo in una nuova revisione.
   • Se stai gestendo il tuo modello API tramite il modulo SmartDocumenti, esportalo in formato JSON SmartDocuments e importalo nel nuovo modello utilizzando un file allegato.
3. Imposta le proprietà di sicurezza della revisione del modello. Nella pagina Contenuti > SmartDocumenti > modello, seleziona Impostazioni di sicurezza.
   
4. Verifica un'eventuale autenticazione preconfigurata nella pagina delle impostazioni del modello (Contenuti > SmartDocuments) facendo clic su Impostazioni nella colonna Operazioni.
   
5. Aggiorna gli eventuali modelli personalizzati per utilizzare la versione 6 degli asset CSS e JS e apporta modifiche in base ai nuovi nomi degli oggetti, ad esempio authSchemes e apiSchema. Per informazioni sull'aggiornamento dei modelli SmartDocumenti, vedi Utilizzare SmartDocs per documentare le API.
6. Esegui nuovamente il rendering e pubblica la revisione del modello.
7. Dopo aver convalidato la nuova documentazione, aggiorna il portale di produzione alla release 15.05.27.

Se sei un cliente Edge Enterprise e hai domande o dubbi sul processo di upgrade, invia un'email a marsh@apigee.com e cnovak@apigee.com. Altrimenti, utilizza la community Apigee per ricevere la risposta migliore.

Modifiche e miglioramenti futuri delle funzionalità

Questa sezione mostra in anteprima le modifiche e i miglioramenti futuri previsti per le funzionalità:

Modifica del comportamento del criterio della cache delle risposte

In una release futura (da determinare), il comportamento predefinito dell'elemento <EscludiErrorResponse> del criterio Cache delle risposte cambierà.

Comportamento attuale: l'elemento <EscludiErrorResponse> nel criterio della cache delle risposte è false per impostazione predefinita. Ciò significa che, per impostazione predefinita, le risposte con qualsiasi codice di stato HTTP possibile (incluso 3xx) vengono memorizzate nella cache in base al criterio Cache delle risposte.

Comportamento futuro: l'elemento <EscludiErrorResponse> nel criterio Cache di risposte viene impostato su true per impostazione predefinita. Ciò significa che, per impostazione predefinita, verranno memorizzate nella cache solo le risposte con codici di stato HTTP da 200 a 205. Per ignorare questo comportamento e memorizzare le risposte nella cache per tutti i codici di stato, devi impostare esplicitamente l'elemento <EscludiErrorResponse> su true.

Soluzione attuale: per Private Cloud 4.15.07.00 e release precedenti, se vuoi memorizzare nella cache solo le risposte con i codici di stato da 200 a 205, devi impostare esplicitamente l'elemento <EscludiErrorResponse> su true.

Bug corretti

In questa release sono stati corretti i bug indicati di seguito.

Problemi noti

Questa release presenta i problemi noti riportati di seguito.

> 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