Hi,

I don't think we can trace the activity called via queue. Because the execution of the queued activity occurs asynchronously in batch requestor. The execution progress of this activity is not predictable. We can understand only if the activity has failed or passed by checking the pxMethodStatus property alone.

Did you try going to the activity ruleform and choosing "action > trace"?   I ask, because I heard that listener activities can be traced in this manner, so it would be worth checking whether queued activities can also be traced similarly.  /Eric

Something else to think about is this:

When we trace data-pages, there's a tracer event type called "adp" that stands for "asynchronous data page".  If you click on that event, you get a SECOND trace open up to show the data-load for that page.

Often, those data-loads of the page are asynchronous activities, so I wonder if it would be possible to similarly show the second trace for asynchronous activities that DON'T happen to be associated with the data-load for a page.

(Hmmm, if it's NOT possible, then a sort-of-strange-but-maybe-useful thing to do is PRETEND you're using a data page, merely to be able to specify your asynch activity and hence get the "adp" and second trace feature available to you)

I guess (though I am not sure) this might not be possible since the queued activities are executed under the context of a batch requestor.