Workflow and ServiceDesk Community

Dear All,

Well, I have a workflow that needs to get the User ID from the HTTPContext and I am using Workflow 7.1 with IIS 7.5 on Windows 2008 R2. I have looked this up and have set the Preferences to use IIS for debugging and set the Sticky URLs.

Sadly, when I run the debugger, I get that old "favourite":

Object reference not set to an instance of an object.

System.NullReferenceException: Object reference not set to an instance of an object.
   at LogicBase.Tool.UI.Debugging.RunActionBase.RunLocal() in c:\build\projects\WF71MR2\core-tool\LogicBase.ToolShared\UI\Debugging\RunActionBase.cs:line 198
   at LogicBase.Tool.UI.Debugging.RunActionBase.Deploy() in c:\build\projects\WF71MR2\core-tool\LogicBase.ToolShared\UI\Debugging\RunActionBase.cs:line 120
   at LogicBase.Tool.UI.Debugging.RunAction.Execute() in c:\build\projects\WF71MR2\core-tool\LogicBase.ToolShared\UI\Debugging\RunAction.cs:line 27
   at LogicBase.Tool.UI.Debugging.RunActionBase.action(Object sender, EventArgs e) in c:\build\projects\WF71MR2\core-tool\LogicBase.ToolShared\UI\Debugging\RunActionBase.cs:line 90
   at LogicBase.Tool.Common.XActionBase.Invoke() in c:\build\projects\WF71MR2\core-tool\LogicBase.ToolShared\Common\UIBases.cs:line 130
   at LogicBase.Tool.Controls.ActionsToolStrip.item_Clicked(Object sender, EventArgs e) in c:\build\projects\WF71MR2\core-tool\LogicBase.ToolShared\Controls\ActionsToolStrip.cs:line 122
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at LogicBase.Tool.Controls.ToolStripEx.WndProc(Message& m) in c:\build\projects\WF71MR2\core-tool\LogicBase.ToolShared\Controls\ToolStripEx.cs:line 43
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Does anyone know how to fix this?

Regards,

QuietLeni

This may be a shot in the dark, but are you using the Workflow Enterprise Management features in the Symantec Management Platform?  I've seen this error message caused by my settings in there before.  If you are, you can test working around it by making your managed Workflow server now "unmanaged", and see if that allows you to run the debugger.  If that gets you past the error, then it was most likely a setting in that managed server in the SMP. 

Again that's a bit of a shot in the dark as this is a pretty generic error message (that generally just means a variable that needs a value doesn't have one).

I don't think get current user works in the debugger, even if you are using IIS. You'd have to enable Authetication on the debug Application URL. 

For testing, you should disable the Get Current User and fill in your credentials, or actualy publish it to your local PC and try it there, after you enable IIS authentication. You'll also have to edit the web config file to use Windows Authentication.

Rob

So I decided to look closer to it and find out where is the problem by using a bit reverse engineering.
 

What I found ?

During preparing local debugging session the method DeployApplication() is called (what is quite obvious) but its execution result is not tested (!!!). So in case application publishing has not be done Designer always will throw NullReferenceException.

I went deeper and I checked why application hasn't been published. Befor publication a deployment rights checking has place. Method UserCanDeployProjectToWAS from http://localhost/altiris/Workflow/Licensing.asmx web service is called (it can be called manually from web browser). As first parameter 'true' value is passed, as second a user name and as third ServiceID of the published project. The project can be published only when this web service method returns true. I my case it returns 'false' and deployment rights checking ends with error message "Notification server authorization failed. User cannot publish directly to a managed server. Please contact administrator."

Is this machine pointing at a SMP or is this machine the SMP itself? It's trying to contact the Licensing service at localhost. Check the Credentials tab of Symantec Explorer and verify the Default SMP is valid.

This is only done if you're using the managed environment setup in Enterprise Management on an SMP. If you're not, you shouldn't have to do the steps above.

I've never been able to make Getcurrent User in Debug with HTTP Context.  If you get this to work please share how.  I've also found that to get it to work in a published app, anonymous access must be disabled and Windows authentication must be enabled in the web.config file (as Rob mentioned).  Be sure to make the web.config change within Workflow designer, not in IIS Admin, otherwise it will get reset each time you publish. 

Chris,

Thanks for replying. I am exposing my ignorance here, but I do not know how to check this. I am developing upon the same box which is my SMP server. How do I check if I am using the Workflow Enterprise Management Features?

I was following your video about using Get Current User...

Kindest regards,

QuietLeni

Basically you're using Enterprise Management if you have an SMP 7 set up with the WF solution installed, and you've created managed and unmanaged environments on that server to control where workflows can be deployed. If you don't have an SMP, or you have one and don't use it for this purpose, you're unmanaged, or not using Enterprise Management (which is perfectly fine).

reecardo,

I understand. To get this far as my development machine, I just installed ITMS and included Workflow. How do I make the server unmanaged to fix this issue?

Kindest regards,

QuietLeni

Servers are unmanaged by default. You shouldn't have to do anything.