How to determine who made changes?

I add/update the Address Book/phones/email/who's who tables using 2 ways, they are web services and the JDE application. In their table triggers, I only want to execute a business function if these changes are done in the JDE application.

If the changes are done using web services then I DON'T want to execute the business function in these table triggers. Is there an elegant way to do this?

Map a field through down into the NER or C BSFN all the way from the external calling application and WSDL down into your Address book NER that ends up in an Address Book table column. PID maybe?

If that field is not blank or what you want (if called from the BSSV), bingo....?

Or get the BSSV to call a different NER C BSFN than the APPL uses?

FYI, audit fields are not usually updated by "table triggers" in JDE. Instead, they are set by the application code before the update is issued.

brandonkirsch said:

FYI, audit fields are not usually updated by "table triggers" in JDE. Instead, they are set by the application code before the update is issued.

Click to expand...

I'm aware of that thanks
I'm just suggesting he use a field on the F0101 to denote to the table trigger where the insert or update originated from.
PID seems like a good one to me as by the look of it they'll be different.

Could be one of the ACnn fields or anything. but as for PID, it is used in N0100041 to decide on various things in the code

"EP01012" for the Address Book screen
"J0100001" for the BSSV

This is set just before the call to N0100041 in J0100001
private static String ADDRESS_BOOK_MBF_KEY = "J0100001_AB_MBF_VERSION";
private static String UPDATE_MASTER_FILE = "2";
private static String PROGRAM_ID = "J0100001";
private static String PROCESSING_MODE_CHANGE = "2";
private static String PROCESSING_MODE_DELETE = "3";
private static String PROCESSING_MODE_ADD = "1";

Now I'm not sure what BSSV you are using, but if you are using this one, that should help

You can put a trigger on top of the impacted tables and capture which app/item is making the change. You could then execute the appropriate piece of code from that point forward. Best not to mess with the audit tags - let the apps update it as they would normally.