Are Epicor Widgets Broken? 🤐

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

[hkeric.wci (Haso Keric)]

I used an ETL such as Service Connect, Jitterbit & Mulesoft in the past… we just did our own proxy (process API) in .NET Core… so much simpler and so much more flexible for free. Coding nowadays with what the framework provides is no harder than figuring out the pesky widgets and working around limitations. Not specific to Epicor but MuleSoft has widgets and limitations.

We are not writing C++ Code and have to learn pointers and memory allocation. Can’t do C#… use python… powershell whatever.

Also the idea of someone with no IT or Technical Coding skill trying to make sense of widgets lets just say HTTP Status Codes… do you want to do a GET, PUT, PATCH, DELETE, OPTIONS, HEAD… it’s not really meant for the non-techie. Do you want your JSON Payload to be serialized, how do you want to handle a 404, 503, 400… I would still have a developer use the tool who understands what happens behind the scenes. No-Code is a buzz word

[utaylor (Utah Taylor)]

I prefer “Low-Code”

[carlosqt (Carlos Quintanilla)]

A BPM using more than 2-4 widgets is simply infamous.

[SteveFossey]

@Aaron_Moreng

I would like of course to see every business process documented in a flowchart.

Yeh… no. As Quality Manager of a newly-minted OEM automotive supplier, I tried aiming for that - but for modern applications we have to be more dynamic than that allows. I just want people to use tools to stop and think, and the closer they get to rapidly deploying new solutions, the less usable those solutions seem to be.

At the same time, I get the low-code / no-code idea too (I do build WordPress sites fairly regularly). I’m more just interested in a tool to manage solutions than a tool to easily create them. At that point hoi polloi can develop whatever they want, provided security is built in and conflict is managed (so, not something like what DMT does to replace SQL)

[Mark_Wonsil]

@Aaron_Moreng

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.

I have to agree with you here. Coders will code and that’s great but unless you’re a software company, we’re not adding much value to the organization unless we understand the domain of the business. If we can make the domain experts more efficient with the system, great. Maybe these widgets are still too “code-like” but something like Aaron is suggesting sounds good to me.

[SAD (Sergey Davydkin)]

@hkeric.wci

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

You just don’t know how to cook them (с)

@hkeric.wci

In addition when Epicor does updates it sends only the tables modified to your PRE, when you do an

1. It occurs only when a smart client proxy is used (probably web-ui was updated to support this mode too). Calls via REST, Service Renderer, naked service-methods do not have such ‘magic’
2. This behavior has no relation to PRE (or any other BPM-specific things). It is just about client-to-server call convention.
3. Also, ‘Epicor’ sends not only the updated tables but all parent rows for modified rows.
4. All above is true only for tableset parameters with ref modifier. In the case of ‘normal’ parameters, even client proxies send whole tablesets.

@hkeric.wci

Not Trigger the “Update” BPM… perhaps you want it, but if you are in the Update already you would cause a loop.

It is a bad idea to bypass facades. In general, this parameter is for infrastructure only. If you call Updated from Update, you just need to make your code self-protected.

@hkeric.wci

Loops in Widgets are the worst.

1. Just in case, loops are not supported officially. And validation explicitly says about that.
2. They are not blocked, since they work in general. But you have to clearly understand how Epicor logic works to implement complex cases.

@hkeric.wci

Added or Updated individually instead of Changed. Their Guide is wrong its not just Added or Updated.

Could you please point me to the exact place in the guide? Changed == Add|Updated|Deleted since E9 (AFAIR).

@hkeric.wci

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

Direct modification of RowMod column is dangerous. The whole Epicor business logic relies on it.
Most likely, Set Field widget restricts access to it, since the widget came from the time when only parameter “tables” were supported. And RowMod in such tables should not be changed ever.

Also, if you need this functionality in Set Field, did you create a feature request?

@hkeric.wci

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

ValueTuple? With such a huge number of fields? In iterable result? Not a good idea.
Regarding C# 6 -

1. we never promised that we will support never version of C# in BPM/EFx.
2. you can treat it as Epicor dialect of C#.

[SAD (Sergey Davydkin)]

@Mark_Wonsil

Was RowMod an Epicor idea?

Yes, this hmm… strange feature came from E9 (and probably from earlier versions). I think it legacy of Progress ABL. But since all business logic is based on it, it cannot be removed

@Mark_Wonsil

Doesn’t ADO .Net DataSets use RowState? Can’t we use RowState now too?

RowState is the DataSet feature. Epicor server-side logic does not use DataSets, it uses Tablesets. And these types have no RowState.

[SAD (Sergey Davydkin)]

@hkeric.wci

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.

Wrong. Filter works only for the True exit, and only till the next condition widget.

[SAD (Sergey Davydkin)]

@hkeric.wci

It works but the code it generates is definitely slow.

Proofs?

[hkeric.wci (Haso Keric)]

I appreciate the conversation!

1. It occurs only when a smart client proxy is used (probably web-ui was updated to support this mode too). Calls via REST, Service Renderer, naked service-methods do not have such ‘magic’
2. This behavior has no relation to PRE (or any other BPM-specific things). It is just about client-to-server call convention.
3. Also, ‘Epicor’ sends not only the updated tables but all parent rows for modified rows.
4. All above is true only for tableset parameters with ref modifier. In the case of ‘normal’ parameters, even client proxies send whole tablesets.

I understand that, I am not complaining that Epicor does it that way. I love it that way. I was pointing out that when you use a Widget in a POST and you invoke the same Update method you get different outcomes which dont align with Epicor’s usual way, when the Facade is called, you get different behaviour than what Epicor usually would do from Smart client; not to rely on that.

For example I’ve seen folks do if (ttOrderDtl.Any()) { ... } when a ipTableName isn’t present they check if the ds has that table to indicate its probably a OrderDtl update. That is what the Epicor trace showed them. But little did they know is that calling Update from a POST or Service Connect would mess up their PRE since it would send ttOrderDtl, ttOrderRel, ttOrderWhatever - just be cautious id say.

In addition since it doesnt include a BeforeImage when your facade fires the following would for example not work:

The saying Just do a trace and you will know what Epicor does and repeat it isn’t necessarily accurate if one thinks the behavior will be the exact same, atleast when using built-in widgets vs Custom Code.

It is a bad idea to bypass facades. In general, this parameter is for infrastructure only. If you call Updated from Update, you just need to make your code self-protected.

What other fields besides callContextBpmData can one use, they are as dangerous once you start using them they can be overwritten by other BPMs.

Also if you have 10 PRE BPMs you would need to add a gatekeeper to all of them, instead of ignoring the facade.

1. Just in case, loops are not supported officially. And validation explicitly says about that.
2. They are not blocked, since they work in general. But you have to clearly understand how Epicor logic works to implement complex cases.

Something as simple as Loop through all OrderDtl and Update a OrderRel column with a datestamp isn’t a complex case.

I know they are not supported officially; is there a reason the BPM Customization tools have been stale for a while now. If I took a poll how many people have used a foreach loop in their BPMs im sure 90% would say they have.

Could you please point me to the exact place in the guide? Changed == Add|Updated|Deleted since E9 (AFAIR).

Since Changed is actually !Unchanged when the code is generated, based on that Guide we all started off with when coming off E9 to E10 - it was taken was !Unchanged() is Added or Updated.

Here is an actual BPM that I have currently have in Production that would exception on Delete:

The fix is to have a condition before that to check for Added or Updated or maybe add an option so we can select Added || Updated in the dropdown

Direct modification of RowMod column is dangerous. The whole Epicor business logic relies on it.
Most likely, Set Field widget restricts access to it, since the widget came from the time when only parameter “tables” were supported. And RowMod in such tables should not be changed ever.

Also, if you need this functionality in Set Field, did you create a feature request?

An example where you always have to set RowMod to U is pretty much on many OnChangeSomething methods. Maybe its time to support RowMod U so folks can use Business Logic and not always go to UpdateExt

Many of the OnChangeSomething check for !string.IsNullOrEmpty(Row.RowMod) you must be able to set it, dangerous or not.

1. we never promised that we will support never version of C# in BPM/EFx.
2. you can treat it as Epicor dialect of C#.

Are there any plans to support some newer C#? Yeah you never promised it I am not saying you did; but why do we have to be so far behind. Maybe something like a FeatureFlag to set CompilerServices language version, wouldn’t be bad.

[hkeric.wci (Haso Keric)]

@SAD

Proofs?

Without even a stop-watch can we assume that this:

Is not faster than:

Now imagine doing the UpdateTableByQuery 10x

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

@JasonMcD thanks for the inspiration yesterday. I finished a BPM on ABCCode.Update Post processing that transfers 10 units of inventory from one warehouse bin to another. I hardcoded everything that would normally be put in by a user (dynamic data) such as part number, warehouse, lot, etc… I am still learning how it all fits together. I also don’t think I am doing the row mod update correctly, do I really need to add it before each call? [image] What I wanted to ask you @JasonMcD is what y…

Is it slow by minutes? No… maybe 100ms maybe 1500ms.

[hkeric.wci (Haso Keric)]

@SAD

Wrong. Filter works only for the True exit, and only till the next condition widget.

You are correct. I was wrong. Not sure if I recalled this from the past using Custom Code after a Condition.

For sure trying to access Unchanged row in Custom Code after a condition won’t work… but you do that rarely anyways. Condition after Custom Code or a Chained Condition works fine.

[JasonMcD (Jason McDermott)]

@JasonMcD

even I gave up on widgets for the RowMod

So, I know the hypocrisy that I am about to engage in as I go on to defend us low-coders, but I think that’s the idea, is that it should be as LOW code as possible, and preferably all widget-able.

@KevinK

If you can read and write code, code is vastly simpler. I think that teaching users to code is a simpler problem

I agree with this in a non-object-oriented language. I can do a VBA macro for Excel pretty easily and there is a ton of info out there for it.

But wow, do I disagree when it comes to BPMs.

Look, there is simply no manual that exists that explains how Epicor business objects tie into C# programming.

Those of you with insane programming backgrounds, I think you just can’t see the colossal leap that it takes to go from “I want to do this” to “Did you use the right adapter?”

What on earth is an adapter?! Where is that in the trace logs?

Like, the barrier to entry from “I see this happening in the UI” to “this is the code you need” is so steep! It is not a 20-hour cram sesh to become an expert. I do agree with that philosophy on a lot of things; I have done that repeatedly over the years. But BPM coding is not one of those 20-hour things; it is a like a college major or at least a minor.

Widgets are really wonderful. I have done so much with them over the last year. And I also totally agree with @hkeric.wci 's criticisms (the ones I understood).

But abandoning widgets because it’s “simple” to learn how to code BPMs, that is not the answer.

[TomAlexander]

@JasonMcD

there is simply no manual that exists that explains how Epicor business objects tie into C# programming

There kind of is one… If you look at the code that gets generated when you use widgets, it is a great way to learn. Haso was just posting about this in another thread.

[hkeric.wci (Haso Keric)]

Here is one that scares me the most… Many people who use widgets join ttTable to RealTable little do they know is that it brings the entire RealTable into memory.

Its just natural to use the Compose Query that way

Joining "TT" records to regular DB records in BPMs

I am opening up this topic, because it was raised at #Insights2018. Please join in on the discussion if you have examples that prove this wrong!!! I just want to curb any urban legend that may be building out in the community based on misunderstood ideas. There was a recommendation made during one of the sessions that JOINING a TT record to a regular database record was bad practice. Instead of joining, you should simply add conditions in your query for any of those links between TT and non-TT…

[KevinK (Kevin Krumwiede)]

@JasonMcD

Look, there is simply no manual that exists that explains how Epicor business objects tie into C# programming.

You’re quite right about that. But this is an Epicor thing, not a coding thing. Epicor’s documentation is basically non-existent compared to what developers are used to on other platforms. Working with Epicor gives me flashbacks to the early '90s. But despite this, if you already live and breathe C#, widgets feel even more restrictive than coding blind.

[JasonMcD (Jason McDermott)]

@TomAlexander

If you look at the code that gets generated when you use widgets

Ooh… not a fan already… I mean, the widget version of this was not hard…

But, I did not know (or really, did not appreciate) this ability till you mentioned it.

[SteveFossey]

@JasonMcD

It is not a 20-hour cram sesh

Oi! I’m right here, you know!

Just kidding, you’re right to some extent - in my case though it was 20 hours to figure out oTrans (ui) use, another 20 for ServiceRenderer(BPM) , and 20 for CallService(efx). Probably another 20 for each building block in Epicor, and as far as I can tell there are 32 building blocks. So about 600 hours of actual development (not just “work”) and Bob’s your proverbial uncle.

The thing is, I went well over 20 on widgets and got frustrated with the lack of visibility of what was going wrong, and decided I’d do better learning C# but that was at the very beginning.

Thanks @SAD and @hkeric.wci and everyone else for livening up this thread, very informative. Sounds like Epicor better keep both and improve both systems…