When using Fabrication with dynamically generated Proxies, there's a big gotcha to be aware of. I just spent hours debugging this problem so I thought I'd share my findings and save others the hassle.
When using dynamically named proxies, Fabrication will alter any outgoing notification names from that proxy. For instance, if you have a proxy named DataProxy_563 and you send a notification from within the Proxy called DataComplete, Fabrication will alter the outgoing notification name to DataProxy_563/DataComplete. This is done, in conjuction with a second notification sent named NOTIFICATION_FROM_PROXY, so that you can have mediators listen for specifically named proxys using a respondToDataProxy_563(note). The problem, however, is that this alteration requires your mediator to know ahead of time that the proxy they are interested in is named DataProxy_563, which you can't do when naming proxys using a dynamic generated name like _563. You lose the simple DataComplete notification altogether and can only listen for "DataProxy_563/DataComplete" (which won't work as a respondTo name) so you have to use the respondToDataProxy_563(note) method.
In my case I wanted to listen for that basic DataComplete notification and then inside the respodToDataComplete() call figure out what Instance of DataProxy it came from and go about my business that way.
Luckly, Darshen was smart (like you didn't know) and include a little mysterious property called expansion which, when set to false, will completely bypass the renaming and send the normal notification. YAY!
My only complaint is that I would have rathered this been set to false by default, rather than true. I don't really see many instances where I would want that default behavoir.
Anyway, simply set this to false in your proxy, assuming of course that you are entending FabricationProxy, to have the normal notification behavoir.