BPM/EFx are server-side stuff. It behaves as other server-side stuff works. In general, it behaves as the code of services. So the usual way here is different from the client-side way.
Again, trace shows client-to-server behavior. BPM works inside server and behaves like other server-side stuff.
What BeforeImage means? I do not know what it is
Some UD fields for example.
Just in caseā¦ Most likely, the ability to bypass facades will be removed in the future.
I agree that BPM and EFx need for-each functionality.
You make two mistakes simultaneously
The article is about extension method added to ICE by me ;). There are 4 method, Add(), Updated(), Deleted() and Unchanged(). So Unchanged() means !Added() && !Updated() && !Deleted(). And therefore !Unchanged() == Added() || Updated() || Deleted().
UI options are inherited from E9. And they have the original means. Actually, there is no relation between UI options and these extension methods.
As for me, the actual fix would be to switch to checkboxes
But I think that such changes have no chance to be implemented in windows client
Maybe, but without official requests, it is least likely possible.
Do you realize that Update methods do not support multiple modified rows in most cases? (in contrast with UpdateExt).
Only after moving the editing logic from client to server. This transition is very complex and expensive.
Improper comparison :). You create a complex query with multiple fields. It is not needed for updating a single field.
But, in general, I wanted to add Udpate Table widget similar to Update Table by Query, but without source query. But again, there were no feature requests for that.
And now, most likely, no one approves such functionality for the existing UI.
BeforeImage is when you are in a POST and you do GetByID and you make a change, before you call Update or UpdateMaster and sometimes other Methodsā¦ you need to create a copy of the row, basically your own RowMod āā blank and then you make changes to second copy of the row RowMod āUā.
If you donāt certain methods will fail, they kind of require both. Epicor uses this technique throughout all of their BPMs. Example from SDK
Do you not get to think for the users anymore you know those āour Customers would benefit from xā. Is it required now that you always have a request first?
Right, and thatās not a trivial distinction. I mean, a tech ref guide to BPM custom coding would be great, but I donāt see it ever happening, so itās widgets, baby!
Definitely, Iām correct I had to add this bloody stuff to the BPM on the late E10.0 development stage just because it works this way in E9 and this requirement was missed.
Actually, you need to remember that filtering is not applied to the directive variables. And completely disabled in EFx.
It is by design. By E9 design. Actually for directives where āwith ruleā setting is available (Standard DD and MD on services with multiple dirty row support) you can change rule from āmatchingā to āexistingā (sorry, donāt remember the exact name).
The thing is, there are like 50 people in the world who are wizards with Epicor widgets, and 50 million C# developers. For the company looking to hire someone to set up Epicor, the choice is clearā¦ if they have a choice at all.
Iām a professional developer (solution designer, architect) more than 30 years already.
And. definitely, code is a more native approach for me.
But widgets have a great benefit over the custom code blocks. They are upgrade-friendly. And it is a great benefit for the product customizations. Custom code is either hard to or even impossible to upgrade.
I do like widgets or coding in blocks, it also lets me visualize the BPM Flow better. I do appreciate your time SAD. I am not bashing widgets; actually I want to use them. But I feel like I canāt without cluttering my flow with āhacksā.
Because the APIs the code is using are mostly undocumented in the sense of not being published and supported. When they change, no thought is given to backward compatibility. Evolving an API in a backward compatible way is a burden, but a much smaller burden than figuring out how to upgrade code after a breaking change. The problem from Epicorās perspective is that they didnāt design these APIs to ever be supported. Supporting them would lock them in to their current design. And supporting them doesnāt align with their marketing.
Not only. For example BPM and EFx can be moved out of proc and start working with Epicor API via REST/gRPC/etc. In such a case, widgets will work after the upgrade. Custom codeā¦ Most likely does not.
BPM is not about the full-fledged coding approach. It is about low-code customization. And we tries (mostly successfully) to support backward compatibility for them.
Custom code is a kind of last resort. And upgradability of them is not guarantied.
One last note on UpdateExt. I do know it does Multiple. But we have stumbled plenty of time with it causing a Row has been modified by another userā¦ especially when we did alot of Service Connect. So switching to a loop and individually calling Update resolved many of those headaches.
I dont f with UpdateExt anymore I am all the way Update; lol
I do agree with you on so many things @SAD I hope that my bitching doesnt convey a negative image. I will try to make some Idea submissions and let them get evaluated.
As a full time Epicor developer; sometimes I feel like only Kinetic gets loved and everything else became second class citizen
I will for sure put the Set Field RowMod idea in
Also is there any plans to stop people from joining ttTable to DbTable.
Iāve actually never had custom code break after an upgrade. It would probably break if Epicor ever cleaned up their BO APIs in preparation for documenting and supporting them. I still wish they wouldā¦
I had to add this bloody stuff to the BPM on the late E10.0 development stage just because it works this way in E9 and this requirement was missed.
