Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
We wtorek 29 kwietnia 2014 roku opublikowaliśmy nową wersję Apigee Edge w chmurze.
Nowe funkcje i ulepszenia
Poniżej znajdziesz opis nowych funkcji i ulepszeń wprowadzanych w tej wersji.
- Panele Analytics
Edge udostępnia teraz nowe raporty dotyczące wydajności punktów końcowych, wydajności serwera proxy interfejsu API i analizy wydajności pamięci podręcznej, które ułatwiają monitorowanie wydajności.
Przeczytaj artykuł „Panele operacji” w artykule Panele informacyjne Analytics. - Agregacja danych niestandardowych na potrzeby skuteczności
Ta funkcja jest już niedostępna.
Nowa funkcja agregacji niestandardowej poprawia skuteczność analiz, ponieważ umożliwia definiowanie niestandardowych wskaźników, które Edge zbiera i przechowuje w miarę wykonywania wywołań interfejsu API. Podczas wyświetlania raportów Edge korzysta z już dostępnych zagregowanych wskaźników, zamiast pobierać je na bieżąco. - Wstępnie skonfigurowana protokół OAuth 2.0 w serwerach proxy interfejsu API
Podczas tworzenia serwera proxy interfejsu API nowa opcja „Zabezpiecz za pomocą tokenów dostępu OAuth w wersji 2.0” automatycznie konfiguruje serwer proxy interfejsu API z zasadami, które obsługują OAuth.
Zobacz OAuth. - Maskowanie danych w logu czasu
Zasób interfejsu API /maskconfigs umożliwia maskowanie danych wrażliwych, takich jak dane kart kredytowych, w sesjach śledzenia serwera proxy interfejsu API, co pomaga zapewnić bezpieczeństwo danych użytkownika podczas tworzenia interfejsów API.
Case:810723
Zobacz Maskowanie i ukrywanie danych. - Zasada uwierzytelniania podstawowego
Zasada uwierzytelniania podstawowego umożliwia dodanie prostego uwierzytelniania podstawowego do serwera proxy interfejsu API, zapewniając automatyczne kodowanie danych logowania użytkownika w standardzie Base64 i wypełnianie nagłówka HTTPAuthorization: Basic.
Zobacz Zasady uwierzytelniania podstawowego. - PostClientFlow
PostClientFlow umożliwia dodawanie zasad MessageLogging, które są wykonywane po wysłaniu odpowiedzi. Skraca to czas oczekiwania na serwer proxy interfejsu API i udostępnia do logowania informacje, które są obliczane dopiero po wysłaniu odpowiedzi, takie jak client.sent.start.timestamp i client.sent.end.timestamp.
Zgłoszenie: 814059
Naprawione błędy
Poprawiliśmy w niej wymienione niżej błędy.
| Temat | Opis |
|---|---|
| Weryfikacja nazwy raportu niestandardowego | Edge sprawdza teraz nazwy raportów niestandardowych, aby uniemożliwić używanie znaków specjalnych. |
| Zgłaszanie problemów z przejściem na szczegółową analizę programisty_app | W raportach niestandardowych, które korzystały z bardziej szczegółowego widoku Developer_app, zwracane były nieprawidłowe aplikacje dewelopera. Naprawiliśmy ten problem. |
| Okres nie obsługuje raportów niestandardowych | W raportach niestandardowych, które zawierały filtry z wieloma wyrażeniami w nawiasach, np. (request_verb eq 'POST') or (request_verb eq
'GET'), zmiana okresu raportu nie miała wpływu na wyniki. Rozwiązaliśmy ten problem.Zgłoszenie: 810753 |
| Wykresy nie są wyświetlane w raportach niestandardowych | Rozwiązaliśmy problem z wykresami, które nie pojawiały się w raportach niestandardowych. Zgłoszenie: 814623 |
| Import WSDL |
|
| Konfiguracja zasady ograniczenia liczby równoczesnych żądań | Selektor docelowego punktu końcowego jest teraz dostępny tylko podczas dodawania zasady limitu równoczesnych żądań do serwera proxy interfejsu API. Docelowy punkt końcowy nie ma zastosowania do innych zasad. |
| Wsparcie firm dla programistów | W przypadku organizacji, dla których są włączone firmy, możesz teraz określić firmę podczas tworzenia lub edytowania dewelopera. Zgłoszenie: 515246 |
| Eksportowanie danych deweloperów, aplikacji i usług | Teraz możesz eksportować deweloperów, aplikacje i produkty do pliku CSV na stronie Programiści w interfejsie zarządzania brzegowym. Ta funkcja jest obecnie niedostępna dla organizacji, w których włączono zarabianie. Zgłoszenie: 747159 |
| Zawieszenie okna aplikacji dewelopera | Gdy deweloper usunął aplikację z portalu Edge dla programistów, kliknięcie tej aplikacji w interfejsie zarządzania brzegowym powodowało zawieszenie okna. Rozwiązaliśmy ten problem. |
| Komentarze w konfiguracji serwera proxy interfejsu API | Komentarze w konfiguracji serwera proxy interfejsu API są teraz widoczne w widoku kodu edytora proxy interfejsu API i inspektorze właściwości. |
| Serwery proxy interfejsu API utworzone z nieprawidłowymi nazwami | Interfejs zarządzania brzegiem sieci umożliwiał wcześniej tworzenie serwerów proxy interfejsów API o nazwach zawierających nieobsługiwane znaki specjalne, co powodowało generowanie nieprawidłowych serwerów proxy interfejsu API, których nie udało się usunąć. Nazwy serwerów proxy interfejsu API są teraz weryfikowane podczas tworzenia. Dozwolone są tylko znaki alfanumeryczne, „-” i „_”. Zgłoszenie: 550390 |
| Wielkość liter w nazwach serwerów proxy interfejsu API | Edge tworzył serwery proxy interfejsów API z małymi literami niezależnie od wprowadzonej wielkości liter. Edge uwzględnia teraz wielkość liter w nazwie wpisanej dla serwera proxy interfejsu API. |
| Ostrzeżenie dotyczące zapisywania serwera proxy interfejsu API | Gdy zapiszesz serwer proxy interfejsu API w edytorze proxy interfejsu API, Edge wdroży serwer proxy interfejsu API we wszystkich środowiskach, w których obecnie wdrożona jest dana wersja, w tym w środowiskach produkcyjnych. Przed zapisaniem serwera proxy w interfejsie zarządzania brzegiem sieci wyświetlane jest teraz ostrzeżenie. |
| Rola niestandardowa bez uprawnień do zapisywania w środowisku produkcyjnym | Aktualizacja wdrożonej wersji interfejsu API powoduje wewnętrzne wycofanie wdrożenia i wdrożenie we wdrożonych środowiskach. Udało się wdrożyć rolę niestandardową bez odpowiednich uprawnień do wdrażania dzięki zapisywaniu serwera proxy interfejsu API. Problem ten został rozwiązany przez egzekwowanie uprawnień do wdrożenia. Zgłoszenie: 813084 |
| Zduplikowany serwer docelowy | Podczas tworzenia duplikatu serwera docelowego zamiast błędu HTTP 409 Edge zastąpił istniejący serwer docelowy i zwrócił stan 201. Problem został rozwiązany przez zgłoszenie błędu 409 i nie zastąpienie istniejącego serwera docelowego. |
| Nie udało się utworzyć sesji śledzenia dla serwerów proxy interfejsu API | Sesje śledzenia nie były tworzone dla środowisk z procesorami wiadomości, które były nieosiągalne. Ten problem został rozwiązany przez dołączenie sesji śledzenia tylko do osiągalnych i dostępnych procesorów wiadomości Zgłoszenie: 812192 |
| Zaktualizowane zachowanie JMSReplyTo | Domyślnie Edge wysyła odpowiedź do kolejki określonej w nagłówku JMSReplyTo.
Jeśli jednak chcesz, aby usługa backendu obsługiwała wysyłanie odpowiedzi do kolejki JMSReplyTo, a nie Edge, dodaj nagłówek X-Apigee-Ignore-JMSResponse do odpowiedzi serwera proxy interfejsu API w dowolnym procesie i ustaw ją na wartość prawda:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Wysokie błędy CLOSE_WAIT i 502 błędów bramy | Rozwiązaliśmy problem, który powodował wysokie wskaźniki CLOSE_WAIT i błędy 502 nieprawidłowej bramy. Zgłoszenia: 814656, 814664, 814670 |
| Katalog tymczasowy Node.js | Po wdrożeniu skryptu Node.js w Edge działa on w piaskownicy, która ogranicza dostęp systemu plików do określonego katalogu. Parametr os.tmpdir zwraca jednak nazwę katalogu, taką jak /tmp lub /var/tmp, która nie istniała w piaskownicy Edge Node.js, co powoduje awarię niektórych skryptów. Piaskownica Edge Node.js zawiera teraz katalog /tmp, którego można używać os.tmpdir. |
| Wyjątki dotyczące wskaźników null w wywołaniach interfejsu API | W zasadzie przypisywania wiadomości stan odpowiedzi o wartości null zwrócił wartość null, ponieważ usługa Edge próbowała przechwycić kod odpowiedzi dla wskaźników. Naprawiliśmy ten problem. Zgłoszenie: 815595 |