Workflow Soluiton

I already have a workflow request project published in the production which is used today.

During test-phase of new project features/updates I have a copy of the project which is tested before published to the production.

 

What I did last time I replaced the "test" project with the production was to:

prevent external connection to access the website

removed the production web site

removed the workflow project

created a package of the update project

added the package to workflow with the same name as the "production" project

 

When this was done I got some weird error when two users tried to access the newly published project "only one task is allowed to be created when starting workflow in the dialog workflow mode". I didn't restart the "workflow server extension" so don't know if that was causing this error or something else; don't know if I performed this "update" in a correct manner.

Question:

If the approver has not yet approved the request before I delete the published "production" project  what will happen with these requests then? Will the new published project with the same name as the production take over?

 

Previous  I used the same project to make updates but published it with another virtual directory name but the release folder would still be the same for these two which prevented the "isolation" of the production and test/new version project.

 

What is the best practise for this kind of scenario when using another project to "stage" the next release?

Hey AngelD

If I am understanding you right , I think what you need is a versioning piece in the Workflow, there is a video on www.workflowswat.com there is a video on how to set this up called Change Management Step 1 - Version Management. Watch it and see if that answers your questions

 

Nice video!

However; this will not solve my problem for now but I will think of this versioning management next time :)

 

The problem is that I basically have to two workflow projects, one that is in production (call it ProdProject) and another that is a copy of the production (call it TestProject) that I will update for next release.

When the test-phase is over and all changes in the TestProject has been tested and approved I want to replace this with the already published ProdProject.

What I want to make sure when I release Test (TestProject name will now be changed to ProdProject; virtual directory name and project name) is that any request that has not yet been approved isn't lost when the replacement takes place.

As the TestProject is a copy of the ProdProject all settings/configuration will be the same except that I will change the project and virtual directory name to <ProjectName>_Test.

Checking the tasks that exists by having a look at the WorkflowManagement page (Unassigned Tasks) I can see both the ProdProject and TestProject tasks but with different Project (column) field values; ProjectName and ProjectName_Test. So this (to me) indicates that non was lost during my previous attempt (see initial post; this thread) but I need to make sure no un-approved request will not be get lost.

 

So how would I best perform the replacement from Test to Prod, what is the best practise of this kind update if any?

As I stated in my initial post; I also got an error after I removed Prod and add Test as Prod, so I also want to make sure this will not happen next time (a restart of the server/computer fixed the issue).

I routinely do updates to my production workflows and publish right on top of them without losing any tasks. I don't version like in the video. I'm the only one in our organization doing Workflows so I know while I'm putting in updates if they will cause any issues with the published version and make adjustments as needed to factor that in. 99% of the time that is not needed however as the changes are not huge sweeping ones to make - at least from my experience. That would probably be different for different developers or organizations with multiple Workflow developers.

I'm sure that works for you but;

I want the customer (group of users) to sign off (approve) the changes before I publish the update(s) to production as that will ensure ("by paper") they have tested and approved the changes and if anything goes wrong they have to order an update.

I also don't want to possible break the working process by adding changes that hasn't been properly tested as that could mean that they wouldn't be able to make any requests until I've fixed the possible issue which sometimes can take a lot of time if it's a big (workflow) project.

For major changes we have sort of a sign off procedure, but i have all my work flows in visual source safe so that i could roll back if needed. For minor changes that don't impact my users ( like routing rules in servicedesk, 'admin' type flows, etc ) they are done in the evening without sign off I also have my dev box's work flow designer connected to my production so i can publish directly from there, saves a step..

I do have a Change Control Process workflow in place for the approvers. It scales based on level of change being done from Level 1 where change is routine, with no impact and minimal risk up to a Level 3 where multiple items are being changed and there is a possibility of impact or risk. Depending on departments affected and change level the number of approvers are also dynamic. Rather than sign off on paper our approvals are done electonically via this Workflow and written to a database.

Prior to updating into production, these changes are extensively tested side by side using a different virtual directory and session ID for the updated project and a clone of the production data for any task(s) that may be in process.

Thanks for the feedback everyone!

 

I (think) just realized that as long as I don't tick the "Generate new service ID" checkbox during the "Unpackage Project" dialog I should be safe to replace the Production with the Test (next release) project and don't have to be worried about loosing any non-yet-approved-requests.

 

For the users having access to both (production and test-phase) releases they can use the "stable" and "development" release to perform their request(s) and I can track & separate them through the WorkflowManagement page (as they have different project names).

Maybe I should have skipped the "the correct way" part of the title as that didn't exactly describe what I was after in this scenario ;)

 

Once again; thanks everyone for taking the time to help out!

By "using a different virtual directory and session ID" I guess you mean service ID as the session ID would be uniq each time a user starts a workflow process right?

With a different virtual directory do you also change "Release" directory path (Local path; ex. C:\Program Files\Altiris\Workflow Designer\WorkflowDeploy\Release\<Project name>)?

What I saw was that if I only change the virtual directory the (new) published project would have the same path which to sounds like both published projects would have the latest published content.