I’ve been looking through the database and one table in particular (ACT_RU_METER_LOG) appears to have some history relevant to the execution of processes and the process engines that executed them.
What I would like to know is, what elements compose the ID_ column UUID values?
Example: 06e7fdee-fb3a-11e5-8794-e61f13e8c467
What I’ve been able to “guess” is as follows:
06e7fdee = Unique identifier
fb3a = ?
11e5 = Possibly the process engine “name” (ID)
8794 = ?
e61f13e8c467 = A specific Camunda host and/or process engine.
I’ve been looking through the source code in an attempt to find where this generated, but haven’t found the exact source.
In case others have a similar question based upon RFC 4122 below.
The first three fields (timestamp) are defined as follows:
The timestamp is a 60 bit value, representing the number of 100 nanosecond intervals since 15 October 1582 00:00:000000000
I didn’t find an easy way to convert the timestamp into a human readable date, although there is code to that. This site has an online converter: https://www.famkruithof.net/uuid/uuidgen?typeReq=-1
Hi Michael,
I wouldn’t put too much effort into interpreting uuids. Their purpose is as universally unique identifier, nothing more, nothing less. To achieve universal uniqueness, the value algorithm ensures spacial uniqueness, Mac address, and uniqueness in time. Hence these two dimensions enable universally unique value…
There is a single, critical piece of information in the UUID (I think), and that is the MAC address of the host. I’m hoping that this will allow me to trace which host executed a particular process step. However, giving it a bit of thought and in context with what I’ve learned, I have the feeling that may not be possible as the last octets of the UUID may not reflect where the process set ran, but rather where the process was created (deployed) initially.
I don’t at this time know how to create a process whose individual steps will consistently run on multiple hosts (or at least have the chance to).
I feel it’s critical for debugging that we know on which actual host a specific step/task/whatever actually ran or attempted to run. According to Thorben, this isn’t something Camunda does right now.
Michael Peoples (mp4783)
Global Customer Service BizOps
Office: +1 614-886-0923
Mobile: +1 614-886-0923
Hi Michael
Another area you may be able to explore, particularly if its asynchronous continuations you want to trace where thy ran could be as follows.
On tomcat the job executor allocates a unique ID to lock jobs. Hence as a proof of concept you could put a post update trigger on the job table and dump out the lock and job/task IDs. A little crude but could enable you to test your requirement…
I was on the phone today with a couple of your guys. There’s really no native way to do this.
I’ll need to look at the behavior of “multi-host execution” in the database. It’s possible that interactions initiated by a process engine carry sufficient information to identify them. If relevant transactions can be identified, then one way to track this would be through MySQL Triggers to write to an external table.
Alternately, we could insist all processes be deployed with additional logging code that would track execution in an external table.
This is just something on a long list of things we need to figure out.
