Hi, we are upgrading from E9 and currently converting all of our ABL code to C#, and are trying to get one particularly annoying piece of code to work. (We generally use the ABL to C# converter)
Services.Bpm.BpmEmail hEmailEx = null;
The above piece of code is where the problem originates, its a problem with the way we are using Services?
“The type or namespace name ‘Services’ could not be found (are you missing a using directive or an assembly reference?)”
The hEmailEx is how we sent email alerts in E9, if someone could help with the C# equivalent that would be awesome. (I would like to avoid using the send an email item)
Thanks for any help!
That’s generally a bad idea, the converted should not be used in my opinion on ANY production code or production system. Rather to get a general idea of what the C# should look like.
Look at the converted code programming guide in EpicWeb to figure out how to send email in code in BPM. this Changed significantly in 10.2 and the converter wasn’t updated AFAIK
Hope this helps, and please please please do yourself a favor and do not use “converter” code in your actual system. Use it as a guide only.
to save a bit of your time, this is the C# code to send an email:
string emailTo = string.Empty;
// if email receiver is different each time then link it to what ever table you use to save emails after finding the match record
emailTo = Db.TableName.FieldName;
var mailer = this.GetMailer(async:true);
var message = new Ice.Mail.SmtpMail();
var from = “Epicor email on Company Configration”;
message.SetFrom(from);
message.SetTo(emailTo);
var subject = “Email Title”;
message.SetSubject(subject);
var bodyBuilder = new System.Text.StringBuilder();
bodyBuilder.Append(“your email text”);
var body = bodyBuilder.ToString();
message.SetBody(body);
mailer.Send(message);
The early days of research into the move from ABL to C# involved some review of tooling to ‘machine translate’ the code. This ended up consisting of a ‘preprocessor’ - tailored to cleaning up some ABL (macros was the big one). With the ‘cleansed’ ABL, we passed it thru a tool we purchased and extended to fit the BO services (loving called the sausage grinder in many presentations). Lastly, we did some Roslyn magic tailored to fitting the new ICE 3 framework and clean up some of the real oddities everyone shakes their head at when looking at the output of this kind of tooling. Lastly, humans with neurons firing reviewed the output and applied some optimizations we discovered along the way of the conversion that did were faster to fix manually then try to update one of the three stages and risk the migrations again. Lather rinse and repeat across 43 million lines of code and ERP 10 was born.
When looking at how we can help migrate expressions / bpm code / etc, we came up with the idea of wrapping the sausage grinder for our professional services group to use and then it was pushed out to all to use.The quality is … mixed to say the least. It was not designed for end users or anything beyond the BO Services as part of the 4 stage conversion that occurred. The coding practices for a procedural language like ABL versus an OO/Functional language like C# and LINQ make the mapping inexact at its best. As Jose mentions though it can be used to get a general feel for the delta to C# when coming from ABL. That was the intent - reduce the fear factor as looking at a foreach in ABL in C#/LINQ is not THAT drastic a difference. To that end, I think the tooling is useful. Blind obedience? I don’t trust MS designers and review them after doing something in a VS designer so I assume no one will trust 100% our tooling either.
With all the negatives, there are plenty of positive and some hilarious anecdotes as well. I just had a question pop up on a service a couple of weeks ago and went to review the code. It went thru the conversion process not needing any attention - there were many that were this way. The code was basically untouched in our version control going back to 1997. So the tool did fill a need.
Just channel your inner Scotty and make sure you are using the right tool for the job.
None of us can be good at what we do if we don’t know WHY the blasted thing works the way it does. Bart, THANK YOU for continuing to explain to us various thought processes and design decisions that went into the now-more-than-43-million lines of code beast we get to call home.
@Bart_Elia Can I have a cheeky guess at which code this relates to. Is it the code that calculates quantities on hand for the PartBin, PartWhse tables? If you’ve not reviewed it since 1997 then that explains why the 6430 conversion just got converted as well as now features in the Menu “Refresh Part Quantities and Allocations”…
I was hoping E10 would negate the need to run this process
The best (incorrect) guess so far internally was a FAX interface. Not telling as folks are still guessing internally and we have many paying attention to E10Help and EUG these days
Thanks Al for the code, and thank you to Jose for the heads up to not trust the convertor too much for anything but the nontrivial stuff. Bart thanks for explaining the convertor a bit
