I'll just tag on with what Russell said. If you do decide to add elements to a pristine BSFN DS try to make the new parameters optional or have default values so callers of the BSFN that don't implement your mods are not effected. Then all you really need to do is a full build to make sure all the C code gets recompiled with the new struct - namely BSFNs that call the modded BSFN.
Having said that I have never found a need to modify a pristine BSFN DS... and we are very heavily modified including many BSFNs. You can often find other ways to "pass" information to a BSFN without modifying the DS directly. If the BSFN you intend to modify makes use of jdeCache the easiest way is to add your own extension or tag cache. This is what we have done with things like the sales order MBF. For example we call AcmeF4211EditLine along with F4211FSEditLine and AcmeF4211EditLine will write to custom jdeCache the additional data that we want passed to F4211FSEditLine and then that custom jdeCache is read by B4200310/311.
Another way, (and this is a little bit of a hack but it works, and if done correctly is safe and doesn't effect callers that DONT implement the mods), is to store your custom parameters in memory (jdeCache or just plain old jdeAlloc) and then pass a handle to the memory location through an existing BSFN DS member in such a way that flags the BSFN that there is custom params to be picked up. I do this by picking a numeric DS member that is allways a positive value and then pass the handle to the memory location as a negative number. The negative number is the indication to the BSFN that the caller is passing custom params. The handle is used by the modded BSFN to pick up the values out of memory, including the originally intended value for the parameter that the handle was passed in.
Say you have the following pristine DS:
Code:
JCHAR szCompany[11];
MATH_NUMERIC mnOrderNumber;
JCHAR szOrderType[3];
...
And you want to pass URAB (mnUserDefinedNumber) for order 01000-12345-SO to the modified BSFN.
Calling BSFN stores the following in memory:
Code:
mnOrderNumber = 12345
mnUserDefinedNumber = 88899
Uses jdeStoreDataPtr to get a handle to the memory location which returns a value of 1.
This is what is passed to the modified BSFN
Code:
szCompany = "01000"
mnOrderNumber = -1
szOrderType= "SO"
The pseudo code in the modified BSFN looks like this:
Code:
if(mnOrderNumber < 0)
{
ID handle = mnOrderNumber * -1;
myCustParams = jdeRemoveDataPtr(hUser, handle)
MathCopy(&lpDS->mnOrderNumber, &myCustParams.mnOrderNumber); //restore the originally intended order number back in the lpDS parameter
//you now have access to the value stored in myCustParams.mnUserDefinedNumber
}
//If mnOrderNumber is >= 0 then it just means an actual order number was passed and the caller didn't implement the mods.
...
if(myCustParams)
jdeFree(myCustParams); //or destroy jdeCache, or what ever free action is appropriate
I usually build a BSFN to set the custom params for the caller so that the ugliness of the implementation is hidden. So from the caller perspective all they do is this:
Code:
SetCustomParams
-> mnOrderNumber = 12345
-> mnUserDefineNumber = 88899
<- mnOrderNumberHandle = -1
ModifiedFunction
-> szCompany = "01000"
-> mnOrderNumber = mnOrderNumberHandle
-> szOrderType = "SO"
And then in ModifiedFunction
Code:
if(mnOrderNumber < 0)
{
GetCustomParams
<> lpDS->mnOrderNumber; // passes -1, gets set to 12345
<- mnUserReservedNumber;
}
I also use this technique so I can pass custom Form/Report Interconnects. Keeps the public interface pristine and easier to retrofit during ESU/upgrades but still allows for callers to optionally invoke custom functionality.