none
How to get an HttpContext within a Windows (SharePoint) Workflow. RRS feed

  • Question

  • Hi All,
     
    I m implementing a SharePoint 2010 along with Project Server 2010.
     
    I want to get an HttpContext within a Workflow.
     
    How to implement that ? Any tricks or workaround guys ?
     
    Thanks.
    Wednesday, December 7, 2011 4:51 AM

All replies

  • Hi There,

    Might be useful for you.
    http://social.msdn.microsoft.com/forums/en-US/windowsworkflowfoundation/thread/af0dad48-bf7a-40e0-adf5-4f3e33579d1e
    Thanks, Amit Khare |EPM Consultant| Blog: http://amitkhare82.blogspot.com http://www.linkedin.com/in/amitkhare82
    Wednesday, December 7, 2011 5:47 AM
  • Hi All,
     
    I m implementing a SharePoint 2010 along with Project Server 2010.
     
    I want to get an HttpContext within a Workflow.
     
    How to implement that ? Any tricks or workaround guys ?
     
    Thanks.


    Its probably more helpful to know why you want the HTTP Context.

    It is very common for Project Server installations to include an App Server that does not run the Web Front End role.  In this case your Workflow can run on a machine in the Farm (via the Queue Service) where there is no web server.

    So you can see getting a HTTP Context is pretty meaningless in this case.

    There are pleny of smart people here that could probably think up a workaround depending on what you need to do.

    Cheers,

       James

     


    James Boman - http://www.boman.biz Software Consultant for IPMO - http://www.ipmo.com.au
    Monday, December 19, 2011 7:18 AM
  • Hi James,

     

    Good remarks,

     

    In my case the Project Server 2010 is integrated with SharePoint 2010 hence end users will use it across the network...

     

    Now the challenges is that I want to get who is the current logged in user "inside the browser" – and as we know workflow run in a different thread and HttpContext in another thread therefore difficult to implement.

     

    However we have a Workflow properties "Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties.OriginatorUser" but it returns always the System Account that’s because the workflow is operating under the Application Pool user, it doesn’t know who the current user of the SPWeb is.

     

     see: http://social.msdn.microsoft.com/Forums/en/sharepointworkflow/thread/db4a7add-1a29-4f5b-be5b-1447028aa6e5

     

    A forum guy suggested me to implement OnTaskChanged Activity so we can capture a parameter called ExternalDataEventargs 'e' hence the user who is actually modifying the task is given by e.identity but the business need is different.

     

    At last as a workaround, I have created a Web Service which return the current user "inside the browser", will consume it inside the workflow and pass the value as a parameter - have to test it - will let you know the final results.

     

    Feedbacks are welcomed :)

     

    • Edited by Moiz_52 Tuesday, December 20, 2011 8:28 AM
    Tuesday, December 20, 2011 8:21 AM
  • Now the challenges is that I want to get who is the current logged in user "inside the browser" – and as we know workflow run in a different thread and HttpContext in another thread therefore difficult to implement.

    Indeed - and if its a multi-server Farm it may not necessarily even be on the same server as the one the user hit with their browser

    However we have a Workflow properties "Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties.OriginatorUser" but it returns always the System Account that’s because the workflow is operating under the Application Pool user, it doesn’t know who the current user of the SPWeb is.

    This is expected because the SharePoint Site Workflow should be running as the Workflow Proxy Account configured in Project Server Settings.

    _

    A forum guy suggested me to implement OnTaskChanged Activity so we can capture a parameter called ExternalDataEventargs 'e' hence the user who is actually modifying the task is given by e.identity but the business need is different.

    This is a better strategy however if the workflow is being advanced by someone operating a PDP, you can use the PSI to find out who the Project is currently checked-out to, as the Project must be Checked-Out for the user to advance the workflow. The only exception to this that I know of is when the Project is selected via Portfolio Analysis, and then the workflow will be run when the project is not checked-out.

    At last as a workaround, I have created a Web Service which return the current user "inside the browser", will consume it inside the workflow and pass the value as a parameter - have to test it - will let you know the final results.

    This is not such a great strategy - as if everything is working correctly you should get the Workflow Proxy Account (as mentioned above).

    Does this Help?

    Cheers,

    J.

     


    James Boman - http://www.boman.biz Software Consultant for IPMO - http://www.ipmo.com.au
    Tuesday, December 20, 2011 11:01 PM
  • Hi James,

    Regarding your first answer - it's correct - that's why I m trying to get the current logged in user "inside the browser" as any user using SharePoint site will be able to logged in.

    The business scenario is as follows:

    Assume that I have 3 PDP:

     

    PDP New Request

    PDP Approval Form

    PDP Status Form

     

    -An end-user will raise a request – He will fill up the form “PDP New Request” and will submit the form.

    -The approver will get the Approval/Rejection “PDP Approval Form” and will take action.

     

    I need to hide the “PDP Approval Form” from the end-user and show him the remaining form which are “PDP New Request” and “PDP Status Form”.

     

    Which Workflow Activities (Office Task – Listen – IfElse…) can you advise for the above scenario taking in consideration that there has to be a Roles Security check and in beetwen there will be no changes  so "OnTaskChanged" will not get into picture.

     

    Thanks and regards.


    • Edited by Moiz_52 Wednesday, December 21, 2011 5:39 AM
    Wednesday, December 21, 2011 5:39 AM
  • Moiz,

        Im not sure PDPs are exactly the right vehicle for what you are trying to do however one thing does come to mind:

    If the people that need to see the Approval PDP are distinctly different from those who are using the New Request PDP and the Status PDP - then you can go into the PDP library in the root of PWA and break security permissions on the various PDPs and set who should see each one, by setting item level permissions on the PDP.

    This will effectively hide PDP's for certain users.

    You could then do the approval security check behind the scenes in your workflow, but the Approval PDP would be hidden from most of the users who don't need to see it.

    Was that helpful?

    Regards,

       J.

     

     


    James Boman - http://www.boman.biz Software Consultant for IPMO - http://www.ipmo.com.au
    Wednesday, December 21, 2011 6:17 AM
  • That sounds good!!!

    will check.

    Thanks James.

    Wednesday, December 21, 2011 6:18 AM