Is there a good event or alert included out of the box in ThingWorx that is only triggered when the platform starts up? I would like to subscribe to it and send a notification to platform admins when the platform starts.
If there are any events that are reliably triggered on shutdown, I'd like to subscribe to that as well.
I found this article which discusses creating a new Thing but would like something already present if possible. https://www.ptc.com/en/support/article/CS230700
Solved! Go to Solution.
A true event that only gets triggered when the platform starts is not present as of today.
You can somehow generate your own event, because in the Application logfile there's a line which says "Application started" or something similar, when the platform started.
You could have a timer that queries at 1 minute interval the logfile for that line, and then triggers a custom event...but the problem is that if your Application log is updated too frequently, you might not even see that entry (since I advise that this kind of query should be done with a specified maxItems). I haven't tested the performance impact of querying the Application log, so that's another thing to watch out for.
A true event that only gets triggered when the platform starts is not present as of today.
You can somehow generate your own event, because in the Application logfile there's a line which says "Application started" or something similar, when the platform started.
You could have a timer that queries at 1 minute interval the logfile for that line, and then triggers a custom event...but the problem is that if your Application log is updated too frequently, you might not even see that entry (since I advise that this kind of query should be done with a specified maxItems). I haven't tested the performance impact of querying the Application log, so that's another thing to watch out for.
Hello,
The "standard" way to detect when the platform is up is by doing it from the outside by checking "/Thingworx/health" endpoint. Here's what the official docker-compose does:
platform:
container_name: platform
image: <redacted>
healthcheck:
test: curl -f localhost:8080/Thingworx/health
interval: 15s
This endpoint doesn't need authentication and ensures that everything has initialized correctly. Once it returns HTTP 200, you can run any other REST services, and your users can safely login.
/ Constantine
Hi @Ascherer17.
It appears you have 2 potential solutions. If you have been successful with either, please mark the appropriate one as the Accepted Solution for the benefit of others in the community.
Regards.
--Sharon
A better way to approach this, in my opinion, is by hooking up to the 'ThingStart' event of an active Thing - preferably a thing you will create for this purpose only. A subscription that hangs from that event on the Thing will be executed whenever the platform starts up as that Thing (along with all others) are re-initialised and "started"..
It's worth keeping in mind that this will ALSO run when you make changes to the Thing entity, as well as when its parent ThingTemplate is updated. Therefore, it's a good idea to have that Thing inheriting from the "GenericThing" Thing Template and avoid making any changes to it manually. I have done this myself on a project and it works a treat.
I like this idea. Have you ever encountered false alarms besides when you might edit/save the Thing?
I'm also curious whether a clustered environment would cause it to behave differently from a single server (I doubt it).
I haven't encountered any false alarms so far. I've been logging the execution of the relevant subscription and it's evident it only runs in the aforementioned cases for me. A simple "GenericThing" shouldn't really restart in any other case, unlike Things inheriting from a different template - perhaps one provided from an extension - which might have a more complicated lifecycle).
Should you ever prove me wrong, however, I guess that you would also need to take into account the platform's 'systemUpTime' (from PlatformSubsystem) in your subscription code.
I haven't tested this in a clustered environment, very interesting question. My gut feeling also says it wouldn't behave differently but best putting that to the test, if you've got a clustered environment spun up somewhere.