User Tools

Site Tools


tnt2:sysdoc:system

Track and Trace 2 - System Overview

The Track and Trace 2 system is built on a Service Oriented Architecture consisting of several individual services performing different tasks. The three main components of the system are:

  • Worker module - does all the changes to the data in the system, data validation and verification
  • REST Service - enables data presentation and manipulation from external services as the Client or the Scanner
  • TnT2 Message Queue (MQ) - messaging transport that distributes the work tasks between services and modules

Worker module

The worker module is divided in to modules and services that are either triggered from MQ messages or from a scheduled timer. The modules and services perform simple tasks on the database or offer data format suitable for presentation or export to the requester. A brief description of each module follows:

detonatebulk

SourceMQ
TargetMQ

The detonatebulk module takes a detonation message containting several serial numbers and creates a detonation transaction containing several detonation messages containing one serial number each.

detonate

SourceMQ
TargetDB

The detonate module takes a detonation message on a single serial number and sets all flags on the packs and items in the database. The detontaion transaction is updated accordingly.

inventory

SourceMQ
TargetDB
TriggersInventory integration

The inventory module takes an inventory message on the MQ and performs all inventory tasks for that message on the packs and items in the database. It then triggers the inventory integration on the outcome of the run.

manifest

SourceMQ
TargetMQ/DB

The manifest module handles the exporting and sending of XML manifests in the system. When an export request is posted on the MQ this module builds the XML manfest from the supplied packs and returns it to the MQ. When a send request is posted on the MQ this module builds the manifest, sends it to the correct site and sets the correct status in the database for the given pack.

movebulk

SourceMQ
TargetMQ

Breaks a bulk move MQ message to individual move messages and creates the move transaction for the bulk.

mover

SourceMQ
TargetDB
TriggersMove integration

Moves a pack/item as according to an individual move message on the MQ. Triggers the move integration afterwards.

package

SourceMQ
TargetDB

The package module handles creation and modification of packs as in the Create pack, Break pack etc functions in the app.

packcheck

SourceTimer
TargetDB

This service checks for empty packages and removes them from the system.

report

SourceTimer
TargetDB

This service builds report data on a schedule for reports that require historical information

reruntransactions

SourceTimer
TargetDB

This service checks for failed transactions in the error log, and if the transactions are viable for rerunning they will be run again.

return

SourceMQ
TargetDB
TriggersReturn integration

Returns a pack/item as according to an individual return message on the MQ. Triggers the return integration afterwards.

returnbulk

SourceMQ
TargetMQ

Creates a return transaction and breaks the bulk return message into individual return messages.

use

SourceMQ
TargetDB
TriggersUse integration

Marks a pack/item as used according to an individual use message on the MQ. Triggers the use integration afterwards.

usebulk

SourceMQ
TargetMQ

Creates a use transaction and breaks the bulk use message into individual use messages.

REST Service

The TnT2 REST Service is a modular REST service providing an interface for external data presentation and maipulation. Currently the following modules are implemented:

  • gui - Handles all communication with the TnT2 web client
  • scanner - Handles all communication with the TnT2 scanner app

The REST service does not do any data manipulation other than putting messages on the MQ for each asked for operation

TnT2 Message Queue (MQ)

The MQ in the Track and Trace 2 system is a simple MongoMQ solution where messages are posted and read from a collection in the database. There is a class implemented to handle all the MQ funcitonality and give safe and reliable operation. Messages are not removed from the MQ, states are handled internally to describe which messages to read or ignore which means that in the event of a system failure all non-completed transactions can be rerun in the system.

tnt2/sysdoc/system.txt · Last modified: 2019/10/25 09:33 by hubbe