Improve logging feature

[Radu]

Improve the logging feature to also include the Thing from which the service was executed, the line where the error happened and offer information on the error in the code logic, including, but not limited to: what was expected, and what was found?

Thingworx's logging functionality is very old and subpar to all IDEs.

[Radu]

I will keep posting frustrating logs that I come across. This is the first one

[JonathanRigsby]

I 100% agree! There are many instances where all the error says is that there was an error; nothing more.

[Radu]

Thank you, Jonathan for your support.

Meanwhile, here's another barely useful log message offered to me.

[Radu]

Another one. Empty.

[ablyth]

Great feature! Here are my contributions...

Being directed to the Server Log from the Application Log... not sure if there is some only accessible from the file system?

No bound thing for a null thing? wat?

Metrics aren't a Warning?

[Radu]

Thanks for your support. Here's another one from my side.

[raluca_edu]

I am adding also another situation:

I created user with limited rights and gave the user access control to the object. Nevertheless I'm not allowed to run ONE specific service. This service causes a NULL pointer exception.

2020-09-16 09:13:58.670+0000 [L: ERROR] [O: E.c.q.l.c.Logger] [I: ] [U: aaa] [S: ] [P: ] [T: https-jsse-nio-8443-exec-3] Unable to Invoke Service GetIndustrialThings on KepwareConnect : null java.lang.NullPointerException: null
at com.thingworx.things.connected.IndustrialGateway.GetIndustrialThings(IndustrialGateway.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

How do I get the info that the object with the missing view right is: IndustrialThingShape without downloading the source code and check the line?

But also this does not help a customer without access to the source code. Access control is a real pain if you get no information about what is missing. In this example, you call a service on an industrial connectivity thing. In the service definition, you see in the result that it uses a datashape. This you make visible. If there is missing access to e.g. the PlatformSubsystem this is nicely documented in the error log. But if the service, like in this case, call other entities, you just get a NULL pointer exception.

In this case we could have the option to temporarily enable an object trace and get all objects that are checked for access control, if e.g. the administrator is performing an action. My solution would be: Create a DebugUser with administrator rights. Whenever access control is requested against this debug user, report the object in the log. In this case, you can easily pipe the chain of object names into the logs.

[StefanBode]

This is very important if you get null pointer exceptions because you don’t have access but do not which object you cannot access with this user. At least the admin with access to the log files should see which object was declined. For example post in the security log all access requests that where denied with the name of the object, the object class and the user who tried this. This is also important in a regulated environment where you want to audit declined object access. 

[iguerra]

If you refer to ScriptLog, I use this method for all my services

try {

  // write here your service code

}
catch(e) {
  // write yere some log info or code that will be executed if on lines above an error is generated, I generally write this:
  logger.error("EntityName->ServiceName error " + e + " on line " + e.lineNumber);
  //throw e //if you want to block execution
}

In this way you have the line number, the error description, and the service is not killed (you may kill it however by calling throw) so can return a custom value.

you may also use error.stack if you need more info

you may put in the log also  me.name if you need to know which is the thing who generated the error (if the service for example is defined on a ThingShape)

As @raluca_edu told some errors occur before execution of a service (so this methog will not work) frequently for permissions, and those are logged on ApplicationLOG ... but again if also the caller service uses try-catch you will get the log ... but not however if it is called directly from a mashup.

[StefanBode]

hi @iguerra,

cool and great enhancement for the script log. I was not aware to get the line number that easily. ... Lack of education.

Anyhow the feature request was about all the "internal" errors you can get initiated by different JAVA functions in the platform. You may not catch up all, but at least the access control issues would be fine. All this NULL pointer stuff is really annoying. 

I would VOTE for the snippet above as a basic START for ALL new services you create, or even better embed ALL script services inside a general try-catch like the one above.!!!

[cbaldwin]

Java Script service thrown errors will now return line numbers and filenames if using this style of error handling as of ThingWorx 9.2 (targeted June 2021).

try {
	throw new Error ("This is the error");
} catch (err) {
	logger.error("{} - {}:{} - {}", me.name, err.fileName, err.lineNumber, err);
}   

[olivierlp]

Delivered in ver 8.5.13, 9.0.6, 9.1.1, 9.2 (See issue - TW-83366). Thank you

[RD_10077105]

I can confirm that on 9.2 this is still not implemented. Attached screenshot below.

The error message, while giving a hint, is still very ambiguous. The Thingworx version is 9.2.1.

[ankit]

Hello @RD_10077105 ,

Thanks for your comment. Can you create a Thingworx issue with the steps to reproduce and attachments of scripts, so that our R&D team can look into it? Let me know if I can assist in any way, feel free to reach out directly. Thank you.

[Radu]

No useful error message.

[Radu]

@ankit please look into this error, as well:

in order for the error to be useful, it should mention the actual name of the remote thing instead of that identifier.