I am trying to write a simple email alert but I receive an error when testing the code.
It’s a pre-processing Bpm on SalesOrder.Update
var ttOrderHed_xRow = (from ttOrderHed_Row in ttOrderHed
where ttOrderHed_Row.Updated()
select ttOrderHed_Row).FirstOrDefault();
if (ttOrderHed_xRow != null)
{
Epicor.Customization.Bpm.InfoMessage.Publish(System.Convert.ToString(ttOrderHed_xRow.ShipComment));
Epicor.Customization.Bpm.InfoMessage.Publish(System.Convert.ToString(ttOrderHed_xRow.DeliveryDate_c));
}
‘OrderHedRow’ does not contain a definition for ‘DeliveryDate_c’ and no extension method ‘DeliveryDate_c’ accepting a first argument of type ‘OrderHedRow’ could be found (are you missing a using directive or an assembly reference?)
I’d be interested in what your thoughts are on advantages / disadvantages of using code instead of widgets.
I tend to could exclusively - unless it’s something really straight forward like a change log in data-directive.
I think when it comes to upgrade time the widgets are more likely to upgrade without issue while code can sometime have issues. For our upgrades I make sure we test all BPM’s that have code widgets.
Multi-Tenant (MT) - the former product that some users still run but has not been sold in over three years is SaaS
Public Cloud or Dedicated Tenant (DT) - the current product is also SaaS
Single Tenant (ST) - is not SaaS but IaaS - Infrastructure as a Service
MT cannot run CODE without a lot of work with Epicor. This includes code widgets. Why? In MT, multiple companies exist in one database and one can use code to see records outside of your company ID.
So if you use widgets, even code widgets, they will only not work for older customers on the MT product. Those BPMs will work on everything else moving forward.
I default to code often too. However, widgets allow for non-technical people to use and modify the results. Also, Epicor will support them if they don’t function as needed.
BTW, to create Code Widgets, on-prem or SaaS, users must have Advanced BPM enabled on their user record. Some on-prem users won’t allow this capability for SOX reasons. Access to the db.context can be like juggling running chainsaws - impressive but you can hurt yourself.
I Strongly promote standard widgets over a C# Code Widget when practical.
ok… now define “When Practical”:
if you have 2 variables to assign in the updated record… use a widget
if you have a couple of conditions, and a pop-up message… use widgets
BUT:
if you have 30 variables to set, you are checking values, have 10 different error messages that could display… its time to start using C#, as it will be easier and faster to maintain.
Very often my BPMs will have four widgets and a Variable
I create a variable called “errorMessage”
Condition widget (to decide if code needs to run.
C# Widget that clears the error message, does some work… if there is an error condition, sets the errorMessage text
Condition widget that looks to see if errorMessage is populated… if so
OH, one other thing… SOME widgets are just not as fast as you can write the code in C#… if you have a speed issue with doing widgets only, then it might be time to consider C#.
UPGRADE CONCERNS: Yes, if you write your BPM in C#, you are taking the responsibility to make sure that upgrades work. Epicor COULD/MIGHT change something… when you do it in C#, Epicor’s upgrade process will not automatically fix things… but when you use standard Widgets, there is a better chance that Epicor’s upgrade utility will fix values to work correctly after the upgrade.:
Tim - this applies to using widgets as well. If you call a BO object and they change the method this does not upgrade but mentions changes in the release notes. Still your problem to fix! Have yet to see an upgrade fix it for you.
