Szablon: Rejestr interfejsów (IDK-13)

Szablon IDK-13, wersja 1.0. Faza: Confirm Prototype (musi istnieć przed rozpoczęciem budowy), utrzymywany przez Go Live i dalej w fazie wsparcia.

Jak korzystać z tego szablonu

Wymień każdy interfejs: te, które istnieją dziś wokół systemu legacy, oraz te, których będzie potrzebować nowe rozwiązanie. Uwzględnij zrzuty plików, arkusze wgrywane ręcznie według harmonogramu i raporty czytane przez inny system. Jeśli dane przekraczają granicę systemu, to jest interfejs.
Rozpocznij inwentaryzację w fazie Confirm Prototype. Rejestr musi być kompletny przed rozpoczęciem budowy, bo zapomniany interfejs zwykle wychodzi na jaw podczas cutover.
Rejestr jest podzielony na trzy tabele powiązane wspólnym ID: identyfikacja i przepływ (sekcja 4), mechanizm i bezpieczeństwo (sekcja 5), eksploatacja i status (sekcja 6). W arkuszu kalkulacyjnym mogą stanowić jedną szeroką tabelę.
Każdy nowy lub zmieniony interfejs dostaje też wiersz w rejestrze CRIM (szablon IDK-10) oraz specyfikację funkcjonalną (szablon IDK-11).
Przeglądaj rejestr przy każdej bramce i przy każdej aktualizacji wydania. Przekaż go do wsparcia przy starcie produkcyjnym.
Usuń wiersze oznaczone „Przykład:”, gdy pojawią się własne wiersze.

Metadane szablonu
Field	Value
ID szablonu	IDK-13
Faza	Confirm Prototype (musi istnieć przed rozpoczęciem budowy), utrzymywany przez Go Live i dalej w fazie wsparcia
Właściciel	Analityk techniczny po stronie klienta odpowiedzialny za integracje, wspierany przez kierownika rozwiązania technicznego
Zatwierdzający	Kierownik projektu po stronie klienta, komitet sterujący dla nowych interfejsów zapisu i utrzymywanych interfejsów legacy
Bramka kwalifikacyjna	Solution Confirmed
Wersja	1.0

Kontrola dokumentu

Pole	Wartość
Projekt	[Nazwa projektu]
Właściciel rejestru	[Imię i nazwisko, rola]
Kierownik rozwiązania technicznego	[Imię i nazwisko]
Właściciel bezpieczeństwa po stronie klienta	[Imię i nazwisko]
Lokalizacja przechowywania	[Link]
Rytm przeglądów	[Na przykład przy każdej bramce i przed każdą aktualizacją wydania]

Wersja	Data	Autor	Zmiana
0.1	[YYYY-MM-DD]	[Imię i nazwisko]	Inwentaryzacja interfejsów legacy
[x.y]	[YYYY-MM-DD]	[Imię i nazwisko]	[Zmiana]

1. Zasady tego rejestru

Każdy interfejs ma jednego wskazanego właściciela biznesowego i jednego wskazanego właściciela technicznego po stronie klienta.
Każdy interfejs działa na własnym koncie integracyjnym z własnym zestawem uprawnień. Żadnych kont współdzielonych ani kont osobistych.
Domyślnie dostęp jest tylko do odczytu. Dostęp zapisu do IFS Cloud jest przyznawany wyłącznie za autoryzacją komitetu sterującego i na podstawie specyfikacji funkcjonalnej.
Utrzymanie interfejsu legacy jest decyzją, nie domyślnym stanem. Wymaga tej samej autoryzacji co nowy interfejs.
Poświadczenia mają wskazanego opiekuna. Rejestr zapisuje, kto je przechowuje, nigdy samego sekretu.
Każdy interfejs określa, jak wykrywane są awarie i kto na nie reaguje. „Ktoś zauważy” nie jest monitoringiem.
Aktualizacje IFS Cloud przechodzą przez standardowe projekcje lub IFS Connect i ich logikę biznesową. Żadnego bezpośredniego dostępu do bazy danych.

2. Listy wartości

Kolumna	Dozwolone wartości
Pochodzenie	Legacy utrzymany / Legacy zastąpiony standardem / Legacy wycofany / Nowy
Kierunek	Przychodzący do IFS Cloud / Wychodzący z IFS Cloud / Oba
Mechanizm	Projekcja REST/OData / IFS Connect (routing komunikatów, transformery, konektory) / Transfer plików / Akcja zdarzeniowa / Wgranie ręczne / Inny
Dostęp	Tylko odczyt / Zapis
Status	Zidentyfikowany / Decyzja w toku / Zatwierdzony / Sprecyzowany / W budowie / W teście / Odebrany / Produkcyjny / Wycofany

3. Decyzje dotyczące interfejsów legacy

Przejdź przez krajobraz legacy razem z IT i zespołami funkcjonalnymi. Zapytaj dla każdego systemu: co wchodzi, co wychodzi, do kogo by zadzwoniono, gdyby przestał działać.

Interfejs legacy	Cel dzisiaj	Decyzja	Uzasadnienie	Zdecydował, data	ID rejestru, jeśli utrzymany lub zastąpiony
Przykład: Nocny plik stanów magazynowych do sklepu internetowego	Sklep internetowy pokazuje dostępność	Zastąpiony wywołaniem projekcji tylko do odczytu	Plik ma dzień opóźnienia, klienci zamawiają towar, którego już nie ma	[Komitet sterujący], [YYYY-MM-DD]	INT-002
Przykład: Eksport cen zakupu do narzędzia arkuszowego	Miesięczna analiza cen przez dział zakupów	Wycofany	Pokryty przez standardową stronę przeglądową i lobby	[Kierownik projektu po stronie klienta], [YYYY-MM-DD]	Brak
[Interfejs]	[Cel]	[Decyzja]	[Uzasadnienie]	[Imię i nazwisko, data]	[ID]

4. Rejestr część A: identyfikacja i przepływ

ID	Nazwa	Pochodzenie	System źródłowy	System docelowy	Kierunek	Obiekty danych	Właściciel biznesowy	Właściciel techniczny
Przykład: INT-001	Monitoring wyjątków w łańcuchu zakupowym	Nowy	IFS Cloud	Zewnętrzna usługa monitorująca działająca w sieci klienta	Wychodzący z IFS Cloud	Pozycje zamówień zakupu, potwierdzenia dostawców, przyjęcia. Klucze obiektów, daty, ilości i statusy. Bez zapisu.	Kierownik zakupów	[Lider integracji IT]
Przykład: INT-002	Dostępność do sklepu internetowego	Legacy zastąpiony	IFS Cloud	Sklep internetowy	Wychodzący z IFS Cloud	Dostępność części magazynowej wg lokalizacji	Kierownik sprzedaży	[Lider integracji IT]
[ID]	[Nazwa]	[Pochodzenie]	[Źródło]	[Cel]	[Kierunek]	[Obiekty]	[Imię i nazwisko]	[Imię i nazwisko]

5. Rejestr część B: mechanizm i bezpieczeństwo

ID	Mechanizm	Wykorzystane projekcje, komunikaty lub pliki	Dostęp	Konto integracyjne	Zestaw uprawnień	Uwierzytelnianie	Opiekun poświadczeń	Ścieżka sieciowa
Przykład: INT-001	Projekcja REST/OData	[Projekcje zamówień zakupu i przyjęć, zestawy encji wymienione w specyfikacji]	Tylko odczyt	[Dedykowane konto, na przykład `SVC_PO_MONITOR_RO`]	[Dedykowany zestaw uprawnień nadający odczyt wyłącznie na wymienionych projekcjach, bez akcji, bez zapisu]	[Poświadczenia klienta OAuth przez dostawcę tożsamości IFS]	[Oficer bezpieczeństwa IT]. Sekret przechowywany w [magazyn sekretów]. Rotowany co `[ustalić w projekcie]`.	Wewnątrz sieci klienta do punktu końcowego IFS Cloud przez HTTPS. Brak połączenia przychodzącego z zewnątrz.
Przykład: INT-002	Projekcja REST/OData	[Projekcja dostępności zapasów]	Tylko odczyt	[Dedykowane konto]	[Dedykowany zestaw uprawnień]	[Poświadczenia klienta OAuth]	[Właściciel platformy sklepu internetowego]	[Ścieżka]
[ID]	[Mechanizm]	[Obiekty]	[Tylko odczyt / Zapis]	[Konto]	[Zestaw uprawnień]	[Metoda]	[Rola, przechowywanie, rotacja]	[Ścieżka]

6. Rejestr część C: eksploatacja i status

ID	Częstotliwość lub wyzwalacz	Wolumen	Obsługa błędów	Monitoring i kto reaguje	ID w rejestrze CRIM	Link do specyfikacji	Status	Dowód testu
Przykład: INT-001	Odpytywanie zaplanowane co `[ustalić w projekcie]`	`[ustalić w projekcie]`	Nieudane odczyty są ponawiane i logowane wyłącznie z kluczami obiektów. Usługa nie może zmieniać danych, więc odzyskiwanie biznesowe w IFS Cloud nie jest potrzebne.	Kontrola kondycji usługi przeglądana przez [lidera integracji IT]. Nieudane uwierzytelnienie wywołuje alert do opiekuna poświadczeń.	[ID]	[Link]	W teście	Dostęp do odczytu zweryfikowany na koncie integracyjnym. Próba zapisu zweryfikowana jako odrzucona. [Tester], [YYYY-MM-DD]
Przykład: INT-002	Na żądanie sklepu internetowego	`[ustalić w projekcie]`	Sklep internetowy pokazuje „dostępność na żądanie”, gdy wywołanie się nie powiedzie	Monitoring platformy sklepu internetowego, alert do [właściciela]	[ID]	[Link]	Sprecyzowany
[ID]	[Częstotliwość]	[Wolumen]	[Obsługa]	[Monitoring, rola]	[ID]	[Link]	[Status]	[Dowód]

7. Kontrole per interfejs przed SAT

Kontrola	Wykonano
Wiersz kompletny w częściach A, B i C	[ ]
Specyfikacja funkcjonalna zatwierdzona, zgoda handlowa w miejscu, gdzie potrzebna	[ ]
Konto integracyjne utworzone z własnym zestawem uprawnień. Przetestowano, że nie może zrobić więcej niż wymieniono.	[ ]
Dla interfejsów tylko do odczytu: przetestowano próbę zapisu i została odrzucona	[ ]
Obsługa błędów przetestowana z co najmniej jedną wymuszoną awarią	[ ]
Monitoring wdrożony, a wskazana osoba otrzymała testowy alert	[ ]
Test wolumenowy wykonany tam, gdzie sekcja 6 pokazuje znaczący wolumen	[ ]
Interfejs ujęty w kompleksowym skrypcie SAT	[ ]
Wpis dodany do planu cutover: czas włączenia, czas wyłączenia legacy, krok weryfikacji	[ ]

8. Cutover i wycofanie z eksploatacji

ID	Działanie przy cutover	Kiedy (odniesienie do wiersza planu cutover)	Właściciel	Weryfikacja	Działanie awaryjne (rollback)
Przykład: INT-002	Zatrzymać nocny plik legacy. Włączyć wywołanie projekcji w sklepie internetowym.	[Odniesienie do wiersza]	[Lider integracji IT]	Sklep internetowy pokazuje dostępność dla testowej części zgodną z IFS Cloud	Ponownie włączyć zadanie pliku legacy
[ID]	[Działanie]	[Odniesienie]	[Imię i nazwisko]	[Kontrola]	[Działanie]

Konta i zaplanowane zadania interfejsów legacy do usunięcia po starcie produkcyjnym: [lista z właścicielem i datą].

9. Przegląd przy każdej aktualizacji wydania

Kontrola	Właściciel	Wykonano
Informacje o wydaniu przeczytane pod kątem projekcji i komunikatów w części B	[Rola]	[ ]
Każdy produkcyjny interfejs przetestowany dymnie w środowisku testowym aktualizacji na swoim prawdziwym koncie	[Rola]	[ ]
Zestawy uprawnień wciąż nadają dokładnie to, co wymieniono, i nic więcej	[Rola]	[ ]
Rotacja poświadczeń jest aktualna	[Rola]	[ ]
Interfejsy o statusie „Produkcyjny”, ale bez ruchu: zapytano właściciela, czy można je wycofać	[Rola]	[ ]
Wersja rejestru zaktualizowana i udostępniona wsparciu	[Rola]	[ ]

10. Przekazanie do wsparcia

Lista integracji z systemami zewnętrznymi jest częścią dokumentu przekazania. Dla każdego produkcyjnego interfejsu wsparcie otrzymuje wiersz rejestru, najnowszą specyfikację funkcjonalną, specyfikację testową, nazwisko opiekuna poświadczeń oraz kontakt monitoringu.

Pozycja	Wykonano
Rejestr odzwierciedla produkcję, zweryfikowane przez właściciela technicznego	[ ]
Specyfikacje pod wskazanymi linkami są najnowszymi wersjami i w języku angielskim	[ ]
Wsparcie zostało przeprowadzone przez każdy interfejs na spotkaniu przekazania	[ ]

11. Zatwierdzenie

Zatwierdzenie na bramce Solution Confirmed stwierdza, że inwentaryzacja interfejsów legacy i nowych jest kompletna wedle najlepszej wiedzy osób podpisujących, oraz że decyzje z sekcji 3 są autoryzowane.

Rola	Imię i nazwisko	Decyzja	Data
Lider IT lub integracji po stronie klienta	[Imię i nazwisko]	[Zatwierdzono / Zatwierdzono z uwagami / Odrzucono]	[YYYY-MM-DD]
Właściciel bezpieczeństwa po stronie klienta	[Imię i nazwisko]
Kierownik projektu po stronie klienta	[Imię i nazwisko]
Kierownik rozwiązania technicznego (przegląd)	[Imię i nazwisko]
Przewodniczący komitetu sterującego (interfejsy zapisu i utrzymywane interfejsy legacy)	[Imię i nazwisko]

Uwagi i warunki: [tekst]

Niezależny szablon zgodny z metodyką wdrożeniową IFS. Nie jest oficjalnym dokumentem IFS. IFS jest zastrzeżonym znakiem towarowym IFS AB.

Marketplace