Roger Palmen

The problem with UoM conversions in the Integrator for BA

Discussion created by Roger Palmen on Nov 16, 2018
Latest reply on Jan 8, 2019 by Roger Palmen

Hi all,

 

Chugging my way through the Integrator in a recent project, i found a list of problems and issues with the UoM conversion functionality in the integrator for BA. First of all, this functionality is not documented.

Secondly, this UoM-conversion feature pops up when the first element in the asset shape has a UoM set, and then assumes this UoM should be used for all outputs for that attribute/column, and that the UoM class should be used for all conversions where there is a different UoM.

Now this starts causing troubles when the Asset shape turns up Elements where this attribute has a UoM of a different class. Now i first thought the Integrator had a good way to deal with this problem by allowing to create a column that includes the UoM of the attribute, so that any application down the line knows what the numbers mean and can deal with them appropriately. But the UoM conversion crashes this idea by throwing errors for every attribute it cannot convert.

 

So in my opinion, the inclusion of this feature has not been thought through properly and should be revised asap.

 

Only the person designing the asset shape can know with some certainity what elements will be included in the future. There is no way the integrator can know upfront, so the suggestion to apply a UoM conversion should be just that: an optional suggestion, turned off by default.

Personally i think UoM conversions are not the role of the Integrator in the first place. UoM logic should reside in the data/business logic layer, and thus AF.  UoM conversions might be possible, but at least should be optional and/or controllable.

 

Feedback item here: UoM conversions should be optional – User Feedback for OSIsoft Products and Services

Outcomes