Ustawienia uruchomień
Zakładka Ustawienia w prawym panelu automatyzacji zbiera nastawy dotyczące tego, jak proces ma być wykonywany: z jakim priorytetem, czy ma być ponawiany po niepowodzeniu biznesowym i ile czasu wolno mu zająć.
Ustawienia dotyczą procesu, a nie pojedynczej wersji - obowiązują wszystkie jego wersje i nie trzeba ich przenosić po każdej publikacji.
Nastawy dla procesów produkcyjnych
Priorytet i politykę ponawiania można ustawić dla automatyzacji opublikowanych. Wersja robocza służy do strojenia kodu, a nie do konfigurowania zachowania produkcyjnego.
1. Priorytet wykonywania
Liczba uruchomień wykonywanych równolegle jest ograniczona licencją. Gdy zgłoszeń jest więcej niż miejsc, ustawia się kolejka - a priorytet decyduje, co zostanie z niej zdjęte najpierw.
| Priorytet | Zastosowanie |
|---|---|
| Wysoki | Procesy pilne, na które ktoś czeka - na przykład wywoływane na żądanie z systemu dziedzinowego. |
| Średni | Wartość domyślna. |
| Niski | Prace masowe i nocne, które mogą poczekać - przetwarzanie wsadowe, raporty okresowe. |
Zasada jest prosta: najpierw wyższy priorytet, a przy równym - starsze zgłoszenie. Uruchomienie o wysokim priorytecie wyprzedzi w kolejce te, które czekają dłużej, ale nigdy nie przerwie pracy już rozpoczętej.
Priorytet ma sens dopiero pod obciążeniem
Dopóki w kolejce jest wolne miejsce, wszystko rusza od razu i priorytet nie robi różnicy. Warto go ustawić zawczasu - zadziała wtedy, gdy nocne przetwarzanie zbiegnie się z procesem uruchomionym na żądanie.
Sekcja Priorytet wykonywania widoczna jest na zrzucie u góry strony. Wybór zatwierdzasz przyciskiem Zapisz - każda z trzech sekcji zapisuje się osobno.
2. Automatyczne ponawianie (błędy biznesowe)
Część niepowodzeń jest przejściowa: system docelowy chwilowo nie odpowiada, dokument nie zdążył się jeszcze pojawić, sesja wygasła. Automatyczne ponawianie pozwala platformie powtórzyć takie uruchomienie bez udziału człowieka.
Ponawiane są wyłącznie błędy biznesowe
Polityka obejmuje uruchomienia zakończone błędem biznesowym, czyli takie, w których skrypt sam zgłosił niepowodzenie przez report_business_error. Zwykłe niepowodzenie techniczne i przekroczenie limitu czasu nie są ponawiane - sposób zgłaszania błędów biznesowych opisuje Kontrakt skryptu.
2.1. Konfiguracja
| Pole | Znaczenie |
|---|---|
| Włącz automatyczne ponawianie | Główny przełącznik polityki. |
| Maksymalna liczba ponowień | Ile dodatkowych uruchomień może powstać po pierwszym niepowodzeniu. Dopuszczalny zakres to 1–10. |
| Ponawiaj tylko, gdy skrypt oznaczył błąd jako możliwy do ponowienia | Zawęża politykę do błędów zgłoszonych z retryable=True. |
| Kody błędów do ponowienia | Lista rozdzielona przecinkami. Puste pole oznacza „każdy błąd biznesowy". |
Pod polem z kodami widnieje przypomnienie o jego składni: Rozdzielone przecinkami. Puste = każdy błąd biznesowy.
Stan domyślny
Świeża automatyzacja ma ponawianie wyłączone, Maksymalną liczbę ponowień ustawioną na 1
i zaznaczony warunek Ponawiaj tylko, gdy skrypt oznaczył błąd jako możliwy do ponowienia.
Samo włączenie przełącznika nie ponowi więc jeszcze niczego, jeśli skrypt nie zgłasza
retryable=True - patrz Kontrakt skryptu.
2.2. Jak działają filtry
Oba filtry można stosować razem - uruchomienie zostanie ponowione tylko wtedy, gdy przejdzie przez wszystkie warunki:
- Polityka jest włączona.
- Nie wyczerpano limitu ponowień.
- Jeśli zaznaczono Ponawiaj tylko… - skrypt zgłosił błąd z
retryable=True. - Jeśli podano kody błędów - kod zgłoszony przez skrypt jest na liście.
2.3. Projektowanie polityki
Rozdziel przyczyny w kodzie robota
Polityka jest tak dobra, jak kody błędów zgłaszane przez skrypt. Warto rozróżnić przyczyny przejściowe od trwałych już w kodzie:
report_business_error("ERP_TIMEOUT", "ERP nie odpowiedział", retryable=True)
report_business_error("INVOICE_REJECTED", "Faktura odrzucona - brak PO", retryable=False)
Pierwszy przypadek ma sens ponawiać, drugi nie - powtórzenie odrzuconej faktury odrzuci ją ponownie i tylko zajmie miejsce w kolejce.
Ponawianie nie naprawia procesu niepoprawnego
Automatyzacja, która przy każdym uruchomieniu dopisuje rekord, po trzech ponowieniach dopisze go czterokrotnie. Zanim włączysz ponawianie, upewnij się, że powtórzenie procesu na tych samych danych jest bezpieczne - albo że robot rozpoznaje pracę już wykonaną i ją pomija.
3. Limity czasu etapów
Uruchomienie dzieli się na etapy: uruchamianie sesji, pobieranie kodu robota, przygotowanie środowiska, instalacja zależności, praca robota, wysyłanie wyników, sprzątanie. Każdy z nich ma własny limit czasu, który chroni przed zawieszeniem procesu na stałe.
Pola pokazują wartości aktualnie obowiązujące - zmieniaj tylko te, w których dany proces odstaje od reszty.
Wartości domyślne, od których odbijają nadpisania:
| Etap | Domyślnie |
|---|---|
| Uruchamianie sesji | 3 min |
| Pobieranie kodu robota | 10 min |
| Przygotowanie środowiska | 15 min |
| Instalacja zależności | 30 min |
| Robot pracuje | 60 min |
| Wysyłanie wyników | 10 min |
| Sprzątanie | 5 min |
3.1. Suma limitów ma twardy pułap
Pod polami widnieje licznik w rodzaju „Łącznie: 2 h 13 min z 24 h", który przelicza się na bieżąco.
Suma limitów wszystkich etapów to najdłuższy możliwy czas jednego uruchomienia. Robot może pracować najwyżej 24 h - dłuższego uruchomienia platforma nie doprowadzi do końca, więc wyższej sumy nie da się zapisać.
Podnosząc jeden etap, warto więc spojrzeć na licznik: przekroczenie doby blokuje zapis całej sekcji, a nie tylko zmienianego pola.
3.2. Limit pracy robota
Dla automatyzacji wykonywanych przez agenta webowego działa pole Robot pracuje - to ono ogranicza czas pracy Twojego skryptu. Platforma przekazuje agentowi dokładnie tę jedną wartość; pozostałe sześć pól opisuje etapy egzekwowane przez agenta windowsowego.
Przekroczenie limitu kończy uruchomienie statusem Przekroczono limit czasu, a komunikat niesie wartość limitu, który został przekroczony.
Suma dotyczy wszystkich siedmiu pól, egzekwowanie - nie
Licznik Łącznie … z 24 h sumuje komplet siedmiu limitów, niezależnie od agenta. Przy
automatyzacji webowej nie traktuj więc tej sumy jako realnego czasu, po którym przebieg
zostanie ucięty - decyduje o tym samo pole Robot pracuje.
Limit ustawiaj z zapasem, ale nie bez umiaru
Zbyt krótki limit ubija pracę, która by się udała, i w panelu wygląda jak awaria produktu. Zbyt długi sprawia, że zawieszony robot blokuje miejsce w kolejce aż do wyczerpania limitu. Dobrym punktem wyjścia jest dwukrotność zmierzonego czasu typowego przebiegu.
Warto zmierzyć, zanim się ustawi: czas trwania każdego uruchomienia widać w zakładce Zakończone. Limit dobieraj po kilku przebiegach na realnych danych, a nie na podstawie oczekiwań - przetwarzanie stu dokumentów rzadko trwa dokładnie sto razy dłużej niż jednego.
3.3. Przywrócenie wartości domyślnych
Wyczyszczenie pola przywraca wartość globalną obowiązującą w środowisku. Nastawa dotyczy całego procesu i obowiązuje wszystkie jego wersje - również te, które nie były jeszcze publikowane.