Anyone got a magic way to find all the places these services are called from within ERP?

One more tool to learn, thanks Chance. It looks pretty cool.

I just don’t know how to use it in the least bit!

SalesOrder.GetRows could easily just be the Epicor client itself.

Be careful if this is a live server, but enabling logging, or enabling some additional log components, ought to help track down where these calls are coming from.

The SQL query is tougher to place, instinct isn’t telling me if it smells like Epicor vs a dashboard query!

So that’s kinda what I am trying to boil it down to. Do you think a tracker could call something like that though?

I mean look at the services being called, all sales order related, and then look at the query… I didn’t do any tracing on orderdtl table in sql to see what queries were being called there.

If it was a query though it would look like this in stack trace

Hey @utaylor, my first suspicion would be that a user created a BAQ gadget tile and has the refresh interval set to 1 minute, since that’s the default interval (and who doesn’t want their BAQ to refresh every minute anyway!). Just something to check, but unfortunately, the “Where Used” functionality in the BAQ Designer doesn’t consider the gadget tile usage.

I would go to your Server folder and open up AppServer.config and enable more tracing/profiling options:

It doesn’t require a IIS reset, it is instantly turned on/off. Then monitor your ServerLog .txt files for more information, also the PDT tool can parse several of these and display them, if you get Notepad confused.

You can only enable them via Notepad, the Admin Console doesn’t have UI options for many of these.

I would start there, enable more diagnostics.

1 Like

If it was a baq though scott I would see the BAQDynamicQuery object being called in stack trace, wouldn’t I?

I never look at any of the tile functionality in Epicor because quite frankly it’s not my cup of tea, it bugs me a lot. Can you create a tile like that in 10.2.500. I have no clue who would even know how to do that scott.

Haso, any downside in performance if I enable these?

Of course, but you enable a few at a time and don’t enable all - for a period of time… I mean we have several always enabled in production.

Try
trace://ice/fw/servicecaller
trace://ice/fw/restapi
profile://ice/fw/tableset

1 Like

I guess to me I’m asking which specific flags would make the most sense.

I’ll dig up the sysadmin tech ref guide and see if they address what each of these flags are doing.

See which one gives you enough info to figure out the origins… For example if you enable:
trace://ice/fw/servicecaller
trace://ice/fw/restapi
profile://ice/fw/tableset

You might find out its a REST Call causing it. :slight_smile: Try a few.

1 Like

Alright, trying in my dev environment.

You say the same query is happening over and over. Does it always reference the same OrderNum?

If so, I’d look into what’s possibly touching/reading that order. I see the tables: JobProd, PartPlant, FSRenewal referenced. Look at things that could need that info.

I know its not as good a method as actually using profiling and tracing, as those could be applied to any other future investigation, but it might get to your problem quicker.

Nah, different orders all for the same customer though… :face_with_monocle:

recalculating credit limit/usage?

Hmmmmmmmm. Doesn’t explain the weird query, but maybe!

How about turning on change logs for the Customer table, along with some suspect fields, and include one of the “changed on” dates? That should user stamp it, and let you dig more if it’s a PICNIC source.

We don’t have any change logs enabled, but I see where you are going, I guess I could do that.

Haso, I turned on the query flag and saw that it was starting to write queries underneath the business object calls in the server trace. That is good.

The next time this happens and I see the same query over and over in the SQL profiler, I will look for the same query in the app server log.

I recently had something similar and someone pointed me to an undocumented SQL stored procedure called sp_who2 (I think). This allowed me to find that an http call from a client called “website” was the culprit, and an email to all users, "hey, anyone have a computer called “website” that I don’t know about? " came up positive.