Poradnik integracji IBAN-Test
Weryfikacja numerów IBAN w n8n z szablonem przepływu pracy
Zaimportuj niewielki przepływ uruchamiany ręcznie, skonfiguruj dane uwierzytelniające API IBAN-Test i kieruj wyniki do gałęzi VALID lub INVALID. Szablon sprawdza jeden numer IBAN naraz i zatrzymuje się, gdy nie może uzyskać wiarygodnego wyniku.
Pobierz pakiet startowy n8n
Plik ZIP zawiera przepływ pracy w formacie JSON, instrukcje konfiguracji, skrypt testowy offline i jego raport. Potrzebujesz instancji n8n obsługującej dołączone standardowe węzły, uprawnienia do tworzenia poświadczeń oraz tokena API IBAN-Test z dostępnym limitem.
Pobierz pakiet startowy (ZIP)Stan testów: Dołączony raport dokumentuje 24 zaliczone testy offline w Node.js: przypadki JavaScript, normalizację, duplikaty, limity, ścisłą klasyfikację wyników, odrzucanie sprzecznych odpowiedzi oraz konfigurację i połączenia przepływu. Definicje węzłów porównano z oficjalną dokumentacją i kodem n8n. Nie było dostępnej instalacji n8n ani danych uwierzytelniających API. Import, wykonanie w n8n, powiązania elementów i uwierzytelnione wywołania API pozostają niezweryfikowane. Przed użyciem wykonaj opisany poniżej test ręczny we własnej instancji.
Co robi szablon
Użyj ich jako startera przed podłączeniem formularza klienta, tabeli lub wewnętrznej bazy danych. Przepływ pracy rozpoczyna się ręcznie i zawiera cztery przykładowe wiersze: opublikowany przykładowy numer IBAN, wariant ze zmienioną cyfrą kontrolną, duplikat i pustą wartość. Usuwa białe znaki, konwertuje litery na wielkie, pomija puste wartości i grupuje duplikaty. Oryginalne pozycje wierszy są zachowywane w sourceRows, dzięki czemu wynik można przypisać do wielu wierszy.
Dopuszczalnych jest dziesięć różnych, niepustych numerów IBAN na przebieg. Jeśli jest ich więcej niż dziesięć, przepływ pracy zatrzymuje się przed pierwszym żądaniem; nadmiarowe wartości nie są po cichu odrzucane. Wartości brakujące lub puste są pomijane, natomiast przygotowanie wartości bez typu string zostaje zatrzymane. Nawet całkowicie puste dane wejściowe prowadzi do zatrzymania. Zapisz numery IBAN w swoim źródle jako tekst.
Każdy pozostały numer IBAN jest wysyłany w osobnym żądaniu REST. Integracja nie korzysta z endpointu zbiorczego: dziesięć różnych numerów IBAN oznacza do dziesięciu wywołań weryfikacji. Usuwanie duplikatów działa tylko w obrębie jednej realizacji przepływu. Ponowne uruchomienie sprawdza te same wartości od nowa. Planując wykorzystanie, uwzględnij dokumentację API IBAN-Test.
1. Zaimportuj plik przepływu pracy
Rozpakuj plik ZIP i otwórz nowy przepływ pracy w n8n. Z menu z trzema kropkami w prawym górnym rogu wybierz Import from File, a następnie iban-test-n8n-workflow.json. Zapisz przepływ pracy pod znaczącą nazwą. Te kroki odpowiadają Instrukcje importowania przepływu pracy n8n.
Powinno pojawić się dziewięć węzłów, począwszy od Run manually. Centralny węzeł One IBAN at a time przetwarza po jednym elemencie. Wyjście loop prowadzi do żądania HTTP i klasyfikatora, który wraca do pętli. Wyjście done prowadzi do gałęzi wyników. Nie zmieniaj tych połączeń podczas testu.
2. Zapisz token API jako dane dostępowe
Otwórz Validate IBAN. Uwierzytelnianie jest skonfigurowane jako Generic Credential Type z Header Auth. Utwórz dane uwierzytelniające nagłówka za pomocą następujących pól lub wybierz istniejące:
- Name:
Authorization - Value:
Bearer YOUR_API_TOKEN. Zastąp symbol zastępczy swoim tokenem i zachowaj spację poBearer.
Zapisz i wybierz te poświadczenia. Pobieranie celowo nie zawiera identyfikatora danych dostępowych ani tajemnicy. Przechowuj swój token tylko w formie danych uwierzytelniających, a nie w przykładowym kodzie lub w zwykłych parametrach węzła. Zobacz n8n odniesienie do poświadczeń żądania HTTP.
Żądanie jest już skonfigurowane jako POST https://www.iban-test.eu/api/v2/iban/validate. Wyrażenie treści JSON to {{ { iban: $json.iban } }}. Żądana jest odpowiedź JSON zawierająca status HTTP, aby następny węzeł mógł sprawdzić zarówno transmisję, jak i wynik API. Ustawienia opisano w Dokumentacja węzła żądania HTTP.
3. Uruchom przykłady ręcznie
Otwórz Sample rows i sprawdź przykładowe wartości. Następnie rozpocznij cały przepływ pracy za pomocą ręcznego wyzwalacza. Z podanych linii tworzone są dwa elementy zapytania. Jeżeli API zostanie wykonane pomyślnie, niezmieniony przykład powinien pojawić się pod VALID results, wariant ze zmienioną cyfrą kontrolną pod INVALID results. Są to oczekiwane wyniki pierwszego testu na żywo, a nie twierdzenie, że pobieranie zostało już przetestowane przy użyciu uwierzytelnionego konta.
Dla każdego elementu wyjściowego sprawdź iban, sourceRows, status i code. Gałęzie kończą się obecnie węzłami No Operation, w których można przeglądać wyniki bez zapisywania w innym systemie. Zastąp przykłady kilkoma wartościami testowymi, których możesz używać przed podłączeniem prawdziwego źródła danych.
Rozróżnij wyniki testów od błędów technicznych
| Odpowiedź | Akcja w przepływie pracy |
|---|---|
HTTP 200, kod 2100, error: false | Zwróć VALID. |
HTTP 200, kod 3100, 3101 lub 3102, error: true | Zwróć INVALID, aby poprawić dane. |
| Inny kod, nieudane żądanie lub nieoczekiwana odpowiedź | Zatrzymaj wykonanie do celów dochodzenia. |
Klasyfikacja wymaga kodu liczbowego w postaci liczby całkowitej i pola błędu logicznego. Kod uwierzytelniający 4002, kod przydziału 4003 i kod zablokowanego dostępu 4004 zatrzymują przepływ. Przekroczenie limitu czasu, status HTTP inny niż 200 lub nieprawidłowa treść odpowiedzi nigdy nie są rejestrowane jako nieprawidłowy numer IBAN. Podstawą jest udokumentowane kody wyników API. Prawidłowy numer IBAN nie potwierdza własności konta ani nie gwarantuje płatności.
węzeł Loop Over Items czeka na klasyfikację przed zażądaniem kolejnego elementu. W przypadku błędu technicznego późniejsze numery IBAN nie będą już wysyłane do API, a rozgałęzienia z ostatecznym wynikiem nie zostaną zrealizowane. Dane wyjściowe poprzedniego węzła mogą być nadal widoczne w edytorze. Traktuj wykonanie jako niekompletne.
Automatyczne powtarzanie jest wyłączone. Przed ponownym uruchomieniem rozwiąż problemy z uwierzytelnianiem lub przydziałem. Ręczny restart może pochłonąć dodatkowe wywołania dla wierszy, które zostały już sprawdzone. Jeśli dodasz później ponowne próby z powodu błędów tymczasowych, ogranicz liczbę i czas oczekiwania. Nigdy nie powtarzaj nieprawidłowych danych wejściowych lub żądań w pętli, gdy limit zostanie wyczerpany.
Przed podłączeniem danych produkcyjnych
Szablon wyłącza zapisywanie danych wykonań ręcznych, zakończonych powodzeniem i błędem, a także zapisywanie postępu. Po imporcie sprawdź ustawienia przepływu. Numery IBAN i odpowiedzi API mogą być widoczne podczas wykonania. Znaczenie mają również zasady hostingu, rejestrowania zdarzeń i kopii zapasowych. Nie przypinaj rzeczywistych danych klientów do węzłów i nie udostępniaj eksportów, które je zawierają.
Po pomyślnym teście ręcznym podłącz każdą gałąź wynikową do zamierzonego celu. Zachowaj identyfikatory źródła i zapobiegaj duplikowaniu rekordów przy powtarzających się uruchomieniach. Harmonogram można dodać dopiero po ustaleniu strefy czasowej, budżetu przydziału, komunikatów o błędach i zachowania podczas ponownego uruchamiania.
Dalsze informacje znajdują się w instrukcjach dla Sprawdź numer IBAN w Arkuszach Google i Sprawdzanie pliku CSV IBAN w Pythonie.
