Hi. The Process Audit table names changed with version 9.7. Prior to that, table names were prefixed (generally) with “WM” and as of 9.7, tables are prefixed with “PRA” (for "PRocess Audit).
You mentioned version 9.8, so yes, you are looking at the correct table. So let’s talk specifically about your case.
You are using a Service Task inside a Subprocess and the implementation of that service invokes pub.prt.log:logActivityMessagess? And, you’re saying this step executes normally but there is no entry in the database table for that instanceId and stepId, is that correct?
If it helps to know, I just crafted a simple model and of course it works as you’d expect. So there must be something missing from your description of the problem or some environmental issue.
Here are some things I would ask you:
when you say “subprocess”, you really mean subprocess, yes? Not Call Activity?
have you tried adding a debugLog or tracePipeline invocation to your flow service associated with your step to ensure that the contents of your flow service you see in Designer are actually what has been deployed and running on your test system? It’s very easy for a Flow Service to drift out-of-date if you’re deploying it anywhere other than your local IS.
You say this same service correctly logs the activity msg from a Service Task in the parent model. Tell me exactly how you’re verifying this, please.
In short, you absolutely can log activity messages from a step in a Subprocess.
Well, I finally now understand your issue. My problem, not yours.
Everything I said before is/was true. But the problem here appears to be with the Monitor UI. I just verified that it is NOT properly rendering the Activity Msgs in the portlet for steps running in a Subprocess.
I would encourage you to log a support incident with Global Support right away. Please drop my name “Thomas Dayton” and let them know I’ve already reproduced the defect and to route the internal defect to webMethods Monitor team.