You can use it to call internal routines. I believe it simply adds some logging, tracing or something... some type of additional diagnostics. I've never actually used it, just seen it in pristine code. You can't use it as a substitute for jdeCallObject... well you probably could IF your called function resides in the same DLL as the calling function. However, I don't believe it would be the preferred way to call a "public" BSFN.
I'm pretty sure this removes the overhead of OCM lookups etc. when calling a function that is within the library. Last time I traced a process where a call was made like this, there was no record of the function call in the jdedebug log. Which was a little annoying.
That's correct. It will in effect statically link the BSFN call. This will only work if the caller and the callee are in the same DLL - you will get a link error if they are not. If you look at pristine code you can see that they only use this on internal subroutines. Doing this with "public" BSFNs like F4211FSEndDoc you would lose debug log info (at least the part of the log that lists all the params and values) and CALLMAP functionality, as well, as you mentioned, the ability to use OCMs to map a BSFN. For things like vertex where some organizations may only have vertex installed on select E1 servers this would be an issue.
I think Oracle added it so they could get additional logging for support purposes since most of their support calls start with "..send us your debug log.." Without debugging (as in Visual Studio debugging) Oracle doesn't have any visibility into the sub-routine calls. This will give Oracle that visibility.
BTW, you don't need that macro to statically link to a "public" BSFN like F4211FSEndDoc... just use it like any other function call. I almost never do that because I don't want to lose all the things I mentioned - makes it harder to use the call stack tools in JDETrace . The overhead of jdeCallObject is minimal. Unless you are calling some BSFN millions of times I can't see where the trade off would be worth it. In fact I bet most of the overhead is in the very first call to a BSFN, the JDE internals may hold on to the function pointer reference for subsequent calls at which point there would be almost zero overhead trade off.