You are viewing limited content. For full access, please sign in.

Question

Question

workflows reverting back to previous versions

asked on June 23, 2014

Good Afternoon All,

 

We've got an issue at a client site where the designed, and modified workflows are reverting back to previous "versions".

 

We have a workflow called HR Manual Process. We make a change to the workflow where a shortcut path is changed in the design. We then save it. A few days or a week later, it has reverted back to the previous design.

 

Example:

 

Original shortcut path is \ABC\123

 

We changed it to \ABC\1234

 

A week later and it changed back to \ABC\123

 

This is becoming rather annoying. Does anyone have any ideas ? We'd considered that it might be a user with Admin rights, but I don't know if it is possible to track / trace changes made to workflow, including the user who might have made the changes. We also considered that the workflow database might be the culprit.

 

Regards,

Brian

0 0

Answers

APPROVED ANSWER
replied on June 23, 2014

Fix the workflow and republish it. Take note of the latest version of this workflow definition as well as the exact time it was published and which user published it. Use this as a control to know that this current version of the workflow should be correct. Then the next time the customer notices that the workflow had been changed, review the version history of the workflow to see what the current version is and when it was last updated. Then look back in the Audit History to see which user has published the workflow since your "control" version and that might help lead to finding out the cause of the workflow definition seemingly reverting back.

0 0
SELECTED ANSWER
replied on July 2, 2014

Hi Alex,

 

It appears we've found a possible culprit. SQL is throwing multiple errors in the event logs that when researched reflect a possible corrupt environment / instance.

 

One of the errors was:

 

  1. SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=1464. Thread=3720. Client. Instance=LASERFICHE. VD=Global\device8C954A87_SQLVDIMemoryName_0.
    1. http://social.msdn.microsoft.com/forums/sqlserver/en-US/f62dccaf-ea26-4b5c-b4b9-41752b358c63/sqlvdi-locsignalabort-descclient-initiates-abort
    2. A bad SQL install was the issue.

 

We're working with the Service Provider to solve these issues and hopefully it will address the ongoing problems.

0 0

Replies

replied on June 23, 2014

You can view the Audit History in the Workflow Administration Console to see which users may have recently published the workflow in question to try and find out the cause of the changes being reverted.

0 0
replied on June 23, 2014

Checked logs as you suggested Alex. It doesn't show any non-expected user activity

0 0
APPROVED ANSWER
replied on June 23, 2014

Fix the workflow and republish it. Take note of the latest version of this workflow definition as well as the exact time it was published and which user published it. Use this as a control to know that this current version of the workflow should be correct. Then the next time the customer notices that the workflow had been changed, review the version history of the workflow to see what the current version is and when it was last updated. Then look back in the Audit History to see which user has published the workflow since your "control" version and that might help lead to finding out the cause of the workflow definition seemingly reverting back.

0 0
SELECTED ANSWER
replied on July 2, 2014

Hi Alex,

 

It appears we've found a possible culprit. SQL is throwing multiple errors in the event logs that when researched reflect a possible corrupt environment / instance.

 

One of the errors was:

 

  1. SQLVDI: Loc=SignalAbort. Desc=Client initiates abort. ErrorCode=(0). Process=1464. Thread=3720. Client. Instance=LASERFICHE. VD=Global\device8C954A87_SQLVDIMemoryName_0.
    1. http://social.msdn.microsoft.com/forums/sqlserver/en-US/f62dccaf-ea26-4b5c-b4b9-41752b358c63/sqlvdi-locsignalabort-descclient-initiates-abort
    2. A bad SQL install was the issue.

 

We're working with the Service Provider to solve these issues and hopefully it will address the ongoing problems.

0 0
replied on July 15, 2014

Alex,

 

I've been working with the service provider, and it appears I have been in multiple non-logged chats on Support and Pre-sales as I cant find where a ticket was created. I've also been in CFW's. We've currently got Microsoft involved and they have questions that need a developers assistance on answering questions. We're in contact with Charles  Suzara.  I'm going to contact support this morning to get a ticket created. Is there any way to get copies of chat logs on this incident? I'm trying to gather all the info I can for Charles so he will know what team to have in discussion with Microsoft.

 

Regards,

Brian

0 0
replied on July 15, 2014

If you had chatted with Presales or attended a CFW with them, you would need to contact them to get a copy of the transcripts. Besides this thread, the only other interaction with Support is through the case you opened this morning. Please make your updates in the case instead of this thread. We'll revisit this thread to post the resolution.

0 0
replied on July 29, 2014

Microsoft was unable to say definitively if this issue was / is purely a Laserfiche issue. They suspect it may be a combination of cache, LF, SQL and even OS. The following trigger script has been implemented and should stop reversions from occurring.

 

USE [Workflow]
GO
/****** Object: Trigger [dbo].[insteadofupdate] Script Date: 07/29/2014 10:42:44 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER trigger [dbo].[insteadofupdate] on [dbo].[workflow_code]
Instead of update
as
declare @workflow_id [int],
@version [int],
@last_update datetime,
@temp datetime
select @workflow_id=i.workflow_id from inserted i;
select @version=i.[version] from inserted i;
select @last_update=i.last_update from inserted i;
select @temp = [last_update] from workflow_code where workflow_code.[workflow_id]= @workflow_id

if (@last_update > @temp)
begin
update workflow_code
set
[designer_code]=a.designer_code,
[workflow_assembly]=a.workflow_assembly,
[last_update]= a.last_update,
[version]=a.[version],
[csharp_assembly]=a.[csharp_assembly],
[vb_assembly]=a.[vb_assembly]
from workflow_code u inner join inserted as a on u.workflow_id=a.workflow_id
end
else
rollback

0 0
replied on July 29, 2014

Note that Workflow itself will just insert into the workflow_code table every time a workflow is published (as that's how it keeps track of the various versions of workflow definitions).

 

If anything is "reverting back" and it's not actually due to some user undoing a change in workflow and republishing, but rather the database actually rolling back to a previous state, I'd be curious as to why that was happening.

 

You can query the workflow_code table directly and look at the latest version of a given workflow to confirm if it really is someone undoing a change and publishing or if it is the database actually rolling back. For example, you modify the workflow properly and publish it and take note that the latest version of the workflow is now version 10. Then when the issue occurs, if you check the table and see that the latest version of the workflow is now 11, 12, etc. then it indicates that someone modified it and republished it. If the latest version of that workflow is now 9 or 8, then the database somehow rolled back.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.