issue in running workflow container operation

[mohammadaamir_khan]

Hi All,

In work item, i have created  given latest end, and in this latest end outcome branch, i am changing the dead line date in container operation.

Issue is by mistake i have given wrong format of date as in screen shot. I have corrected error later, but there are few workflows in production which started before transport and those are in error.

I tried restarting those work flow, but still they are going in error again.

Please suggest how to process errored workflows.

Thanks in advance.

[Former Member]

I assume that the workflow goes into error during the execution of the container operation. It might be that there is nothing you can do, since the 02:00:00 has been hardcoded, and it will alwasy try to execute the operation with that value (you cannot change it). Good idea always to put the constants into a container element, so you can change values if necessary with the WF admin tools (=change container functionality).

Probably the easiest solution is to restart the workflows, and then manually change the deadlines to the correct ones (if necessary).

Regards,

Karri

PS. Also a good idea to test this kind of changes before going to production. You can always change the deadlines (and container element values etc.) in the runtime to make the testing easier (no need to way X amount of days).

Regards,

Karri

[mohammadaamir_khan]

Hi Karri,

I change the deadline date and re started the workflow, but still it is going to container and failing there.

Is there anyway to bypass the particular step.

Thanks

[Former Member]

Sorry, perhaps I was not clear. You need to restart the whole workfow (not just "restart after error"). Restarting after error just tries to "continue" the workflow from the same phase, but you still have the step with a serious error, and you will always run into the same error. I don't see any way to skip the step.

You should restart the workflow from beginning. This means that you for example trigger the same event that started the workflow at the first place (if you are using evets) or then start it with SWUS or whatever. This way the workflow will run with the new version of the workflow that does not have the bad container operation step. (Also remember to logically delete the old workflow instance.)

Regards,

Karri

[mohammadaamir_khan]

Hi Karri,

Thats main issue . I cant start another workflow as this work flow has already passed many steps like updating info types, which cant be reverted.

Thanks

[Former Member]

This is a tricky one. I am not sure if there is a way to solve the problem. Hopefully someone can give you some trick, since I am out of ideas.

If there are just few cases, could you somehow process the rest of the business process manually? Execute the needed code "outside the workflow". I don't know what your workflow is doing, but lets say it should still update some infotype (after an approval) - then just ask admin to update the infotype etc.

Good luck!

Regards,

Karri

[former_member186746]

Hi,

Well my worfklow trainer back in the day once said when someone asked him :"Can you do X with workflow"

- "Only when you can do it without workflow can you do something with workflow".

If it is impossible to restart the workflow by either SWUS or SWUE due to master data changes. And if it is not possible to manually change the active workflow template due to literals being used in bindings. Then you have to identify the subsequent steps and which user interaction is needed for this business process to end in the preferred way.

You can find out the tasks which should have been executed additionally and then execute them out of the workflow with SE24 or SWO1.

You've mentioned infotypes....., HR workflows can be huge, so far still the most complex ones I have come accross. You could also find the help of an experienced HR consultant and then revert the changes that were done with workflow and then you can restart them.

Kind regards and good luck, Rob Dielemans

[former_member185167]

Hello,

It appears that this was not tested even once before being put into Production! You should make sure the Workflow developer in question never does this again. I always assume I have made a mistake so I test, test, test until I'm convinced it works.

You should replicate this error in a simple 2-step workflow in your DEV system and see if there is any way of getting past the step with the value error. I'll try it too.

regards

Rick Bakker

[mohammadaamir_khan]

Dear Rick,

It was carelessness from my part. Thing is there were many functional requirements i concentrated testing them. I do testing deadline offset with time as 02:00:00 for 2 hour and it worked fine so i skipped date offset as it required to wait for a day for latest end but i should have tried individual scenarios separately.

Please let me know if you find any solution.

Thanks

[Former Member]

Hi,

You should normally test the deadlines with the final (production usage) values. You can check whether the deadline(s) where correctly set by opening the work item technical view. It is even possible to change the deadlines there to test the behavior what happens when the deadline is reached etc. From my point of view much better to test the deadlines this way. Otherwise it is easy to forget the change the deadlines back to normal before transporting, and/or cause even worse problems...

I know, it doesn't help you at this point, but as a hint for the future.

Kind regards,

Karri

[former_member185167]

Hello,

Unfortunately, I did not find a solution. Being a Container Operation step it does not even show up in the workflow log, so I could not even try to change the container values.

I agree with what Karri wrote above. For proper testing in the Test and Dev system you can't make changes in Workflow Designer so don't do it in DEV either.

regards

Rick Bakker