The question is silly (and close to being dumb) - I want to print the name of the script, which is being executed by camunda (both as a script task and as a script variable).
The history of this meaningful request is simple - as a BE, I am once again asked that question "can you help investigating what is this NPE - %clearly a script variable name of one of the scripts%?
I do realize that there is a second option being - add logging to groovy scripts. But the thing is - there are a lot of them. And people make more… and standing above them with a hammer is not an option.
Unfortunately I personally haven’t seen anything like you’re requesting, but maybe tweaking the logging might shed more light in your NPE investigations.
I had some problems similar to yours @Draakzward which I solved as follows:
We use Slack as a communication tool here at the company, so in addition to the logs we have, which should be standard for troubleshooting, when some types of errors occur that are important and related to the business itself, and not with the code or modeling of the process, we send this error with an easy-to-understand description to a slack group, where our business people have access and can quickly understand what happened, without the need to contact the IT team.
Including Camunda errors, for example, we have a step where the insurance company sends us some events, and these events fall into an Amazon SQS (FIFO Queue) and we later send them to Camunda via messageCorrelate, if we have an error, it retry another 2 times, and if it is not possible to send it to Camunda for some reason, we send this event to a deadletter queue, and then at this moment, a message is also sent to slack informing the reason for the error.
This is just one suggestion among several possible.
I hope it helps you come up with some good ideas for your case.
It is a possibility, yes. But the thing is that there are cases like:
user task (with input parameters as scripts)
-> script task
-> script
-> yep, again
-> service task
-> user task
And “here” I’m getting a "Sorry, but one of your scripts failed on a NullPointer “randon variable, which could be in some of this scripts” (like “pattern” for date… which is common).
Which starts the game of “hm, let me just read all of the scripts to assume which one actually failed”.
I dont know the entire context of your application my brother, but from what I understand, the null pointer could be coming from a variable of type Date that was possibly not defined before running your script, and it seems to me that this “Date” should come from a user task, Wouldn’t putting the Date field as “required” be an option? or even define that, if a date has not been specified, there is a default date?
For example, if the Date field is not filled in, the script searches for the current date (new Date()) and adds 10 more days (this is just an example, as I don’t know the business context of your application).
In my opinion, a NullPointer must be treated so that it does not occur, but anyway, as I explained, in addition to not knowing the context, this is just my humble opinion.
I would try to handle this exception so that it does not occur in any case, and thus we would eliminate this problem so as not to have to do manual work of looking for logs, or even bothering business personnel, with possible “Unfilled Dates”.
but from what I understand, the null pointer could be coming from a variable of type Date that was possibly not defined before running your script,
This is the problem in fact - people work and change the flow, after which something bricks, and nobody can tell what precisely And this becomes a zoo with one person changed something, and something later on threw an NullPointer.
But since the NullPointer doesn’t really give an understanding WHAT SPECIFIC STEP, you can hear my distant swearing, going from that step and looking at what specifically died… Which is the point of this topic.
I can imagine your happiness when you see this happening… I can hear your scream from here in Brazil, and your slapping the table with your palm…hahahahaha, but unfortunately this seems to be more of a people problem than a problem with your process BPM or code.
People couldn’t simply change everything without at least discussing this in a meeting and especially bringing together those who support the affected tool, in this case Camunda.
But anyway, I don’t know the context and so I don’t know what’s going on in the company.
In this case, I imagine that we don’t have much to do, other than keep looking for crumbs of information in the logs, and spend hours and hours supporting a single problem.
Or we pray for the culture to be changed in the company.
And this becomes a zoo with one person changed something, and something later on threw an NullPointer.
