Once you got your rows the way you are now how did you plan to foreach them in widgets, and update the order rels?
Other option could be on Post GetList of the BAQ (as an updatable) loop the records and do your updates there and just schedule the BAQ. That’s how I would have done it pre-functions
Fill a temp table with your BAQ then use the Update By Query widget.
Learn basic code unless you want this hot mess lol. Old dogs can learn new tricks I promise you! Look at @Mark_Wonsil he’s ancient and out here kicking ass!
Update Table by Query, no?
Actually, there’s a SalesOrder.ChangeMake method that’s used in the trace. That might be all we need.
So, the “fill a temp table with a BAQ” step is foreign to me… What would that look like?
In the Fill Table By Query widget, I see I need
Yeah it’s kind of my thing to resist.
Sure but you suffer performance which was the initial complaint. Old simple example of some of the difference between Custom Code and Widget bastardization. @hkeric.wci examples generate the same result, one with a lot less CPU labor
Widgets are there to tailor not develop custom solutions. You’re trying to develop a new scheduled process not alter an existing epicor process. That’s sort of where I draw the line on widgets mentally.
… tailor (look at me using the new Epicor lingo, I’m Bougie like that)
FYI, I finished up this draft, and it does work, actually updating the releases that I wanted.
If you ignore the middle 4 troubleshooting widgets, this is mighty simple. 5 widgets including Start and setting the EmptyString variable - which was probably pointless in itself.
I did not use the ChangeMake method like the trace did. That does make me nervous… But I couldn’t get it to work. It constantly errored out.
The 2.3 minutes is lousy, sure. But again, I see it as the 1000+ orders and lines that bog it down.
This will run at night, once per night, so I’ll live. I’m just irritated that it’s inefficient.
That’s a brilliant delineation. I’d never thought of it that way. Thanks for succinctness!
I sent @JasonMcD a solution offline. The only reason he wanted a Function was to schedule his process. Stepping back, what he’s trying to do we should be able to do with a UBAQ to update the Make flag on OrderRel lines that meet a certain condition. He’s demonstrated the speed of the BAQ already, now he needs to execute it on a schedule. So, we created a function that has only one widget: Invoke-Business Object and that BO is the DynamicQuery. The UABQ returns the affected records, so would could add a new widget to email them, log them, whatever.
I’m not against using code whatsoever. There are just some things that are very difficult or impossible in widgets. But code makes some things difficult too, like upgrades. Josh had to create a utility to help him find all the code embedded in their solutions which makes it easier to manage. Having a way to save various custom objects in source control would work too…cough cough. Any public company should review all code widgets for SOX compliance and have compensating controls around the code’s purpose.
All that to say, some people are coders and are going to start out of the box with a code widget. Others are going to try to stick to widgets. I guess the takeaway is knowing what is the problem that we are trying to solve and to choose a combination of tools that is easy to manage over time.
If they would just make a looping widget to be able to handle a dataset (like automation studio does…) it would negate the need for a lot of custom code. Really that’s were code works better is it can loop on a dataset a lot easier.
BUT, I’ve also had widgets break in upgrades @Mark_Wonsil , so I don’t think I subscribe to the “Widgets are upgrade proof” theology. If they change the method parameter, you need to fix it on the widget the same as you would have to do in code. And some methods simply don’t work with the widgets because not all of the methods are consistent with how they handle the data set (I’m looking at you row mods), and some just don’t work at all.
Of course I can’t come up with any of the examples my anecdotal evidence is talking about because my memory for those specifics is mush. But I do know it’s happened to me.
If you use the epicor BO’s in code, and not some weird reflection, or just going wild with DB updates, code upgrades as well as widgets in my opinion.
steps of soapbox and hands it back to @Mark_Wonsil 
Hearty agreement there. That is my biggest wall I run into over and over.
Yep. Ran into that the other day. RowMod refused to be set except with a C# block.
Oh, nor do I. Widgets are code generators and there are errors to be had there too! Widget will be good for changes in syntax changes or implementing more efficient code with newer versions of supporting software. (You guys would have loved to have a widget when MS renamed invoke to Invoke for example.) However, the find all methods used for a particular Business object is super easy with widgets.
Exactly.
Completely agree. I would like something that was functional (like LINQ). As a really effing old coder, I am constantly fighting the urge to do everything in an iterative manner. These new functional languages (like F#, etc.) have features that are seeping into C# that make me look at loops differently.
Also, It would be nice to declare generic collections like Lists, Dictionaries, to use as inputs to widgets. This might be a nice back door to get some iteration. 
Interesting. I started writing reporting and queries and so forth, so functional programming is feels a lot like the set theory stuff I’m used to. I’m constantly having to remind myself “oh, yeah, I need to loop through that.”
I use widgets first, I’ll use code IF I have a snippet that can be modified to suit.
There is “the right tool for the job”, but there is also “the tool I am comfortable using”. I don’t use a chainsaw… I know how, I’ve used them before, but I’m less comfortable doing so now. If I have a situation where a chain saw is required, I ask a friend or hire somebody.
Luckily, if I have a situation where more advanced code is required, my company has a Development team.
And this is Epicor. At the version upgrade level, all bets are off. Some may be more off than others, but they’re still all off.
Oh, add multiple lines (Actions) to the “Set Argument/Variable” widget! We don’t need a widget for every single assignment.
Oh my word, yes.
This alone probably makes most people abandon widgets. Talk about obnoxious repetitive tasks with no value-add.
I would have thought that idea was already out there.
And why isn’t there a looping one? (@JasonMcD , you have an assignment)
Really, for Epicors push into “No code for you!” it seems like they’ve given up on improving the widgets much.
I miss all the fun stuff lately. 
I feel like this is a good time to bring up my status quote Maslow’s Law of Hammer
Widgets have a purpose and so does code right tool for the right job just because you can use one or the other it doesn’t mean they are the right tool.
Widgets can’t natively loop through a dataset and they impose a not insignificant performance burden. So for complex (read requires looping or mass updating) they are NOT the right tool 
