@Mark_Wonsil.
I just realized I was trying to pass credentials in the Params section instead of the authorization section…happy second Monday?
I can get PostMan to Pull that query pretty fast without any issues, which means that the dynamic get section of code seems to be the problem. Are there better ways of getting the data compared to the following:
Seriously though, thanks for all the help Mark!
Was the nuget package updated? (Maybe a bug in DynamicGet)
Was epicor updated just before the error started? (A bug in Epicor, if possible enable server logging and see if the errors appear there)
Can you try a system baq or a new but simpler baq instead of APOTool2? (Maybe something specific to this BAQ causes the error?
If nothing works maybe @josecgomez has more ideas 
I updated the nuget package earlier, should be up to date. We haven’t had an upgrade recently, at least not since this last worked. As for trying another baq it exits with code 0… not sure what that means. Thanks for the insight!
As far as performance goes, I’ll leave that to @josecgomez and @jgiese.wci as they are the authors behind that library and know how to make it sing.
Quick note about Basic Authentication. As you see, the username and password is encoded but not one way. This is why Epicor requires us to have certs protecting the traffic. Any persistent threat on your network will be looking for Basic Auth headers going by to pick out credentials and grab any API-Keys. Eventually, you’ll want to get to token access. It’s documented in the REST guide but I’m pretty sure the NuGet package does it too.
Dylan
What version of the nugget are you using?
There is a RestLog property that you can look at that can tell you more info
Anything there in the RestLog property?
@Mark_Wonsil,
This is the first I’m hearing of a token option. I will have to dig into that. Do you have the Rest guide notes handy?
@josecgomez,
I am currently using v1.1.11 of the EpicorRestAPI. I see a RESTLOG option in the code. What would be the optimum placement for a Restlog statement to go, before the line causing the error, on the line causing the error, or after? Also, what would the RestLog statement look like?
Thanks to all of you helping with this!
Hi Dylan
It’s just a log all you need to do is look at it as it runs
Either print it’s result or put a break right after the error and take a look at that property
It will contain the whole request response etc
Actually @dgreenEA I just ran into an issue this morning that may be related…
I was having weird errors in REST myself and then I realized the account (user account) I was using had been logged on to the wrong COMPANY
So my REST calls I wasn’t explicitly indicating which company via the CallSettings header, now it couldn’t find a BAQ that used to be there…
So… give that a shot, set your CallSettings header and see if that makes things better.
Example Here:
Under the license example notice how I set the CallSettings header to company EPIC03
That helped a little bit. I still get the following error if I let the baq run wide open.
But it happens at the 1 minute 40 seconds mark every time. If I cut the data in half it seems to work properly now. Any idea why that seems to be happening?
OK Dylan, time to spill the beans. What are you trying to do accomplish - from a business perspective? The REST architecture is about changing state via http. The work should be done at the server and not the client. So maybe there’s some tweaks to your process that will reduce the request to fewer than 100 seconds.
I am pulling all PO’s that have not been invoiced via the rest and exporting them in a csv file. Formatting them to fit the needs of our cardholder and sending them to their file import system to be uploaded and processed.
The end goal of this program was to schedule it to run on a server thus automating the process.
As for what all we can do from a logic standpoint on the baq I’m trying to reduce the number of tables it touches.
How long does the BAQ run when run within Epicor?
18 seconds seems long let alone 3 minutes. Maybe we can cut that down a bit.
If not, it sounds better to run as a task and then retrieve the results by REST once ready.
Oh I’m guessing its just timing you, pass in a top clause and a next (basically paginate the request)
RestSharp is using HttpWebRequest under the hood, which has a default timeout of 100 seconds.
So that’s why it’s dying near or around a minute and change…
Let me see if I can expose the timeout for you, however that just seems like a query that takes too long to run you should paginate it.
Try passing in inline count parameter to get a total count of your items then use top, skip to loop through the request
Dictionary<string, string> dic = new Dictionary<string, string>();
dic.add("$top", "100);
dic.add("$inlinecount", "allpages);
EpicorRest.DynamicGet("BaqSvc", "APOTool2", dic);
That returns a new value in your result called odata.count
Which you can then use along with $top and $skip to re-run the query in pieces until you get all your results.
I’ll release a new copy of the library with the option to set the timeout. But you should fix the query instead or use paging either way
@josecgomez, @Mark_Wonsil, @Jonathan,
Gentlemen, you’re the best! I was able to get the timings fixed on my baq and added the section in the header that points to the proper company. I believe that everything is now working as it should, and it doesn’t time out after 1 minute 40 seconds any more! Thank you all for the assist!! Thumbs up for all, solution to Jose.
Hi Jose,
I have the same problem with timeout, and I use the latest version of API but i not found how set timeout.
please can send me the name of option for timeut settings?
Thanks
Massimo
