====== Track and Trace 2 - System Overview ======

{{tnt2:sysdoc:tnt2_overview.svg}}

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 ====
|Source|MQ|
|Target|MQ|

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 ====
|Source|MQ|
|Target|DB|

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 ====
|Source|MQ|
|Target|DB|
|Triggers|Inventory 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 ====
|Source|MQ|
|Target|MQ/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 ====
|Source|MQ|
|Target|MQ|

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

==== mover ====
|Source|MQ|
|Target|DB|
|Triggers|Move integration|

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

==== package ====
|Source|MQ|
|Target|DB|

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

==== packcheck ====
|Source|Timer|
|Target|DB|

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

==== report ====
|Source|Timer|
|Target|DB|

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

==== reruntransactions ====
|Source|Timer|
|Target|DB|

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

==== return ====
|Source|MQ|
|Target|DB|
|Triggers|Return integration|

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

==== returnbulk ====
|Source|MQ|
|Target|MQ|

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

==== use ====
|Source|MQ|
|Target|DB|
|Triggers|Use integration|

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

==== usebulk ====
|Source|MQ|
|Target|MQ|

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.