Reflection is banned*, and if you try to circumvent it by coding directly in the xml file importing is blocked… I have tried.
How can I make REST calls from a configrator?
I’m not super familiar with configurator but if you can use custom code at all you would be able to make the rest call. This sort of thing
var client = new RestClient("http://{{Host}}/api/v1/Erp.Bo.SalesOrderSvc/SalesOrders");
var request = new RestRequest(Method.GET);
request.AddHeader("Postman-Token", "c55691ca-dbaf-4a4b-ac3f-726a205091cc");
request.AddHeader("cache-control", "no-cache");
request.AddHeader("Authorization", "Basic [token]=");
request.AddHeader("Content-Type", "application/json");
IRestResponse response = client.Execute(request);
Custom code is allowed on client side, but only base c#, no references. I could do that in a customization but not a configurator. There is a web browser control though, I wonder if I could hack that to make REST calls.
lame
I hope that it’s vNext. Configurator is a big UD Method/Function user base. I curious to know what the Kinetic configurator is going to look like. 
Separately, I’m wondering when we’ll get BAQ access to PCInputValues. (Pinging @Rich) I just lost configured opportunities to SalesForce because I can’t report on it. I’m holding them back but it’s just a matter of time before we have two part configurators to maintain. 
Yes, I was very excited when I saw the thread title as I hoped it would help solve some of the painful configurator organization / restriction issues I have.
You don’t happen to use ECC with your configurators do you? If so could you take a look at this thread?
Sorry. We do not use ECC. Nobody puts a million dollar metrology solution into a shopping cart. 
@Mark_Wonsil - I thought we discussed this. There is a way if you can use an external query that redirects back into your E10 DB and uses the view that Epicor provided. Can you do that with your current cloud situation?
It looks like even us MT users are allowed to use custom code in these new functions…
DB access is limited to read only – does that mean we can still update the database through BO’s or is it totally locked down so that you can’t even update via BO’s?
I don’t know about DT, but I can’t create external BAQ’s at all.
Can call BOs as usual. There isn’t the standard DB context available with the way functions are designed so it limits those options. It makes sense functions could conceivably be called where there is not context.
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…
Bart,
So here is one situation that had me looking at Epicor Functions hopefully:
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.
Hey Mark -
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…
@Bart_Elia is getting an EUG Webinar Guernsey on 30 October on Fuctions. So if you are a member it might be worth tuning in.
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…