Case Study: Weighbridge Integrations 

Overview

A common scenario for our liquids business customers, is one where goods are moved from and to Stock Tanks at locations (Terminals) that use Weighbridges to measure the weight of the trucks on entry and exit. These results need to be fed into ITAS to allow an accurate recording for both maintaining the actual quantities of the associated Purchase or Sale Contracts, as well as the stock levels of the Stock Tanks themselves.

Legacy services have been devised to generate instructions for the 3rd party weighbridge software and interpret the back-flow of information after weighing is completed. One of the main issues has been maintaining the formats of the files as each weighbridge could potentially have its own software and settings, meaning that requirements needed to be handled at a low level. Any upgrades to the 3rd party software would often involve changes to the ITAS legacy services that could be time-consuming and difficult to test in a development environment.

Alternative Solution

Adopting the strategy of migrating legacy services to the ITAS Services architecture, components used within the Weighbridge workflow were broken out and made available to the ITAS API. This allowed middleware workflows to be developed that consumed data/endpoints from both ITAS and the 3rd party software. Transformation, mapping and management/monitoring therefore moved into the Integration Platform environment. API endpoints became more generic and re-usable. 

Workflow Sample

• An optional step is the Notification of a Release that has been marked as ready to Send to Weighbridge. This can be used as a trigger for the Workflow to begin, although not necessary if triggered manually or in response to an alternate Event. It is possible, for example, to create a Data Change alert that monitors the Sent property on the Order (phys09_sent). Refinement to a specific activity (Instructions created for example) can be managed through a Workflow. 
  
  
• Details relating to the Release can be retrieved in a number of ways. The ITAS (REST) API has a dedicated set of endpoints (ExpedCallOff, DeliveryInOrder, DeliveryOutOrder) that contain the most common properties, whereas ClientServices API will allow a more bespoke approach to constructing a query as it uses GraphQL. As well as the Data Entities mentioned previously, the PhysicalOrder Data Entity is a good example as it drives by the main Order and links to the underlying Physical Trade. If Instructions have been created there is also the option of using StockLoading as this will list Stock Units and associated weights identified through PROTANK (where available).
  
  
• The Workflow can then perform its activities involving the 3rd Party software (API, flat-file exchange) to create the order in the other system linked to the Weighbridge.
  
  
• It is assumed that once the loading has physically taken place (either stock has been brought in or taken out) the 3rd Party system will be able to notify the Workflow in a recognised way (message, file drop). The results from the Weighbridge will need to be extracted for the minimum of information expected; Stock Unit(s) and associated Weights.
  
  
• The next step is to update the Release information in ITAS. This is a two-step process:
  • Update the Order details through the StockMovement endpoint (allows details concerning the actual delivery to be recorded)
  • Save the Loading details through the StockLoading endpoint (allows recording which Stock Unit(s) with corresponding Quantities were involved in the Order)
    
    
• The final stage is to Confirm the Order has been processed (MarkOrderAsProcessed). This will mark the Release as Delivered, generate accounting and so on.