I'm looking for some insight on where GP's business rules are defined and enforced. I ran SQL Server Profiler and examined a few stored procedures that were called during data entry and the sp's didn't appear to have any business logic in them. I have read that eConnect enforces business rules for interfaces like webservices. Does Dexterity enforce business rules for the client? The GP SDK didn't appear to define any business rules or at what layer those business rules are enforced.
We are looking at what it would take to build custom interfaces for GP and 3rd party documents that aren't covered by MS's existing web services. I'd like to know what pre-existing validation I can take advantage of, what I will need to develop, and where I can find definitions for the business rules that the client and eConnect currently enforce. Thanks!
I have written a blog post for next week on this topic. The link below will be valid after Monday.
The short answer is that the business logic is in the Dexterity code and you would need to look at the source code to get a full understanding.
If you can work through eConnect that would be best. The Software Development Kit (SDK) also contains information worth reviewing.
David Musgrave [MSFT]Escalation Engineer - Microsoft Dynamics GPMicrosoft Dynamics Support - Asia Pacific
Microsoft Dynamics (formerly Microsoft Business Solutions)http://www.microsoft.com/Dynamics
Any views contained within are my personal views and not necessarily Microsoft policy.This posting is provided "AS IS" with no warranties, and confers no rights.
This is debatable! Business logic, unfortunately, seems to be dispersed between the UI and the database. Take the case of Manufacturing: MRP business logic is encapsulated within a stored proc. I don't think there is a clear cut. I agree that a lot of business logic still resides inside Dex, but that will depend on how far back was the module written as well.
Have a look at my blog post on the subject
Business Applications communities