cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

Logging Things w/ Different Properties in Value Stream

Ascherer17
14-Alexandrite

Logging Things w/ Different Properties in Value Stream

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

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

4 REPLIES 4

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" .

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.

Ascherer17
14-Alexandrite
(To:Ascherer17)

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.

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,

Top Tags