Pierwszy termin DPP w UE (Baterie): 106 dni Zapewnij zgodność teraz
Język
EN DE FR IT ES NL PL BG CS DA EL ET FI HR HU LT LV MT PT RO SK SL SV
Produkt
Funkcje Obsługa posprzedażowa Jak to działa Demo Enterprise Cennik
Sektory
Wszystkie sektory Tekstylia Elektronika Baterie
Zasoby
Blog Porównaj oprogramowanie DPP Wymagania krajowe Ocena gotowości Sprawdzanie twierdzeń ekologicznych Bezpłatne materiały do pobrania Słownik
Firma
Partnerzy Kontakt
Zaloguj się Rozpocznij bezpłatnie
Blog / GS1 i normy / Resolver GS1 Digital Link: jak działa
GS1 i normy

Resolver GS1 Digital Link: jak działa

MyProductPassport · sty 20, 2026 · Zaktualizowano lis 03, 2026 · 10 min czytania

Czym jest resolver GS1 Digital Link

Resolver GS1 Digital Link to usługa internetowa, która pełni rolę inteligentnego pośrednika między identyfikatorem produktu a informacjami powiązanymi z tym produktem. Gdy konsument skanuje kod QR na produkcie lub gdy system automatycznie odpytuje identyfikator produktu, resolver otrzymuje URI GS1 Digital Link i na podstawie tożsamości produktu, rodzaju żądanej informacji oraz kontekstu żądania decyduje, dokąd je skierować.

Resolver można porównać do inteligentnego drogowskazu dla informacji o produkcie. Tak jak serwer DNS tłumaczy nazwy domen na adresy IP, tak resolver Digital Link tłumaczy identyfikatory produktów na adresy URL, pod którymi można znaleźć informacje o produkcie, w tym dane cyfrowego paszportu produktu. Ten poziom pośrednictwa ma kluczowe znaczenie, ponieważ oddziela stały identyfikator produktu od lokalizacji danych produktowych, która może się zmieniać.

W przypadku cyfrowych paszportów produktów przewidzianych w ESPR resolver odgrywa centralną rolę. Nośnik danych umieszczony na produkcie koduje URI GS1 Digital Link. Po zeskanowaniu URI trafia do resolvera, który przekierowuje żądanie do źródła danych DPP. Jeśli zmieni się platforma DPP albo dane zostaną przeniesione na nowy serwer, wystarczy zaktualizować konfigurację resolvera: miliony kodów QR już wydrukowanych na produktach nadal działają prawidłowo.

Architektura resolvera Digital Link

Resolver GS1 Digital Link składa się z kilku komponentów logicznych, które współpracują ze sobą, aby przetwarzać przychodzące żądania i dostarczać odpowiednie odpowiedzi.

Parser URI to pierwszy komponent, który przetwarza przychodzące żądanie. Wyodrębnia z URI Digital Link identyfikatory GS1: identyfikator podstawowy (zwykle GTIN), ewentualne kwalifikatory (numer seryjny, numer partii) oraz wszelkie dodatkowe atrybuty. Sprawdza, czy URI jest zgodny ze specyfikacją składni GS1 Digital Link, i odrzuca błędnie sformułowane żądania.

Silnik rozwiązywania linków stanowi rdzeń resolvera. Utrzymuje bazę danych rekordów linków, czyli powiązań między identyfikatorami produktów a adresami URL, pod którymi znajdują się informacje o tych produktach. Każdy rekord określa identyfikator produktu, którego dotyczy, rodzaj dostępnej informacji (strona produktu, cyfrowy paszport produktu, dane dotyczące bezpieczeństwa, informacje o wycofaniu), docelowy adres URL oraz warunki, w których dany link ma być używany.

Moduł negocjacji treści analizuje przychodzące żądanie, aby ustalić, jakiego rodzaju odpowiedzi oczekuje wnioskujący. Służą do tego nagłówki HTTP Accept, parametry zapytania lub sama struktura URI. Przeglądarka internetowa żądająca text/html otrzyma przekierowanie na stronę czytelną dla człowieka. Maszyna żądająca application/json otrzyma dane ustrukturyzowane. System żądający application/ld+json otrzyma dane powiązane w formacie JSON-LD. To podejście, jeden URI i wiele reprezentacji, jest fundamentem architektury Digital Link.

Moduł odpowiedzi generuje odpowiednią odpowiedź HTTP, zwykle kod 307 (Temporary Redirect), który kieruje wnioskującego pod docelowy adres URL wskazany przez silnik rozwiązywania linków. W przypadku żądań API resolver może zamiast przekierowania zwrócić linkset (dokument JSON zawierający listę wszystkich dostępnych zasobów informacyjnych dla zidentyfikowanego produktu).

Jak przebiega rozwiązywanie: krok po kroku

Aby zrozumieć, jak resolver Digital Link działa w praktyce, rozważmy następujący scenariusz: konsument skanuje kod QR na produkcie. Kod QR koduje URI https://resolver.example.com/01/05012345678901/21/SN12345.

Najpierw smartfon konsumenta dekoduje kod QR i otwiera URI w przeglądarce internetowej. Przeglądarka wysyła żądanie HTTP GET do resolver.example.com ze ścieżką /01/05012345678901/21/SN12345. Żądanie zawiera nagłówek Accept wskazujący, że przeglądarka preferuje treści typu text/html.

Parser URI resolvera wyodrębnia ze ścieżki numer GTIN (05012345678901) oraz numer seryjny (SN12345). Weryfikuje te identyfikatory i przekazuje je do silnika rozwiązywania linków.

Silnik rozwiązywania linków wyszukuje tę kombinację identyfikatorów w swojej bazie danych i znajduje kilka rekordów linków dla tego produktu:

  • Link do cyfrowego paszportu produktu wskazujący na https://dpp.example.com/passport/SN12345
  • Link do strony z informacjami o produkcie wskazujący na https://brand.example.com/products/widget-pro
  • Link do informacji o wycofaniu wskazujący na https://recalls.example.com/check/05012345678901
  • Punkt końcowy danych powiązanych JSON-LD wskazujący na https://api.example.com/01/05012345678901/21/SN12345

Moduł negocjacji treści odnotowuje, że żądanie pochodzi z przeglądarki internetowej i dotyczy HTML. Na podstawie domyślnego typu linku skonfigurowanego w resolverze oraz kontekstu żądania wybiera link do cyfrowego paszportu produktu jako najwłaściwszą odpowiedź dla konsumenta skanującego kod QR.

Resolver zwraca odpowiedź 307 Temporary Redirect z nagłówkiem Location ustawionym na https://dpp.example.com/passport/SN12345. Przeglądarka konsumenta podąża za przekierowaniem i wyświetla stronę cyfrowego paszportu produktu.

Typy linków i ramy zgodności GS1

GS1 definiuje słownik typów linków, za pomocą którego resolvery kategoryzują zasoby informacyjne powiązane z produktami. Te ustandaryzowane typy linków zapewniają, że różne resolvery działają w spójny sposób, a systemy pobierające dane mogą niezawodnie żądać określonych rodzajów informacji.

Najważniejsze typy linków w kontekście cyfrowych paszportów produktów to:

  • gs1:digitalProductPassport, podstawowy zasób danych DPP zawierający pełne informacje paszportowe wymagane przez ESPR
  • gs1:productSustainabilityInfo, informacje środowiskowe i dotyczące zrównoważoności produktu
  • gs1:pip, strona z informacjami o produkcie, zwykle strona internetowa produktu marki przeznaczona dla konsumentów
  • gs1:safetyInfo, informacje dotyczące bezpieczeństwa, w tym karty charakterystyki i ostrzeżenia o zagrożeniach
  • gs1:recallStatus, informacja, czy produkt jest objęty wycofaniem
  • gs1:traceability, informacje o identyfikowalności w łańcuchu dostaw, potencjalnie z odesłaniem do danych zdarzeń EPCIS
  • gs1:certificationInfo, certyfikaty i deklaracje zgodności powiązane z produktem

GS1 opublikowała ramy zgodności dla resolverów Digital Link, które definiują różne poziomy możliwości. Resolvery poziomu 0 wykonują podstawowe przekierowania HTTP. Resolvery poziomu 1 obsługują negocjację treści. Resolvery poziomu 2 obsługują pełne API linkset, umożliwiając maszynom wykrycie wszystkich dostępnych zasobów informacyjnych dla produktu. Resolvery poziomu 3 dodatkowo obsługują skompresowane URI Digital Link i inne zaawansowane funkcje.

W wdrożeniach DPP zaleca się resolver poziomu 1 lub 2. Negocjacja treści (poziom 1) zapewnia, że zarówno ludzie, jak i systemy maszynowe otrzymują odpowiednie odpowiedzi. API linkset (poziom 2) pozwala systemom organów nadzoru i rejestrom DPP automatycznie wykrywać dane paszportowe dowolnego produktu i uzyskiwać do nich dostęp.

Sposoby wdrożenia: budowa, zakup lub GS1

Firmy wdrażające DPP mają trzy główne możliwości w zakresie infrastruktury resolvera Digital Link: zbudowanie własnego resolvera, skorzystanie z komercyjnej usługi resolvera lub wykorzystanie sieci resolverów GS1.

Własny resolver daje maksymalną kontrolę nad logiką rozwiązywania, identyfikacją wizualną marki i integracją z istniejącymi systemami. GS1 opublikowała referencyjne implementacje open source, które mogą posłużyć za punkt wyjścia. Utrzymanie resolvera na dużą skalę wymaga jednak solidnej infrastruktury internetowej, monitoringu i stałej konserwacji. Resolver musi charakteryzować się wysoką dostępnością: jeśli przestanie działać, przestaje działać każdy kod QR, który na niego wskazuje.

Komercyjne usługi resolverów, oferowane przez różnych dostawców technologii, w tym platformy DPP, zapewniają zarządzaną infrastrukturę resolvera bez obciążeń operacyjnych. Usługi te zazwyczaj oferują internetowe panele administracyjne do zarządzania rekordami linków, pulpity analityczne pokazujące aktywność skanowania oraz API integracyjne do automatycznego zarządzania linkami. Dla większości firm zarządzana usługa resolvera zapewnia najlepszą równowagę między funkcjonalnością a prostotą obsługi.

Sieć resolverów GS1 (id.gs1.org) to globalna usługa rozwiązywania utrzymywana przez samą GS1. Właściciele marek mogą rejestrować swoje produkty i konfigurować cele rozwiązywania za pośrednictwem krajowej organizacji członkowskiej GS1. Takie podejście wykorzystuje globalną rozpoznawalność i wiarygodność domeny GS1, ale może oferować mniejszą elastyczność w zakresie personalizacji i identyfikacji marki niż utrzymywanie własnej domeny resolvera.

Wiele platform DPP, w tym MyProductPassport, oferuje wbudowaną funkcję resolvera. Dzięki temu zintegrowanemu podejściu firmy nie muszą tworzyć odrębnej infrastruktury resolvera: platforma obsługuje rozwiązywanie URI, negocjację treści i zarządzanie linkami, a także zarządzanie danymi paszportowymi i generowanie kodów QR.

Konfiguracja resolvera pod kątem zgodności DPP

Konfiguracja resolvera dla cyfrowych paszportów produktów zgodnych z ESPR wymaga uwzględnienia kilku wymogów regulacyjnych i technicznych.

Resolver musi zapewniać trwały dostęp do danych paszportowych. ESPR wymaga, aby informacje w DPP pozostawały dostępne przez określony czas po wprowadzeniu produktu do obrotu. Oznacza to, że resolver musi działać i obsługiwać żądania przez cały okres przechowywania, nawet jeśli produkt został wycofany z produkcji. Firmy powinny upewnić się, że ich infrastruktura resolvera lub dostawca usług zobowiązuje się do zachowania wymaganych okresów przechowywania.

Odpowiedzi resolvera powinny zawierać odpowiednie nagłówki HTTP dotyczące buforowania i CORS (Cross-Origin Resource Sharing), aby dane DPP były dostępne z poziomu aplikacji internetowych, aplikacji mobilnych i systemów organów nadzoru. Nagłówek Link powinien informować o dostępnych typach linków, umożliwiając natywne w HTTP wykrywanie zasobów informacyjnych.

W przypadku produktów z identyfikacją na poziomie numeru seryjnego resolver musi obsługiwać kwalifikatory numeru seryjnego w ścieżce URI. Baza linków musi więc zawierać rekordy na poziomie numerów seryjnych (lub obsługiwać dopasowanie wieloznaczne, które kieruje żądania dotyczące konkretnych numerów seryjnych do właściwej instancji paszportu). W przypadku produktów identyfikowanych na poziomie partii resolver musi analogicznie obsługiwać kwalifikatory partii.

Bezpieczeństwo jest ważnym aspektem wdrażania resolvera. Resolver powinien korzystać wyłącznie z HTTPS, stosować ograniczanie liczby żądań w celu zapobiegania nadużyciom i przewidywać uwierzytelnianie dla funkcji administracyjnych. O ile samo rozwiązywanie powinno być publicznie dostępne (aby zapewnić otwarty dostęp do danych DPP zgodnie z zamysłem ESPR), o tyle interfejs zarządzania musi być chroniony.

Zaawansowane funkcje resolverów dla ekosystemów DPP

Poza podstawowym rozwiązywaniem ekosystem DPP wzbogaca kilka zaawansowanych funkcji resolverów:

  • Analityka i śledzenie skanów: resolvery mogą rejestrować zdarzenia skanowania, dając markom wgląd w to, gdzie, kiedy i jak często odwiedzane są paszporty ich produktów
  • Rozwiązywanie uwzględniające geolokalizację: resolvery mogą kierować żądania do treści paszportu przygotowanych dla danego języka lub regionu na podstawie lokalizacji wnioskującego
  • Rozwiązywanie w ujęciu czasowym: resolvery mogą przechowywać historyczne wersje rekordów linków, umożliwiając dostęp do danych paszportowych w postaci z określonego momentu
  • Rozwiązywanie awaryjne: resolvery mogą stosować kaskadową logikę rozwiązywania, sięgając kolejno do wielu źródeł danych, jeśli źródło podstawowe jest niedostępne
  • Obsługa skompresowanych URI: GS1 Digital Link definiuje skompresowane formaty URI, które zmniejszają wymaganą gęstość danych w kodach QR, umożliwiając stosowanie mniejszych kodów lub wyższego poziomu korekcji błędów

Funkcje te nie są wymagane do spełnienia podstawowych wymogów ESPR, ale mogą znacząco poprawić użyteczność i niezawodność wdrożeń DPP. Analityka skanów dostarcza na przykład cennych informacji rynkowych o zainteresowaniu konsumentów informacjami dotyczącymi zrównoważoności, pomagając firmom ocenić zwrot z inwestycji w DPP.

W miarę dojrzewania ekosystemu DPP możliwości resolverów będą prawdopodobnie dalej się rozwijać. Rejestr DPP Komisji Europejskiej, działający od 20 lipca 2026 r., współpracuje z resolverami w celu indeksowania danych paszportowych i uzyskiwania do nich dostępu na całym rynku UE. Operatorzy resolverów powinni śledzić te zmiany i dbać o to, aby ich wdrożenia pozostawały zgodne ze zmieniającymi się wymogami infrastrukturalnymi.

Testowanie i walidacja wdrożenia resolvera

Przed uruchomieniem resolvera w środowisku produkcyjnym niezbędne są gruntowne testy, które zapewnią zgodność ze specyfikacjami GS1 i niezawodne działanie w rzeczywistych warunkach.

GS1 udostępnia zestawy testów zgodności, które weryfikują działanie resolvera względem specyfikacji Digital Link. Testy te sprawdzają poprawność parsowania URI, właściwe kody odpowiedzi HTTP, dokładność negocjacji treści oraz zgodne generowanie linksetów. Przeprowadzenie tych testów na własnym resolverze pozwala wykryć odstępstwa od specyfikacji, zanim spowodują problemy z prawdziwymi produktami i prawdziwymi konsumentami.

Równie ważne są testy obciążeniowe. Resolver dużej marki konsumenckiej może w szczytowych momentach musieć obsłużyć tysiące żądań na sekundę, na przykład podczas premiery produktu, viralowego momentu w mediach społecznościowych czy kampanii kontrolnej organów nadzoru. Znajomość limitów wydajności resolvera i wdrożenie odpowiednich strategii skalowania (buforowanie, równoważenie obciążenia, dystrybucja przez CDN) zapewnia stałą wydajność.

Testy end-to-end powinny obejmować cały łańcuch, od zeskanowania kodu QR po wyświetlenie paszportu. Oznacza to fizyczne wydrukowanie kodów QR, zeskanowanie ich różnymi modelami smartfonów z różnymi systemami operacyjnymi oraz potwierdzenie, że resolver prawidłowo kieruje każde żądanie do właściwej treści paszportu. Testy zarówno na urządzeniach konsumenckich, jak i z użyciem klientów programowych gwarantują, że wszystkie ścieżki dostępu działają poprawnie.

Wreszcie dla produkcyjnej infrastruktury resolvera należy wdrożyć monitoring i alerty. Monitorowanie dostępności, śledzenie czasów odpowiedzi i alerty dotyczące wskaźnika błędów umożliwiają szybkie wykrywanie i usuwanie problemów, które mogłyby uniemożliwić konsumentom i organom nadzoru dostęp do danych cyfrowego paszportu produktu.

Link skopiowany do schowka
MP

MyProductPassport

Cyfrowe Paszporty Produktów

Pomagamy firmom poruszać się po wymaganiach Cyfrowego Paszportu Produktu, zgodności z ESPR i transparentności produktów zrównoważonych.