Skip to main content
A
Ascherer1716-Pearl
16-Pearl
December 19, 2017
Solved

Logging Things w/ Different Properties in Value Stream

  • December 19, 2017
  • 3 replies
  • 4770 views

I know that it is possible to use a single Value Stream Thing to log entirely different properties of multiple Things.

Example: Logging temperature and pressure for Thing1 as well as voltage and current for Thing2 all in the same Value Stream.

My question is does anyone know or have experience with this and how it would affect Value Stream performance (reading/writing)?

I'm trying to figure out the best way to organize Things' logged properties.  i.e. Should all machines in a department share a Value Stream?  Should each machine have its own Value Stream (this is probably overkill)?

I'm using Thingworx 7.1.

Thanks

Best answer by CarlesColl

We use a totally different approach for ValueStream, we have a multi-tenancy approach and we don't like to have the same ValueStream for different tenancies. Also having a ValueStream on a ThingTemplate level can be a big inheritance pain, as imagine you have an inheritance chain with two different value streams... Or imagine on future ThingWorx version where you can share different servers (federation) and you have the same code base but different Thing Instances on different servers, then sharing ValueStream on ThingTemplate level maybe a problem....

Rather on having a default ValueStream at Template Level, we assign ValueStream on Thing Creation, on our case where we have an hierarchy of things ( System Like ) we do have a ValueStream on Hierarchy root and all inner hierarchy things "inherit" value stream.

Just my two cents.

3 replies

S
sgreywilson16-Pearl
16-Pearl
December 19, 2017

Currently - Indirectly all value stream data resides in a single Table so you could just use a single value stream. That being said the approach is to add the Value stream at the Template level and if there are different templates if makes sense to create a different value stream per template.

The overall performance will depend on additional factors (amount of data and ingestion rate)  also the area of performance is in constant development and improvement. So the "Informed practice"  of using a value stream per template feels good to me.


The performance of value stream is best when querying based on time - If more complex queries are required then the approach would be to write the stream to both the Value Stream and an external database  or just to the Database and use the standard SQL query approach for more complex queries.


Again these areas are being worked on and approaches might change but this is the current "Informed practice" .

C
CarlesColl1-VisitorAnswer
1-Visitor
December 20, 2017

We use a totally different approach for ValueStream, we have a multi-tenancy approach and we don't like to have the same ValueStream for different tenancies. Also having a ValueStream on a ThingTemplate level can be a big inheritance pain, as imagine you have an inheritance chain with two different value streams... Or imagine on future ThingWorx version where you can share different servers (federation) and you have the same code base but different Thing Instances on different servers, then sharing ValueStream on ThingTemplate level maybe a problem....

Rather on having a default ValueStream at Template Level, we assign ValueStream on Thing Creation, on our case where we have an hierarchy of things ( System Like ) we do have a ValueStream on Hierarchy root and all inner hierarchy things "inherit" value stream.

Just my two cents.

    A
    Ascherer1716-PearlAuthor
    16-Pearl
    December 20, 2017

    I think it may have been mentioned in some of the online trainings that it's a good idea or standard practice to assign the Value Stream at a Template level.  It makes sense, especially when there are many Things that come from the same Template. 

    My question is rooted in the idea that most of the Things I create may be singular instances rather than mass numbers from the same Template.  So I'm wondering if there would be any problems in, say, grouping Things into Value Streams based on geographical area or room number even though the machine Things in a specific group may have entirely different properties. 

    It sounds like there shouldn't be much of a difference, so I'll probably figure out which grouping is most logical to our solution.

    C
    CarlesColl1-Visitor
    1-Visitor
    December 21, 2017

    Hi,

    There isn't any problem on sharing ValueStream based on where Things are instead of the ThingTemplate that they belong to, if you look at my previous answer it's exactly what I pointed out.

    Best Regards,

    Terms & ConditionsCookie settingsAccessibility statement