Why Microsoft Dynamics GP 10 Workflow is Joke?
Most of the things in Microsoft Dynamics GP are Dexterity based; which is a RAD scripting like environment with rich support for Forms, Tables etc; something like PL/SQL. Dynamics GP also supports .NET based clients assemblies that you can load against GP forms; for that you need to create form factories according to the Dynamics GP expectations. You specify these form factories in Dynamics.exe.config file (a typical .NET form app looking config). You create the form, their windows and controls on them in Dexterity and to access these controls etc in the .NET client assembly you use GP Visual Studio Tools app to generate an assembly from your Dexterity Dictionary Changes and then reference this assembly in your client assembly. Unfortunately GP thin client is old days VB6 like two tier app; you need to deploy your dictionary changes, changes in .config and the two client assemblies to each workstation! (whenever you make any changes and want to release some update). The story does more complicated when we involve the server part!
At the server side; Dynamics GP uses Microsoft Office SharePoint Server. It needs full MOSS (for apparently no reason; I think what it provides can be done in plain WSS). It needs GP Web Services; which unfortunately you need to setup separate to MOSS. I guess they decided to keep it separate so that if you just need GP Web Services without Workflow or Business portal; you may…..but I think they should had used WSS for workflow and this GP Web Service component should be implemented on WSS…I explain why…..The GP Web Services needs “Dynamics Security” component against which GP Web Services does security checking. This Dynamics Security component I guess is shared across their Dynamics product line and its implemented as web service (one more web service) and in the back end it uses Active Directory Application Mode; this makes sense but its over engineering…why because as said before if they have implemented GP Web Services on WSS they could have used WSS Security Infrastructure….and things could have become much cleaner to maintain…The server side story doesn't end here….
You need to code a server side workflow assembly through which you basically exposes the entity fields that you want the rules to run on. This assembly is not a typical Windows Workflow assembly or typical SharePoint Workflow assembly; instead its an addon like assembly which “SharePoint GP Workflow” uses. This assembly is bit tricky to code….I think the simpler solution must have been to make available some Windows Workflow Activities; so that one could use it the way they wanted to…either in Visual Studio to develop some SharePoint Workflow; or through Sharepoint Designer…
The overall experience of bringing the system online and start coding some real thing…and then coding something….is all messy….it could have much simpler….I am not sure if they are improving it in the upcoming GP 2010 or not….but till then GP Workflow is really a joke!!!