W stronę technologii nr 1: Nowości IT w Globalnym Systemie LEI oraz API do pobierania plików wersji źródłowej
W tej nowej serii blogów Christoph Schneider, dyrektor działu operacji i rozwoju IT w GLEIF, wyjaśnia ostatnie aktualizacje techniczne wdrażane w infrastrukturze IT w GLEIF w ramach starań zespołu IT, by ułatwić użytkownikom dostęp do danych LEI. Pierwsza część zawiera przegląd najnowszych aktualizacji API do pobierania plików wersji źródłowej oraz jego znaczenia dla osiągnięcia skalowalności.
Autor: Christoph Schneider
Data: 2022-09-30
Odsłon:
Głównym elementem działalności GLEIF jest zapewnienie przejrzystej i dostępnej identyfikacji podmiotów prawnych oraz usług w zakresie danych. Kluczem do tego jest solidna, globalna infrastruktura IT, która zapewnia wszystkim odbiorcom danych w Globalnym Systemie LEI łatwą integrację, dostęp i wykorzystanie danych LEI na wielu platformach i w wielu systemach.
Dział IT w GLEIF pracuje niestrudzenie, by globalna infrastruktura oferowała użytkownikom możliwie najlepsze doświadczenia, stale wprowadzając aktualizacje i ulepszenia w miarę rozwoju Globalnego Systemu LEI. Najnowsza aktualizacja w tym procesie dotyczy API do pobierania plików wersji źródłowej i zostanie wprowadzona 10 października. Pliki wersji źródłowej i pliki delta są aktualizowane przez GLEIF trzy razy dziennie i zapewniają łatwy dostęp do najnowszych informacji na temat nowych i zaktualizowanych kodów LEI. Umożliwiający dostęp API do pobierania jest niezbędny wielu zespołom programistycznym, które potrzebują automatycznych aktualizacji danych, aby dostarczyć swoim organizacjom dokładne i terminowe dane. Najnowsza zmiana w API do pobierania plików wersji źródłowej pomoże użytkownikom osiągnąć lepszą skalowalność i niezawodność, a także usunąć wąskie gardła, które powstawały w czasie pobierania plików za pomocą API.
Na kogo wpłynie ta aktualizacja?
Ta aktualizacja spowoduje przekierowanie do bezpośredniej ścieżki pliku zamiast bezpośredniego pobierania z punktu końcowego API. Zespoły korzystające z adresów URL dla API do pobierania plików wersji źródłowej, które powodują bezpośrednie pobieranie plików (np. https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/20220601-0000.csv), muszą zaktualizować konfiguracje zgodnie z tą zmianą. W przypadku korzystania z API w ten sposób należy zwrócić zespołowi technicznemu uwagę na tę aktualizację, aby zapewnić zgodne z oczekiwaniami działanie przekierowania.
Należy pamiętać, że nadchodząca zmiana wpłynie na następujące domeny:
API do pobierania plików wersji źródłowej oferuje kilka wygodnych punktów końcowych API do bezpośredniego pobierania plików wersji źródłowej (delta) według daty publikacji lub specjalnego słowa kluczowego „latest”. Więcej informacji na ten temat można znaleźć w specyfikacji i instrukcji użytkowania plików wersji źródłowej i plików delta GLEIF. Link jest dostępny na końcu tego artykułu.
Obecnie wywołanie punktu końcowego API do pobierania powoduje bezpośrednie pobranie pliku (kod odpowiedzi HTTP 200). Poniżej przedstawiono przykład cURL:
Curl https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/20220601-0000.csv
# HTTP/1.1 200 OK
Po proponowanej dacie (2022-10-10), wszystkie żądania API będą przekierowywane do ścieżki bezpośredniego pobierania pliku (kod odpowiedzi HTTP 302 z nagłówkiem Location). Poniżej przedstawiono przykład cURL:
curl -L https://goldencopy.gleif.org/api/v2/golden-copies/publishes/lei2/20220601-0000.csv
#HTTP/1.1 302 Found
# Location: https://goldencopy.gleif.org/storage/golden-copy-files/2022/06/01/6/20220601-0000-gleif-goldencopy-lei2-golden-copy.csv.zip
# ...
# HTTP/1.1 200 OK
W powyższym przykładzie cURL jedyną wymaganą zmianą jest dodanie znacznika lokalizacji (-L lub --location), aby zapewnić przejście do nowej lokalizacji przekierowania. Takie zachowanie może być domyślne lub może wymagać innej konfiguracji lub obsługi w zależności od klienta HTTP. Wszyscy odbiorcy danych powinni zadbać, by ich klienty/aplikacje HTTP odpowiednio reagowały na przekierowania, jak pokazano powyżej.
W jaki sposób odpowiednie zespoły mogą skonfigurować aktualizację?
Przed wprowadzeniem zmian należy przygotować i przetestować system. Wprowadzony zostanie kod statusu przekierowania HTTP 302, a istniejące systemy należy zaktualizować w celu obsługi nowego zachowania w sposób kompatybilny w przód za pomocą jednej z następujących metod:
(Zalecane) Zapewnienie, by klient/aplikacja HTTP odpowiednio reagowały na przekierowania. Takie zachowanie może być domyślne lub może wymagać innej konfiguracji lub obsługi w zależności od klienta HTTP.
Ręczna aktualizacja systemu i dodatkowa obsługa odpowiedzi HTTP 302 oraz sprawdzanie nagłówka Location i korzystanie z URL bezpośredniego pobierania pliku.
Czy dostępne jest tymczasowe środowisko testowe?
GLEIF udostępniła tymczasowe środowisko testowe dla odbiorców danych, aby mogli sprawdzić, czy ich systemy obsługują nowe zachowanie, oraz upewnić się, czy działają przekierowania do bezpośredniego pobierania plików. Ułatwi to przejście do nowego zachowania przekierowania.
Poniżej znajdują się przykłady w tymczasowym środowisku testowym, które przedstawiają nowe zachowanie przekierowania:
Należy pamiętać, że to środowisko testowe obsługuje tylko datę publikacji 19990101-0000, ale zmiana dotyczy wszystkich wzorów, w tym specjalnego słowa kluczowego „latest” (np. …/publishes/lei2/latest.csv). Ponadto środowisko testowe stanowi przykład podzbioru danych wersji źródłowej wyłącznie do celów demonstracyjnych. Nie jest on przeznaczony do rzeczywistego użytku, a środowisko zostanie zlikwidowane po wprowadzeniu zachowania API danych wersji źródłowej.
GLEIF zachęca do współpracy z odbiorcami danych w ramach całego Globalnego Systemu LEI. W razie pytań dotyczących najnowszej aktualizacji lub chęci porozmawiania o tym, jak GLEIF może wesprzeć zespół, by wykorzystać moc LEI, prosimy o kontakt: info@gleif.org.
Aby na bieżąco otrzymywać najnowsze informacje techniczne od zespołu IT w GLEIF, kliknij tutaj, aby zapisać się do newslettera.
Najważniejsze terminy:
API – API oznacza interfejs programowania aplikacji. API to zestaw definicji i protokołów umożliwiających programom komputerowym wzajemną komunikację za pośrednictwem ogólnoświatowej sieci.
Punkt końcowy – Punkt końcowy to lokalizacja odbierająca żądania sieciowe. API to zbiór punktów końcowych.
Żądanie API – Wywołanie lub żądanie API to wiadomość wysyłana do punktu końcowego (serwera) z prośbą o dostarczenie usługi lub informacji przez API.
Odpowiedź API – Dane odpowiedzi otrzymywane od API w celu dostarczenia usługi lub informacji.
Kody statusu odpowiedzi HTTP – Jest to lista kodów statusu odpowiedzi HTTP. Kody statusu są wysyłane przez serwer w odpowiedzi na żądanie API zgłoszone do punktu końcowego, serwera. Każdy kod statusu ma określone znaczenie.
Pliki wersji źródłowej – Pliki zawierające LEI i powiązane dane referencyjne przesłane przez podmioty nadające LEI do GLEIF.
Pliki delta – Pliki delta identyfikują tylko nowo nadane LEI i/lub zmiany w danych referencyjnych LEI, które zostały zgłoszone w przeszłości w pliku wersji źródłowej opublikowanym wcześniej (8 godzin wcześniej, 24 godziny wcześniej, 7 dni wcześniej, maksymalnie 31 dni wcześniej).
Usługi GLEIF – Zestaw usług świadczonych zarówno publicznie, jak i dla naszych partnerów w celu zapewnienia integralności operacyjnej w ramach Globalnego Systemu LEI.
Osoby pragnące umieścić wpis w blogu prosimy o odwiedzenie strony: funkcje internetowego blogu GLEIF w języku angielskim. Imię i nazwisko autora komentarza pojawi się obok wpisu. Adresy e-mail nie będą publikowane. Uczestnictwo w forum dyskusyjnym i korzystanie z niego oznacza zgodę na przestrzeganie obowiązujących Zasad korzystania z blogu GLEIF, które należy uważnie przeczytać.
Christoph Schneider jest dyrektorem działu operacji i rozwoju IT w Global Legal Entity Identifier Foundation (GLEIF). W czerwcu 2017 r. dołączył do Międzynarodowej Organizacji Normalizacyjnej (ISO) jako współlider prac Komitetu Technicznego ISO 68 Grupy ds. Doradztwa Technicznego FinTech (ISO TC 68 FinTech TAG) w zakresie tożsamości cyfrowej. Ma bogate doświadczenie w opracowywaniu i wdrażaniu rozwiązań w obszarze technologii finansowych. Uzyskał tytuł magistra w dziedzinie biznesowych systemów informatycznych na Technische Universität Darmstadt.
