Skip to main content

HI,

 

I have iplemented cutom auditing in most of my workflows. Unfortunately, initailly it did not take into account the action that was taken. What I would like to do is join my custom auditing tables with the K2 auditing tables in the K2 database to generate reports that show what action was taken in each step by which user. I have a prcessinstanceid field in my auditing tables which i am hoping i can use as thekey whe joining onto the K2 auditing table. Would you guys be able to tell me in the K2 database which tables store what action was taken in each step.

 

@Update: The reason, I am using custom auditing is beacsue, with K2 oout of the box, if your process called an IPC you cannot audit that. If there is a way to keep the audit going even f the process called and IPC that would be great. If that did not make sense, let me give you an example; I have proessinstaceid 123. It has one activity A and then once ativity a is complete it goes to activity b which calls an IPC and then it comes back to activity b and then moves on to activity c. Now when i use the out of the ox smartobject "Activity Instance Destination" I will only see activity A and C becasue activity b does not have a destination.

 

Thanks in advance 

Hi s0m3one,

 

My understanding of an IPC event is that it is used to trigger another workflow/event.  In that case, the information is exactly where you are looking for it, in the Activity Instance Destination object, but has a different procID, since it's a seperate workflow.

 

Regards,


Mike

Hi,

 

If you want to change the way you capture audits you can do so by saving the Activity Level Data Field called Action Result to your auditing table.

Drop a SmartObject event underneath your client event and then pass the Action Result value into the method that creates your auditing record.

I believe this would be the simplest, then you don't need to join it to the K2 database for reporting. However, this will only work from the point of deployment and you would probably still need to join to the K2 DB for older instances.

 

K2's policy is that they don't really like direct DB queries, but if you cannot use K2 smartobjects to get the reporting data, then you can use the (NOLOCK) query hint to join to some of the ServerLog schema's tables. You can use the ServerLog.IPC table to join from your parent process to the child process and then use the ServerLog.ActInst and ServerLog.ActInstData tables to get the Activity Instance info and the Action Result Data Field Value.

 

I hope this helps!

 

Regards,

JohanL

Curiosity: If the only thing activity B is doing is starting another process, why do you need an audit trail for that activity?  Isn't the fact that you have a new instance of the other process sufficient for auditing?

 

You should also be aware that because of the way K2 works internally, there could be a delay between when an activity actually occurs and when it is recorded to the database.

Thank you all for your help and suggestions. Decided to go for the storing action result option as that seemed to be the cleanest solution. 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings