Integracja ServiceNow
OpenFactory zawiera domyślnie wyłączone moduły integracji ServiceNow dla Change Management, CMDB, Incident Management, Event Management oraz dostarczania dowodów GRC. Każdy moduł i każdy automatyczny hook trzeba włączyć jawnie.
To integracja operatorska, a nie funkcja obrazu. Dodanie build feature servicenow dotyczy oprogramowania w obrazie i nie konfiguruje integracji control plane opisanej tutaj.
Wymagania wstępne
- zatwierdzona instancja ServiceNow i klient OAuth;
- dedykowane konto/aplikacja serwisowa z least privilege;
- wychodzący dostęp sieciowy ograniczony do oczekiwanej instancji;
- jawne mapowanie tabel, pól, stanów, przypisań i ownership;
- stabilny klucz szyfrowania platform settings; oraz
- nieprodukcyjne środowisko ServiceNow do testów akceptacyjnych.
Client secret jest szyfrowany Fernet w zapisanych platform settings i nie występuje w zwykłych odpowiedziach. Gdy klucz szyfrowania platformy się zmieni lub zostanie utracony, zapisanego secret nie da się odszyfrować i trzeba go zastąpić.
Konfiguracja warstwami
- Skonfiguruj URL instancji, client ID i secret w admin integration settings.
- Uruchom integration health check i zachowaj wynik każdego pojedynczego checku.
- Włącz jeden moduł bez automatic hooks.
- Wywołaj jego manual endpoint względem rekordu testowego.
- Zweryfikuj powstały rekord ServiceNow, powiązanie OpenFactory, idempotencję i zachowanie przy błędach.
- Włącz jeden automatic hook i powtórz test.
Nigdy nie włączaj wszystkich hooków jako pierwszego testu integracji.
Moduły
| Moduł | Obecna powierzchnia | Ważna granica |
|---|---|---|
| Change Management | Ręczne tworzenie change request/odświeżanie statusu, polling lub webhook approval updates, live-deploy gate | Powiązany request nie oznacza, że otrzymano approval; mapuj stany i zachowanie przy odrzuceniu jawnie. |
| CMDB | Ręczna synchronizacja/wycofanie maszyny plus fleet snapshots i diffs | Udany API write nie dowodzi CI reconciliation ani kompletności relacji. |
| Incident Management | Ręczne incydenty oraz opcjonalne hooki drift, attestation lub CVE; ograniczone feedback actions | Przychodzące webhooks muszą być uwierzytelnione, a każda action autoryzowana osobno. |
| Event Management | Buforowana/ręczna event delivery oraz wybrane build/live-state hooks | Bufory nie są gwarantowanym audit log; monitoruj delivery, utratę, duplikaty i retry. |
| GRC | Push dowodów build test/attestation z konfigurowalnym mapowaniem | Wyniki techniczne to dowody, a nie automatyczna control ani wniosek o zgodności. |
Wszystkie ustawienia modułów i operacyjne endpoints to administrator surfaces, chyba że endpoint dokumentuje węższego internal consumer.
Bezpieczeństwo approval
Zanim użyjesz ServiceNow do gatingu wdrożenia, przetestuj:
- stany approved, rejected, canceled, expired, unknown i unreachable;
- zduplikowane webhooks i out-of-order updates;
- walidację HMAC tam, gdzie skonfigurowana;
- polling recovery po pominiętych webhookach;
- zachowanie fail-closed, gdy policy wymaga approval; oraz
- ścieżkę recovery operatora, która nie omija po cichu accountable decyzji.
Przechowuj razem OpenFactory build/deploy ID oraz ServiceNow sys_id/number.
Dowody operacyjne
Monitoruj integration health endpoint, modułowy recent status, logi background task, buffer depth, failed deliveries, stale lifecycle findings oraz rotację secrets/key. Zielony connection test potwierdza tylko checki wykonane w danym momencie.
Do akceptacji użyj instancji sandbox i rekordów syntetycznych. Przed włączeniem produkcyjnym omów z właścicielem instancji dokładne ServiceNow ACLs, business rules, data residency, retention i licensing.