Niestandardowe hooki i wyzwalacze

Hooks and triggers connect platform lifecycle events to automated responses – so that things happen at the right moment automatically, not when someone remembers to act.

Framework Behavior Extensibility udostępnia zdarzenia platformy jako punkty zaczepienia dla niestandardowej logiki. Zdarzenie zostaje wywołane — projekt zostaje zapisany do Workspace, inicjowane jest wydanie, zmienia się stan cyklu życia komponentu — a hook reaguje. Odpowiedzią może być walidacja, która blokuje działanie, jeśli warunki nie są spełnione, efekt uboczny, który powiadamia lub aktualizuje system zewnętrzny, albo transformacja przygotowująca dane do kolejnego etapu potoku.

Hooki sprawiają, że platforma działa proaktywnie. Bez nich automatyzacja jest reaktywna: ktoś zauważa stan i uruchamia działanie. Dzięki hookom platforma działa we właściwym momencie z definicji, ponieważ wyzwalaczem jest samo zdarzenie.

Typy hooków i ich role

• Blocking hooks (pre-action) – hook blokujący uruchamia się przed zakończeniem działania i może uniemożliwić jego kontynuację. Hook zarejestrowany dla zdarzenia pre-release może uruchomić końcowy zestaw walidacji i przerwać wydanie, jeśli któraś z nich zakończy się niepowodzeniem. Hook przy zatwierdzaniu komponentu może sprawdzić, czy wszystkie wymagane pola są uzupełnione i czy wszystkie części producenta znajdują się na zatwierdzonej liście, zanim komponent trafi do biblioteki.

  Hooki blokujące są mechanizmem egzekwowania reguł, które muszą być spełnione, zanim działanie zostanie dozwolone – nie reguł, które idealnie powinny być spełnione, ale reguł, które muszą być spełnione. To właśnie one stanowią różnicę między „zalecamy sprawdzenie X przed wydaniem” a „wydanie nie może nastąpić, jeśli X nie jest spełnione”.

• Non-blocking hooks (post-action) – hook nieblokujący uruchamia się po zakończeniu działania i wyzwala efekty uboczne. Hook dla post-release może przesłać artefakty wydania do systemu zewnętrznego, zaktualizować rekord w ERP, powiadomić dalszy zespół w procesie lub zapisać zdarzenie audytowe. Wydanie już nastąpiło; hook obsługuje jego konsekwencje.

  Hooki po wykonaniu akcji są mechanizmem integracji służącym do utrzymywania synchronizacji systemów zewnętrznych ze stanem platformy. Są bardziej niezawodne niż okresowe odpytywanie lub ręczny eksport danych, ponieważ uruchamiają się dokładnie wtedy, gdy wystąpi odpowiednie zdarzenie.

• Scheduled triggers – poza hookami sterowanymi zdarzeniami platforma obsługuje planowane wykonywanie logiki automatyzacji – skryptów lub kontroli uruchamianych cyklicznie według harmonogramu, a nie w odpowiedzi na konkretne zdarzenie. Jest to przydatne w przypadku raportowania okresowego, synchronizacji danych, która nie musi odbywać się w czasie rzeczywistym, oraz operacji utrzymaniowych, które powinny być wykonywane regularnie.

Typowe wzorce

• Release gate enforcement – blokujący hook pre-release uruchamia końcowy zestaw kontroli – niestandardowe walidacje, odwołania do systemów zewnętrznych, sprawdzenie kompletności dokumentacji – i blokuje wydanie, jeśli którakolwiek z nich zakończy się niepowodzeniem. Inżynier otrzymuje jasną informację zwrotną o tym, co nie przeszło i co musi zostać rozwiązane. Rekord wydania zawiera wyniki hooka, dzięki czemu istnieje pełna ścieżka audytu tego, co zostało sprawdzone i co zakończyło się powodzeniem.

• Post-release propagation – hook nieblokujący post-release przesyła dane wydania do systemów downstream: realizacji produkcji, ERP, zarządzania projektami, systemów archiwizacji. Hook uruchamia się automatycznie po zakończeniu wydania, eliminując ręczny etap powiadamiania lub aktualizowania każdego systemu.

• Lifecycle synchronization – gdy stan cyklu życia komponentu zmienia się w Altium 365 – z „In Design” na „Released” albo z „Active” na „Obsolete” – hook może propagować tę zmianę do PLM, ERP lub innych systemów utrzymujących rekordy komponentów. Hook jest punktem synchronizacji; zdarzenie platformy jest autorytatywnym wyzwalaczem.

• Key System Flow override – w bardziej zaawansowanych przypadkach hooki mogą być używane do nadpisywania lub rozszerzania podstawowych przepływów platformy – modyfikowania domyślnego zachowania w kluczowych punktach cyklu życia systemu. To zaawansowany sposób użycia i znajduje się na roadmapie jako funkcja, która będzie z czasem rozwijana.

Ryzyka i obsługa błędów

Hooki blokujące, które zawodzą z powodu niedostępności systemu zewnętrznego, nie powinny po cichu przepuszczać projektów dalej. Tryb awarii ma znaczenie: hook, który nie może połączyć się z listą zatwierdzonych dostawców, powinien domyślnie blokować — zablokować działanie i zgłosić, że kontrola nie mogła zostać ukończona — zamiast domyślnie przepuszczać i pozwalać, by potencjalnie niezgodny projekt przeszedł dalej.

Hooki po wykonaniu akcji, które wysyłają dane do systemów zewnętrznych, wprowadzają zależność od dostępności tych systemów. Projektuj z myślą o częściowej awarii: rejestruj zdarzenia, których nie udało się dostarczyć, wdrażaj logikę ponawiania prób i upewnij się, że nieudany hook nie pozostawi platformy i systemu zewnętrznego w niespójnym stanie.