Given that your code is triggering the In-Tran, perhaps the MsgBox doesnt work.
You could try setting ttUD03 Character02 to “It works” in the Data Directive and see if it applies.
MessageBoxes probably assume you are being called from a Client UI.
Given that your code is triggering the In-Tran, perhaps the MsgBox doesnt work.
You could try setting ttUD03 Character02 to “It works” in the Data Directive and see if it applies.
MessageBoxes probably assume you are being called from a Client UI.
Ok I tried a field setter in the In-Trans (for both an “updated” and an “added” test) and neither took
You did do a “Added” as well right?
Correct. Probably time to step away and see if the oracles tell me what I’m doing wrong lol
I also tried variations with condition, without condition. Even the Info MessageBox worked.
Check your Server Log
https://SERVERNAME/EpicorERP/ServerLog20220104.txt
I run my code inside ABCCode GetByID POST
Ok something must be goofed on my end…I’ll check it out
Where is your code that does the Update fire in, which BPM? I also tested it in ABCCode.Update.POST to make sure it wasnt a ds
variable conflict.
Also Enable/Disable and save the DD a few times
I’ll show you in a bit…but the code to create ud05 records is on data directives for shiphead, dropshiphead, and quotehead. Is that what you meant?
Is it in In-Transaction Data Directive or Standard? If its inside In-Transaction then your Data Directive for UD05 may not fire. Usually your supposed to do those calls in a Method Directive
You are technically “inside the base, of the base” and Epicor does Db.DisableTriggers()
Interesting…might be something. Perhaps moving those to the post processing of the update methods would get this working?
Maybe it depends which Data Directive and if Epicor disabled triggers… For example I can do it in ABCCode In-transaction just fine.
Inconsistent and undocumented behavior in epicor?? Color me shocked
Ok now I am truly losing my mind…
I re-created the same BPM on ShipHead.UpdateMaster.POST, and disable the old Standard DD on ShipHead which was/is responsible for writing the UD05 record.
Disabled Std. DD:
Created and Enabled PostProc BPM:
Same code, same behavior, still writes records to the table no problem.
I enabled trace logging for both “log” and BPM via the appconfig.
In the Standard DD for UD05, I took off all conditions and simply am writing to the log.
In my server log, I can see that indeed my ShipHead BPMs, both DD and Method work just fine, however the UD05 services I invoke in my code (which successfully creates records, mind you) nor my little diagnostics log message are anywhere to be found.
Absolutely baffling!
Sleep on it Aaron! I don’t want your head to explode haha It’s only January 4th! Still have a whole year of challenges ahead!
Every day is a struggle when you’re me
I’m seeing you do some cool stuff, would like to catch up with you at insights if they have it this year and if you are going.
There many great ideas already in this conversation!
Initially, after reading your problem, you could have a scheduled function or UBAQ that periodically polls the table the records are in and attempts to resend them.
I’m not entirely sure of the scope of your problem, but it definitely sounds similar to processes we do. We are implementing event-driven architecture and ERP sends events in real time (standard data directives) to a service that sends to AWS. In the event of a failure (we don’t write successes too much db overhead), we write out to a UD table to capture the failed payload. We then have a UBAQ (on 10.2.300) invoked via a cron job that polls that table periodically and resends the data.
Hey Jeff,
Yes that was certainly on the table. I wanted to avoid polling my own table.
What I decided instead was to, after each event writer writes its event, was to call a Function to notify the Function that an event was written (in lieu of being able to work with UD05 table changes).
The Function, when invoked, scans UD05 and iterates over records to then process the work.
Sorry, I cannot answer your question. I’m just not familiar with Epicor CDC.