GS1 Resolver CE upgrade to v2.4 on Monday 29th March 2021

[Nick Lansley]

Hello fellow GS1 Resolver CE developers!

On Monday 29th March 2021, the codebase for Github repo for Resolver CE updates to v2.4

This is a minor update from an implementation point of view, all data formats and database are entirely unchanged, just a newer code base.

Here's what to look forward to:

• Various bug fixes / code changes from triallists' feedback
• Performance improvements to existing code
• Express routes applied for GS1 Identifier Key Types: GTIN, GLN, GLNX, SSCC, GRAI, GIAI, GSRN, GDTI, GINC, GSIN, GCN, CPID, GMN
• Changed all instances of defaultLink* to defaultLinkMulti
• Compressed URIs implemented 
• Updated rules that generate a 400 Bad Request
• Updated Node from v15.1 on Alpine Linux 3.12 to v15.11 on Alpine Linux 3.13 to fix increasingly old version of npm as well as taking advantages of improved performance and bug fixes in Node V8 runtime.

You may be interested in learning a little more about how Resolver selects the most appropriate response for a particular entry if more than one is available. If so, read on!

As you are no doubt aware, a Resolver stores its data with 7 unique attributes:

1. Identifier Key Type (e.g. '01' for GTIN)
2. Identifier Key (the GTIN itself in this case)
3. Qualifiers in the URI stem (lot number, serial number)
4. LinkType
5. Language (e.g. 'fr' for French)
6. Context (for GS1 Global Office Resolver, this is Territory - e.g. 'BE' for Belgium)
7. MimeType (e.g. 'application/pdf' for a PDF document).

Attributes 1 - 3 define a unique entry, and with each entry. attributes 4 - 7 are known as the 'four contexts'. 

An example from the four contexts might be "I want to get the Electronic Patient Information Leaflet (linkType) written in French (language) for Belgium (context) as a PDF file (mimeType).

Given that the combination of first three unique attributes, Resolver will have arrived at the 'responses' list and now must choose which response to respond with. To do this, it follows these rules:

Note that the default linkType is found first and used as Linktype value if no linktype is provided in the request. If no default linktype flag is set at all for this entry, the linktype in the first response of the responses array is chosen. Well, what else can it do?!

1. Search for Linktype, Language,  Context and mimeType
2. Search for Linktype, Language, Context and default mimeType
3. Search for Linktype, Language and Context
4. Search for Linktype, Language and default Context
5. Search for Linktype and Language 
6. Search for Linktype and default Language 
7. Search for Linktype
8. * FAIL * (404 even though we have an entry as there is nothing we can do. Logically this can only happen if there aren't any responses in the response array).

Note how the rules reveal a hierarchy of context importance, in order of:

1. Linktype - the most important
2. Language
3. Context / Territory
4. MimeType - the least important

Hopefully, that gives you some insight into how Resolver chooses the most appropriate entry!

Cheers

Nick