Workflow Soluiton

 View Only
  • 1.  Workflow Server (7.0 SP3) move

    Posted Jan 27, 2012 03:39 PM

    We will soon be migrating from our current NS/Helpdesk 6.x environment to ITMS/ServiceDesk 7.1 SP2. About 2 years ago, we setup an SMP 7.0 MR2 (Windows 2003 32-bit) server and ServiceDesk 7.0 MR2 (Windows 2003 x64) server, in anticipation of migrating shortly thereafter. The project plan for fully implementing that environment was postponed however until now. The problem I'm running into is I am currently using the ServiceDesk server as my Workflow 7.0 SP3 server (we don't use the ProcessManager) and before we can start to migrate, we will need to reload the OS on both the SMP and ServiceDesk servers (my Workflow server) so we are using the prerequisite Windows 2008 R2 on both. As a result, I need to move my Workflows to another server while we upgrade those so I can keep my current Workflows running until I get them all migrated to Workflow 7.1 SP2.

    What I need to know is, when I install Workflow Server 7.0 SP3 onto another server, how do I change any tasks that are currently in-process to reflect the new server name? We are using SQL persistence through Exchange right now and I'm not positive how I can make the task links for the in-process tasks reflect the new server name I'll be moving to.

    Thanks for any ideas!



  • 2.  RE: Workflow Server (7.0 SP3) move

    Posted Jan 27, 2012 04:11 PM

    See this previous post:

    https://www-secure.symantec.com/connect/forums/service-desk-70-71-upgrade-issues

    The URLs in ReportProcess (and Task, I believe) have servernames hardcoded in them. You can use the SP in the previous thread to look for mentions of the old wf server, and yoou can get them redirected to the new server via some mass UPDATE statements. Like this:

    UPDATE ReportProcess SET UrlColumn = REPLACE(UrlColumn, 'OldServer', 'NewServer')

    I'd backup your SQL DB before attempting any updates of these URLs first, just to be safe.



  • 3.  RE: Workflow Server (7.0 SP3) move

    Posted Jan 27, 2012 04:29 PM

    Thanks for the reply reecardo.

    All my Workflows use the 'DefaultTaskSource' as we don't currently use ProcessManager. The tasks are either emailed to a user, launched through a custom portal page I create in workflow or they invoke tasks inside Helpdesk 6.x tickets. All I could find in the ReportProcess and Tasks tables were a handful of references to SD.IncidentManagement, SD.KBSubmission and SD.ChangeManagement. I'm pretty sure those are references left over from when I was testing ServiceDesk before we scrapped that plan and switched to just using the server as a Workflow 7.0 SP3 server.

    Do you know where would the 'DefaultTaskSource' tasks be located? Is that the Messages table? I did try that SP but it only found the server name in columns that looked like they were associated with the aforementioned ServiceDesk items.



  • 4.  RE: Workflow Server (7.0 SP3) move

    Posted Jan 28, 2012 01:37 PM

    The message data in the Messages table is binary and can't be updated by that SP (nor should it). URLs don't enter here at all... it's basically messages with flow data.

    If that SP comes up empty and just has tasks pointing to old ServiceTask data, you should be good. DefaultTaskSource basically means you're not using Process Manager/AD/etc. for assignment data - you're just doing your own thing using email.



  • 5.  RE: Workflow Server (7.0 SP3) move

    Posted Jan 30, 2012 12:45 PM

    Where in SQL, does the information get stored that is used to construct the workflowmanagement.aspx page's process links and task links/urls' ?

     



  • 6.  RE: Workflow Server (7.0 SP3) move

    Posted Jan 31, 2012 06:53 AM

    This information is stored in a message in queue with its name ending with ".assignments". The assignments messages are always created in pairs with tasks messages and share with them the same MessageId (which is a WorkflowTaskID). More precisely this info is an element of object of TaskAssignmentStructure class which is binary serilized and stored in Message column (if exchange is based on DB).

    The WorkflowManagement.aspx script reads this information directly from exchange queues using WorkflowService class. You can get similar effect using WorkflowManagementService.asmx web service and calling its GetTaskAssignment method passing a TaskID as a parameter.
     



  • 7.  RE: Workflow Server (7.0 SP3) move

    Posted Feb 03, 2012 12:51 PM

    I made a test project that reads a Message for a specific QueueName. I then took that Message data and changed it to text using a ByteArrayToText component using UTF8 encoding. I then used a ReplaceStringInText component to update all instances of the current server name to the new server name. After that I converted the updated string back to a Byte Array using a TextToByteArray component.

    At this point I'm stuck as I'm not sure how to update the Message value in SQL with the updated Byte Array. Is there anyway to do this or do you think this will even work (without corrupting the Message value in SQL)? Thanks for any ideas!



  • 8.  RE: Workflow Server (7.0 SP3) move

    Posted Feb 06, 2012 10:41 AM

    I'm shocked. How did you do this?

    Reading a Message from queue is quite easy, but how you was able to convert the Message data to text??

    I suppose that is rather not possible.

    First, the Message data are placed in a field named "PayLoad" of type System.Object and variable of this type cannot be added to project and are not shown in any Desiner's variable editor I've ever used. Do you really have access to field PayLoad in the Message structure?

    Second, the conversion to text is improper operation. The Message data should be deserialized - not converted. If you really get access to the PayLoad this field is automatically deserialized to object of proper data type - in this particular case to a TaskAssignmentStructure.

    Third, the string replacement should be done field by field of the deserialized structure. Then corrected TaskAssignmentStructure can be stored as an object in queue again.

    Excuse me, but I suspect that you converted to text the whole Message structure. Replacing strings in such converted structure doesn't guarantee that other non-string data (e.g. DateTime) won't be destroyed. I supposed you intended to convert this changed Message to byte array again and store it in queue.

    Unfortunatelly, you won't we able to store correctly this structure in queue again using standard Put Message In Exchange component. The problem is that this component requires on input an object of specified data type, which will be put inside Message, like TaskAssignmentStructure. You can't pass to it a Message structure because the effect will be placing one Message inside another Message and workflow engine won't be able to read it back.

    The next problem is that the TaskAssignmentStructure seems to be unaccessible to Designer's data type selector wizards. So it cannot be selected as input object for Put Message In Exchange component.

    I think your idea to do conversion in that way seems to be too risky. It can be done easier and safier by C# program maybe no more then two dozen lines long.