Skip to content

Purpose and features of the Barcode Printing API

Labels with barcodes are used in the labs in Sanger to identify information related to pieces of labware. As the barcodes are encoded within the labels, decoding the information encoded within the barcodes require specialised equipment - barcode readers. The encoded information vary, but overall, some common information displayed are:

  1. Identifier for the labware (usually encoded)
  2. Type of the labware (i.e., labware "purpose")
  3. Timestamps (e.g., created date/time)

For printing barcodes, an application (e.g., Sequencecape, Limber, Sapio) would need to access the printers located on-premises. These printers are made accessible by certain networks, and they are accessed only via specific protocols such as FTP. Therefore, to encapsulate these protocol logic, Sanger teams have developed thin applications that abstract away the protocols by providing a set of known - much accessible - ways to access the printers.

Since there can be multiple such barcode printing providers (e.g., print-my-barcode, sprint), the Barcode Printing API integration consolidates them and provides a unified interface to interact with the different barcode printing providers. In other words, this integration intends to act as a facade to multiple barcode printing providers.

Features of the Barcode Printing API

Barcode Printing API allows applications to communicate with the on-premises barcode printing providers through a unified interface. As the time of writing, the following providers are supported:

  1. print-my-barcode
  2. sprint

In the future, when new barcode providers arrive, this integration will envolve. As it unifies different barcode providers, if the accepted payloads are updated, they would be updated through different API versions so that the previous versions are stable and still usable. It is likely that the integration would evolve internally to route the request(s) to the corresponding providers based on a discriminator key in the payload. However, since at the time of writing, there is only print-my-barcode and sprint which are routed via print-my-barcode itself so the integration currently does not make any routing decisions. When the integration evolves, the Process API might evolve such that it encapsulates the routing logic.