4.15.07.00 - Note di rilascio di Apigee Edge for Private Cloud

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Martedì 8 settembre 2015 abbiamo rilasciato una versione principale di Apigee Edge for Private Cloud.

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

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

A quali versioni di Edge puoi eseguire l'upgrade 4.15.07.00

A seconda della versione attuale di Edge, puoi:

• Esegui l'upgrade diretto alla versione 4.15.07.00
• Esegui l'upgrade in modo incrementale, ovvero devi eseguire l'upgrade dalla versione attuale a un'altra versione di Edge, quindi eseguire l'upgrade alla versione 4.15.07.00.

Per ulteriori informazioni, consulta A quali versioni di Edge for Private Cloud 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 di Cassandra SSTable:
   1. Cambia directory in /<install-root>/apigee4/data/cassandra/data.
   2. Esegui un comando di ricerca,
      > find . -name *-ic-*
      I risultati dovrebbero restituire un insieme di file .db se esegui Cassandra 1.2 SSTable.
   3. Esegui questo comando di ricerca:
      > find . -name *-hf-*
      I risultati devono essere vuoti, il che significa che non sono presenti file .db nel formato hf. Se non vedi file in formato hf, hai terminato e puoi eseguire l'upgrade alla versione 4.15.07.00.
      
      Il formato hf è per le tabelle SSTable di Cassandra 1.0. Se hai file *.db nel formato hf, devi eseguire l'upgrade di SSTable come descritto nel resto di questa procedura.
2. Se trovi file *.db nel formato hf, esegui l'upgrade di SSTable eseguendo il seguente comando su ogni nodo Cassandra finché non avrai eseguito l'upgrade di tutti i nodi Cassandra:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -a
3. Ripeti il passaggio 1 per verificare che tutti i file *.db siano nel formato ic per la versione 1.2 di Cassandra.
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 alla versione 4.15.07.00, controlla i file *.db per assicurarti che siano stati tutti aggiornati alla 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 esegui Cassandra 2.0.

Nuove funzionalità e miglioramenti

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

Installazione e upgrade

Upgrade e disinstallazione selettivi dei componenti

Gli script apigee-upgrade.sh e apigee-uninstall.sh ora ti consentono di selezionare i componenti Edge da aggiornare o disinstallare. 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 non riesce durante un upgrade, ora puoi utilizzare lo script apigee-rollback.sh per eseguire il rollback dell'upgrade. Dopo aver risolto eventuali problemi di upgrade, puoi riprovare. (OPDK-1275)

Opzioni dello script di installazione abbreviato

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

Installazione di SmartDocs

Quando installi SmartDocs con lo script setup-smartdocs.sh, ti viene chiesto di inserire l'organizzazione, l'ambiente e l'host virtuale, il che garantisce che SmartDocs venga installato nella posizione prevista. In precedenza, questi valori erano codificati 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 edge

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 non supporta più JDK 1.6. (OPDK-1187)

Supporto per sistemi operativi

Apigee Edge for Private Cloud ha ampliato 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 da una release precedente, la tua versione di Cassandra verrà aggiornata. (OPDK-1197)

Supporto di 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é conservare l'hashing legacy per i token esistenti prima di questa nuova funzionalità. In precedenza in Edge for Private Cloud, una proprietà denominata hash.oauth.tokens.enabled nel file keymanagement.properties (sul server di gestione e sui processori di messaggi) consentiva l'hashing SHA1 automatico dei token OAuth. Questa proprietà è ora deprecata.

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

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

Struttura di directory piatta per i file di log

Puoi configurare Edge in modo che memorizzi i file di log in una struttura di directory piatta impostando una nuova proprietà enable.flat.directory.structure su true nel file message-logging.properties. Per saperne di più, consulta le norme relative alla registrazione dei messaggi. (APIRT-1394)

Prestazioni della cache dell'ambiente

Per una migliore gestione e utilizzo della cache in memoria, le impostazioni "Numero massimo di elementi in memoria" nelle risorse della cache dell'ambiente sono state ritirate. Il numero totale di elementi presenti in tutte le risorse della cache (inclusa la cache predefinita) dipende 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 è il 40% della memoria totale disponibile, determinata dalle impostazioni della proprietà della cache nel file cache.properties del processore di messaggi. Gli elementi verranno eliminati dalla cache in memoria solo quando la memoria della cache è insufficiente o gli elementi scadono.

Per ripristinare il vecchio comportamento 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à di API Services incluse in questa release.

Nuovo editor proxy come predefinito

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

Nuovo criterio Elimina informazioni OAuth v2.0

Una nuova norma "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 saperne di più, consulta le norme relative alle informazioni OAuthV2. (MGMT-2257)

Nuovo criterio Elimina informazioni OAuth v1.0

Un nuovo criterio "Elimina informazioni OAuth v1.0" ti consente di eliminare i token di richiesta, i token di accesso e i codici di verifica OAuth v1.0. Il criterio sostituisce la funzionalità precedentemente fornita dall'API di gestione. Per maggiori informazioni, consulta le norme relative all'eliminazione delle 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 le liste consentite e le liste bloccate quando gli indirizzi IP sono contenuti nell'intestazione HTTP X-FORWARDED-FOR.

Se è abilitato il controllo di più indirizzi IP nell'intestazione (contatta l'assistenza per impostare la funzionalità feature.enableMultipleXForwardCheckForACL), un nuovo elemento <ValidateBasedOn> nel criterio ti consente di eseguire il controllo in base al primo IP, all'ultimo IP o a tutti gli IP nell'intestazione. Per saperne di più, consulta la policy di controllo dell'accesso.

Nuove entità nella policy Access Entity

Il criterio Entità di accesso fornisce l'accesso alle seguenti nuove entità: consumerkey-scopes, authorizationcode, requesttoken e verifier. Per saperne di più, consulta Policy di accesso all'entità.

Policy di Statistics Collector: conversione automatica del nome delle statistiche in minuscolo

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

Rimozione di Trace classico nell'editor proxy API

L'ultima versione 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 della UI di gestione

Puoi accedere alla community Apigee dal menu Guida della UI di gestione.

Messaggi di errore nell'interfaccia utente di gestione

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

• L'interfaccia utente di gestione utilizzata per raggruppare e visualizzare tutti i messaggi di errore nell'interfaccia utente per l'intera sessione di accesso, a meno che non li abbia chiusi. 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)

Miglioramenti delle prestazioni e degli errori dell'interfaccia utente

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

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

Nella pagina Utenti dell'organizzazione dell'interfaccia utente di gestione (Amministrazione > Utenti dell'organizzazione), i nomi dei ruoli ora sono collegamenti ipertestuali, che ti consentono di accedere rapidamente alle pagine dei ruoli. (MGMT-1055)

Nuove variabili di destinazione nel flusso di messaggi

Le nuove variabili nei flussi di messaggi forniscono informazioni più complete sull'URL per gli endpoint di destinazione 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 dell'indicazione nome server (SNI)

Edge supporta l'utilizzo di Server Name Indication in uscita (dal processore di messaggi agli endpoint di destinazione). Se vuoi utilizzare SNI, contatta l'assistenza Apigee Edge.

È necessario Java 1.7.

Con SNI, un'estensione di TLS/SSL, è possibile pubblicare più target HTTPS dallo stesso indirizzo IP e dalla stessa porta senza richiedere che tutti i target utilizzino lo stesso certificato.

Non è necessaria alcuna configurazione specifica per Edge. Se il tuo ambiente è configurato per SNI in uscita (il cloud perimetrale è predefinito), 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

Un nuovo campo "Algoritmo di firma" è stato aggiunto ai dettagli del certificato SSL, visualizzabile nell'interfaccia utente di gestione (Amministrazione > Certificati SSL) e nell'API di gestione (Ottieni dettagli certificato da un keystore o un truststore). Il campo mostra "sha1WithRSAEncryption" o "sha256WithRSAEncryption", a seconda del tipo di algoritmo di hashing utilizzato per generare il certificato.

Visualizzazione dei certificati SSL in scadenza

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

Errore di configurazione della protezione dalle minacce

Per impostazione predefinita, Edge genera un codice di stato HTTP 500 Internal Server Error 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 imposti la proprietà dell'organizzazione features.isPolicyHttpStatusEnabled su true, si verifica il seguente comportamento:

• Richiesta: con una norma di protezione dalle minacce allegata a qualsiasi flusso di richieste, i messaggi non validi restituiscono un codice di stato 400, insieme a un messaggio di errore della norma corrispondente.
• Risposta: con una policy di protezione dalle minacce collegata a qualsiasi flusso di risposta, i messaggi non validi restituiscono comunque un codice di stato 500 e viene generato uno dei messaggi di errore della policy corrispondenti (anziché solo ExecutionFailed).

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

Schemi aggiornati per endpoint, proxy e altre entità

Gli schemi di riferimento sono stati aggiornati per le entità non correlate alle norme, come TargetEndpoint, ProxyEndpoint, APIProxy e molte altre. Vedi https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Servizi per gli sviluppatori

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

Disponibilità generale di SmartDocs

Smart Docs passerà dalla versione beta alla disponibilità generale. Gli aggiornamenti e le nuove funzionalità includono:

• Supporto di Swagger 2.0, incluso l'importazione per file o URL, incluso il supporto per oggetti di sicurezza con nome personalizzato.
• Miglioramenti al design visivo nei modelli che generano Smart Docs.
• Miglioramenti dell'usabilità e del flusso di lavoro nel portale per sviluppatori, disponibili tramite il menu Contenuti > Smart Docs in Drupal.
• L'autenticazione nota come "token personalizzato" è ora denominata "chiave API".
• Oggetti "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 SmartDocs preconfigurate.

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

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

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

Le app per sviluppatori in Edge hanno sia un nome interno che non cambia sia un nome visualizzato che puoi modificare. In una pagina dell'app per sviluppatori nell'interfaccia utente di gestione (Pubblica > App per sviluppatori > nome dell'app), il "Nome" interno dell'app viene visualizzato insieme al "Nome visualizzato", il che semplifica l'identificazione visiva delle 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'API o la UI di gestione, i dati precedenti a sei mesi rispetto alla data corrente non sono accessibili per impostazione predefinita. Se vuoi accedere a dati più vecchi di sei mesi, contatta l'assistenza Apigee Edge.

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

La versione classica facoltativa dei report di analisi personalizzati non è più disponibile nell'interfaccia utente di gestione.

Rendimento del widget Coinvolgimento dello sviluppatore

Il widget Funnel nella dashboard principale di Analytics (sezione Coinvolgimento degli sviluppatori) è stato migliorato per offrire prestazioni migliori.

Monetizzazione

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

Notifiche via email per i piani tariffari

Un nuovo tipo di notifica via email del piano tariffario ti consente di avvisare gli sviluppatori quando raggiungono un determinato limite di transazioni o di spesa nei piani tariffari a fasce di volume o in bundle che hanno acquistato. Per maggiori dettagli, vedi Configurare le notifiche utilizzando i modelli di notifica.

Sincronizzazione dei periodi di commissione ricorrente e base di aggregazione

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

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

Ora i due periodi sono sincronizzati. Quando in un piano tariffario esistono sia una commissione ricorrente diversa da zero sia una scheda tariffaria a volumi o bundle, viene utilizzato il periodo della commissione ricorrente per entrambi. Ad esempio, se esiste una tariffa mensile ricorrente, anche i bundle delle schede tariffarie vengono reimpostati mensilmente (per impostazione predefinita all'inizio del mese).

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

La base di aggregazione verrà ritirata e rimossa dalla monetizzazione in una futura release. Per ulteriori informazioni, consulta la sezione Specificare i dettagli del piano con tariffario.

Attributi personalizzati nei report di riepilogo sulle entrate

Le norme di registrazione delle transazioni ti consentono di acquisire facoltativamente i dati degli attributi personalizzati dalle transazioni e ora puoi includere questi attributi personalizzati delle transazioni nei report riepilogativi sulle entrate. Se aggiungi una proprietà MINT.SUMMARY_CUSTOM_ATTRIBUTES alla tua organizzazione, puoi indicare quali attributi personalizzati vengono aggiunti alle tabelle del database per essere utilizzati nei report.

I clienti di Apigee Edge for Private Cloud possono impostare il flag con la seguente chiamata API e le credenziali di amministratore di 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>"

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

Procedura di upgrade di Smart Docs

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

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

Tieni presente che, sebbene tu possa eseguire il rendering e pubblicare SmartDocs all'interno del tuo portale per sviluppatori, SmartDocs vengono generate 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 gli sviluppatori esistono negli ambienti Pantheon).

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

1. Aggiorna e testa la release 15.05.27 negli ambienti dev o test su Pantheon.
2. Crea un nuovo modello per sostituire qualsiasi modello API esistente che hai utilizzato.
   • Se hai importato documenti Swagger o WADL, importali di nuovo in una nuova revisione.
   • Se hai gestito il modello API tramite il modulo SmartDocs, esportalo come SmartDocs JSON e importalo nel nuovo modello utilizzando l'allegato di file.
3. Imposta le proprietà di sicurezza della revisione del modello. Nella pagina Contenuti > Smart Docs > modello, seleziona Impostazioni di sicurezza.
   
4. Controlla l'eventuale autenticazione preconfigurata nella pagina delle impostazioni del modello (Contenuti > Smart Docs) facendo clic su Impostazioni nella colonna Operazioni.
   
5. Aggiorna tutti i modelli personalizzati in modo che utilizzino la versione 6 degli asset CSS e JS e apporta modifiche per riflettere eventuali nuovi nomi di oggetti, come authSchemes e apiSchema. Per informazioni sull'aggiornamento dei modelli SmartDocs, consulta Utilizzare SmartDocs per documentare le API.
6. Esegui di nuovo il rendering e pubblica la revisione del modello.
7. Dopo aver convalidato la nuova documentazione, aggiorna il portale produzione alla release 15.05.27.

Se sei un cliente aziendale di Edge e hai domande o dubbi sulla procedura di upgrade, invia un'email a marsh@apigee.com e cnovak@apigee.com. In caso contrario, utilizza la community Apigee per ottenere 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 il comportamento della policy di memorizzazione nella cache delle risposte

In una release futura (da determinare), il comportamento predefinito dell'elemento <ExcludeErrorResponse> del criterio Cache di risposta cambierà.

Comportamento attuale: l'elemento <ExcludeErrorResponse> nel criterio di 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 dal criterio di memorizzazione nella cache delle risposte.

Comportamento futuro: l'elemento <ExcludeErrorResponse> nel criterio di memorizzazione nella cache delle risposte verrà 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 nella cache le risposte per tutti i codici di stato, devi impostare in modo esplicito l'elemento <ExcludeErrorResponse> su true.

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

Bug corretti

In questa release sono stati corretti i seguenti bug.

Problemi noti

Questa release presenta i seguenti problemi noti.

> 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