¶ Matching service
The matching service is the first component to be considered, as it is the one that will allow the DPP Service to be used from multiple entry points, and eventually acts as a continuity gateway for interoperability.
In terms of complexity, it can provide two levels of matching:
- Partial match: The service can recognize not an exact item but the reference of a group/series, and redirect further down to another service to provide a more precise result.
- Exact match: Returns (or redirects) to the exact page for a given item.
As the entry point, it should have ample resources to handle the load and should be able to handle a high number of requests.
As such, it is designed as a very simple service that can work in semi-isolation from the rest of the solution, providing easier scalability options.
¶ Partial matches
A matching service providing partial match can be useful in two ways.
Aside from the main goal of exposing a dynamic DPP to an end-user, some class of products may not require a fully dynamic service to provide the required DPP content, which can include user guides, technical datasheets, and so on.
For these cases, the matching service can limit itself to only some fields, such as a product number or a manufacturer, to either return a predetermined static page or redirect to a service regardless of the specific unit being requested.
Another use of partial match could be, in extremely large-scale implementations, to have a first filter that consumes less resources and then redirects users to a second, less solicited matching service that can spend time needed to perform a full lookup on a subset of data.
In that case, the first layer would only match on a manufacturer, and the second layer would match on a product number for that manufacturer only.
From a scalability perspective, this could be useful for a single entry-point solution requiring high throughput.
Another commonly envisioned use case is to redirect to the appropriate DPP service regarding the product and let the DPP service handle unique numbers by forwarding the whole request.
This is likely to be the most common use case, as it's often the case that each product line is handled by a single service; however, a future implementation with extreme interoperability could then allow for a specific serial number to redirect to another service.
¶ Exact matches
The same service looking for unique details can be configured to match on a fully identified unique object, such as a serial number, to redirect to a specific DPP service.
This use case, as described before, would likely be used for extreme interoperability at the matching service level, but is unlikely to be of use at the beginning of the deployment of DPP solutions.
¶ Matching fields
The matching service considers the following fields as input to match a product to a configured DPP service:
- Requested domain name
The URL used to query the service can be personalized to match a manufacturer's domain (for example,dpp.brandname1.comanddpp.brand2.comcould point to the same matching service, with the domain name being part of the matching operation to separate different brand products. - Unique identifier
A serial number associated with a product number or with a given brand can be used to uniquely identify a product.
While a serial number alone would not typically be considered enough to uniquely identify a product, if the matching service is specific to a brand/manufacturer/product line, it could be considered sufficient to act as a unique identifier.
Note that in the case of KeeeX-based product identification, a unique product IDX is associated with each product regardless. - Extra context information
These extra informations are not particularly useful to the matching service but can be used as hints as to what the next step is (e.g., user redirection to a landing page or directly opening the specific unit DPP).
Most of these extras are expected to be left available for the DPP service to handle. - The calling interface
If the request is received from an end-user's web browser, a standard HTML page is returned, usually alongside a redirection (either a direct HTTP redirect or a static redirection page for a smoother user experience).
For requests originating from another service or application, a formalized JSON response is returned instead, leaving the calling application responsible for handling the redirection or displaying the data.
Some examples of simple redirections would be:
As indicated in other parts of this documentation, the service is compatible with the GS1 Digital Link standard[1], regarding common fields.
¶ Implementation
The implementation of the matching service depends on a database that stores data about various fields used for matching and where users are redirected to, in accordance with the above description.
This service requires feedback from the actual DPP service or brand/manufacturer input to effectively redirect requests correctly.
This kind of feedback can occur asynchronously in batches, keeping the whole solution decoupled.
It is also expected that the matching service operates in read-only fashion on its database.
Note that, in terms of trust, the matching service is not trusted; the burden of validating the actual data lies with both the user side (with appropriate measures, such as using an advanced data carrier) and the DPP Service (by providing verifiable and authentic data).