Starting with the 8.1 release, the architecture of ThingWorx Analytics has changed from being a single sever to being split into several independent microservices. This has been done to allow services to run concurrently. It also prevents issues with one microservice from affecting the others.
The new Analytics Server Architecture consists of a suite of 9 microservices:
All of the microservices work together to create a similar experience for users as it was in the past. The data that is uploaded and generated by the Analytics Server is stored directly in a file system, instead of a Postgres Database like it was in the past.
Please note that ThingWorx Foundation is required to be installed and operating before Installing Analytics. During the install you will be asked to supply IP Address of the ThingWorx Instance that will be used for Analytics. At this step, the AnalyticsServerThing is configured which allows the user to interact with Analytics Server through ThingWorx. All of the configured microservices are represented as Things under the AnalyticsServerThing. This is because ThingWorx Analytics has become a native part of ThingWorx Foundation functionality and is dependent on ThingWorx for user interaction.
Because of these changes, there is no longer a direct ThingWorx Analytics Server REST API. Support for accessing the services via REST calls is now provided through the ThingWorx Core REST API layer. Because of this, a new URI pattern is required moving forward.
One other update from the older versions is that the requirement to use application keys and Application IDs are no longer necessary. This should come as a welcome relief as the Application keys and IDs were the source of issues for users who may have misplaced them etc.
In the old versions, jobs, models, signals, etc. were all tied to the dataset. So there was no way to a model from one dataset to the other. With the new architecture, this is no longer the case you are able to move a model from one dataset to the other seamlessly. Please note that when moving a model from one dataset to the other, it must have the same metadata between each of the datasets. This is because a model created to increase efficiency in a factory would provide no insight on a dataset that monitors the soil moisture in a corn field.
Although going over the exact changes to the Metadata is out of scope for this post, it is worth mentioning. For more details on the changes, please follow this link.
In conclusion, the new architecture of ThingWorx Analytics was done to increase scalability and to produce a more robust system. The new release is much more integrated into the ThingWorx Platform to increase the ease of use from the previous releases. It is much less data-centric than it was in the past and geared more to the solutions themselves.
Here is a diagram of ThingWorx Analytics. Let me know if you are looking for a different diagram?
Thanks John.Analytics architecture is really helpful . But I am looking for the block diagram and data flow sequence architecture for Thingworx Core. I have attached one Thingworx core architecure , which I found from the internet. Please validate if same is correct.
Also request your help to share the data flow sequence w.r.t architecture of both (Thingworx core and Analytics) by giving a real time scenario example.
The ThingWorx diagram attached looks correct. I will investigate to see if we have any charts the cover the data flow sequence architecture of ThingWorx and ThingWorx Analytics.
Here is a diagram that covers data flow between ThingWorx and ThingWorx Analytics.
Let me know if this helps.