This might be me not understanding the limits of the new kinetic architecture. Configurator User defined methods in Kinetic can only pass back one value via the return statement. You can’t use the “out” and “ref” modifier any longer. This means if I need 2 or more items I need to either package them up in a delimited string or build separate methods for each item. No longer can I do GetSomeThings(partNum, out weight, out cost, out prodCode);
Support says this is by design.
@Jkinneman , our CAM advised us of this change so I added it to the pile of reasons we’re not using the Kinetic Configurator.
I’ve concluded that we’ll have to start over in Kinetic. Converting an existing configurator, unless it’s very simple, just isn’t worth it.
I should add that I’m actually very excited about the Kinetic Configurator. Once it’s fully baked, it will be a big step forward. It just needs more time in the oven.
What aspects do you think will be a big step forward? I’m trying to decide if I even want to remake my configurators in Kinetic or just put as much as possible into Epicor functions and then do the rest outside E11 as a stand alone app that calls my functions via REST api.
I fully agree that this is the direction Epicor has to go. 100% browser is a given in today’s world. The configurator has always been a different world compared to other screens so what is normal behavior in the configurator might be counter to how something works in a typical screen like Order Entry. The concept of “pages” doesn’t always match with “tabs” and the like. Communication across pages may be incomplete based on a recent ticket I opened.
The configurator pretty much wants to see things in a synchronous world so the natural asynchronous behavior gets in the way sometimes. Hence the need for “await”. Someone that routinely builds Kinetic screens like Order Entry might not understand the configurator concepts and I think that shows in how the Kinetic Configurator behaves vs Classic Configurator.
Having worked with the configurator across Epicor 8,9,10 and Kinetic the configurator has always lagged behind with the new releases.
So far I have yet to release a Kinetic version for client use. My latest attempt resulted in at least 4 tickets.
With that said Epicor will get it there, soon I hope.
As to rolling your own even with the quarks of the Kinetic Configurator I think that will be more work than it is worth. I’ll mumble under my breath about it but I’ll figure out a structured solution to the out/ref issue.
I am having the same issue with converting UD methods. I simply ask for the sales price of the partnumber to be returned (out) on my UDMethod and the ref is the partnum. I noticed that you said “but I’ll figure out a structured solution to the out/ref issue.”
Have you figured it out yet?
I handle it one of two ways.
Using a string array and then convert anything i need.
I have also passed back a Json string which I convert back into a data table on the calling side, this is when I have a lot of data to pass back. For example I use a data table to store all the MOM related items. Then each material MOM rule queries this table to find the related information it needs. The code is identical for each rule as the query just needs to know which material sequence is asking for its information.