4.15.07.00 – informacje o wersji Apigee Edge for Private Cloud

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

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

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
• Private Cloud: 4.15.04.01

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

W zależności od obecnej 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żesz 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 uaktualnić 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 dla 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 stylu sstable 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 ulepszanie

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 zmian 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. Teraz 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)

Platforma Edge

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. Wcześniej w usłudze Edge for Private Cloud właściwość o nazwie 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 mieszania 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ą 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 podręcznej 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 ona niewystarczająca lub gdy elementy wygasną.

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ń, w tym bardziej kompleksowe widoki przepływów warunkowych i punktów końcowych na stronie Przegląd, całą konfigurację 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 „Usuń informacje OAuth 2.0” umożliwiają usuwanie tokenów dostępu OAuth 2.0 i kodów autoryzacji. Zastępuje ona funkcję, którą wcześniej udostępniał interfejs Management API. Więcej informacji znajdziesz w artykule Usuwanie informacji o zasadach 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. Zastępuje ona funkcję wcześniej udostępnianą przez interfejs API zarządzania. Więcej informacji znajdziesz w zasadach dotyczących 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łączono 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 dotyczące podmiotu dostępu 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 modułu zbierającego (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 „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

Poniżej znajdziesz ulepszenia komunikatów o błędach w interfejsie zarządzania:

• 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 odrzucisz. 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 poprawki 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 pozwala szybko przechodzić 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.
• TargetServer: loadbalancing.targetserver zastępuje targetserver.name. Poza tym element target.basepath jest wypełniany tylko wtedy, gdy element <Path> jest używany w elemencie HTTPTargetConnection <LoadBalancer> w punkcie końcowym docelowym.

Obsługa rozszerzenia 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

Strona Certyfikaty SSL w interfejsie zarządzania (Administracja > Certyfikaty SSL) wskazuje, kiedy certyfikaty SSL wygasają w ciągu 10, 15, 30 lub 90 dni, w zależności od wyboru w nowym polu menu wygasania.

Błąd konfiguracji zabezpieczenia przed zagrożeniami

Domyślnie Edge zwraca kod stanu HTTP 500 Internal Server Error i błąd ExecutionFailed, jeśli wiadomość nie przejdzie zasady 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: w przypadku przepływu żądań, do którego 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 jeden z odpowiednich komunikatów o błędzie zasady (zamiast ExecutionFailed).

Klienci Cloud 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 nieobjętych 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

Ta wersja zawiera nowe funkcje usług dla deweloperów.

Ogólna dostępność SmartDocs

SmartDocs wychodzą z wersji beta i stają się ogólnie dostępne. 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 Smart Doc.
• 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 „bezpieczeństwa” uwierzytelniania zdefiniowane na poziomie wersji.
• Konfiguracja uwierzytelniania klienta na poziomie szablonu. Nowe wersje nie resetują już wstępnie skonfigurowanych danych logowania klienta SmartDocs.

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

Dokumentację SmartDocs znajdziesz w artykule Korzystanie z 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) wewnętrzna „Nazwa” aplikacji jest wyświetlana 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 interfejsem API.

Usługi analityczne

Ta wersja zawiera 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 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 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 taryfowych

Nowy typ powiadomienia e-mail o pakiecie cenowym umożliwia powiadamianie deweloperów, gdy osiągną określony limit transakcji lub limit pieniężny w zakupionych przez nich pakietach cenowych z zakresem ilościowym lub pakietach. Więcej informacji znajdziesz w artykule Konfigurowanie powiadomień za pomocą szablonów powiadomień.

Synchronizacja okresów Opłaty cyklicznej i Okresu agregacji

W ramach planu cenowego 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 zakresem woluminów lub pakietów, który określał, kiedy wykorzystanie pakietu było resetowane dla 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 w przyszłej wersji usunięte z funkcji zarabiania. 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 for Private Cloud 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 przekształcania SmartDocs

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

Wszystkie strony SmartDocs, które zostały już opublikowane w portalu dla programistó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 programistó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 interfejsu 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 programistycznych lub testowych na platformie Pantheon.
2. Utwórz nowy model, który zastąpi dotychczasowy model 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 (data nie jest jeszcze znana) zmieni się domyślne działanie elementu <ExcludeErrorResponse> zasady Pamięć podręczna odpowiedzi.

Obecne działanie: 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 odpowiedzi 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 Private Cloud 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