Get incident information from Java API

Camunda 7 Topics Discussion & Questions
1

Hello

I read your thead about incident handling in Getting Stack Trace in Boundary Error Event - #13 by StephenOTT

I have a similar problem but I didn’t find solution in the comment. So I have a bpmn diagram like this: withbreakpoint.bpmn (3.7 KB)

If I run this process an incident will be generated. I can create an own incident handler but I would like to inform my business user where was the problem. The API will give back the noError activityId because I put the async after. How can I know that the problem was occured in the error notation and not in the noError notation? I see in the stack trace but that is not fine for me because I would like to alert my business users more userfriendly for example: There was an error on the Error notation the problem was …

Is it possible?

Thanks in advance: Gábor

2

@Gabor_Sandor you can catch the error error, wrap the error with a better error message and then throw the error(blocking) (or generate the incident with the incident api (non-blocking)).

(shown as JS examples:)
Incident API:

var IncidentEntity  = Java.type('org.camunda.bpm.engine.impl.persistence.entity.IncidentEntity');

var IncidentContext = Java.type('org.camunda.bpm.engine.impl.incident.IncidentContext');

var context = new IncidentContext();
context.setActivityId(execution.getCurrentActivityId());
context.setExecutionId(execution.getProcessInstanceId());
context.setProcessDefinitionId(execution.getProcessDefinitionId());

var newIncident  = IncidentEntity.createAndInsertIncident("myCustomIncidentType", context, "A custom incident message.");

newIncident.id

Catch the error:

try {
  doSomething()
} catch (e) {
  switch (e) {
    case "value1":
      throw "There was a error related to: " + e.theErrorMessage();
      break;
    case "value2":
      throw "There was some other error related to: " + e.theErrorMessage();
      break;
    default:
      throw "Something went wrong and I dont know what it was: " + e.theErrorMessage();
      break;
  }
}

If you are catching the error, then just parse the camunda incident that is generated.

I would likely want to add something like “{{{the ouputted error message goes here}}}” so you can more easily parse the throw exception that camunda wraps around the responses.

3

Hello

Thanks the quick response. My problem that I am not able or don’t know how can I throw custom error. The business case is that our business user will create for example a Groovy task where he will create a syntax error or there will be a wrong dmn in the process and I would like to inform him after the execution that there was an error in the process pls see your … DMN or script task and fix the problem. In your example I need to create the error message what is not possible in this case.

4

Can you explain your larger use case?

Based on your explanation you are saying that the end-user will provide Groovy code that you will execute within a script task?

5

The groovy was a bad example but it can be. A valid use case that our business will edit the dmn and there will be an error in the dmn. She like to change the input parameter or change to advance mode and use the string value without the ". This was my yesterday problem. I catch the error and give back the juel error but I need to see the Tomcat log to know the name of the notation. That will be fine if I can inform without stacktrace about the wrong step.

6

Hi @Gabor_Sandor,

sometimes a exception.getRootCause().getLocalizedMessage() helps to get the real dmn errors.

Hope this helps, Ingo

1 Like
7

There is no exception object if I use custom incident handler :frowning: or I don’t
know how can I get :).

8

Ok, after I checked the code, you may need a new JobRetryCmd to set the exceptionMessage accordingly.

Here is an example from another use case: https://github.com/camunda/camunda-consulting/tree/master/snippets/change-job-retry

Don’t know if it’s worth the effort…

9

I have studied your proposal sorry but I don’t see how can this example
help for me :).

10

Overwrite the logException(JobEntity job) method.

11