Dobre-złe Open Data. Jak przyłączyliśmy dane z API o fińskich przedsiębiorcach

29 listopada 2018 Andrzej Precz Magdalena Nowaczyk

W Transparent Data, firmie technologicznej specjalizującej się w dostarczaniu danych o firmach i przedsiębiorcach za pośrednictwem API, baz danych i web services, podjęliśmy wyzwanie przyłączenia danych o przedsiębiorcach zarejestrowanych w Finlandii. Spisaliśmy nasze doświadczenia i dzielimy się z nimi w postaci poniższego artykułu.

Andrzej Precz. Back-end PHP Developer w Transparent Data. Odkąd półtora roku temu dołączył do zespołu Data&Services, każdy dzień zajmuje mu przyłączanie nowych źródeł i obmyślanie sposobów na pozyskanie danych nawet “zza zamkniętych drzwi”. Wcześniej, przez prawie dekadę, programował w serwisie Allegro.

Magdalena Nowaczyk. Marketing & PR Manager w Transparent Data. Z wykształcenia magister kognitywistyki, z zamiłowania człowiek od ubierania tego, co niewidzialne w słowa. Zanim objęła stanowisko Marketing & PR Managera w Transparent Data, przez lata pracowała w marketingu modowym i do dziś próbuje przekonać programistów, że czyste i efektywne kody powinny być również ładne i pełne wdzięku.

Spis treści

Etap 1: diagnoza zadania

Do jednego z naszych serwisów informacji gospodarczej potrzebowaliśmy przyłączyć dane o wszystkich firmach zarejestrowanych w Finlandii, czyli połączyć się z fińskim rejestrem przedsiębiorców PRH Patentti- Ja Rekisterihallitus Virre.

Etap 2: analiza dostępnych źródeł

Zadanie szybko wydało się wyjątkowo optymistyczne, bo już po wstępnym researchu dostępnych państwowych źródeł, okazało się, że serwis oryginalnego rejestru PRH, Virre, udostępnia otwarte Open Data API umożliwiające wykonywanie nie tylko odpytań o konkretną firmę po podaniu jej Business ID (ciekawostka: po fińsku Business ID znaczy “Y-tunnus”), ale także zapytań wyszukujących po wielu kryteriach. Jak każdego praktyka REST, ta druga informacja mocno nas ucieszyła, bo taka cecha otwartego API zdecydowanie ułatwia proces odkrywania nowych podmiotów.

Zobacz też

Backend Zasady czystego kodu C# w pigułce

Etap 3: przyłączenie pierwszego źródła

Przystąpiliśmy zatem do pracy. Za pomocą endpointu wyszukiwania dało się szybko uzyskać listę firm z nazwą i jej unikalnym Business ID. Ogromnym zaskoczeniem okazał się fakt, iż w rejestrze fińskim znajdują się nawet firmy założone w XIX wieku, takie jak Nokia Oyj z 1896! W polskich, czeskich czy słowackich rejestrach, z niczym podobnym nigdy się nie spotkaliśmy.

Podsumowując, sprawnie i łatwo udało się nam pozyskać bazę prawie 400 tysięcy firm bez konieczności wykonywania wielu zapytań do API. Dla każdego podmiotu mogliśmy dodatkowo odpytać o uzupełniające informacje w łatwym do sparsowania formacie JSON. Wystarczyło podać jego Business ID. Pomyśleliśmy, “WOW! Świetnie przygotowane rządowe Open Data API!”.

Mała trudność jaką napotkaliśmy: w porównaniu z danymi prezentowanymi na oficjalnej stronie rejestru, zabrakło kilku niewiele znaczących informacji jak np. trade register number, czyli archaicznego numeru rejestrowego używanego przed erą Business ID. Informacje te nie jawiły się być na tyle cenne, by tylko dla nich dodawać parsowanie rejestrowej strony HTML firmy. Postanowiliśmy więc pominąć tę dodatkową czynność.

Duża trudność jaką napotkaliśmy: podjęcie decyzji, które źródło ostatecznie przyłączyć. Serwis Virre oferuje dwa różne typy API, które po wstępnych testach wydawały się być bardzo do siebie podobne — TR Public Notices oraz BIS Business Information System. W końcu padło na TR, gdyż udostępniał on nieco łatwiejsze do pobrania informacje dotyczące danej firmy, czyli umożliwiał zagregowanie pojedynczej wartości bez konieczności analizy historii zmian tej wartości i bez wyciągania wartości obowiązującej aktualnie. Dodatkowo TR zwracał też adres endpointa do BIS, co uznaliśmy za przydatne, gdyby na dalszych etapach prac pojawiła się potrzeba skorzystania z niego.

Etap 4: pierwsze testy i pierwsze rozczarowania — przyłączenie drugiego źródła

Prędko TR API okazało się być niewystarczającym źródłem danych. Dla zbyt wielu podmiotów gospodarczych nie zwracał takich danych jak registered office (miasto siedziby firmy) czy business line (rodzaj fińskiego PKD). Pojawiła się zatem potrzeba skorzystania również z BIS, by uzupełnić brakujące dane. Mając od ręki adres endpointa do BIS, szybko dorobiliśmy dopytanie o dane z drugiego źródła.

Mała trudność jaką napotkaliśmy: okazało się, że oba źródła Open Data nie zwracają informacji o fundacjach, które podobnie jak u nas w Polsce również wpisywane są do państwowych rejestrów. Pobranie danych fundacji możliwe było wyłącznie z osobnej wyszukiwarki na stronie. Biorąc pod uwagę koszt dodania tego zbioru i niewielką liczbę podmiotów w nim się znajdujących, podjęliśmy biznesową decyzję o pominięciu fundacji.

Etap 5: kolejne testy i miła niespodzianka

Testy wykazały jedną naprawdę fajną rzecz — Open Data API zwracało dane nie tylko w języku fińskim, ale i szwedzkim, i angielskim. Jak wiadomo, tłumaczenie w samym źródle jest zawsze wyżej cenione (i jest dokładniejsze!) niż na stronach docelowych. Przyszłościowo postanowiliśmy więc zapisywać wszystkie agregowane dane w trzech językach. Doszliśmy do wniosku, że kiedyś z pewnością nam się to przyda, gdy któryś z Klientów poprosi o tłumaczenie serwisu na inne języki.

Etap 6: wdrożenie i zrozumienie błędnej decyzji

Wdrożenie poszło sprawnie. Dane pobrały się i uzupełniły stosunkowo szybko do bazy. Zadanie jawiło się jako wykonane. Niestety w pewnym momencie wyszło na jaw, że źródło TR dla wielu znalezionych firm nieaktywnych zwraca błąd 404 (czyli podmiot nie istnieje), podczas gdy źródło BIS informacje te prezentuje. Innymi słowy, nasza wstępna decyzja, że to źródło TR będzie podstawowym, okazała się błędna.

Zrobiliśmy zatem szybkie przełączenie na BIS.

Docelowo udało nam się nawet usunąć wszelkie odpytania do TR, więc finalnie wyszło wydajniej. Przeprowadziliśmy kolejne wdrożenie z poczuciem dobrze wykonanej pracy.

Etap 7: analiza zebranych danych i kolejne rozczarowanie

Po ponad miesiącu przyszedł czas na remanent stanu posiadanych danych. Okazało się, że inne komercyjne platformy informacji gospodarczej zbierające dane z Finlandii, zawierają między 540 tys., a nawet milionem podmiotów gospodarczych, a my mamy zaledwie 400 tys.

Rozpoczęliśmy szukanie przyczyn tak dużej rozbieżności i zauważyliśmy, że Open Data API państwowego oryginalnego rejestru, nie serwuje danych dla wszystkich typów działalności gospodarczej w Finlandii. Wśród brakujących firm najbardziej liczną grupą okazały się być jednoosobowe działalności gospodarcze (odpowiednik naszego polskiego CEIDG), których szacunkowo według strony Virre jest ponad 200 tys.

Decyzja mogła być tylko jedna: dorabiamy czytanie ze strony HTML i włączamy użycie wyszukiwarki firm na stronie Virre.

Etap 8: parsowanie HTML żeby uzupełnić bazę danych

Czytanie ze strony HTML okazało się być stosunkowo problematyczne, bo jednak strona www nie jest tak crawler-friendly jak Open Data. Cookies, sesje, autoryzacje, wybiórczo działająca wyszukiwarka — to ta ciemna strona medalu.

Do tego dochodzą problemy z formatem umieszczanych na stronach danych. Parsowanie HTML jest zawsze trudniejszym zadaniem od czytania JSONa, zwłaszcza dla adresów siedziby, które są często podane w formie kilku linijek tekstu. W takich przypadkach nigdy nie ma pewności czy nie pojawią się adresy łamiące regułę działającą dla 99% przypadków.

Dodatkowo musieliśmy żmudnie odpytywać wyszukiwarkę tak, by „odkryć” maksymalnie dużo, a najlepiej wszystkie firmy. Czyli szukanie po ID, nazwie, mieście, formie prawnej itd. Itd.

Wartość dodana wykonanej pracy: oprócz dociągnięcia brakujących firm, udało nam się podłączyć pominięte wcześniej fundacje i archaiczne, ale jednak istniejące numery trade register number. Dodatkowo baza e-maili i niektórych dat dotyczących wydarzeń w firmach, również się powiększyła, co oznacza, że jednak dostępne Open Data API rejestru nie było równoznaczne z rzeczywistą bazą danych Virre.

Etap 9: przygoda z wyszukiwarką i kolejna lekcja wiedzy o fińskich rejestrach

Gdy przystąpiliśmy do uzupełniania bazy poprzez wizyty na pojedynczych stronach firm, znalezionych w wyszukiwarce rejestru, sądziliśmy, że działa ona tak jak Open Data API. Czyli pytamy przede wszystkim po Business ID — wszak każdy podmiot w rejestrze musi posiadać ten numer identyfikacyjny i ten numer, podobnie jak polski NIP czy KRS, jest unikalny.

Wyszukiwarka na stronie zaczęła nam jednak zwracać firmy także i bez tego numeru! Mające tylko trade register number albo nie posiadające i tego numeru.

Etap 10: zmiana fundamentalnych założeń aplikacji

Usuwanie fundamentalnych założeń w działaniu aplikacji jest zadaniem niewdzięcznym i często żmudnym. Niemniej zadanie trzeba po prostu dowieźć.

Po ponownej analizie dostępnych danych, ostatecznie zdecydowaliśmy się na rozpoznawanie firm w rejestrze po ich wewnętrznych unikalnych numerach company ID i foundation ID, a numer Business ID stał się tylko opcjonalny.

Zobacz też

Big data Migracja do chmury? Wypełnij ankietę i sprawdź, jak wygląda ten proces u innych!

Etap 11: wdrożenie zmian i konsekwencje

Mechanizm należało przerobić tak, by sukcesywnie uzupełniał unikalne wewnętrzne identyfikatory dla firm wczytanych wcześniej z Open Data API.

Znów skorzystaliśmy z treści stron HTML rejestru. I znów trafiliśmy na mały problem— Open Data API serwowało informacje, których na stronie internetowej rejestru nigdzie nie było (m.in. numery Business ID innych firm powiązanych). Nie mogliśmy zatem zupełnie przestać korzystać z Open Data API.

Jeszcze jedną konsekwencją użycia zbierania danych z pojedynczych stron rejestru było pobieranie informacji tylko dla jednego języka. O szwedzkie i angielskie wartości musielibyśmy dodatkowo pytać stronę każdego podmiotu, tracąc trzykrotnie więcej czasu. Poza tym np. status firmy „ceased” serwowany z Open Data API stał w sprzeczności ze statusem „dissolved” serwowanym przez stronę rejestrową tej samej firmy. To stało się ostatecznym gwoździem do trumny pomysłu trzymania niektórych danych w wielu językach. Zostaliśmy zatem przy zbieraniu danych w języku fińskim.

W kilku słowach podsumowania

Zasadnym wydaje się zapytać, czy mogliśmy uniknąć błędnych decyzji i straconego czasu. Może droga po Finlandii nie byłaby tak wyboista, gdybyśmy wnikliwiej przeanalizowali źródła albo może gdybyśmy mieli więcej szczęścia szybciej trafiając na firmy z niestandardowymi danymi, albo gdyby… Stop! Doświadczenie z pracy z otwartymi danymi — nie tylko fińskimi, ale i polskimi, angielskimi, słowackimi itd. — już dawno zakazało nam używać słowa “gdyby” w znaczeniu robienia sobie wyrzutów.

Powiedzmy szczerze: Open Data API potrzebują nie tylko firmy takie jak nasza czy nasi Klienci. Potrzebuje ich też społeczeństwo. Ewidentnie jednak widać, że choć państwa europejskie stosunkowo pozytywnie odnoszą się do otwierania kolejnych źródeł, często brakuje im odpowiedniego zaplecza technologicznego, by źródła te rzeczywiście działały jak powinny. Rozproszenie danych, rozproszenie rejestrów, przygody z rekordami typu DD-MM-RRRR, w które ktoś jednak wpisuje treść “przed rokiem 1900” — na to trzeba się po prostu przygotować.