[Intum Pomoc](https://intum.pl/pomoc.md) / [InConnector](https://intum.pl/pomoc/inconnector.md)

# [Uruchamianie i sprawdzanie konektora](https://intum.pl/pomoc/inconnector/connect-uruchamianie-i-testowanie.md)

Zanim konektor zacznie pracować sam, w tle albo z flow, warto sprawdzić ręcznie, że odpowiada -
i mieć jak sprawdzić później, co właściwie do niego przyszło. Ten artykuł opisuje oba kierunki:
wywołania, które system wysyła do usługi, i żądania, które usługa przysyła do systemu.

> [!PATH]
> [Konektory](app:/connect/connectors) → *wybrany konektor*

## Ręczne uruchomienie wywołania {#execute}

Na karcie konektora, przy każdej pozycji z listy **Metody**, stoi odnośnik:

- **execute** - przy wywołaniu prywatnym (domyślnym). Kliknięcie pyta o potwierdzenie i od razu
  uruchamia wywołanie z pustymi danymi wejściowymi
- **url** - przy wywołaniu oznaczonym jako publiczne. Otwarcie tego adresu robi to samo, z tą
  różnicą, że taki adres da się też wywołać programowo z zewnątrz przez API konta (np. skryptem,
  z tokenem API konta) - zawsze jednak w kontekście zalogowanego konta, nie jako anonimowy
  dostęp bez żadnej autoryzacji

Część wywołań oczekuje danych wejściowych w formacie JSON - dla nich odnośnik **execute**
otwiera osobny ekran z polem **Parametry JSON** (podpowiedź nad polem pokazuje przykład) zamiast
uruchamiać wywołanie od razu. Wpisz dane i potwierdź przyciskiem **Wykonaj** - system pokazuje
surową odpowiedź usługi, dokładnie taką, jaką dostałby przepływ.

To samo uruchomienie da się wywołać też z karty [obiektu danych](inconnector/connect-procesy-flow-obiekty-danych)
- wtedy jako dane wejściowe idzie treść tego konkretnego obiektu, co przydaje się przy ponownym
przetworzeniu jednego zamówienia czy jednej faktury bez ręcznego przepisywania danych.

## Podgląd żądań przychodzących {#requesty}

Wywołania opisane wyżej to ruch wychodzący - system pyta usługę. W drugą stronę usługi
najczęściej odzywają się same, webhookiem: sklep zawiadamia o nowym zamówieniu, bank o wpłacie,
operator płatności o zmianie statusu.

Żeby zobaczyć, co faktycznie przyszło, włącz na konektorze **Loguj żądania** (w opcjach
dodatkowych edycji konektora), a potem otwórz **Requesty** na karcie konektora - lista pokazuje
każde żądanie z jego treścią, kodem odpowiedzi i czasem. Przy pojedynczym żądaniu jest przycisk
**Ponów Request**, który wysyła je do konektora jeszcze raz - przydatne przy diagnozowaniu, bez
czekania, aż usługa nadawcza spróbuje ponownie sama.

> [!WARNING]
> Logowanie żądań zostaw włączone tylko na czas diagnozy. Przy usłudze, która odpytuje system co
> kilka minut (albo webhookach z dużym ruchem), lista rośnie bardzo szybko i traci sens jako
> narzędzie diagnostyczne - trudno w niej znaleźć akurat to jedno żądanie.

## Kolejność sprawdzania nowego połączenia {#kolejnosc}

1. Zapisz konektor z minimalną konfiguracją (adres, klucz/dane do logowania).
2. Uruchom najprostsze wywołanie odnośnikiem **execute** - jeśli odpowiada bez błędu, adres i
   dane do logowania są poprawne.
3. Jeśli konektor ma też reagować na webhooki z usługi, włącz **Loguj żądania**, poproś usługę
   (albo sam sprowokuj zdarzenie) i sprawdź **Requesty**, czy żądanie w ogóle dotarło.
4. Wyłącz logowanie i podłącz konektor do właściwego [flow](inconnector/connect-flow).

Błędy przy tym kroku - brak odpowiedzi, błąd autoryzacji, wywołanie, które nie widzi klucza -
opisuje [Błąd autoryzacji albo sekretu w
konektorze](inconnector/connect-problemy-blad-autoryzacji-lub-sekretu).