Are Epicor Widgets Broken? 🤐

[hkeric.wci (Haso Keric)]

I have come to the conclusion that invoking BO Objects especially the ones that do an Update are broken. They yield incorrect results and have been forever. I couldn’t imagine a world without Custom Code you would be dead in the water for any serious customization.

But even more frustrating for the community that Epicor doesn’t mention “Before Image” in any of their guides or at Insights for a decade that I’ve been around.

Typical Behaviour when Epicor does an Update

It sends Modified Row with a RowMod “” (blank) and RowMod “U” which allows you to use conditions such as “If field changed from x to y” among other things.

When you use Widgets Epicor obviously never creates the “Before Image”. You can create it just fine when you do Custom Code.

var dsInvoice = bo.GetByID(row.InvoiceNum);
var originalRow = dsInvoice.InvcHead.NewRow();
BufferCopy.Copy(dsInvoice.InvcHead[0], originalRow);
dsInvoice.InvcHead.Add(originalRow);

You could probably do that with nightmarish widgets as well by cluttering your flow with a bunch of nonsense

In addition when Epicor does updates it sends only the tables modified to your PRE, when you do an Update via a Widget you get the entire dataset, which is fine - just keep in mind not to rely on that.

Lastly, Sometimes you need to do an Update in a POST and Epicor doesn’t have a Widget approach to ignoring facades but you can do that just fine in code and avoid the circular loop of death.

When you use Ice.Assemblies.ServiceRenderer.GetService(Db, true) you are also setting the ignoreFacade to true… What is a Facade in Epicor? Well if you use the ICE SDK and you create your own Business Objects you always create a SvcFacade.cs file which contains the required code for interacting with BPM… So by setting ignoreFacade to true you are basically saying… Do Not Trigger the “Update” BPM… perhaps you want it, but if you are in the Update already you would cause a loop.

Lets not even start with loops

Loops in Widgets are the worst.

Joining ttTable to Db Table

This is considered a crime and should be thought to be avoided at all costs.

Changed Includes Delete

In Epicor’s custom code guide they state that Changed = Add/Update but it also include Delete so you are better of using Added or Updated individually instead of Changed. Their Guide is wrong its not just Added or Updated.

Conclusion

I’ve done Custom Code for many years and have been giving Widgets a try lately, only to stumble upon limitations and limitations… For example RcvMisc.RowMod isn’t accessible via Set Field but you can set it fine via Custom Code. That among many other things simply seem not to be getting any love from Epicor.

Stuck in 1735

Also why are we still stuck on C# 6 compilation; can’t even use ValueTuple

---

What are your favorite widgets gotchas?

[utaylor (Utah Taylor)]

Haso, I had some this past year as I tried out using functions and tracing business processes.

I forgot to write them down and it would take me a minute to work back through the flow and understand it again, but I can say I agree with the looping aspect.

I wish we could loop somehow, but nah.

[utaylor (Utah Taylor)]

And Haso, I haven’t come across anything that needs the “Before Image” yet.

I’d like to experience this.

What business object method would you suggest I use to experience this?

[Mark_Wonsil]

@hkeric.wci

It sends Modified Row with a RowMod “” (blank) and RowMod “U” which allows you to use conditions such as “If field changed from x to y” among other things.

Was RowMod an Epicor idea? Doesn’t ADO .Net DataSets use RowState? Can’t we use RowState now too?

[hkeric.wci (Haso Keric)]

Wait there is more…

If you use a condition such as if abc changed from x to y… then the next condition can’t do it anymore… Epicor will strip the RowMod “” (blank) out - by filtering it out.

It’s @jgiese.wci favorite by design feature

[hkeric.wci (Haso Keric)]

@hkeric.wci

For example RcvMisc.RowMod isn’t accessible via Set Field but you can set it fine via Custom Code.

When you have to use Custom Code just for RowMod or the following BO doesnt work

[utaylor (Utah Taylor)]

I think I do have a custom code widget to set it to U if I recall correctly

[JasonMcD (Jason McDermott)]

@hkeric.wci

When you have to use Custom Code just for RowMod or the following BO doesnt work

I don’t know what you are talking about.

NOT a lost cause - a function for new labor dtl with no code

So #1, THANK YOU to @josecgomez and @Banderson for my new favorite post ever. From that discussion plus the Trace Parser, I actually made a function to create a labor transaction. I feel so smart! My one complaint, though, I had to use a custom code block to set the rowMod on the Submit method for the labor to be approved. Really? I did all of THAT with widgets and there’s no way for the submit method to work - ever - unless you throw some C# at it?! COME ON! [image] For posterity, the cod…

[hkeric.wci (Haso Keric)]

I see we have a Update Table By Query fan yikes

[utaylor (Utah Taylor)]

Yes hahaha, but it’s updating the dataset variable in the BPM, is that poor processing Haso?

This was one of the first times I tried tracing and doing a widget based replication of the trace.

[hkeric.wci (Haso Keric)]

It works but the code it generates is definitely slow. Wish they could just fix Set Field Until then I’ll keep using Custom Code (on prem).

[utaylor (Utah Taylor)]

Yeah, maybe that is the bug (design feature) that you were pointing out and that’s why I had to do the update by table widget over and over.

[utaylor (Utah Taylor)]

Haso I was trying anything to get the RowMod to stick and this finally worked so I don’t know what to say.

[JasonMcD (Jason McDermott)]

@hkeric.wci

I see we have a Update Table By Query fan

Man, even I gave up on widgets for the RowMod, and I am Mr. Anti-code. It’s actually EASIER to read

MyDataset.LaborDtl[0].RowMod= "U";

than it is to set up and troubleshoot the fill table widget.

[utaylor (Utah Taylor)]

Yeah I just was trying my hardest to not custom code.

[Mark_Wonsil]

Just to be clear, you’re replacing all of the those RowMod updates with a single Custom Code block or are we just swapping out Update by Query for a Code Block?

(Except for the poor old MT users, code blocks work in Public Cloud or Single Tenant. )

[jgiese.wci (Joshua Giese)]

@hkeric.wci

Epicor will strip the RowMod “” (blank) out - by filtering it out.

It’s @jgiese.wci favorite by design feature

I get it but I don’t like it lol! Oh well Enable Post Process for the win.

[SteveFossey]

Honestly, I’m an uneducated script kiddie and it wasn’t a big deal to go from “VBA for dummies” to “C# for dummies”. Okay, without this forum I’d have been dead but frankly, so would Epicor themselves.

It’s been tough to learn the principles and there are some gotchas but they could strip the widgets from the codebase tomorrow and we’d be fine. They really just make for impressive sales presentations to show managers who love flowcharts.

With Efx it’s even better, once you realize that @SAD is right - they’re never going to really document everything.

Speaking of flowcharts, one of the best things about c# is that managers think it’s terrifying - so before you start solving, you can more or less force them to actually map their processes and understand what they’re trying to change. This is an ongoing battle but easier with nothing visual to show them

[Aaron_Moreng]

I don’t know man, I think the closer Epicor can get to no/low code customization, the better they are going to sit in the marketplace. The ultimate goal of no/low code is to bring the technology closer to the unwashed masses.

This benefits the technical people by not bottlenecking the entire process into their to-do list. A tool to visually configure and orchestrate the business process automation is worth more than a bunch of complex code that only a developer can read and maintain. This is coming from someone who is indeed a developer and a manager.

It’s arguably more wise to use ones communication skills to garner understanding and implement successful technology (independent of a specific tool) across the organization rather than intimidate with the use of said tools. Complexity and skill in making a solution isn’t what makes it a good one; only in what it does for the business matters.
I would like of course to see every business process documented in a flowchart. Maybe someday

[TomAlexander]

@Aaron_Moreng

A tool to visually configure and orchestrate the business process automation is worth more than a bunch of complex code that only a developer can read and maintain

I do like what you’re saying overall, but I also think well written clean code is easier to read and maintain than widgets. With widgets, especially if you’re doing something complex, you are constantly clicking in and out of different expression editors and can only see one thing at a time. You have to hold so much in your working memory, it’s a nightmare. With custom code, everything is right there in front of you on one screen (ideally).