4.15.07.00 – informacje o wersji Apigee Edge for Private Cloud

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

We wtorek 8 września 2015 r. wdrożyliśmy ważną aktualizację funkcji Apigee Edge dla chmury prywatnej.

Od poprzedniej kwartalnej wersji Edge for Private Cloud (4.15.04.00) pojawiły się i są uwzględnione w tej wersji kwartalnej te wersje:

• Chmura: 15.04.15, 15.04.29, 15.05.27, 15.06.10 i 15.06.24
• Private Cloud: 4.15.04.01

Do których wersji Edge można przejść? 4.15.07.00

W zależności od bieżącej wersji Edge możesz:

• Przejdź bezpośrednio do wersji 4.15.07.00
• stopniowo, co oznacza, że musisz przejść z obecnej wersji na inną wersję przeglądarki Edge, a potem zaktualizować do wersji 4.15.07.00.

Więcej informacji znajdziesz w artykule Które wersje Edge for Private Cloud można uaktualnić do wersji 4.15.07.00.

Przed przejściem z wersji 4.15.01.x lub wcześniejszej

1. Sprawdź wersję SSTable w Cassandra:
   1. Zmień katalog na /<install-root>/apigee4/data/cassandra/data.
   2. Uruchom polecenie znajdowania,
      > znajdowanie . -name *-ic-*
      Jeśli używasz SSTable w wersji 1 .2, wyniki powinny zawierać zestaw plików.db.
   3. Uruchom to polecenie:
      > znajdź . -name *-hf-*
      Wyniki powinny być puste, co oznacza, że żadne pliki .db nie mają formatu hf. Jeśli nie widzisz żadnych plików w formacie hf, to znaczy, że wszystko jest w porządku i możesz przejść na wersję 4.15.07.00.
      
      Format hf jest przeznaczony dla tabel SSTables w Cassandra 1.0. Jeśli masz pliki *.db w formacie hf, musisz uaktualnić tabelę SS zgodnie z dalszą częścią tej procedury.
2. Jeśli znajdziesz pliki *.db w formacie hf, zaktualizuj SSTable, wykonując to polecenie na każdym węźle Cassandra, aż zaktualizujesz wszystkie węzły Cassandra:
   > /<install-root>/apigee4/share/apache-cassandra/bin/nodetool -h localhost upgradesstables -a
3. Powtórz krok 1, aby sprawdzić, czy wszystkie pliki *.db są w formacie ic dla wersji Cassandra 1.2.
4. Powtórz kroki 1–3 w przypadku każdego węzła Cassandra w instalacji Edge.
5. Uaktualnij do wersji Edge 4.15.07.00.
6. Po uaktualnieniu do wersji 4.15.07.00 sprawdź pliki *.db, aby upewnić się, że wszystkie zostały uaktualnione do stylu sstable w wersji C* 2.0:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . -name *-jb-*
   Jeśli używasz Cassandra 2 .0, to polecenie powinno zwrócić zestaw plików.db.

Nowe funkcje i ulepszenia

Poniżej znajdziesz nowe funkcje i udoskonalenia w tej wersji.

Instalacja i uaktualnianie

Selektywna aktualizacja i odinstalowanie komponentów

Skrypty apigee-upgrade.sh i apigee-uninstall.sh umożliwiają teraz wybranie komponentów Edge do uaktualnienia lub odinstalowania. Wcześniej aktualizował lub odinstalowywał wszystkie komponenty w węźle. (OPDK-1377, OPDK-1175)

Cofanie uaktualnienia

Jeśli skrypt apigee-upgrade.sh nie zadziała podczas uaktualniania, możesz użyć skryptu apigee-rollback.sh, aby cofnąć uaktualnienie. Po rozwiązaniu problemów z aktualizacją możesz ponownie spróbować przeprowadzić aktualizację. (OPDK-1275)

Skrócone opcje skryptu instalatora

Skrypty instalacyjne nie obsługują już długich opcji, takich jak --help. Teraz obsługują tylko opcje jednoliterowe, takie jak -h. (OPDK-1356)

Instalacja SmartDocs

Podczas instalowania SmartDocs za pomocą skryptu setup-smartdocs.sh pojawi się prośba o podanie organizacji, środowiska i hosta wirtualnego, co zapewni zainstalowanie SmartDocs w oczekiwanej lokalizacji. Wcześniej te wartości były zakodowane na stałe w skrypcie. (OPDK-1310)

Uruchamianie polecenia update-cass-pwd-in-config.sh bez wyświetlania komunikatów

Skrypt update-cass-pwd-in-config.sh może być uruchamiany bez wyświetlania komunikatów, jeśli ustawisz zmienne środowiskowe ENABLE_CASS_AUTH, CASS_USERNAME i CASS_PASSWORD. (OPDK-1309)

Edge Platform

Poniżej znajdziesz nowe funkcje platformy Edge dostępne w tej wersji.

OpenJDK 1.7 obsługiwany przez Edge Private Cloud

Ta wersja Edge obsługuje Oracle JDK 1.7 i OpenJDK 7, a obsługa JDK 1.6 została wycofana. (OPDK-1187)

Pomoc dotycząca systemu operacyjnego

Apigee Edge for Private Cloud rozszerzyło obsługę systemów operacyjnych o Red Hat Enterprise Linux 6.6 i 7.0 (64-bit), CentOS 6.5, 6.6 i 7.0 (64-bit) oraz Oracle Linux 6.5.

Cassandra 2.0.15 zawarta w OPDK 15.07

Ta wersja instaluje Cassandra 2.0.15. Jeśli przechodzisz na nowszą wersję z poprzedniej wersji, zostanie zaktualizowana Twoja wersja Cassandra. (OPDK-1197)

Obsługa SHA2 do szyfrowania haszowania tokenów OAuth

Aby lepiej chronić tokeny OAuth w przypadku naruszenia bezpieczeństwa bazy danych, Edge obsługuje algorytmy SHA2 do szyfrowania haszowania tokenów OAuth (oprócz SHA1). Dzięki nowym właściwościom na poziomie organizacji możesz włączyć i skonfigurować szyfrowanie nowych tokenów, a także zachować starsze szyfrowanie tokenów, które istniały przed wprowadzeniem tej nowej funkcji. Wcześniej w Edge for Private Cloud właściwość hash.oauth.tokens.enabled w pliku keymanagement.properties (na serwerze zarządzania i procesorach wiadomości) umożliwiała automatyczne szyfrowanie SHA1 tokenów OAuth. Ta właściwość została wycofana.

Jeśli wcześniej używasz właściwości hash.oauth.tokens.enabled, aby włączyć szyfrowanie SHA1, skrypt uaktualniania w tej wersji automatycznie wygeneruje dla Ciebie nowe właściwości na poziomie organizacji. Aby zweryfikować po uaktualnieniu, jako administrator systemu wykonaj operację GET za pomocą tego interfejsu API: https://{host}:{port}/v1/o/{your_org}.

• Informacje o włączaniu funkcji szyfrowania tokenów w organizacji za pomocą nowych usług znajdziesz w sekcji „Szyfrowanie tokenów w bazie danych” w artykule Prośby o tokeny dostępu.
• Informacje o zbiorczym haszowaniu istniejących tokenów znajdziesz w przewodniku operacji dla Edge for Private Cloud. (APIRT-1389)

Płaska struktura katalogów dla plików dziennika

Możesz skonfigurować przeglądarkę Edge tak, aby przechowywała pliki dziennika w płaskiej strukturze katalogów. W tym celu w pliku message-logging.properties ustaw nową właściwość enable.flat.directory.structure na wartość true. Więcej informacji znajdziesz w zasadach dotyczących rejestrowania wiadomości. (APIRT-1394)

Wydajność pamięci podręcznej środowiska

Aby ułatwić zarządzanie pamięcią podręczną i jej wykorzystanie, wycofaliśmy ustawienia „Maksymalna liczba elementów w pamięci” w zasobach pamięci podręcznej środowiska. Łączna liczba elementów we wszystkich zasobach pamięci podręcznej (w tym domyślnej) zależy od łącznej ilości pamięci przydzielonej do tej pamięci podręcznej. Domyślnie łączna pamięć przydzielona do pamięci podręcznej w danym procesorze wiadomości wynosi 40% łącznej dostępnej pamięci, co jest określane przez ustawienia właściwości pamięci podręcznej w pliku cache.properties procesora wiadomości. Elementy będą usuwane z pamięci podręcznej tylko wtedy, gdy jest za mało pamięci podręcznej lub gdy ich okres ważności upłynął.

Aby przywrócić poprzednie zachowanie polegające na używaniu właściwości „Maksymalna liczba elementów w pamięci” do zarządzania pamięcią podręczną, ustaw właściwość overrideMaxElementsInCacheResource=false w pliku cache.properties. (APIRT-1140)

Usługi API

Oto nowe funkcje usług interfejsu API dostępne w tej wersji.

Nowy edytor proxy jako domyślny

Nowy edytor proxy API jest domyślnie włączony w interfejsie zarządzania. Nowy edytor zawiera wiele ulepszeń dotyczących użyteczności, w tym bardziej kompleksowe widoki przepływów warunkowych i punktów końcowych na stronie Przegląd, całą konfigurację na stronie Rozwijanie, bardziej intuicyjne dodawanie przepływów warunkowych, punktów końcowych i reguł, bardziej kompletne widoki XML zamiast małych fragmentów kodu, wyszukiwanie, które indeksuje nazwy plików i tekst, a także wiele innych funkcji. (MGMT-2279)

Nowa polityka dotycząca usuwania informacji OAuth 2.0

Nowa zasada „Usuwanie informacji OAuth 2.0” umożliwia usuwanie tokenów dostępu OAuth 2 i kodów autoryzacji. Zasady te zastępują funkcje, które wcześniej były dostępne w interfejsie API do zarządzania. Więcej informacji znajdziesz w zasadach dotyczących usuwania informacji OAuth 2. (MGMT-2257)

Nowa polityka dotycząca usuwania informacji OAuth w wersji 1.0

Nowa zasada „Usuwanie informacji OAuth w wersji 1.0” umożliwia usuwanie tokenów żądań OAuth w wersji 1.0, tokenów dostępu i kodów weryfikacyjnych. Zasady te zastępują funkcje, które wcześniej były dostępne w interfejsie API do zarządzania. Więcej informacji znajdziesz w zasadach dotyczących usuwania informacji OAuth v1. (APIRT-1351)

Zasady kontroli dostępu

Zasady kontroli dostępu zostały ulepszone, aby umożliwić bardziej szczegółową ocenę adresów IP na potrzeby dodawania do listy dozwolonych i odrzucania, gdy adresy IP znajdują się w nagłówku HTTP X-FORWARDED-FOR.

Jeśli w nagłówku jest włączone sprawdzanie wielu adresów IP (skontaktuj się z zespołem pomocy, aby skonfigurować opcję feature.enableMultipleXForwardCheckForACL), nowy element <ValidateBasedOn> w zasadach umożliwia sprawdzanie pierwszego, ostatniego lub wszystkich adresów IP w nagłówku. Więcej informacji znajdziesz w zasadach dotyczących kontroli dostępu.

Nowe typy encji w zasadach dostępu

Zasady dotyczące dostępu do obiektów zapewniają dostęp do tych nowych obiektów: consumerkey-scopes, authorizationcode, requesttoken i verifier. Więcej informacji znajdziesz w zasadach dotyczących dostępu do jednostek.

Zasady dotyczące Statistics Collector: automatyczne przekształcanie nazwy statystyk na małe litery

Podczas tworzenia niestandardowej kolekcji Analytics w edytorze usługi proxy interfejsu API (strona Tworzenie > Narzędzia > Niestandardowa kolekcja Analytics) zmienna kolekcji (statystyka) „Nazwa” musi być zapisana małymi literami. Jeśli wpiszesz nazwę wielkimi literami, narzędzie automatycznie zmieni ją na małe litery w zasadach Zbierania statystyk. (MGMT-740)

Usunięcie klasycznego śledzenia w edytorze proxy interfejsu API

Najnowsza wersja funkcji śledzenia w edytorze proxy interfejsu API przeszła z wersji beta do wersji ogólnodostępnej. Dostęp do „klasycznego śledzenia” za pomocą linku „Uzyskaj dostęp do klasycznej wersji śledzenia” nie jest już dostępny.

Dostęp do społeczności Apigee z menu pomocy w interfejsie zarządzania

Dostęp do społeczności Apigee uzyskasz w menu pomocy w interfejsie zarządzania.

Komunikaty o błędach w interfejsie zarządzania

Oto ulepszenia komunikatów o błędach w interfejsie zarządzania:

• Interfejs zarządzania służący do grupowania i wyświetlania wszystkich komunikatów o błędach w interfejsie przez całą sesję logowania, chyba że je odrzucisz. W ramach tej aktualizacji komunikaty o błędach są automatycznie usuwane, gdy opuścisz stronę, na której wystąpiły. (MGMT-2254)
• Interfejs zarządzania nie tłumi już duplikatów komunikatów o błędach. (MGMT-2242)

Ulepszenia działania interfejsu i poprawki błędów

Wprowadziliśmy ogólne ulepszenia różnych obszarów interfejsu zarządzania, w tym wyświetlania strony, wydajności i oczyszczania komunikatów o błędach.

Hiperlinki ról na stronie Użytkownicy organizacji w interfejsie zarządzania

Na stronie Użytkownicy organizacji w interfejsie zarządzania (Administracja > Użytkownicy organizacji) nazwy ról są teraz połączone hiperlinkami, co pozwala szybko przechodzić do stron ról. (MGMT-1055)

Nowe zmienne docelowe w przepływie wiadomości

Nowe zmienne w przepływach wiadomości zapewniają bardziej kompletne informacje o adresach URL docelowych punktów końcowych i docelowych serwerów:

• TargetEndpoint: request.url zastępuje target.basepath.with.query.
• TargetServer: loadbalancing.targetserver zastępuje targetserver.name. Ponadto element target.basepath jest wypełniany tylko wtedy, gdy w elementzie HTTPTargetConnection w elemencie TargetEndpoint występuje element <Path>.<LoadBalancer>

Obsługa Server Name Indication (SNI)

Edge obsługuje użycie wskazywania nazwy serwera w kierunku odwrotnym (od procesora wiadomości do punktów końcowych docelowych). Jeśli chcesz używać SNI, skontaktuj się z zespołem pomocy Apigee.

Wymagana jest wersja Java 1.7.

Dzięki SNI, które jest rozszerzeniem TLS/SSL, wiele docelowych adresów HTTPS może być obsługiwanych za pomocą tego samego adresu IP i portu bez konieczności używania tego samego certyfikatu.

Nie trzeba konfigurować przeglądarki Edge. Jeśli Twoje środowisko jest skonfigurowane pod kątem południowego SNI (domyślnie jest to Edge w chmurze), Edge obsługuje tę usługę.

Edge automatycznie wyodrębnia nazwa hosta z adresu URL żądania i dodaje go do żądania uzgadniania połączenia SSL. Jeśli na przykład docelowy host to https://example.com/request/path, przeglądarka Edge doda rozszerzenie server_name, jak pokazano poniżej:

Więcej informacji o SNI znajdziesz na stronie http://en.wikipedia.org/wiki/Server_Name_Indication.

„Algorytm podpisu” w szczegółach certyfikatów SSL

Do szczegółów certyfikatu SSL dodano nowe pole „Algorytm podpisu”, które jest widoczne w interfejsie zarządzania (Administracja > Certyfikaty SSL) oraz w interfejsie API zarządzania (Pobieranie szczegółów certyfikatu z Keystore lub Truststore). W tym polu widoczny jest albo „sha1WithRSAEncryption”, albo „sha256WithRSAEncryption”, w zależności od typu algorytmu haszowania użytego do wygenerowania certyfikatu.

Wyświetlanie certyfikatów SSL, które wkrótce wygasną

Strona Certyfikaty SSL w interfejsie zarządzania (Administracja > Certyfikaty SSL) wskazuje, kiedy kończy się ważność certyfikatów SSL w ciągu 10, 15, 30 lub 90 dni, w zależności od wybranej opcji w polu menu Nowy termin ważności.

Konfiguracja błędów ochrony przed zagrożeniami

Domyślnie Edge zwraca kod stanu HTTP 500 Błąd serwera wewnętrznego i błąd ExecutionFailed, jeśli wiadomość nie przejdzie przez zasadę Ochrona przed zagrożeniami w formacie JSON lub XML. Możesz zmienić to zachowanie błędu za pomocą nowej usługi na poziomie organizacji. Gdy ustawisz właściwość features.isPolicyHttpStatusEnabled w organizacji na wartość true, nastąpi:

• Żądanie: jeśli do dowolnego przepływu żądań dołączona jest zasada ochrony przed zagrożeniami, nieprawidłowe komunikaty zwracają kod stanu 400 wraz z odpowiednim komunikatem o błędzie zasad.
• Odpowiedź: jeśli do dowolnego przepływu odpowiedzi dołączona jest zasada ochrony przed zagrożeniami, nieprawidłowe wiadomości nadal zwracają kod stanu 500, a wywoływany jest jeden z odpowiednich komunikatów o błędzie zasad (a nie tylko ExecutionFailed).

Klienci Cloud muszą skontaktować się z zespołem pomocy Apigee, aby skonfigurować właściwość organizacji. Ta funkcja będzie dostępna dla klientów korzystających z Edge Private Cloud w ramach kolejnej kwartalnej aktualizacji Private Cloud.

Zaktualizowane schematy punktów końcowych, serwerów proxy i innych encji

Schematy referencyjne zostały zaktualizowane w przypadku jednostek niebędących elementami zasad, takich jak TargetEndpoint, ProxyEndpoint, APIProxy i wiele innych. Zobacz https://github.com/apigee/api-platform-samples/tree/master/schemas. (APIRT-1249)

Usługi dla deweloperów

Poniżej znajdziesz nowe funkcje Usług dla deweloperów w tej wersji.

Ogólna dostępność SmartDocs

SmartDocs przechodzi z wersji beta do wersji ogólnodostępnej. Aktualizacje i nowe funkcje:

• Obsługa Swagger 2.0, w tym importowanie za pomocą pliku lub adresu URL, w tym obsługa obiektów zabezpieczeń o niestandardowych nazwach.
• Ulepszenia wizualne w szablonach, które generują dokumenty inteligentne.
• Ulepszenia dotyczące użyteczności i procesów w portalu dla deweloperów, dostępne w menu Treści > SmartDocs w Drupalu.
• Metoda uwierzytelniania „Token niestandardowy” została teraz zastąpiona przez „Klucz API”.
• Obiekty „security” uwierzytelniania zdefiniowane na poziomie poprawki.
• Konfiguracja uwierzytelniania klienta na poziomie szablonu. Nowe wersje nie resetują żadnych wstępnie skonfigurowanych danych logowania klienta SmartDocs.

Więcej informacji o funkcjach znajdziesz w tym poście na blogu.

Dokumentację SmartDocs znajdziesz w artykule Używanie SmartDocs do dokumentowania interfejsów API.

Nazwa aplikacji dewelopera wyświetlana w interfejsie zarządzania

Aplikacje dewelopera w Edge mają zarówno wewnętrzną nazwę, która się nie zmienia, jak i wyświetlaną nazwę, którą możesz zmienić. Na stronie Aplikacja dewelopera w interfejsie zarządzania (Opublikuj > Aplikacje dewelopera > nazwa aplikacji) wyświetlana jest wewnętrzna „Nazwa” aplikacji wraz z „Wyświetlaną nazwą”, co ułatwia wizualne identyfikowanie aplikacji po ich nazwach wewnętrznych na potrzeby rozwiązywania problemów i zarządzania interfejsem API.

Usługi Analytics

Oto nowe funkcje Analytics Services dostępne w tej wersji.

Czas przechowywania danych

Podczas generowania raportów analitycznych za pomocą interfejsu zarządzania lub interfejsu API domyślnie nie są dostępne dane starsze niż 6 miesięcy. Jeśli chcesz uzyskać dostęp do danych starszych niż 6 miesięcy, skontaktuj się z zespołem pomocy Apigee.

Usunięcie klasycznej wersji raportów niestandardowych z interfejsu zarządzania

Opcjonalna klasyczna wersja niestandardowych raportów analitycznych nie jest już dostępna w interfejsie zarządzania.

Skuteczność widżetu Zaangażowanie dewelopera

Ulepszono widżet ścieżki w głównym panelu Analytics (sekcja Zaangażowanie deweloperów), aby zwiększyć jego skuteczność.

Zarabianie

Poniżej przedstawiamy nowe funkcje zarabiania dostępne w tej wersji.

E-maile z powiadomieniami o planach cenowych

Nowy typ powiadomienia e-mail o planie taryfowym umożliwia Ci informowanie deweloperów o osiągnięciu określonego limitu transakcji lub kwoty w zakupionych przez nich planach taryfowych z ograniczeniem objętości lub pakiecie. Więcej informacji znajdziesz w artykule Konfigurowanie powiadomień za pomocą szablonów powiadomień.

Synchronizacja okresów opłaty cyklicznej i okresów podstawy agregacji

W ramach planu taryfowego mogły obowiązywać 2 różne okresy:

• Okres opłat cyklicznych, skonfigurowany na karcie Opłaty w planie cenowym, który określał, kiedy deweloperom naliczano opłaty cykliczne.
• Okres podstawy agregacji zdefiniowany w cenniku planów z ograniczonym wolumenem lub pakietów, który określa, kiedy zresetowano użycie pakietu przez deweloperów.

Te 2 okresy są teraz zsynchronizowane. Jeśli w ramach abonamentu występują zarówno niezerowa opłata cykliczna, jak i karta stawek z ograniczeniem objętości lub pakietu, okres opłaty cyklicznej jest używany w obu przypadkach. Jeśli na przykład istnieje miesięczna opłata cykliczna, pakiety cenników są również resetowane co miesiąc (domyślnie na początku miesiąca).

Jeśli nie ma opłaty cyklicznej, pakiety są resetowane na podstawie podstawy agregacji zdefiniowanej w taryfie. Jeśli na przykład deweloper zacznie używać cennika 19 dnia miesiąca, a podstawa agregacji to „co miesiąc”, użycie pakietu zostanie zresetowane miesiąc po 19 dniu.

Podstawa agregacji zostanie wycofana i w przyszłej wersji zostanie usunięta z monetyzacji. Więcej informacji znajdziesz w artykule Określanie szczegółów abonamentu.

Atrybuty niestandardowe w raportach z podsumowaniem przychodów

Zasady rejestrowania transakcji umożliwiają opcjonalne rejestrowanie danych atrybutów niestandardowych z transakcji. Możesz teraz uwzględniać te atrybuty transakcji niestandardowych w raportach o przychodach z transakcji. Dodając do organizacji właściwość MINT.SUMMARY_CUSTOM_ATTRIBUTES, możesz wskazać, które atrybuty niestandardowe mają być dodawane do tabel bazy danych na potrzeby raportów.

Klienci korzystający z Apigee Edge for Private Cloud mogą ustawić tę flagę za pomocą tego wywołania interfejsu API i poświadczeń administratora systemu.

curl -u email:password -X PUT -H "Content-type:application/xml" http://host:8080/v1/o/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isMonetizationEnabled">true</Property>
        <Property name="MINT.SUMMARY_CUSTOM_ATTRIBUTES">[&quot;my_attribute_1&quot;,&quot;my_attribute_2&quot;]</Property>
        <Property name="features.topLevelDevelopersAreCompanies">false</Property>
    </Properties>
</Organization>"

Pamiętaj, że tablica atrybutów niestandardowych w wywołaniu interfejsu API jest zakodowana na potrzeby adresu URL.

Proces przekształcania SmartDocs

Jeśli korzystasz już z SmartDocs w wersji beta, nowe funkcje i możliwości w wersji ogólnodostępnej wymagają aktualizacji SmartDocs w portalu dla deweloperów.

Strony SmartDocs, które zostały już opublikowane w portalu dewelopera, będą nadal działać, ale przed edytowaniem lub opublikowaniem zmian na istniejących lub nowych stronach musisz wykonać proces aktualizacji.

Pamiętaj, że chociaż możesz renderować i publikować dokumenty SmartDocs w portalu dewelopera, dokumenty te są generowane na podstawie modelu interfejsu API, który znajduje się w usłudze zarządzania interfejsem API na krawędzi od firmy Apigee. Wszelkie zmiany wprowadzone w modelu interfejsu API w Edge będą takie same we wszystkich środowiskach Pantheon (podobnie jak deweloperzy w różnych środowiskach Pantheon).

Aby przejść z wersji beta SmartDocs do wersji ogólnodostępnej

1. Zaktualizuj i przetestuj wersję 15.05.27 w środowisku rozwojowym lub testowym w Pantheonie.
2. Utwórz nowy model, aby zastąpić dowolny dotychczasowy model interfejsu API, którego używasz.
   • Jeśli importujesz dokumenty Swagger lub WADL, zaimportuj je ponownie do nowej wersji.
   • Jeśli model interfejsu API był aktualizowany za pomocą modułu SmartDocs, wyeksportuj go jako plik JSON SmartDocs i zaimportuj do nowego modelu za pomocą załącznika.
3. Ustaw właściwości zabezpieczeń wersji modelu. Na stronie Treść > SmartDocs > model wybierz Ustawienia zabezpieczeń.
   
4. Sprawdź dowolną wstępnie skonfigurowaną metodę uwierzytelniania na stronie ustawień modelu (Treści > SmartDocs) przez kliknięcie Ustawień w kolumnie Operacje.
   
5. Zaktualizuj wszystkie szablony niestandardowe, aby używały zasobów CSS i JS w wersji 6. Wprowadź zmiany, aby uwzględnić nowe nazwy obiektów, np. authSchemes i apiSchema. Informacje o aktualizowaniu szablonów SmartDocs znajdziesz w artykule Używanie SmartDocs do dokumentowania interfejsów API.
6. Ponownie wyrenderuj i opublikuj zaktualizowany model.
7. Po zweryfikowaniu nowej dokumentacji zaktualizuj portal produkcyjny do wersji 15.05.27.

Jeśli jesteś klientem Edge Enterprise i masz pytania lub wątpliwości dotyczące procesu aktualizacji, wyślij e-maila na adresy marsh@apigee.com i cnovak@apigee.com. W przeciwnym razie skorzystaj z społeczności Apigee, aby uzyskać najlepszą odpowiedź.

Przyszłe zmiany i ulepszenia funkcji

W tej sekcji przedstawiamy przewidywane przyszłe zmiany i ulepszenia funkcji:

Zmień zachowanie zasady dotyczącej pamięci podręcznej odpowiedzi

W przyszłej wersji (która zostanie jeszcze ustalona) domyślne działanie elementu <ExcludeErrorResponse> w zasadach dotyczących pamięci podręcznej odpowiedzi ulegnie zmianie.

Obecnie: element <ExcludeErrorResponse> w zasadach dotyczącej pamięci podręcznej odpowiedzi ma domyślnie wartość „fałsz”. Oznacza to, że domyślnie odpowiedzi z dowolnym możliwym kodem stanu HTTP (w tym 3xx) są przechowywane w pamięci podręcznej zgodnie z zasadami dotyczącymi pamięci podręcznej odpowiedzi.

Przyszłe działanie: element <ExcludeErrorResponse> w sekcji Response Cache policy będzie domyślnie ustawiony na wartość Prawda. Oznacza to, że domyślnie w pamięci będą przechowywane tylko odpowiedzi z kodami stanu HTTP od 200 do 205. Aby zastąpić to zachowanie i zapisać w pamięci podręcznej odpowiedzi dla wszystkich kodów stanu, musisz jawnie ustawić element <ExcludeErrorResponse> na wartość true.

Obecna obejście problemu: w przypadku wersji 4.15.07.00 i starszych chmury prywatnej, jeśli chcesz przechowywać w pamięci podręcznej odpowiedzi tylko z kodami stanu 200–205, musisz wyraźnie ustawić element <ExcludeErrorResponse> na wartość true.

Naprawione błędy

W tej wersji naprawiliśmy te błędy:

Znane problemy

W tej wersji występują te znane problemy.

> source /{install-dir}/apigee4/bin/apigee-env.sh 

> VER=`basename $(find $SHARE_DIR/installer/monetization -name "mint-*.zip") | cut -d "-" -f 2,3,4` 

> sed -i "s/^MONETIZATION_VERSION=.*/MONETIZATION_VERSION=$VER/" /install-dir/apigee4/bin/apigee-env.sh 

> rm /install-dir/apigee4/share/monetization 

************************************** 
In order to complete the monetization upgrade please run: 
sudo /opt/apigee4/share/monetization/schema/migration/MOPDK4.15.04.00/
365-create-notification-condition.sh 
************************************** 

connect.ranges.denied=10.0.0.0/8,192.168.0.0/16,127.0.0.1/32

<install_dir>/apigge4/bin/apigee-service message-processor restart