I am working on a fairly simple data directive to alert members of our team automatically when a forecast order has been placed. It is working currently however the email is a bit more difficult to read than id like when including the data fields. Particularly the created by and Custnum fields. Our user ID’s are fairly different from peoples’ actual names so for the users receiving this email they wouldn’t be able to easily determine who created entry. And then it would just be nice to have the customer name display instead of the customer number.
I’ve searched around and I saw a bit about maybe using the invoke BO method to link those fields to the fields i’m looking for in other tables but I couldn’t quite make that work. I’ve seen other instances of users using code to do this but I’m not particularly good at programming.
LINQ query within the BPM. You join the SysUserFile table to your dataset and output the desired columns. I’d do it in code, but I believe you can do something similar with a fill table by query widget.
Scheduled function that aggregates recent changes. This is my go-to method.
Create a BAQ with all of your fields, and execute it via the DynamicQuery BO. This gets a little hairy from a data directive. You’d probably want to use a post-proc BPM on Erp.BO.Forecast.Update instead.
Frankly, going through the update method is better in several ways. You really only want to use a data directive if it’s something like Job records, which can be created and modified by any one of a half dozen modules and you want your rules applied consistently.
After posting I dug a bit more into the invoke BO method I originally mentioned and was able to get it working. I was able to invoke the GetByID method and output the table’s as variables (it was the return value binding that I was originally missing). This has worked pretty well after a few tests.
I am curious why this may not be a good method to approach this problem though. The scheduled function to aggregate recent changes sounds interesting, would you be able to elaborate on that?
Data directives should be a method of last resort because of how often they can be triggered. It’s kind of a blunt hammer. It will do the thing you want. It will do it often. Possibly too often.
GetByID should also be approached with caution since it grabs everything related to the record. I’ve seen huge payloads returned on Job calls, for example. A query is better unless you will be updating a record and actually need everything.
Now, is any of that an issue on this specific implementation? Probably not. However, if you put a data directive on PartTran that then called JobEntry.GetByID you’d notice a performance impact. It’s a not-great practice that you can get away with on small, infrequently used modules, but will hang you if tried on bigger, busier parts of the system.
Functions are a way to centralize complicated customizations in one place, and reduce the amount of stuff in BPM’s spread across the system. You can also schedule them using the Task Agent. I’d search the forum for more information. They’re powerful, therefore hard to summarize.
I did initially start with a method directive instead of a data directive. Using the Forecast.Update BO however I found that the two conditions I tried to use (The specified field has been changed from any to another, and there is at least one added row to the specified table) did not trigger the email to send upon adding a new forecast entry.
I will look into this option as wells as the function option John recommended. This could be a topic for another thread but is there any decent education material, preferrably free, on programming with specific focus on Epicor. I can write C# code but am unfamiliar with creating code to be used in Epicor. If there is any documentation or maybe even a few example tutorials that someone has links to I would greatly appreciate it. Thanks for all of the help everyone!
I have these on a standard data directive, so it is after the write, so the user does not have to wait for it to happen. If your environment works with sending Async (some are finicky) then it is even less of a load. Email Credit Hold Sample.cs (3.2 KB)
Yeah I posted one not long ago, and just had to profusely apologize in advance and beg for forgiveness. It was too much to rewrite just to get the point across.
