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 un'importante release di funzionalità di Apigee Edge for Private Cloud.

Dalla precedente release trimestrale di Edge for Private Cloud (4.15.04.00), sono state pubblicate 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 versione 4.15.07.00

A seconda della versione di Edge che utilizzi, puoi:

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

Per saperne di più, consulta 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 la directory in /<install-root>/apigee4/data/cassandra/data.
   2. Esegui un comando find,
      > find . -name *-ic-*
      I risultati dovrebbero restituire un insieme di file .db se utilizzi Cassandra 1.2 SSTable.
   3. Esegui questo comando find:
      > find . -name *-hf-*
      I risultati dovrebbero essere vuoti, il che significa che non sono presenti file .db nel formato hf. Se non vedi file in formato hf, hai finito e puoi eseguire l'upgrade alla versione 4.15.07.00.
      
      Il formato hf è per le 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 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 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 sia stato eseguito l'upgrade di tutti 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 utilizzi 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 va a buon fine 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 a eseguire l'upgrade. (OPDK-1275)

Opzioni dello script del programma di installazione abbreviato

Gli script di installazione non accettano più la forma estesa delle opzioni, ad esempio --help. Ora accettano solo opzioni con una singola 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, per assicurarti che SmartDocs 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)

Edge Platform

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 for Private Cloud ha ampliato il supporto dei sistemi operativi 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é mantenere l'hashing precedente su tutti 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) 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 l'upgrade, esegui un 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 alle operazioni 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 la policy Message Logging. (APIRT-1394)

Prestazioni della cache dell'ambiente

Per una migliore gestione e un migliore utilizzo della memoria cache, le impostazioni "Numero massimo di elementi in memoria" sulle 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 è pari al 40% della memoria totale disponibile, determinata dalle impostazioni della proprietà della cache nel file cache.properties del processore di messaggi. Gli elementi verranno rimossi dalla memoria cache solo quando la memoria cache è insufficiente o gli elementi scadono.

Per ripristinare il comportamento precedente, ovvero l'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 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 di flussi condizionali ed endpoint nella pagina Panoramica, tutte le configurazioni nella pagina Sviluppa, aggiunta più intuitiva di flussi condizionali, endpoint e policy, visualizzazioni XML più complete anziché piccoli snippet, ricerca che esegue la scansione di nomi file e testo e altro ancora. (MGMT-2279)

Nuova policy Delete OAuth v2.0 Info

Una nuova policy "Elimina informazioni OAuth v2.0" consente di eliminare i token di accesso e i codici di autorizzazione OAuth v2. La policy sostituisce la funzionalità precedentemente fornita dall'API di gestione. Per saperne di più, consulta Elimina la policy OAuthV2 Info. (MGMT-2257)

Nuova policy Delete OAuth v1.0 Info

Una nuova policy "Delete OAuth v1.0 Info" consente di eliminare i token di richiesta, i token di accesso e i codici di verifica OAuth v1.0. La policy sostituisce la funzionalità precedentemente fornita dall'API di gestione. Per saperne di più, consulta Policy Delete OAuth V1 Info. (APIRT-1351)

Policy di controllo degli accessi

La policy di controllo degli accessi è stata migliorata per consentire una valutazione più granulare degli indirizzi IP per l'inserimento in liste consentite e bloccate quando gli indirizzi IP sono contenuti nell'intestazione HTTP X-FORWARDED-FOR.

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

Nuove entità nella policy di accesso alle entità

La policy Access Entity fornisce l'accesso alle seguenti nuove entità: consumerkey-scopes, authorizationcode, requesttoken e verifier. Per saperne di più, consulta Policy Access Entity.

Policy Statistics Collector: conversione automatica del nome della statistica in lettere minuscole

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

Rimozione di Trace classico nell'editor proxy API

La versione più recente della funzionalità di traccia 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 di Apigee dal menu Guida della UI 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 raggruppava e visualizzava tutti i messaggi di errore nella UI per l'intera sessione di accesso, a meno che non venissero ignorati. Con questo aggiornamento, i messaggi di errore vengono cancellati automaticamente quando esci dalla pagina in cui si sono verificati. (MGMT-2254)
• La UI di gestione non elimina più i messaggi di errore duplicati. (MGMT-2242)

Miglioramenti alle prestazioni e agli errori dell'interfaccia utente

Sono stati apportati miglioramenti generali a diverse aree della UI 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 della UI di gestione (Amministratore > 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 sugli 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 <LoadBalancer> HTTPTargetConnection di TargetEndpoint.

Supporto di Server Name Indication (SNI)

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

È richiesto Java 1.7.

Con SNI, che è un'estensione di TLS/SSL, più target HTTPS possono essere gestiti dallo stesso indirizzo IP e dalla stessa porta senza che tutti questi target debbano utilizzare lo stesso certificato.

Non è richiesta alcuna configurazione specifica per Edge. Se l'ambiente è configurato per SNI southbound (Edge Cloud lo è per impostazione predefinita), 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 saperne di più su SNI, visita la pagina http://en.wikipedia.org/wiki/Server_Name_Indication.

"Algoritmo di firma" nei dettagli dei certificati SSL

È stato aggiunto un nuovo campo "Algoritmo di firma" ai dettagli del certificato SSL, visualizzabile nell'interfaccia utente di gestione (Amministratore > Certificati SSL) e nell'API di gestione (Recupera i dettagli del certificato da un keystore o truststore). 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 nuovo campo a discesa della scadenza.

Configurazione degli errori di protezione dalle minacce

Per impostazione predefinita, Edge genera un codice di stato HTTP 500 Errore interno del server e un errore ExecutionFailed se un messaggio non supera una policy JSON o XML Threat Protection. 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 policy di protezione dalle minacce collegata a qualsiasi flusso di richieste, i messaggi non validi restituiscono un codice di stato 400, insieme a un messaggio di errore della policy corrispondente.
• Risposta: con una policy di protezione dalle minacce associata 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 policy, come TargetEndpoint, ProxyEndpoint, APIProxy e molte altre. Consulta la pagina https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Servizi per gli sviluppatori

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

Disponibilità generale di SmartDocs

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

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

Per ulteriori descrizioni delle caratteristiche, consulta questo blog post.

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

Nome dell'app per sviluppatori visualizzato nell'interfaccia utente di gestione

Le app per sviluppatori in Edge hanno un nome interno che non cambia e un nome visualizzato che puoi modificare. In una pagina App sviluppatore nell'interfaccia utente di gestione (Pubblica > App sviluppatore > nome app), il "Nome" interno dell'app viene visualizzato insieme al "Nome visualizzato", semplificando 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'interfaccia utente o l'API di gestione, i dati risalenti a più di sei mesi prima della data corrente non sono accessibili per impostazione predefinita. Se vuoi accedere a dati risalenti a più di sei mesi fa, contatta l'assistenza di Apigee Edge.

Rimozione della versione classica dei report personalizzati dalla UI 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 della canalizzazione nella dashboard principale di analisi (sezione Coinvolgimento degli sviluppatori) è stato migliorato per offrire un rendimento migliore.

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 per i piani tariffari ti consente di informare gli sviluppatori quando raggiungono un determinato limite di transazioni o di dollari nei piani tariffari a volume o in bundle che hanno acquistato. Per i dettagli, consulta Configura le notifiche utilizzando i modelli di notifica.

Sincronizzazione dei periodi della tariffa ricorrente e della base di aggregazione

In un piano tariffario, potevano essere attivi due diversi periodi di tempo:

• Periodo della tariffa ricorrente, configurato nella scheda Tariffe di un piano tariffario, che determina quando agli sviluppatori viene addebitata una tariffa ricorrente.
• Il periodo di base di aggregazione, definito nel tariffario per i piani a volume o in bundle, che ha determinato il momento in cui l'utilizzo del bundle è stato reimpostato per gli sviluppatori.

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

Se non è presente una tariffa ricorrente, i pacchetti vengono reimpostati in base alla base di aggregazione definita nel listino prezzi. 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 19.

La base di aggregazione è stata ritirata e verrà rimossa dalla monetizzazione in una release futura. Per saperne di più, consulta Specifica i dettagli del piano tariffario.

Attributi personalizzati nei report Entrate di riepilogo

Le policy di registrazione delle transazioni ti consentono di acquisire facoltativamente i dati degli attributi personalizzati dalle transazioni. Ora puoi includere questi attributi personalizzati delle transazioni nei report di riepilogo delle entrate. Aggiungendo una proprietà MINT.SUMMARY_CUSTOM_ATTRIBUTES alla tua organizzazione, puoi indicare quali attributi personalizzati vengono aggiunti alle tabelle del database per l'utilizzo 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 nell'URL.

Procedura di upgrade di SmartDocs

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

Tutte le pagine SmartDocs già pubblicate nel portale per sviluppatori continueranno a funzionare, ma devi seguire la procedura di aggiornamento prima di modificare o pubblicare 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 viene generato 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 (analogamente a come gli sviluppatori esistono in tutti gli ambienti Pantheon).

Eseguire l'upgrade dalla versione beta di SmartDocs alla disponibilità generale

1. Aggiorna e testa la release 15.05.27 nei tuoi ambienti di sviluppo o di 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 tuo modello API tramite il modulo SmartDocs, esportalo come JSON SmartDocs e importalo nel nuovo modello utilizzando l'allegato file.
3. Imposta le proprietà di sicurezza della revisione del modello. Nella pagina Contenuti > SmartDocs > modello, seleziona Impostazioni di sicurezza.
   
4. Controlla l'autenticazione preconfigurata nella pagina delle impostazioni del modello (Contenuti > SmartDocs) 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 i nuovi nomi degli oggetti, come authSchemes e apiSchema. Per informazioni sull'aggiornamento dei modelli SmartDocs, consulta Utilizzo di 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 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 di Apigee per ricevere la risposta migliore.

Modifiche e miglioramenti futuri delle funzionalità

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

Modifica del comportamento della policy Response Cache

In una release futura (da definire), il comportamento predefinito dell'elemento <ExcludeErrorResponse> della policy Response Cache cambierà.

Comportamento attuale: l'elemento <ExcludeErrorResponse> nella policy di memorizzazione nella 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 dalla policy Response Cache.

Comportamento futuro: l'elemento <ExcludeErrorResponse> nella policy Response Cache 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 compresi tra 200 e 205. Per eseguire l'override di questo comportamento e memorizzare nella cache le risposte per tutti i codici di stato, devi impostare esplicitamente 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.

Correzioni di bug

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