Ta strona została przetłumaczona przez Cloud Translation API.

Jak wysyłać bezpośrednie żądania do routerów lub procesorów

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Wprowadzenie

Podczas rozwiązywania problemów warto uruchamiać interfejsy API bezpośrednio z komponentami Apigee, takimi jak router czy procesor komunikatów. Na przykład możesz to zrobić, aby:

Debuguj przejściowe problemy z niektórymi żądaniami do interfejsu API, które wskazują na problem z konkretnym komponentem Apigee (routerem lub procesorem wiadomości).
Zbierz więcej informacji diagnostycznych przez włączenie trybu debugowania w określonej instancji komponentu Apigee.
Wyłącz, że problem jest spowodowany przez konkretny komponent Apigee.
Sprawdź, czy operacje, takie jak wywoływanie nowej instancji lub ponowne uruchomienie instancji, przynoszą pożądany efekt.

Wymagania wstępne

Bezpośredni dostęp do routera lub komponentów procesora wiadomości, wobec których mają być uruchamiane żądania do interfejsu API.
Narzędzie cURL musi być zainstalowane w konkretnej instancji komponentu.
Żądanie do interfejsu API, które chcesz przetestować, w formacie cURL.

Oto przykładowe polecenie curl, którego możesz użyć, aby wysłać żądanie do serwera proxy interfejsu API z komputera lokalnego:
```
curl https://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'
```
Uwaga: problemy, takie jak brakujące wdrożenia, można zidentyfikować nawet po częściowym skręceniu. Jeśli ruch jest kierowany do odpowiedniego serwera proxy, dla którego potrzebny jest tylko prawidłowy host i ścieżka bazowa, możesz przeprowadzać przydatne testy bez nagłówków, które byłyby konieczne do uzyskania odpowiedzi, np. nagłówka autoryzacji. W tym przypadku prawidłowym przykładem będzie powyższy przykład bez nagłówka:
```
curl https://myorg-test.mycompany.com/v1/customers
```

Jak uruchamiać żądania do interfejsu API bezpośrednio względem routerów Apigee

Scenariusz 1. Żądania do interfejsu API kierowane do aliasu hosta wskazującego routery

Jeśli wpis DNS aliasu hosta jest skonfigurowany tak, aby wskazywał routery Apigee Edge (czyli nie ma systemu równoważenia obciążenia ELB), możesz użyć tych poleceń curl, aby wysłać żądania do interfejsu API bezpośrednio do routera:

Host wirtualny skonfigurowany do niezabezpieczonej komunikacji przez port 80

curl -v --resolve HOST_ALIAS:80:127.0.0.1 http://HOST_ALIAS/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Na przykład:

curl -v --resolve myorg-test.mycompany.com:80:127.0.0.1 http://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Host wirtualny jest skonfigurowany do kończenia SSL na porcie 443 routera

curl -v --resolve HOST_ALIAS:443:127.0.0.1 https://HOST_ALIAS/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Na przykład:

curl -v --resolve myorg-test.mycompany.com:443:127.0.0.1 https://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Scenariusz 2. Żądania do interfejsu API kierowane do aliasu hosta wskazującego pliki ELB

Jeśli wpis DNS aliasu hosta jest skonfigurowany tak, aby wskazywał elastyczny system równoważenia obciążenia (ELB), możesz użyć tych poleceń curl, aby wysyłać żądania do interfejsu API bezpośrednio do routera:

Host wirtualny skonfigurowany do niezabezpieczonej komunikacji przez port 80

curl -v --resolve HOST_ALIAS:80:127.0.0.1 http://HOST_ALIAS/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Na przykład:

curl -v --resolve myorg-test.mycompany.com:80:127.0.0.1 http://myorg-test.mycompany.com/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Host wirtualny skonfigurowany pod kątem wysokiego portu i protokołu SSL kończy się w systemie równoważenia obciążenia przed routerem Apigee

curl -v --resolve HOST_ALIAS:PORT_NUMBER:127.0.0.1 http:/HOST_ALIAS:PORT_NUMBER/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Na przykład:

curl -v --resolve myorg-test.mycompany.com:19001:127.0.0.1 http://myorg-test.mycompany.com/v1/customers -H 'authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Host wirtualny skonfigurowany pod kątem wysokiego portu i protokołu SSL kończy się na routerze Apigee

Inaczej mówiąc, system równoważenia obciążenia jest skonfigurowany tak, aby wykorzystywał przekazywanie TCP do routera Apigee.

curl -v --resolve HOST_ALIAS:PORT_NUMBER:127.0.0.1 https:/HOST_ALIAS:PORT_NUMBER/PROXY_BASE_PATH/ -H 'HEADER: VALUE'

Na przykład:

curl -v --resolve myorg-test.mycompany.com:19001:127.0.0.1 https://myorg-test.mycompany.com/v1/customers -H 'authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2'

Jak uruchamiać żądania bezpośrednio wobec procesorów wiadomości Apigee

Scenariusz 1. Żądanie interfejsu API do procesora wiadomości przez domyślny port 8998

Domyślny port, na którym procesor wiadomości nasłuchuje ruchu z routera Apigee, to 8998. Dlatego we wszystkich przypadkach, w których ten port nie został zmieniony, ruch musi być kierowany bezpośrednio na ten port w określonej instancji procesora wiadomości, jak w przykładzie poniżej. Żądanie curl musi zostać wysłane na adres URL http://INTERNAL_IP_OF_MP:8998 wraz z nagłówkiem X-Apigee.Host z nazwą hosta i portem używanym w hostach wirtualnych, jak w tych 3 przykładach:

Host wirtualny jest skonfigurowany pod kątem zakończenia SSL na routerze

curl -v http://INTERNAL_IP_OF_MP:8998/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:443'

Na przykład:

curl -v http://10.10.53.115:8998/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:443'

Host wirtualny jest skonfigurowany dla „wysokiego portu” i zakończenie SSL ma miejsce w systemie równoważenia obciążenia LUB na routerze Apigee:

curl -v http://INTERNAL_IP_OF_MP:8998/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:PORT_NUMBER'

Na przykład:

curl -v http://10.10.53.115:8998/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:19001'

Host wirtualny jest skonfigurowany na domyślny port http 80

curl -v http://INTERNAL_IP_OF_MP:8998/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:80'

Na przykład:

curl -v http://10.10.53.115:8998/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:80'

Scenariusz 2. Żądanie do interfejsu API wysyłane do procesora wiadomości przez port SSL 8443

Istnieje możliwość skonfigurowania komunikacji SSL między routerem a procesorem wiadomości. W podanych niżej przykładach używany jest port 8443 – port sugerowany w dokumentacji Apigee.

Host wirtualny jest skonfigurowany pod kątem zakończenia SSL na routerze

curl -v -k https://INTERNAL_IP_OF_MP:8443/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:443'

Na przykład:

curl -v https://10.10.53.115:8443/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:80'

Host wirtualny jest skonfigurowany pod kątem zakończenia SSL w systemie równoważenia obciążenia, a ruch jest przekierowywany do routera przez wysoki port.
```
curl -v https://INTERNAL_IP_OF_MP:8443/PROXY_BASE_PATH/ -H 'HEADER: VALUE' -H 'X-Apigee.Host: HOST_ALIAS:PORT_NUMBER'
```
Na przykład:
```
curl -v https://10.10.53.115:8443/v1/customers -H 'Authorization: Bearer AxLqyU09GA10lrAiVRQCGXzMi9W2' -H 'X-Apigee.Host: myorg-test.mycompany.com:19001'
```
Uwaga: to samo polecenie curl jest używane w przypadku żądań, które korzystają z wzajemnego protokołu SSL, więc nie można przetestować ich bez certyfikatu klienta.