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.
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?
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)?
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.
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…
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.
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…
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…