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 sul rendimento degli endpoint, dei proxy API e della cache per aiutarti a monitorare il rendimento.
Consulta "Le dashboard delle operazioni" in Dashboard di Analytics. - Aggregazione delle metriche personalizzate per il rendimento
Questa funzionalità non è più disponibile.
Una nuova funzionalità di aggregazione personalizzata migliora le prestazioni di analisi consentendoti di definire metriche personalizzate che Edge raccoglie e memorizza man mano che 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 token di accesso OAuth v2.0" configura automaticamente il proxy API con criteri che supportano OAuth.
Consulta OAuth. - Mascheramento dei dati nella traccia
La risorsa API /maskconfigs consente di mascherare i dati sensibili, come i dati della carta di credito, nelle sessioni di traccia del proxy API, contribuendo a garantire la sicurezza dei dati utente durante lo sviluppo dell'API.
Case:810723
Consulta Mascheramento e nascondimento dei dati. - Policy di autenticazione di base
La policy di autenticazione di base ti consente di aggiungere un'autenticazione di base leggera a un proxy API, fornendo la codifica Base64 automatica delle credenziali utente e il popolamento dell'intestazione HTTPAuthorization: Basic.
Consulta i criteri di autenticazione di base. - PostClientFlow
PostClientFlow consente di aggiungere criteri MessageLogging che vengono eseguiti 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, ad esempio client.sent.start.timestamp e client.sent.end.timestamp.
Richiesta: 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. |
| Segnalare problemi con il drill-down developer_app | Nei report personalizzati che utilizzavano il livello di analisi 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.Richiesta: 810753 |
| Grafici non visualizzati nei report personalizzati | È stato risolto un problema per cui i grafici non venivano visualizzati nei report personalizzati. Richiesta: 814623 |
| Importazione WSDL |
|
| Configurazione dei criteri di limite di frequenza simultanea | Il selettore dell'endpoint di destinazione è ora disponibile solo quando si aggiunge una policy di limite di frequenza simultanea a un proxy API. L'endpoint di destinazione non si applica ad altri criteri. |
| Assistenza aziendale per gli sviluppatori | Per le organizzazioni che hanno attivato le aziende, ora puoi specificare un'azienda quando
crei o modifichi uno sviluppatore. Richiesta: 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 Edge. Questa funzionalità non è attualmente disponibile per le organizzazioni che
hanno attivato la monetizzazione. Richiesta: 747159 |
| Blocco della finestra App per sviluppatori | Dopo che uno sviluppatore ha eliminato un'app nel portale per sviluppatori Edge, se si faceva clic sull'app dello sviluppatore nell'interfaccia utente di gestione Edge, la finestra si bloccava. 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 proxy API e in Property Inspector. |
| Proxy API creati con nomi non validi | L'interfaccia utente di gestione Edge consentiva in precedenza 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 "_". Richiesta: 550390 |
| Sensibilità alle maiuscole e minuscole nella denominazione dei proxy API | Edge creava proxy API con nomi in minuscolo, indipendentemente dalla distinzione tra maiuscole e minuscole inserita. Edge ora rispetta la distinzione tra maiuscole e minuscole del nome inserito per il proxy API. |
| Avviso durante il salvataggio del proxy API | Quando salvi un proxy API nell'editor proxy API, Edge esegue il deployment del proxy API in tutti gli ambienti in cui è attualmente implementata la revisione, inclusi gli ambienti di produzione. L'interfaccia utente di gestione Edge ora mostra un avviso prima di salvare il proxy. |
| Ruolo personalizzato senza autorizzazioni salvato nell'ambiente di produzione | Quando una revisione dell'API di cui è stato eseguito il deployment viene aggiornata, viene attivato un annullamento del deployment interno e un deployment sugli
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. Richiesta: 813084 |
| Server di destinazione duplicato | Quando è stato creato un server di destinazione duplicato, anziché un errore HTTP 409, Edge ha sovrascritto il server di destinazione esistente e ha restituito 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 tracciamento non venivano create per gli ambienti con processori di messaggi non raggiungibili. Questo problema è stato risolto collegando le sessioni di traccia solo ai
processori di messaggi raggiungibili e disponibili Richiesta: 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 alla risposta del proxy API in qualsiasi flusso e impostala su true:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Errori CLOSE_WAIT e 502 Bad Gateway elevati | È stato risolto un problema che causava metriche CLOSE_WAIT elevate ed errori 502 Bad Gateway. Richieste: 814656, 814664, 814670 |
| Directory temporanea di Node.js | Quando uno script Node.js viene implementato su 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 Edge Node.js, causando l'interruzione di alcuni script. La sandbox Edge Node.js 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. Richiesta: 815595 |