Are Epicor Widgets Broken? 🤐

[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).

[Aaron_Moreng]

almost sounds like a widget problem more than anything

[KevinK (Kevin Krumwiede)]

Agreed, more than a couple widgets rapidly becomes a nightmare. If you can read and write code, code is vastly simpler. I think that teaching users to code is a simpler problem than developing a widget language that is anywhere near as expressive as code.