Process ID variable availability in running process

Camunda 7 Topics Discussion & Questions
1

Is there a way to reference the “parent” process ID for a process that executes its steps on multiple process engines?

What I want to do is record history in a separate database as each step takes place and I need a way to “tie” them all back together again when reporting.

I guess a more general question would be, what information about the “environment” is available to a task/process when it is executing that is not set in the process code itself? What I’m looking for would be analogous to shell environment variables or server environment variables in an Apache web server.

Thanks.

Michael

2

Hi Michael,

I’m not quite sure that I understand what you mean with parent process id in relation to multiple process engines.

Also the available environment depends on the context in which you implement your code.

In execution listeners etc. you most likely have a DelegateExecution available. Or more general the current process instance id, process definition key and process definition id should always be available.

Maybe you could give an example in which context you are implementing your recording?

Cheers,
Sebastian

3

If I have a process that executes steps on a physically different process engines, I want to record data about a specific task step. When the entire process is complete, I want to be able to report on which step ran on which actual physical process engine host. To do that, I must have a way to tie all of the individual steps together in much the same way that the Camunda management GUI does when you look at the history of a specific process instance.

I want to do this at the time that the step actually executes; therefore I need to have some sort of “persistent” value that will allow me to tag that specific step to all the other steps of the process. This is the first part of my question.

In many applications, Apache web server for example, there are variables available to any application running in them (example: PHP server variables). What I want to know is, when a process step/task/whatever is running on the Camunda engine, what “environment” variables are always available to it (example: process engine name)?

Michael

4

Hi,

the nearest to environment variables is maybe the static Context object, which is an internal API structure to give access to different contexts, depending on the current context. For example if available you could get the process engine configuration, process application context, command context and execution context.

Cheers,
Sebastian

5

Hi Michael,

here’s another possible approach;

For each engine node, add a unique node name into the Tomcat catalina.properties, for example NODE=node1, NODE=node2…on each respective node

Now in your code, you will be able to perform a property lookup using System.getProperty(“NODE”). Hence, add a listener on each task to log the task ID and node name or add global listener to do the same.

Ive not done this, but in theory it should work…

Note: In addition, in terms of process engine ‘variables’ available, have a look at the javadoc for ExecutionImpl, as when you use the ‘execution’ context, this is whats available…
regards

Rob

6

When you reconstruct the history of a process, no matter which process engine it ran on, how do you tie all of those events together?

What I want to do is put in listeners where every step that is executed writes a record to a completely separate database and contains the following:

  • “Common” ID that would tie that step to process/job that it was a part of

  • High-precision timestamp

  • Hostname of the Camunda process engine host that the step ran on

I have a Java class that can do all of the above with the exception of providing that common ID. I don’t know how to get that ID from the “environment” or context or whatever.

Michael

7

Hi Michael,

how is your Java Class called? Execution Listener? If yes then:

public class MyExecutionListener implements ExecutionListener {

  @Override
  public void notify(DelegateExecution execution) throws Exception {
    String processInstanceId = execution.getProcessInstanceId();
  }

}

Cheers,
Sebastian

8

Hi Michael,

out of curiosity, whats the use case for wanting to know which node does what etc? The reason I ask is engine nodes tend to be stateless… Hence curious on the use case…

regards

Rob

9

Simply put, if something is going wrong with a process that could be caused by some “difference” in the node it was run on, then we would want to know what that node was.

For example, we use SSH keys to permit commands to be run on hosts. If a node didn’t have the key, the failure to login would be attributed by the process as a login failure, not a process failure. Therefore, the command would not have run. You could trap this with more sophisticated error handling, but why wouldn’t you want to know exactly where something executed.

In this case, the process would not have retried the step because it would not have considered it as having “failed”. The process would run to completion without ever having successfully run the command. The next time it ran, it might work if it ran on a server with the proper keys. Thus, all things being equal, you wouldn’t know why the first instance failed other than the error message possibly contained in a process variable.

This is as much a practical matter as a philosophical one. You should know with absolute certainty where, when, and what happened.

Michael

10

Thanks Michael, I thought that may have been the use case. Another’s strategy could be rather than log everything, use a custom incident handler to log more details when a system incident occurs. I actually use custom incident handlers to raise support tickets when things go wrong…

Regards
Rob

11

One my colleagues has also simply included a process variable that is set with the host upon which the task is run. While this certainly works (and I considered it), it requires the developer to remember to include it every time. Never trust developers…

12