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
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)
That's true for asynchronous calling i could go for Load-Data-Page method using Data Page and I could trace it using ADP option. But, Here we have to create one more additional data page rule and clear it after the use. :)
For now I just completed my development using call method and later changed it to Queue method. Used Log messages for debugging.
But still couldn't get a way to use the tracer and track the Queued activity!