API środowiska przeglądarki przenosi do kodu tworzenie środowisk, przypisywanie proxy, sprawdzanie stanu oraz uruchamianie i zatrzymywanie. Dzięki temu operacje zbiorcze są powtarzalne i audytowalne, a integracja z frameworkami automatyzacji jest prostsza. Przed integracją warto przygotować usługę lokalną, dane dostępowe i sprawdzić konflikty portów.
Gdy liczba środowisk kont rośnie do kilkudziesięciu, ręczne otwieranie okien i sprawdzanie każdej konfiguracji staje się wąskim gardłem. Zbiorcze tworzenie środowisk, masowe sprawdzanie stanu i uruchamianie według harmonogramu to zadania, które rozsądniej przekazać programowi.
Do tego służy API środowiska przeglądarki: przenosi działania związane z zarządzaniem środowiskiem z interfejsu do kodu, aby mogły być wywoływane przez skrypty lub własne systemy.
Dlaczego nie kontynuować ręcznie?
Problem z pracą ręczną nie polega tylko na tym, że jest wolna. Najbardziej kłopotliwe są trzy kwestie.
Pierwsza to skala. Jeśli w kilkudziesięciu środowiskach trzeba zmienić proxy, stronę startową lub odbudować konfigurację, ręczna praca oznacza setki kliknięć, a pojedynczy błąd łatwo przeoczyć. Druga to powtarzalność. Wynik ręcznej konfiguracji zależy od sposobu wykonania zadania danego dnia; ten sam wymóg zrealizowany dwa razy może dać nieco inne środowiska. W API konfiguracja jest zapisana jako parametry, więc jeden przebieg i sto przebiegów korzystają z tej samej logiki, a w razie problemu można wrócić do parametrów i znaleźć przyczynę. Trzecia to audytowalność. Wywołania API naturalnie pozostawiają zapis tego, kto, kiedy i które środowisko uruchomił oraz co zmienił. Gdy zespół rośnie, pamięć i ustne przekazanie informacji przestają wystarczać.
Jest też praktyczny powód: procesy ręczne trudno połączyć z istniejącymi systemami. Dane kont mogą znajdować się w arkuszach, harmonogram zadań gdzie indziej, a raporty w jeszcze innym narzędziu. API pozwala te elementy połączyć.
Jakie możliwości zwykle udostępnia API?
Szczegóły implementacji różnią się między dostawcami, ale API do zarządzania środowiskami zwykle obejmuje cztery grupy funkcji o podobnych granicach.
Najbardziej podstawowe jest zarządzanie cyklem życia środowiska: tworzenie, modyfikowanie i usuwanie środowisk oraz zbiorcze zapisywanie proxy, stron startowych i parametrów fingerprintu. Niektóre pola są obowiązkowe. Na przykład podczas tworzenia środowiska często wymagany jest identyfikator grupy; jego brak może od razu spowodować błąd parametrów.
Przypisanie proxy określa, czy środowisko jest prawidłowo powiązane z trasą sieciową. Jest to też jedna z najczęściej automatyzowanych czynności w zarządzaniu wieloma kontami: przypisanie konfiguracji proxy do konkretnego środowiska albo zbiorcza zmiana wyjścia dla wszystkich środowisk w danej grupie.
Zapytania o stan służą do wyświetlania list środowisk, informacji o grupach i aktualnie działających instancji. Dzięki nim można masowo sprawdzić, czy konta i środowiska nie zostały błędnie sparowane.
Planowanie zadań uruchamia i zatrzymuje instancje przeglądarki oraz zwraca stan działania i port debugowania. Po uruchomieniu framework automatyzacji przejmuje przeglądarkę przez zwrócony port i wykonuje właściwe operacje.
Mówiąc prosto: API przygotowuje i otwiera środowisko, a framework automatyzacji wykonuje pracę w jego wnętrzu. Gdy ten podział jest jasny, sposób integracji również staje się jasny.
Co warto przygotować przed integracją?
API jest zwykle udostępniane jako usługa lokalna i domyślnie działa tylko na tym samym komputerze. Dostęp zewnętrzny należy włączać jawnie tylko wtedy, gdy jest potrzebny. Warto też uruchomić weryfikację danych uwierzytelniających, aby każde żądanie wymagało prawidłowego Key i inne lokalne programy nie mogły swobodnie wywoływać usługi. Key należy traktować jako wewnętrzne dane dostępowe i nie umieszczać go we wspólnych dokumentach ani publicznych repozytoriach.
Najczęstsze problemy w łańcuchu automatyzacji dotyczą sieci i portów. Jeśli wywołanie zwraca 502 lub 503, bieżąca sieć może nie rozwiązywać nazwy hosta API; zastąpienie jej 127.0.0.1 lub localhost często pomaga. Odrzucone połączenie lub błąd proxy zwykle oznacza, że żądanie przechodzi przez nieprawidłowo skonfigurowany port proxy. Należy sprawdzić ścieżkę żądania albo użyć bezpośrednio adresu lokalnego. Jeśli sam stan lokalnego API jest nieprawidłowy, warto sprawdzić, czy program antywirusowy lub narzędzie proxy nie zajmuje kolidującego portu, i tymczasowo je wyłączyć na czas testu.
Częste problemy dotyczą też parametrów i sterowników. Przy błędzie o brakującym obowiązkowym parametrze należy najpierw porównać treść żądania z dokumentacją API. Brak identyfikatora grupy podczas zbiorczego tworzenia środowisk to typowy błąd. Sterownika przeglądarki zwykle nie trzeba pobierać osobno: klient instaluje odpowiednią wersję razem z silnikiem przeglądarki, a API uruchamiania zwraca skryptowi ścieżkę sterownika. Można użyć jej bezpośrednio. Opcje takie jak blokowanie obrazów czy wyłączanie powiadomień należy przekazać jako argumenty uruchomieniowe przy starcie przeglądarki; zmiana ich w konfiguracji środowiska nie przyniesie oczekiwanego efektu.
Na końcu należy sprawdzić połączenie. Jeśli środowisko uruchamia się poprawnie, ale skrypt nie może się połączyć, najpierw trzeba potwierdzić użycie portu debugowania zwróconego przez API, a potem sprawdzić, czy ten port nie jest już zajęty przez inny program.
Granice trzeba określić z góry
API ułatwia operacje zbiorcze, co oznacza również, że pojedynczy błąd może zadziałać na wiele środowisk naraz. Należy zachować co najmniej dwie granice: używać go wyłącznie dla własnych lub wyraźnie autoryzowanych kont i systemów biznesowych; nie używać go do masowej automatycznej rejestracji, omijania weryfikacji platform ani zabezpieczeń witryn. Jeśli platforma ma jasno określone zasady dotyczące liczby kont lub tożsamości, API jedynie poprawia wydajność zarządzania; nie zmienia tych zasad.
W takich scenariuszach PurpleMark zapewnia funkcje na poziomie środowiska: scentralizowane zarządzanie środowiskami, proxy i grupami w przestrzeni webowej, sterowanie uruchamianiem i zatrzymywaniem z systemów zewnętrznych przez lokalne API z walidacją Key oraz punkt integracji dla frameworków automatyzacji. Rozwiązanie pasuje do zespołów, które chcą włączyć zarządzanie środowiskiem do istniejących procesów.
Często zadawane pytania
Czy można korzystać bez znajomości programowania? Na początek nie trzeba używać API. Tworzenie, konfiguracja i operacje zbiorcze na środowiskach są dostępne również w interfejsie graficznym. API jest lepszym wyborem dla zespołów, które muszą połączyć własne systemy lub skrypty.
Czy API ujawnia informacje o kontach? Lokalne API jest domyślnie dostępne tylko na tym samym komputerze, a dodatkowo można włączyć walidację Key. Najważniejsze jest, by nie umieszczać Key ani informacji o API w publicznym repozytorium.
Jaki jest związek między API a funkcjami zbiorczymi w interfejsie? Funkcje zbiorcze w interfejsie są przeznaczone do działań uruchamianych ręcznie. API jest programistycznym punktem wejścia, odpowiednim do osadzania w procesach automatyzacji. Oba rozwiązują różne problemy.
Podsumowanie
Wartość API środowiska przeglądarki polega na standaryzacji przygotowania środowiska: tworzeniu zbiorczym, uruchamianiu zgodnie z konfiguracją, sprawdzaniu stanu i integracji z frameworkami automatyzacji. Przed integracją należy poprawnie skonfigurować usługę lokalną i dane dostępowe. W razie błędów warto sprawdzać kolejno sieć, parametry, sterowniki i porty, zachowując ograniczenie do własnych lub autoryzowanych systemów.
