Processing locations

(0) Share

Report

Posted on by Charles Ray

Is there a resource that lists where GP processing is done by task and module? Since GP uses a Client-Server process model, some processing is done in SQL, some passed to the GP client. Many GP performance and disconnect issues today are caused by well-intentioned IT teams setting Domain-level security policies as well as aggressive active Antivirus scanning. It would shorten the diagnostic process if we knew which side the process was on so we had a clue what side of the lot to start digging. Yes, we can get that information through DEXSQL logs, SQL traces, and Sysinternals Process Monitor.

Are there rules of thumb for posting, reporting, SmartList, sorting, etc.? Again, I know the basic answers, but more often than not responsibilities are shared between client and server, and a resource like this would speed the diagnostic process and resolution.

Any assistance is appreciated.

*This post is locked for comments

All responses (5)

Answers (1)

Verified answer

Derek Albaugh on at

Like (1)

Report

RE: Processing locations

Charles,

In Dynamics GP, if you go to Administration > System, and click on Process Server, you'll see a list of all processes that you can use with Process Server.

They're mainly in the default Financial, Sales, Purchasing, Inventory, Payroll and Project series, but with others.

Basically the rule of thumb is, any process that requires user interaction, such as to click a dialog window or select a value or anything like that, cannot be used in Process Server, because the functionality isn't there to be able to select a value or click a button through DPS.

In the SystemAdminGuide.pdf in the Dynamics GP Documentation directory, Part 3 has a couple chapters on the Distributed Process Server, that may provide additional information.

Thank you,
Charles Ray on at

Like (0)

Report

RE: Processing locations

Thanks, Mariano. While all processes are indeed initiated at the client, much of the actual processing is still run inside SQL. The stored procedures you spoke of run on the SQL Server, and they too can cause issues from server-side bottlenecks.

This is what I'm trying to sort out.

Another way to partially answer the question might be to ask "What processes can be delegated to other workstations by the Dynamics Process Server?"
Mariano Gomez 26,225 on at

Like (1)

Report

RE: Processing locations

All processes are done client side unless you are using the Dynamics Process Server (DPS). Some processes do execute stored procedures, and can become performance bottlenecks. Most of the performance and disconnect problems I notice tend to be in virtualized environments with NIC card "offload" settings turned on.

The old Performance whitepaper still has tons of good information on database and network consideration. I find myself going through it as of late.

mbs.microsoft.com/.../MDGP2010_WhitePaper_Performance

Hope this helps.
Charles Ray on at

Like (0)

Report

RE: Processing locations

Thanks, Derek. I know the question I'm asking treads a fine line, but I find myself somewhat uniquely positioned in that same niche in the technical/SQL, but not quite development side of the product for over 20 years now. The performance white paper throughout all its iterations continues to provide invaluable information.
Derek Albaugh on at

Like (1)

Report

RE: Processing locations

Hello Charles,

Nothing that I'm aware. We have the Dynamics GP performance white paper that we put together to go through all the causes we've seen for performance issues with Dynamics GP but I've never seen or heard of any type of documentation that breaks down what you mentioned with processing by task and module.

Antivirus recommendation is to not actively scan the Dynamics GP directory and have exclusions for Dynamics.exe, DynUtils.exe, etc.

Disconnect issues we don't have a lot on, as that starts getting more into the network/SQL side of things and less on the Dynamics GP side. We do have a blog that has some settings and ways to verify connectivity/network issues, but that's about the extent on that.

That's the information I'm aware, there may be more that others on the forums have found or used that may also help.........

Thanks