4.15.07.00 – informacje o wersji Apigee Edge for Private Cloud

Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info

We wtorek 8 września 2015 r. udostępniliśmy ważną wersję funkcji Apigee Edge Private Cloud.

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

• Chmura: 15.04.15, 15.04.29, 15.05.27, 15.06.10 i 15.06.24
• Chmura prywatna: 4.15.04.01

Na które wersje Edge można przejść 4.15.07.00

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

• Bezpośrednie przejście na wersję 4.15.07.00
• Uaktualniaj stopniowo, co oznacza, że musisz przejść z obecnej wersji na inną wersję Edge, a następnie uaktualnić do wersji 4.15.07.00.

Więcej informacji znajdziesz w artykule Do której wersji Edge for Private Cloud można uaktualnić wersję 4.15.07.00.

Przed uaktualnieniem z wersji 4.15.01.x lub starszej

1. Sprawdź wersję SSTable Cassandra:
   1. Przejdź do katalogu /<install-root>/apigee4/data/cassandra/data.
   2. Uruchom polecenie wyszukiwania:
      > find . -name *-ic-*
      Jeśli używasz tabeli SSTable w Cassandrze 1 .2, wyniki powinny zawierać zestaw plików.db.
   3. Uruchom to polecenie wyszukiwania:
      > find . -name *-hf-*
      Wyniki powinny być puste, co oznacza, że w formacie hf nie ma plików .db. Jeśli nie widzisz żadnych plików w formacie hf, możesz zakończyć proces i zaktualizować oprogramowanie do wersji 4.15.07.00.
      
      Format hf jest przeznaczony dla tabel SSTable w Cassandrze 1.0. Jeśli masz pliki *.db w formacie hf, musisz zaktualizować SSTable zgodnie z pozostałą częścią tej procedury.
2. Jeśli znajdziesz pliki *.db w formacie hf, uaktualnij SSTable, wykonując to polecenie na każdym węźle Cassandra, aż uaktualnisz 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 w przypadku wersji Cassandra 1.2.
4. Powtórz kroki 1–3 na każdym węźle Cassandra w instalacji Edge.
5. Uaktualnij do wersji Edge 4.15.07.00.
6. Po aktualizacji do wersji 4.15.07.00 sprawdź, czy wszystkie pliki *.db zostały zaktualizowane do tabeli sstable w stylu C* 2.0:
   > cd /<install-root>/apigee4/data/cassandra/data
   > find . -name *-jb-*
   To polecenie powinno zwrócić zestaw plików .db, jeśli używasz Cassandry w wersji 2.0.

Nowe funkcje i ulepszenia

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

Instalacja i aktualizacja

Selektywne uaktualnianie i odinstalowywanie komponentów

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

Cofanie uaktualnienia

Jeśli skrypt apigee-upgrade.sh zakończy się niepowodzeniem podczas uaktualniania, możesz użyć skryptu apigee-rollback.sh do wycofania uaktualnienia. Po rozwiązaniu problemów z aktualizacją możesz spróbować ponownie. (OPDK-1275)

Opcje skróconego skryptu instalatora

Skrypty instalacyjne nie przyjmują już opcji w długiej formie, np. --help. Obecnie akceptują tylko opcje składające się z jednej litery, np. -h. (OPDK-1356)

Instalacja SmartDocs

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

Uruchamianie skryptu update-cass-pwd-in-config.sh bez monitów

Skrypt update-cass-pwd-in-config.sh może działać bez monitów, jeśli ustawisz zmienne środowiskowe ENABLE_CASS_AUTH, CASS_USERNAME i CASS_PASSWORD. (OPDK-1309)

Edge Platform

Ta wersja zawiera nowe funkcje platformy Edge:

OpenJDK 1.7 obsługiwany przez Edge Private Cloud

Ta wersja Edge obsługuje Oracle JDK 1.7 i OpenJDK 7, a nie obsługuje już JDK 1.6. (OPDK-1187)

Obsługa systemu operacyjnego

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

Cassandra 2.0.15 w OPDK 15.07

Ta wersja instaluje Cassandrę 2.0.15. Jeśli uaktualniasz poprzednią wersję, Twoja wersja Cassandry zostanie zaktualizowana. (OPDK-1197)

Obsługa SHA2 w przypadku haszowania tokenów OAuth

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

Jeśli do włączenia funkcji haszowania SHA1 używasz właściwości hash.oauth.tokens.enabled, skrypt uaktualniający w tej wersji automatycznie wygeneruje dla Ciebie nowe właściwości na poziomie organizacji. Aby sprawdzić, czy uaktualnienie się powiodło, wyślij żądanie GET jako administrator systemu za pomocą tego interfejsu API: https://{host}:{port}/v1/o/{your_org}.

• Informacje o włączaniu w organizacji haszowania tokenów za pomocą nowych właściwości znajdziesz w sekcji „Haszowanie tokenów w bazie danych” w artykule Żądanie tokenów dostępu.
• Informacje o zbiorczym haszowaniu istniejących tokenów znajdziesz w przewodniku po operacjach Edge for Private Cloud. (APIRT-1389)

Płaska struktura katalogów plików dziennika

Możesz skonfigurować Edge tak, aby przechowywał pliki dziennika w płaskiej strukturze katalogów, ustawiając w pliku message-logging.properties wartość „true” dla nowej właściwości enable.flat.directory.structure. Więcej informacji znajdziesz w zasadach dotyczących rejestrowania wiadomości. (APIRT-1394)

Wydajność pamięci podręcznej środowiska

Aby lepiej zarządzać pamięcią podręczną w pamięci i ją wykorzystywać, ustawienia „Maksymalna liczba elementów w pamięci” w zasobach pamięci podręcznej środowiska zostały wycofane. Łączna liczba elementów we wszystkich zasobach pamięci podręcznej (w tym w pamięci domyślnej) zależy od łącznej ilości pamięci przydzielonej do pamięci podręcznej. Domyślnie łączna ilość pamięci przydzielonej do buforowania w pamięci na danym procesorze wiadomości to 40% łącznej dostępnej pamięci. Jest ona określana przez ustawienia właściwości pamięci podręcznej w pliku cache.properties procesora wiadomości. Elementy są usuwane z pamięci podręcznej tylko wtedy, gdy jest w niej za mało miejsca lub gdy wygaśnie ich ważność.

Aby przywrócić stare działanie polegające na używaniu właściwości „Maximum Elements in Memory” (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

Ta wersja zawiera te nowe funkcje usług API:

Nowy edytor proxy jako domyślny

Nowy edytor proxy interfejsu API jest domyślnie włączony w interfejsie zarządzania. Nowy edytor zawiera wiele ulepszeń, które zwiększają wygodę użytkowania. Należą do nich m.in. bardziej kompleksowe widoki przepływów warunkowych i punktów końcowych na stronie Przegląd, cała konfiguracja na stronie Tworzenie, bardziej intuicyjne dodawanie przepływów warunkowych, punktów końcowych i zasad, pełniejsze widoki XML zamiast małych fragmentów, wyszukiwanie, które przeszukuje nazwy plików i tekst, i wiele innych. (MGMT-2279)

Nowe zasady dotyczące usuwania informacji o OAuth w wersji 2.0

Nowe zasady „Usuwanie informacji OAuth w wersji 2.0” umożliwiają usuwanie tokenów dostępu OAuth w wersji 2 i kodów autoryzacji. Zasady zastępują funkcje, które wcześniej były dostępne w interfejsie Management API. Więcej informacji znajdziesz w artykule Usuwanie zasad dotyczących informacji OAuthV2. (MGMT-2257)

Nowe zasady dotyczące usuwania informacji o OAuth 1.0

Nowe zasady „Usuń informacje o OAuth 1.0” umożliwiają usuwanie tokenów żądań, tokenów dostępu i kodów weryfikacyjnych OAuth 1.0. Zasada ta zastępuje funkcję wcześniej udostępnianą przez interfejs Management API. Więcej informacji znajdziesz w artykule Zasady dotyczące usuwania informacji o OAuth V1. (APIRT-1351)

Zasady kontroli dostępu

Zasady kontroli dostępu zostały ulepszone, aby umożliwić dokładniejszą ocenę adresów IP na potrzeby tworzenia list dozwolonych i zabronionych, gdy adresy IP znajdują się w nagłówku HTTP X-FORWARDED-FOR.

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

Nowe podmioty w zasadach dostępu do podmiotów

Zasady Access Entity zapewniają dostęp do tych nowych podmiotów: consumerkey-scopes, authorizationcode, requesttoken i verifier. Więcej informacji znajdziesz w artykule Zasady dotyczące podmiotów mających dostęp.

Zasady dotyczące kolektora statystyk: automatyczna zmiana nazwy statystyk na małe litery

Podczas tworzenia niestandardowej kolekcji danych analitycznych w edytorze proxy interfejsu API (strona Develop > Tools > Custom Analytics Collection) zmienna kolektora (statystyka) „Name” musi być zapisana małymi literami. Jeśli wpiszesz nazwę wielkimi literami, narzędzie automatycznie przekonwertuje ją na małe litery w zasadach modułu zbierającego statystyki. (MGMT-740)

Usunięcie klasycznego śledzenia w edytorze proxy interfejsu API

Najnowsza wersja funkcji śledzenia w edytorze proxy interfejsu API została przeniesiona z wersji beta do ogólnej dostępności. Dostęp do „klasycznego śledzenia” za pomocą linku „Uzyskaj dostęp do klasycznej wersji śledzenia” nie jest już możliwy.

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

Dostęp do społeczności Apigee możesz uzyskać z menu Pomoc w interfejsie zarządzania.

Komunikaty o błędach w interfejsie zarządzania

W interfejsie zarządzania wprowadziliśmy te ulepszenia komunikatów o błędach:

• Interfejs zarządzania używany do grupowania i wyświetlania wszystkich komunikatów o błędach w interfejsie przez cały czas trwania sesji logowania, chyba że je zamkniesz. Dzięki tej aktualizacji komunikaty o błędach są automatycznie usuwane po opuszczeniu strony, na której wystąpiły. (MGMT-2254)
• Interfejs zarządzania nie pomija już zduplikowanych komunikatów o błędach. (MGMT-2242)

Ulepszenia wydajności interfejsu i obsługi błędów

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

Hiperłącza do 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 hiperlinkami, co umożliwia szybkie przechodzenie do stron ról. (MGMT-1055)

Nowe zmienne docelowe w przepływie wiadomości

Nowe zmienne w przepływach wiadomości zawierają pełniejsze informacje o adresach URL docelowych punktów końcowych i serwerów docelowych:

• TargetEndpoint: request.url zastępuje target.basepath.with.query.
• Serwer docelowy: loadbalancing.targetserver zastępuje targetserver.name. Poza tym pole target.basepath jest wypełniane tylko wtedy, gdy element <Path> jest używany w elemencie HTTPTargetConnection <LoadBalancer> w punkcie TargetEndpoint.

Obsługa SNI (Server Name Indication)

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

Wymagana jest Java 1.7.

SNI, czyli rozszerzenie protokołu TLS/SSL, umożliwia obsługę wielu miejsc docelowych HTTPS z tego samego adresu IP i portu bez konieczności używania przez nie tego samego certyfikatu.

Nie jest wymagana żadna konfiguracja specyficzna dla Edge. Jeśli środowisko jest skonfigurowane pod kątem rozszerzenia SNI w kierunku południowym (chmura Edge jest domyślnie), Edge je obsługuje.

Edge automatycznie wyodrębnia nazwę hosta z adresu URL żądania i dodaje ją do żądania uzgodnienia połączenia SSL. Jeśli na przykład host docelowy to https://example.com/request/path, Edge dodaje rozszerzenie server_name w sposób pokazany 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 dodaliśmy nowe pole „Algorytm podpisu”, które można wyświetlić w interfejsie zarządzania (Administracja > Certyfikaty SSL) i interfejsie API zarządzania (Pobieranie szczegółów certyfikatu z magazynu kluczy lub magazynu zaufanych certyfikatów). To pole zawiera wartość „sha1WithRSAEncryption” lub „sha256WithRSAEncryption” w zależności od typu algorytmu mieszającego użytego do wygenerowania certyfikatu.

Wyświetlanie certyfikatów SSL, których ważność wkrótce wygaśnie

Na stronie Certyfikaty SSL w interfejsie zarządzania (Administracja > Certyfikaty SSL) wyświetla się informacja o tym, kiedy certyfikaty SSL wygasną w ciągu 10, 15, 30 lub 90 dni, w zależności od wyboru w nowym polu menu wygasania.

Błąd konfiguracji ochrony przed zagrożeniami

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

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

Klienci korzystający z usług w chmurze muszą skontaktować się z zespołem pomocy Apigee Edge, aby ustawić właściwość organizacji. Ta funkcja będzie dostępna dla klientów Edge Private Cloud w kolejnej kwartalnej wersji Private Cloud.

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

Zaktualizowaliśmy schematy referencyjne dla elementów, które nie są objęte zasadami, 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

W tej wersji usług dla deweloperów wprowadziliśmy te nowe funkcje:

Ogólna dostępność SmartDocs

SmartDocs wychodzi z wersji beta i staje się ogólnie dostępny. Aktualizacje i nowe funkcje obejmują:

• Obsługa Swaggera 2.0, w tym importowanie według pliku lub adresu URL, a także obsługa obiektów zabezpieczeń o niestandardowych nazwach.
• Ulepszenia projektu wizualnego w szablonach, które generują dokumenty SmartDocs.
• Ulepszenia dotyczące użyteczności i przepływu pracy w Portalu dla deweloperów, dostępne w menu Treści > SmartDocs w Drupalu.
• Uwierzytelnianie znane dotychczas jako „Token niestandardowy” nosi teraz nazwę „Klucz interfejsu API”.
• Obiekty „security” uwierzytelniania zdefiniowane na poziomie wersji.
• Konfiguracja uwierzytelniania klienta na poziomie szablonu. Nowe wersje nie resetują już wstępnie skonfigurowanych danych logowania klienta Smart Docs.

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 deweloperskie w Edge mają wewnętrzną nazwę, która się nie zmienia, oraz nazwę wyświetlaną, którą możesz zmienić. Na stronie aplikacji 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 według ich wewnętrznych nazw na potrzeby rozwiązywania problemów i zarządzania interfejsami API.

Usługi analityczne

W tej wersji udostępniamy te nowe funkcje usług analitycznych:

Limit czasu przechowywania danych

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

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

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

Skuteczność widżetu Zaangażowanie deweloperów

Widżet ścieżki na głównym panelu analitycznym (sekcja Zaangażowanie deweloperów) został ulepszony, aby zapewnić lepszą wydajność.

Zarabianie

Ta wersja zawiera nowe funkcje zarabiania.

E-maile z powiadomieniami o planach cenowych

Nowy typ powiadomienia e-mail o pakiecie cenowym umożliwia powiadamianie deweloperów o osiągnięciu określonego limitu transakcji lub limitu w dolarach w przypadku zakupionych przez nich pakietów cenowych z zakresem ilościowym lub pakietów. Więcej informacji znajdziesz w artykule Konfigurowanie powiadomień za pomocą szablonów powiadomień.

Synchronizacja okresów opłaty cyklicznej i podstawy agregacji

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

• Okres opłaty cyklicznej skonfigurowany na karcie Opłaty w planie cenowym, który określał, kiedy deweloperzy byli obciążani opłatą cykliczną.
• Okres podstawowy agregacji, zdefiniowany w cenniku planów z płatnością za wolumen lub pakietów, który określał, kiedy wykorzystanie pakietu było resetowane w przypadku deweloperów.

Te 2 okresy są teraz zsynchronizowane. Jeśli w abonamencie występują zarówno niezerowa opłata cykliczna, jak i cennik oparty na przedziałach ilościowych lub pakietach, okres opłaty cyklicznej jest używany w obu przypadkach. Jeśli na przykład istnieje miesięczna opłata cykliczna, pakiety cennika są też resetowane co miesiąc (domyślnie na początku miesiąca).

Jeśli nie ma opłaty cyklicznej, pakiety są resetowane na podstawie parametru Aggregation Basis (Podstawa agregacji) zdefiniowanego w cenniku. Jeśli na przykład deweloper zacznie korzystać z cennika 19 dnia miesiąca, a podstawą agregacji będzie każdy miesiąc, wykorzystanie pakietu zostanie zresetowane miesiąc po 19 dniu miesiąca.

Kryterium agregacji zostanie wycofane i usunięte z funkcji zarabiania w przyszłej wersji. Więcej informacji znajdziesz w artykule Określanie szczegółów planu cennika.

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 niestandardowe atrybuty transakcji w raportach podsumowujących przychody. Dodając do organizacji usługę MINT.SUMMARY_CUSTOM_ATTRIBUTES, możesz wskazać, które atrybuty niestandardowe mają być dodawane do tabel bazy danych do użycia w raportach.

Klienci Apigee Edge na potrzeby chmury prywatnej mogą ustawić flagę za pomocą tego wywołania interfejsu API i danych logowania 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 uaktualniania SmartDocs

Jeśli korzystasz już z SmartDocs w okresie testów beta, nowe funkcje i możliwości w wersji ogólnodostępnej wymagają uaktualnienia SmartDocs w portalu dewelopera.

Wszystkie strony SmartDocs, które zostały już opublikowane w portalu dla deweloperów, będą nadal działać, ale przed edytowaniem lub publikowaniem zmian na istniejących lub nowych stronach musisz przejść proces aktualizacji.

Pamiętaj, że dokumenty SmartDocs możesz renderować i publikować w portalu dla deweloperów, ale są one generowane na podstawie modelu interfejsu API, który znajduje się w usługach zarządzania interfejsami API Edge od Apigee. Wszelkie zmiany wprowadzone w modelu API w Edge będą takie same we wszystkich środowiskach Pantheon (podobnie jak w przypadku deweloperów w środowiskach Pantheon).

Aby przejść z wersji beta SmartDocs na wersję ogólnodostępną:

1. Zaktualizuj i przetestuj wersję 15.05.27 w środowiskach programistycznym lub testowym na platformie Pantheon.
2. Utwórz nowy model, który zastąpi dotychczasowy model interfejsu API.
   • Jeśli importujesz dokumenty Swagger lub WADL, zaimportuj je ponownie do nowej wersji.
   • Jeśli model interfejsu API był utrzymywany 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ści > SmartDocs > model kliknij Ustawienia zabezpieczeń.
   
4. Sprawdź wstępnie skonfigurowane uwierzytelnianie na stronie ustawień modelu (Treści > SmartDocs), klikając Ustawienia w kolumnie Operacje.
   
5. Zaktualizuj wszystkie szablony niestandardowe, aby korzystały z wersji 6 zasobów CSS i JS, i wprowadź zmiany odzwierciedlające nowe nazwy obiektów, takie jak authSchemes i apiSchema. Informacje o aktualizowaniu szablonów SmartDocs znajdziesz w artykule Dokumentowanie interfejsów API za pomocą SmartDocs.
6. Ponownie wyrenderuj i opublikuj zmienioną wersję modelu.
7. Po sprawdzeniu nowej dokumentacji zaktualizuj portal produkcyjny do wersji 15.05.27.

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

Przyszłe zmiany i ulepszenia funkcji

W tej sekcji znajdziesz zapowiedź przyszłych zmian i ulepszeń funkcji:

Zmiana zachowania zasady pamięci podręcznej odpowiedzi

W przyszłej wersji (termin zostanie określony) zmieni się domyślne działanie elementu <ExcludeErrorResponse> zasady Pamięć podręczna odpowiedzi.

Obecne zachowanie: element <ExcludeErrorResponse> w zasadach pamięci podręcznej odpowiedzi ma domyślnie wartość false. Oznacza to, że domyślnie odpowiedzi z dowolnym możliwym kodem stanu HTTP (w tym 3xx) są zapisywane w pamięci podręcznej przez zasadę pamięci podręcznej odpowiedzi.

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

Obecne obejście: w przypadku chmury prywatnej w wersji 4.15.07.00 i starszych, jeśli chcesz buforować odpowiedzi tylko z kodami stanu od 200 do 205, musisz jawnie ustawić element <ExcludeErrorResponse> na wartość true.

Usunięte 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