Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Martedì 29 aprile 2014 abbiamo rilasciato una nuova versione cloud di Apigee Edge.
Nuove funzionalità e miglioramenti
Di seguito sono riportate le nuove funzionalità e i miglioramenti di questa release.
- Dashboard di Analytics
Edge ora fornisce nuovi report di analisi del rendimento degli endpoint, del rendimento dei proxy API e del rendimento della cache per aiutarti a monitorare il rendimento.
Consulta "Le dashboard operative" in Dashboard di Analytics. - Aggregazione delle metriche personalizzate per il rendimento
Questa funzionalità non è più disponibile.
Una nuova funzionalità di aggregazione personalizzata migliora il rendimento di Analytics consentendoti di definire metriche personalizzate che Edge raccoglie e archivia quando vengono effettuate chiamate API. Quando visualizzi i report, Edge accede alle metriche aggregate già disponibili anziché recuperarle al volo. - OAuth 2.0 preconfigurato nei proxy API
Quando crei un proxy API, una nuova opzione "Proteggi con i token di accesso OAuth v2.0" configura automaticamente il proxy API con policy che supportano OAuth.
Consulta OAuth. - Mascheramento dei dati nella traccia
La risorsa API /maskconfigs consente di mascherare i dati sensibili, come le informazioni sulla carta di credito, nelle sessioni di traccia del proxy API, contribuendo a garantire la sicurezza dei dati utente durante lo sviluppo dell'API.
Caso:810723
Consulta Mascheramento e occultamento dei dati. - Policy Autenticazione di base
La policy Autenticazione di base consente di aggiungere l'autenticazione di base leggera a un proxy API, fornendo la codifica Base64 automatica delle credenziali utente e il popolamento dell'intestazione HTTPAuthorization: Basicheader.
Consulta Policy Autenticazione di base. - PostClientFlow
PostClientFlow consente di aggiungere policy MessageLogging che vengono eseguite dopo l'invio della risposta. Ciò riduce la latenza del proxy API e rende disponibili per la registrazione informazioni che non vengono calcolate fino a dopo l'invio della risposta, come client.sent.start.timestamp e client.sent.end.timestamp.
Caso: 814059
Bug corretti
In questa release sono stati corretti i seguenti bug.
| Argomento | Descrizione |
|---|---|
| Convalida del nome del report personalizzato | Edge ora convalida i nomi dei report personalizzati per impedire l'utilizzo di caratteri speciali caratteri. |
| Segnala problemi con il drill-down developer_app | Nei report personalizzati che utilizzavano il drill-down developer_app venivano restituite app per sviluppatori errate. Il problema è stato risolto. |
| Il periodo di tempo non funziona nei report personalizzati | Nei report personalizzati che contenevano filtri con più espressioni tra parentesi
, ad esempio (request_verb eq 'POST') or (request_verb eq
'GET'), la modifica del periodo di tempo del report non aveva alcun effetto sui risultati. Il problema
è stato risolto.Caso: 810753 |
| I grafici non vengono visualizzati nei report personalizzati | È stato risolto un problema per cui i grafici non venivano visualizzati nei report personalizzati. Caso: 814623 |
| Importazione WSDL |
|
| Configurazione della policy Limite di frequenza simultaneo | Il selettore Endpoint di destinazione è ora disponibile solo quando si aggiunge una policy Limite di frequenza simultaneo a un proxy API. L'endpoint di destinazione non si applica ad altre policy. |
| Assistenza aziendale per gli sviluppatori | Per le organizzazioni in cui sono attivate le aziende, ora puoi specificare un'azienda quando
crei o modifichi uno sviluppatore. Caso: 515246 |
| Esportazione di sviluppatori, app e prodotti | Ora puoi esportare sviluppatori, app e prodotti in un file CSV dalla pagina Sviluppatori
nell'interfaccia utente di gestione di Edge. Questa funzionalità non è attualmente disponibile per le organizzazioni in cui
è attivata la monetizzazione. Caso: 747159 |
| La finestra App per sviluppatori non risponde | Dopo che uno sviluppatore ha eliminato un'app nel portale per sviluppatori Edge, se fai clic sull'app per sviluppatori nell'interfaccia utente di gestione di Edge, la finestra non risponde. Il problema è stato risolto. |
| Commenti in una configurazione del proxy API | I commenti in una configurazione del proxy API sono ora visibili nella visualizzazione del codice dell'editor del proxy API e nell'ispettore delle proprietà. |
| Proxy API creati con nomi non validi | In precedenza, l'interfaccia utente di gestione di Edge consentiva la creazione di proxy API i cui nomi
contenevano caratteri speciali non supportati, con conseguenti proxy API non validi che non potevano essere
eliminati. I nomi dei proxy API vengono ora convalidati al momento della creazione. Sono consentiti solo caratteri alfanumerici, "-" e
"_". Caso: 550390 |
| Distinzione tra maiuscole e minuscole nella denominazione del proxy API | Edge creava proxy API con nomi in minuscolo, indipendentemente dal caso inserito. Edge ora rispetta il caso del nome inserito per il proxy API. |
| Avviso sul salvataggio del proxy API | Quando salvi un proxy API nell'editor del proxy API, Edge esegue il deployment del proxy API in tutti gli ambienti in cui è attualmente eseguito il deployment della revisione, inclusi gli ambienti di produzione. L'interfaccia utente di gestione di Edge ora mostra un avviso prima di salvare il proxy. |
| Ruolo personalizzato senza autorizzazioni salvate nell'ambiente di produzione | Quando una revisione dell'API di cui è stato eseguito il deployment viene aggiornata, viene attivato un annullamento del deployment e un deployment interni negli ambienti di cui è stato eseguito il deployment. Un ruolo personalizzato senza le autorizzazioni di deployment appropriate è stato in grado di
eseguire il deployment salvando un proxy API. Questo problema è stato risolto applicando le autorizzazioni di deployment
permissions. Caso: 813084 |
| Server di destinazione duplicato | Quando creavi un server di destinazione duplicato, anziché un errore HTTP 409, Edge sovrascriveva il server di destinazione esistente e restituiva uno stato 201. Questo problema è stato risolto generando un errore 409 e non sovrascrivendo il server di destinazione esistente. |
| Impossibile creare sessioni di traccia per i proxy API | Le sessioni di traccia non venivano create per gli ambienti con processori di messaggi che
non erano raggiungibili. Questo problema è stato risolto collegando le sessioni di traccia solo ai
processori di messaggi raggiungibili e disponibili Caso: 812192 |
| Comportamento aggiornato di JMSReplyTo | Per impostazione predefinita, Edge invia la risposta alla coda specificata nell'intestazione JMSReplyTo.
Tuttavia, se vuoi che il servizio di backend gestisca l'invio della risposta alla coda JMSReplyTo
anziché Edge, aggiungi l'intestazione X-Apigee-Ignore-JMSResponse al proxy API
risposta in qualsiasi flusso e impostala su true:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Errori elevati di CLOSE_WAIT e 502 Bad Gateway | È stato risolto un problema che causava metriche CLOSE_WAIT elevate ed errori 502 Bad Gateway. Casi: 814656, 814664, 814670 |
| Directory temporanea di Node.js | Quando uno script Node.js viene eseguito il deployment in Edge, viene eseguito all'interno di una sandbox che limita l'accesso al file system a una determinata directory. Tuttavia, os.tmpdir restituisce un nome di directory come /tmp o /var/tmp, che non esisteva nella sandbox Node.js di Edge, causando l'interruzione di alcuni script. La sandbox Node.js di Edge ora include una directory /tmp da utilizzare per os.tmpdir. |
| Eccezioni di puntatore nullo nelle chiamate API | Nella policy Assegna messaggio, uno stato di risposta nullo ha generato un'eccezione di puntatore nullo quando
Edge ha tentato di acquisire il codice di risposta per le metriche. Il problema è stato risolto. Caso: 815595 |