Make: Dyrektywa Rollback

0:00Cześć! W tej oraz kolejnych lekcjach pokażę Ci

0:02zaawansowane techniki obsługi błędów w Integromacie.

0:05Przede wszystkim zaczniemy od tego, aby skonfigurować sobie połączenie z Airtable,

0:09w ramach którego będziemy próbowali aktualizować poszczególne wpisy.

0:13W tym jednak przypadku podamy tutaj błędne identyfikatory rekordów i tym samym po

0:17wykonaniu tego scenariusza otrzymamy tutaj błąd.

0:19Zapewne nie jest Ci to obcy widok,

0:21ponieważ tego typu błędy zdarzają się praktycznie na każdym kroku.

0:25Dodatkowo muszę tutaj zaznaczyć, że

0:27domyślnym zachowaniem tego tematu jest wykorzystanie modułu Rollback.

0:31Taki moduł w przypadku pojedynczych

0:33modułów umożliwia cofnięcie zmian, które zostały wykonane.

0:36W tym jednak przypadku po pierwsze nie doszło do modyfikacji żadnych danych, a

0:41dodatkowo Airtable nie daje nam możliwości cofania wprowadzonych zmian.

0:45Więcej informacji na temat takiej dyrektywy znajdziesz w dokumentacji, w

0:49której mamy zaznaczone przede wszystkim to, że wykonanie scenariusza w momencie

0:52wystąpienia tej dyrektywy natychmiast go zatrzyma.

0:55Wszystkie pozostałe moduły nie zostaną

0:57wykonane i dodatkowo zostanie podjęta próba odwrócenia wprowadzonych zmian.

1:02Ale tak jak wspomniałem, w przypadku większości modułów nie jest to możliwe.

1:06Taka możliwość dotyczy wyłącznie takich modułów oznaczone tagiem ACID.

1:11Takie akcje możesz znaleźć chociażby w module MySQL.

1:14Ze względu na to, że bazy danych wspierają wykorzystanie tzw.

1:17transakcji, oznacza to, że jeżeli mamy zestaw akcji, które mają zostać wykonane

1:21na bazie danych, zostaną one zatwierdzone i tym samym zastosowane w naszej bazie.

1:26Dopiero w sytuacji, gdy rzeczywiście ich podjęcie będzie zweryfikowane jako

1:30możliwe, a w sytuacji, gdy coś pójdzie po drodze nie tak, wszystkie modyfikacje

1:35uwzględnione w danej transakcji będą mogły zostać cofnięte.

1:38Tymczasem jeżeli wrócimy do dokumentacji,

1:40to mamy tutaj jeszcze informację o tym, że w przypadku scenariuszy, które

1:44uwzględniają tą opcję z scheduling'u, czyli planowanych wykonań, to w momencie

1:48wystąpienia dyrektywy Rollback, zostaną one wyłączone i domyślnie dzieje

1:52się coś takiego w przypadku trzeciej próby.

1:55Natomiast w samych ustawieniach tego

1:56scenariusza możesz wskazać, ile razy wykonanie scenariusza zostanie podjęte,

2:00zanim faktycznie opcja scheduling'u zostanie wyłączona.

2:04Idąc dalej, scenariusz, w przypadku

2:05którego wystąpi ta dyrektywa zostanie oznaczony tagiem error.

2:09I czegoś takiego mamy tutaj potwierdzenie w momencie, gdy wykonamy ten scenariusz, a

2:13następnie cofniemy się do listy ostatnich wykonań.

2:16Rzeczywiście mamy tutaj oznaczenie wystąpienia błędu i jednocześnie też

2:20otrzymaliśmy wiadomość email informujący nas o wystąpieniem błędzie.

2:24Poza tym w przypadku deaktywowania tego scenariusza automatycznie dostaniemy

2:29dodatkową wiadomość informującą nas o tym fakcie.

2:32W takiej sytuacji jedyne co możemy zrobić, to po prostu przejść do edycji tej

2:35automatyzacji i wprowadzić zmiany, które spowodowały błąd.

2:39W tym konkretnym przypadku będzie to

2:41aktualizacja identyfikatora danego wpisu, a następnie ponowne wykonanie scenariusza.

2:46Tutaj jednak warto zaznaczyć, że w sytuacji, gdy ten moduł byłby np.

2:49piąty, to wszystkie wcześniejsze akcje po

2:52pierwsze zostałyby już wykonane, a dodatkowo w momencie gdy ponownie

2:56aktywowali ten scenariusz, to również zostaną one wykonane raz jeszcze.

3:00Natomiast jednocześnie wszystkie kolejne akcje, które następowały by po module, w

3:04którym wystąpił błąd, nie zostaną wykonane do czasu jego naprawienia.

3:08Coś takiego sprawia, że w niektórych

3:10przypadkach taka obsługa błędów jest bardzo uciążliwa i może doprowadzić do

3:14błędnej aktualizacji danych, które później musimy ręcznie poprawić.

3:18Jednocześnie też istnieje kilka innych

3:20sposobów dotyczących naprawy błędów, o których powiem Ci w kolejnych lekcjach.