Changes to an existing workflow

[#1]

Hi,

I have a rather major change that needs to be done on an existing and active (production) workflow. I am wondering what should be the best approach.

1) Back up a copy of the workflow in DEV and make the necessary changes to the <b>old workflow</b>. Transport the <b>amended old workflow </b>to PROD.

2) Back up a copy of the workflow in DEV and make the necessary changes to the <b>copied workflow</b>. Transport the <b>amended copied workflow</b> to PROD.

Any comments? Points will be awarded for helpful advice. Thanks.

[Former Member]

Thanks for the advice.

Actually, I have a custom screen that's dependent on the workflow. At every step of the workflow, the user will go to the screen and fill in remarks in a field corresponding to that step. The remarks will be stored in a maintenance table. They are non-key fields.

The new requirement is to remove several steps of the workflow. This means that other than changing the workflow, I have to remove some fields from the custom screen.

If I use versioning for the workflow, it looks fine for the workflow as the correct version will be used. However, I will face problems with the screen as there can only be one version at any time.

I can think of 2 solutions.

1) Disallow the users from triggering a new run of the workflow until all active sessions are completed. After that, transport all changes (new version of workflow and screen) to PROD.

2) Create a new workflow and new screen.

[martin_nooteboom]

Isn't it enough to create a new version and let this work with the new screen? All the started workflows will have the old screen and flow, and the new ones will have the new screen and flow.

Regards,

Martin

[Former Member]

Martin, what happens, if you change for example some screen inside your task/method? Old and new workflows both are using the new screen, or? Then what if your old workflow is depended on some of the fields of the screen, which have been now removed?

[martin_nooteboom]

Hi Karri,

When you change a method than the new version of the method will be used when the task is called. If you don't want this, you would have to create a new task and use this in the new version.

Basically the rule is, what has been started will not be affected by changes, so changes to the workflow definition will not have an effect, but changes to tasks (which will be started new) will. And changes to ABAP (a method) also.

These are some basics you need to know before you change an existing workflow, but are not that well explained everywhere.

Regards,

Martin

[Former Member]

Martin, yes, I was aware of this. I just somehow misunderstood some of your earlier posts, and got a bit confused.

As a result: In this particular case I would recommend to create a new task, and a new method, and a new screen to be created (if these are going to be major changes). The same old workflow can be used.

[martin_nooteboom]

Hi Karri,

I already had an idea my post wasn't that clear. When I saw your post, i realized my answer was a bit cutting corners.

Regards,

Martin

[surjith_kumar]

Hi,

While transporting the changed workflow in Production, make sure that the previous workflow which is working does not have any error.

i.e. for P.O you made a workflow, before move to production go to SWPR and check no error for you P.O workflow (i.e. the workflow which you designed). If any error in workflow restart it completely and move the changed workflow.

which out rectifying the error if you move to production then you restart the previous Approval request , the workflow won't work properly.

Regards,

Surjith

[Former Member]

Hi,

"If you change your WF definition, the instance already active will follow the old one."

Yes, I am worried about the active sessions.

I will check out the creation of a new version. I noticed that when I made a copy of a workflow. The copied workflow will contain the same tasks (ie same task number). Does this mean that making changes to a task in the copied version will affect the original workflow?

[Former Member]

Yes changes in the copy may affect the original workflow ( Coz you will be changing the tasks which are used by it). So be careful !

And for active sessions. What happens is if you create a version and transport it. the workflow engine will wait till the active sessions ( Of old version ofcourse) are over and after that it will put the new version in place as the active workflow. Versioning should be the way out for ou as suggest by previous posts !

Best of Luck,

Regards,

Anuj Sethi

[Former Member]

Hi,

maybe the right answer is the versioning of your WF. Anyway looking at the two ways proposed I suggest the second.

For example : a WF instance, once started can't be modified (I've not verified if it's still true in ECC, but in 4.7 it's still so). If you change your WF definition, the instance already active will follow the old one. So It may happen that you need to close all your old WFs and start new sessions with the modified flow. In this case it can be usefull keep the two WF separeted.

Regards,

Gianluca

[martin_nooteboom]

Hi,

I have verified it and it is still so, a started workflow will not be affected by changes. You can create a new version of the workflow (no need to copy it) and make the changes there. The only thing you have to check is if there are any subworklfows which you will change. If so you need to be sure that the 'old' workflows can handle the change and that the business is ok with a difference in the workflows.

Regards,

Martin

[Former Member]

Hmmm, if the changes really are going to be major ones (=changing totally the tasks & screens, the flow itself, etc.), maybe it would be a good idea after all to create a copy of the workflow, and copies of the tasks & screens, etc.). But I would say that you are the best person to estimate, if this is needed or not.

You can also test this: Just start now some workflows, do your changes, and test how the workflows, that you have started earlier, behave. (If you are worried that what happens to the already started workflows after your changes.)

[Former Member]

Create a new version of the workflow. => In the workflow builder in the menu you have an option to generate version. Generate the version, do your changes, and transport it to production.

If something goes wrong later, you'll always find the old version of the workflow and can activate that, and transport it to production then.

EDIT: Actually, you don't have to generate a new version in SWDD. When you transport the workflow into production, it will generate a new version there anyway. All the new workflows use the new version, and all the running instances will use the old. Generating a new version in SWDD is just for your own convenience (=You'll have a backup of the old version).

Message was edited by:

Karri Kemppi