Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info
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 ulepszenia w tej wersji.
- Panele Analytics
Edge udostępnia teraz nowe raporty analityczne dotyczące skuteczności punktów końcowych, skuteczności serwera proxy interfejsu API i skuteczności pamięci podręcznej, które pomagają monitorować skuteczność.
Więcej informacji znajdziesz w sekcji „Panele operacyjne” w artykule Panele informacyjne Analytics. - Agregacja niestandardowych danych dotyczących skuteczności
Ta funkcja nie jest już dostępna.
Nowa funkcja niestandardowej agregacji zwiększa wydajność analityczną, umożliwiając definiowanie niestandardowych danych, które Edge zbiera i przechowuje w miarę wykonywania wywołań interfejsu API. Gdy wyświetlasz raporty, Edge uzyskuje dostęp do dostępnych już zagregowanych danych, zamiast pobierać je na bieżąco. - Wstępnie skonfigurowany protokół OAuth 2.0 w proxy interfejsu API
Podczas tworzenia proxy interfejsu API nowa opcja „Zabezpiecz za pomocą tokenów dostępu OAuth 2.0” automatycznie konfiguruje proxy interfejsu API za pomocą zasad obsługujących OAuth.
Zobacz OAuth. - Maskowanie danych w śledzeniu
Zasób interfejsu API /maskconfigs umożliwia maskowanie danych wrażliwych, takich jak informacje o kartach kredytowych, w sesjach śledzenia proxy interfejsu API, co pomaga zapewnić bezpieczeństwo danych użytkowników podczas tworzenia interfejsu API.
Case:810723
Zobacz Maskowanie i ukrywanie danych. - Zasada uwierzytelniania podstawowego
Zasada uwierzytelniania podstawowego umożliwia dodanie do serwera proxy interfejsu API lekkiego uwierzytelniania podstawowego, które zapewnia 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 serwera proxy interfejsu API i udostępnia informacje do rejestrowania, które nie są obliczane do momentu wysłania odpowiedzi, np. client.sent.start.timestamp i client.sent.end.timestamp.
Zgłoszenie: 814059
Usunięte błędy
W tej wersji naprawiliśmy te błędy:
| Temat | Opis |
|---|---|
| Weryfikacja nazwy raportu niestandardowego | Edge weryfikuje teraz nazwy raportów niestandardowych, aby uniemożliwić używanie znaków specjalnych. |
| Zgłaszanie problemów z szczegółowymi informacjami o aplikacji dewelopera | W raportach niestandardowych, które korzystały z szczegółowych informacji o aplikacji dewelopera, zwracane były nieprawidłowe aplikacje dewelopera. Naprawiliśmy ten problem. |
| Przedział czasu nie działa w raportach 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. Ten problem został rozwiązany.Zgłoszenie: 810753 |
| Wykresy nie wyświetlają 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 WSDL |
|
| Konfiguracja zasady ograniczenia liczby równoczesnych żądań | Selektor docelowego punktu końcowego jest teraz dostępny tylko podczas dodawania do proxy interfejsu API zasad dotyczących limitu jednoczesnych wywołań. Punkt końcowy docelowy nie ma zastosowania do innych zasad. |
| Pomoc dla deweloperów | W przypadku organizacji, które mają włączone firmy, możesz teraz określić firmę podczas tworzenia lub edytowania dewelopera. Zgłoszenie: 515246 |
| Eksportowanie programistów, aplikacji i usług | Możesz teraz eksportować deweloperów, aplikacje i produkty do pliku CSV ze strony Deweloperzy w interfejsie zarządzania Edge. Ta funkcja jest obecnie niedostępna dla organizacji, które mają włączone zarabianie. Zgłoszenie: 747159 |
| Zawieszanie się okna Aplikacje dla deweloperów | Gdy deweloper usunął aplikację w portalu dla deweloperów Edge, kliknięcie tej aplikacji w interfejsie zarządzania Edge powodowało zawieszenie okna. Ten problem został rozwiązany. |
| Komentarze w konfiguracji proxy interfejsu API | Komentarze w konfiguracji proxy interfejsu API są teraz widoczne w widoku kodu edytora proxy interfejsu API i w Inspektorze właściwości. |
| Proxy interfejsu API utworzone z nieprawidłowymi nazwami | Interfejs zarządzania Edge umożliwiał wcześniej tworzenie serwerów proxy interfejsu API, których nazwy zawierały nieobsługiwane znaki specjalne. Powodowało to powstawanie nieprawidłowych serwerów proxy interfejsu API, których nie można było usunąć. Nazwy proxy interfejsu API są teraz weryfikowane w momencie tworzenia. Dozwolone są tylko znaki alfanumeryczne oraz „-” i „_”. Zgłoszenie: 550390 |
| Rozróżnianie wielkości liter w nazwach serwerów proxy interfejsu API | Edge tworzył proxy interfejsu API z nazwami pisanymi małymi literami, niezależnie od wielkości liter wpisanych przez użytkownika. Edge uwzględnia teraz wielkość liter w nazwie wpisanej dla serwera proxy interfejsu API. |
| Ostrzeżenie podczas zapisywania 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 jest obecnie wdrożona wersja, w tym w środowiskach produkcyjnych. Interfejs zarządzania Edge wyświetla teraz ostrzeżenie przed zapisaniem serwera proxy. |
| Rola niestandardowa bez uprawnień zapisywana w środowisku produkcyjnym | Gdy zaktualizowana zostanie wdrożona wersja interfejsu API, spowoduje to wewnętrzne wycofanie i wdrożenie w środowiskach, w których jest ona wdrożona. Rola niestandardowa bez odpowiednich uprawnień do wdrażania mogła wdrożyć zmiany, zapisując serwer proxy interfejsu API. Ten problem został rozwiązany przez wymuszenie uprawnień do wdrażania. Zgłoszenie: 813084 |
| Zduplikowany serwer docelowy | Podczas tworzenia zduplikowanego serwera docelowego Edge zamiast błędu HTTP 409 nadpisywał istniejący serwer docelowy i zwracał stan 201. Ten problem został rozwiązany przez zgłaszanie błędu 409 i niezastępowanie istniejącego serwera docelowego. |
| Nie można tworzyć sesji śledzenia dla proxy interfejsu API | Sesje śledzenia nie były tworzone w przypadku środowisk z procesorami wiadomości, które były niedostępne. Problem został rozwiązany przez dołączanie sesji śledzenia tylko do dostępnych procesorów wiadomości. Sprawa: 812192 |
| Zaktualizowane działanie JMSReplyTo | Domyślnie Edge wysyła odpowiedź do kolejki określonej w nagłówku JMSReplyTo.
Jeśli jednak chcesz, aby usługa backendu wysyłała odpowiedź do kolejki JMSReplyTo zamiast Edge, dodaj nagłówek X-Apigee-Ignore-JMSResponse do odpowiedzi proxy interfejsu API w dowolnym przepływie i ustaw wartość „true”:<Header name="X-Apigee-Ignore-JMSResponse">true</Header> |
| Duża liczba błędów CLOSE_WAIT i 502 Bad Gateway | Rozwiązaliśmy problem, który powodował wysokie wartości wskaźnika CLOSE_WAIT i błędy 502 Nieprawidłowa brama. Zgłoszenia: 814656, 814664, 814670 |
| Katalog tymczasowy Node.js | Gdy skrypt Node.js jest wdrażany w Edge, działa w środowisku piaskownicy, które ogranicza dostęp do systemu plików do określonego katalogu. Funkcja os.tmpdir zwraca jednak nazwę katalogu, np. /tmp lub /var/tmp, który nie istniał w środowisku piaskownicy Edge Node.js, co powodowało nieprawidłowe działanie niektórych skryptów. Piaskownica Edge Node.js zawiera teraz katalog /tmp, z którego może korzystać os.tmpdir. |
| Wyjątki wskaźnika o wartości null w wywołaniach interfejsu API | W zasadach przypisywania wiadomości stan odpowiedzi null powodował wyjątek wskaźnika null, ponieważ Edge próbował przechwycić kod odpowiedzi na potrzeby danych. Naprawiliśmy ten problem. Zgłoszenie: 815595 |