Multiple topics here so I hope to catch them all. Some aspects will be safe harbor, look ahead so if you don’t want to consider that skip ahead to a different topic…
The reflection discussion is a bit misleading. As @josecgomez is known to do, he has done some reflection into private code and doing some tricks in Functions for his scenarios. I am fine with HIM doing that to pull off some tricks in Functions because when the private variables change and break his code, he can update that rather quickly because he is Jose. For normal humans, I would warn away from that approach until ERP 10 adds some ease of use APIs for making calling not alone Functions but REST in general a lot easier and stable from release to release. This did not make the 500 deadline and while I cannot guarantee delivery in vNext, its an obvious feature to add. You saw that safe harbor above right?
As @jgiese.wci described above, calling a REST or more specifically an http URL is pretty straight forward and there are a variety of APIs to leverage. Choose your favorite one for on-premise or your cloud flavor and go forth and REST. The tricky part will be authentication. Grabbing the users credentials and sending them along to the server as we are all used to doing in Session or a BO call from client customization. That’s all prettied up and you don’t think about it too much when doing customizations. If you want to do this today in client customization, Configurator, etc you need to make some choices. You can do something bad like hard coding an existing username/password (please don’t do that). You can be running Windows Auth so just grab the context of the process and pass that thru. You can leverage the Token authentication approach and grab a token from the token service and leverage that.
This is all in the category of possible but with trade offs and a little more technical than it should be at this time. As mentioned in the original post, there are some rough edges in the features versus something like BPM that has been there for 15+ years. Give us at least a second release before tossing out the feature as hard to use
Wrapping this up, I asked for feedback. There is a lot of functionality here and even more ideas from within the Epicor walls. Which comes first? That’s where you all come in. Continue to kick the tires and share your pain points and needs. We are listening…
So here is one situation that had me looking at Epicor Functions hopefully:
We have a custom built quoting tool that we couldn’t make as a configurator. It uses libraries for polygon clipping & Boolean operations, a library for operating with DXF files, and another for creating PDFs. The customer supplies information about their machine and the program produces a drawing and quote for a product that will fit in their machine. The information is added to the quote via REST.
Management now wants to add an web store were users can provide this information and order the product immediately. We are looking at ECC. Our existing tool will not work with ECC.
First idea that occurs to me is to reverse the direction, instead of pushing information into Epicor, pull it in. If I could have a configurator that takes the inputs and passed them to the tool, than it could work with ECC.
I was hoping that Epicor Functions would allow me to get the information out of a configurator to an external tool, but it seems like the answer is not yet? What would be the correct approach in this case?
A ‘Global UDMethod’ or a dozen other names people have brainstormed has been requested for some time in Configurator. The ability to have a common piece of logic across configurators is something being reviewed.
I am not an expert in Configurator or ECC but if the data you need is in there or elsewhere in the system in Parts, etc then you can create your ‘orchestration’ logic in a function.
Gather all the data from various data sources with the ability to do some logic and present one service of the tailored information you need. If it was just data a BAQ would be possibly enough to query. If you have increased needs to apply some logic over the data and orchestration of several services and db data… those kinds of scenarios are where Functions will play nicely.
It sounds like from what you are saying, making a configurator that makes a REST call to my custom tool with the needed data is the right approach. But I don’t see any way to do this as a MT SaaS user.
Yes, SaaS MT has some limitations as to how little coding is supported. That’s a different sales conversation of cost versus benefit.
If you do need the flexibility of a Public Cloud (new name for DT), you can chat with your CAM about moving to that option in Cloud instead. You can still create Functions in MT. You are just restricted to using widgets, no code. You can do a lot in those widgets so don’t dismiss immediately.
BAQ access to Configurator Data is coming along slower than I had expected. Dev resources have been focused on some of the newer capabilities like the Epicor Functions and getting time for other items has proven difficult. That said, access to the raw XML Configurator data via a BAQ is included in 10.2.500 - Table name Erp.PcValueSet.
I am also trying to wedge in some time to allow a SQL view - Erp.PcInputValue for your purposes - to be included as an option in the standard BAQ designer. If all goes well, you may see that as soon as 10.2.500.5. As we get a little closer to having that I will contact you to see if you would like to preview…
Thanks @rich! Seriously, we appreciate it. This week I was on a reference call for a company who are configurator users and they are interested in moving to the cloud but are a little concerned that they might not be able to get to their PC input data. They would go live on .500, so this is great news.
Once done, I can see some nice EDD analysis for the sales reps to show…
@Rich - Echoing @Mark_Wonsil’s words - THANK YOU!! We’ve been waiting for a long time for this - and so have others. I’ve got come serious table-regenerating scripts that run daily to build UD tables full of Config data (using that little SQL view that was already in the DB) so we can use it in BAQs - and now I might be able to get rid of all that overhead.
And allowing SQL views to be used in the BAQ - that would be so very helpful! I’ll up-vote that for sure!!
@Aaron_Moreng nothing to announce yet but REST assured we are looking at options (Pun intended - @Mark_Wonsil is a horrible influence). This is something we need internally (CSF, CSG, Industry verticals) so I hear the audience feedback well…
EFX question on 600.3. It does not seem possible to call a function from another within the same library. Is that accurate or am I missing something? @SAD wasn’t sure if you had any input on that topic.
Sorry, I literally have no time to read forum (and Yammer too).
However, regarding this specific question I can provide exact answer… No, EFx does not support calling functions from the same library with a caller. It still is in roadmap, but not for near future.
This feature requires quite a lot of additional code, especially in UI.
