Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
We wtorek 29 kwietnia 2014 r. udostępniliśmy nową wersję Apigee Edge w chmurze.
Nowe funkcje i ulepszenia
Poniżej znajdziesz nowe funkcje i udoskonalenia w tej wersji.
- Panele w Analytics
Edge zawiera teraz nowe raporty Analytics dotyczące wydajności punktu końcowego, wydajności serwera proxy API i wydajności pamięci podręcznej, które ułatwiają monitorowanie wydajności.
Więcej informacji o panelach operacyjnych znajdziesz w sekcji Panele operacyjne. - Agresja danych niestandardowych na potrzeby analizy skuteczności
Ta funkcja nie jest już dostępna.
Nowa funkcja niestandardowego agregacji poprawia wydajność funkcji analitycznych, umożliwiając definiowanie niestandardowych danych, które Edge gromadzi i przechowuje podczas wywołań interfejsu API. Gdy przeglądasz raporty, przeglądarka Edge uzyskuje dostęp do już dostępnych danych zbiorczych, a nie pobiera ich na bieżąco. - Wstępnie skonfigurowane OAuth 2.0 w wymiennikach interfejsu API
Podczas tworzenia wymiennika interfejsu API nowa opcja „Zabezpiecz za pomocą tokenów dostępu OAuth 2.0” automatycznie konfiguruje wymiennik interfejsu API za pomocą zasad obsługujących OAuth.
Zobacz OAuth. - Maskowanie danych w sesjach śledzenia
Przy użyciu zasobu interfejsu API /maskconfigs możesz maskować dane wrażliwe, takie jak informacje o karcie kredytowej, w sesjach śledzenia proxy interfejsu API. Pomaga to zapewnić bezpieczeństwo danych użytkowników podczas rozwoju interfejsu API.
Wątek:810723
Zobacz Maskowanie i ukrywanie danych. - Zasada uwierzytelniania podstawowego
Zasada uwierzytelniania podstawowego umożliwia dodanie lekkiego uwierzytelniania podstawowego do serwera pośredniczącego interfejsu API, zapewniając automatyczne kodowanie Base64 danych logowania użytkownika 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. Zmniejsza to opóźnienie proxy interfejsu API i umożliwia udostępnianie informacji do rejestrowania, które nie są obliczane do momentu wysłania odpowiedzi, takich jak client.sent.start.timestamp i client.sent.end.timestamp.
Przypadek: 814059
Naprawione błędy
W tej wersji naprawiliśmy te błędy:
| Temat | Opis |
|---|---|
| Weryfikacja nazwy raportu niestandardowego | Edge sprawdza teraz nazwy raportów niestandardowych, aby nie zezwalać na używanie znaków specjalnych. |
| Zgłaszanie problemów z poziomem dewelopera_aplikacji | W raportach niestandardowych, które korzystały z poziomu szczegółowości developer_app, zwracane były niewłaściwe aplikacje dewelopera. Naprawiliśmy ten problem. |
| Przedział czasu nie działa w raportach niestandardowych | W raportach niestandardowych zawierających filtry z wieloma wyrażeniami w nawiasach (np. (request_verb eq 'POST') or (request_verb eq
'GET')) zmiana przedziału czasowego raportu nie miała wpływu na wyniki. Ten problem został rozwiązany.Zgłoszenie: 810753 |
| Wykresy nie pojawiają się w raportach niestandardowych | Rozwiązaliśmy problem polegający na tym, że wykresy nie pojawiały się w raportach niestandardowych. Zgłoszenie: 814623 |
| Importowanie pliku WSDL |
|
| Konfiguracja zasady równoczesnego ograniczenia szybkości | Selektor docelowego punktu końcowego jest teraz dostępny tylko podczas dodawania zasad dotyczących limitu szybkości współbieżnej do serwera proxy interfejsu API. Punkt końcowy docelowo nie dotyczy innych zasad. |
| Pomoc dla deweloperów ze strony firmy | W przypadku organizacji, w których firmach jest włączona ta funkcja, możesz teraz określić firmę podczas tworzenia lub edytowania dewelopera. Zgłoszenie: 515246 |
| Eksportowanie programistów, aplikacji i produktów | Teraz możesz eksportować dane o deweloperach, aplikacjach i produktach do pliku CSV ze strony Deweloperzy w interfejsie zarządzania Edge. Ta funkcja jest obecnie niedostępna dla organizacji, które mają włączoną monetyzację. Zgłoszenie: 747159 |
| Zawieszanie okna Aplikacje dla deweloperów | Gdy deweloper usunął aplikację na portalu Edge dla deweloperów, kliknięcie tej aplikacji w interfejsie zarządzania Edge powodowało zawieszanie okna. Ten problem został rozwiązany. |
| Komentarze w konfiguracji proxy interfejsu API | Komentarze w konfiguracji proxy interfejsu API są teraz widoczne w widoku kodu w edytorze proxy interfejsu API oraz w inspektorze usługi. |
| Serwery proxy interfejsu API utworzone z nieprawidłowymi nazwami | Wcześniej interfejs zarządzania Edge umożliwiał tworzenie serwerów proxy interfejsu API, których nazwy zawierały niedozwolone znaki specjalne. W rezultacie powstawały nieprawidłowe serwery proxy interfejsu API, których nie można było usunąć. Nazwy proxy interfejsu API są teraz weryfikowane w momencie ich tworzenia. Dozwolone są tylko znaki alfanumeryczne, „-” i „_”. Zgłoszenie: 550390 |
| Wielkość liter w nazewnictwie proxy w interfejsie API | Edge tworzył serwery proxy API o nazwach z małymi literami, niezależnie od wielkości liter wpisywanych nazw. Edge uwzględnia teraz wielkość liter w nazwie podanej dla serwera proxy API. |
| Ostrzeżenie o zapisywaniu proxy interfejsu API | Gdy zapiszesz proxy interfejsu API w edytorze proxy interfejsu API, Edge wdroży proxy interfejsu API we wszystkich środowiskach, w których obecnie jest ono wdrożone, w tym w środowiskach produkcyjnych. W interfejsie zarządzania Edge wyświetlane jest teraz ostrzeżenie przed zapisaniem serwera proxy. |
| Rola niestandardowa bez uprawnień zapisywania do środowiska produkcyjnego | Gdy wdrożona wersja interfejsu API zostanie zaktualizowana, powoduje to wewnętrzne wycofanie i wdrożenie w wdrożonych środowiskach. Rola niestandardowa bez odpowiednich uprawnień do wdrażania mogła wdrożyć rolę, zapisując serwer proxy interfejsu API. Problem został rozwiązany przez wymuszenie uprawnień do wdrażania. Zgłoszenie: 813084 |
| Zduplikowany serwer docelowy | Podczas tworzenia duplikatu serwera docelowego zamiast błędu HTTP 409 przeglądarka Edge zastąpiła dotychczasowy serwer docelowy nowym i zwróciła kod stanu 201. Rozwiązaliśmy ten problem, wyświetlając błąd 409 i nie zastępując istniejącego serwera docelowego. |
| Nie można utworzyć sesji śledzenia dla serwerów proxy interfejsu API | Sesje śledzenia nie były tworzone w przypadku środowisk z niedostępnymi procesorami wiadomości. Ten problem został rozwiązany przez dołączenie sesji śledzonych tylko do dostępnych i dostępnych procesorów wiadomości Przypadek: 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 backendowa wysyłała odpowiedź do kolejki JMSReplyTo, a nie Edge, dodaj nagłówek X-Apigee-Ignore-JMSResponse do odpowiedzi proxy interfejsu API w dowolnym procesie i ustaw go na wartość true:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Wysoka liczba błędów CLOSE_WAIT i 502 (nieprawidłowa brama) | Rozwiązaliśmy problem, który powodował wysokie wartości wskaźnika CLOSE_WAIT i błędy 502 (błędna bramka). Przypadki: 814656, 814664, 814670 |
| Katalog tymczasowy Node.js | Gdy skrypt Node.js jest wdrażany w Edge, jest uruchamiany w piaskownicy, która ogranicza dostęp systemu plików do określonego katalogu. Jednak os.tmpdir zwraca nazwę katalogu, np. /tmp lub /var/tmp, która nie istnieje w piaskownicy Node.js w Edge, co powoduje błąd niektórych skryptów. Piaskownica Node.js w Edge zawiera teraz katalog /tmp, który może być używany przez funkcję os.tmpdir. |
| Wyjątki wskaźnika o wartości null w przypadku wywołań interfejsu API | W zasadach przypisywania wiadomości stan odpowiedzi null spowodował wyjątek wskaźnika null, ponieważ przeglądarka Edge próbowała przechwycić kod odpowiedzi dla danych. Naprawiliśmy ten problem. Zgłoszenie: 815595 |