ThingWorx provides the capability to write arbitrary messages to log entities (e.g. CommunicationLog, ApplicationLog, ScriptLog, etc.) using the REST API.
As we prepare for the rollout of the next version of ThingWorx, we would like to understand if anyone is actually using the REST API to write to logs.
If so, how are you using it?
If not, we are considering removing this capability in order to focus on providing and maintaining other great functionality.
Thanks for your feedback.
you could solve this by implementing an extension. Define your own Shape with some services. Within these services you can address your required logger.
Logger APP_LOGGER = LogUtilities.getInstance().getApplicationLogger("sublogger-name");
Logger CONFIG_LOGGER = LogUtilities.getInstance().getConfigurationLogger("sublogger-name");
Create a thing, add your shape. Now can use this thing via REST to report into specific logger.
logger: "Foo" /* STRING */,
message: "Hello" /* STRING */
"message"": "Hello via REST"
Result should be like this:
I've never seen it used on any project. The opposite use case (i.e. streaming ThingWorx logs into external systems) would make more sense IMHO.
In addition to my question, here's the reason why I ask.
1. From an "I want to write to a log" usecase, the preferred way is to use in the ThingWorx services a "logger.warn" statement (or similar), which is usually used to debug service functionality. Since ThingWorx is REST capable OOTM, this will also result in an user's capability to call a service via REST to be capable to write in any of the logs, indirectly.
In addition to the snippet above, each of the logs, have a service, called
That would allow direct writing to the any of the logs.
Even if we stop supporting the direct route, the user would still be capable to write to the logs, indirectly.
I support Constantine's feedback.
I remember lots of RFPs' that asked us to prove "we can output/send logs to a central logging system" (eg: Cigna).
That was/is a problem, since in the product we don't have an event that would allow us to intercept the message and call an external API. We always would need to resort to workarounds, which are not so nice in some cases.