WF template activation issue

[Former Member]

Hello dear SCN,

Context of the issue

We're using a custom workflow in our ERP6.0 systems. I had to make a change (FYI - simply added a condition that uses a method, one branch goes on normally, the other uses a control step to complete the WF, and also changed the event linkage), and now there is an activation issue.

The issue

Our dev system has two clients, the 600 to make changes and the 100 to test.

In client 600:

- SWDD shows version 003 of the template as being active

- table HRS1205 shows version 003 as being active

- checking the wf in SWDD gives no errors

- activating the wf in SWDD gives no errors

- SWUD's consistency check says everything is fine

- SWI1_DIAG shows nothing

However, in client 100:

- SWDD says no version is active

- table HRS1205 shows version 003 as being active

- SWUD's consistency check says "workflow definition does not exist"

- SWI1_DIAG shows nothing

- SWEL shows the events are properly received and checked, but after that it stops with error WD274 "Workflow definition of task 'WS98100159' cannot be activated" (same is given when testing in SWUS)

- when we try to open a container of a pre-existing task in SWIA, it gives error WL820 "task cannot be read"

So it kind of makes sense we can't start the workflow since it's inactive, but it why on earth is it shown as inactive in one client but not the other? Templates are supposed to be cross-client, right?

What we already tried to fix it

- generate a new version and activate that one

- activate an old version

- delete and old version that had errors in it

- cancel the changes and reactivate

- change the syntax used to pass the parameter to the method called in the change we made (just in case it was a syntax error not being picked up by the "check" button)

- transport again the event linkage TR using SCC1

- regenerate the business object

- clean buffers using SWU_OBUF, in both clients

- refresh organizational environment, in both clients

- searched SCN for similar issues, but most people that had error CD724 just had to correct errors when checking in SWDD, others had transport issues, which we do not have

Our questions to you

- did you already experience this, and if so, how did you solve it?

- any ideas on what we could try next? Our next step is searching for sap notes; if you already know one that could help, don't hesistate to give its number

Thanks in advance !

Jonathan

[SandySingh · Accepted solution]

Hi Jonathan,

Try Transaction SWDD_CONFIG to activate the workflow in both Client 100. It is client-dependent adjustment of a workflow definition.

Refer to SAP Note  1641526 - Workflow configuration lost during transport

1711877 - Workflown configuration: Activate/deactivate

1037979 - WF: active version of workflow definition is not selected

Regards

Sandy

[Former Member · Accepted solution]

Hello Sandy,

In this case it's a customer workflow, so activating a configuration triggers error WD363 ("customer-own workflows are not allowed to be configured").

Thanks for the notes, 1037979 seemed promising! However our sap_basis is on release 731, and all these corrections are already implemented.

We also found note 982352 which seemed to describe exactly the issue, but it was also already implemented.

Regards,

Jonathan

[SandySingh · Accepted solution]

Hi Jonathan,

Have you tried Transaction SWU7 to check the consistency of WF template.

Can you try transporting the workbench request (having this workflow change )contents from Client 600 to 100 using Transaction SCC1. I know this might not make sense to move workbench entries but the issue you are getting is also very strange. No harm in trying.

You can also try to transport the WF definition from DEV to QAS and verify the results.

Let us know the results

Reward points if helpful

Regards

Sandy

[SandySingh · Accepted solution]

Hi Jonathan,

You can also try following report program.

RSWDACT0                       WF: Activate Workflow Definition(s) Without Workflow Editor

RSWDACTIVATE                Activate Versions of a Workflow Definition

If dont  have access to these reports, use FM

CALL FUNCTION 'SWD_ACTIVATE_WORKFLOW'

   EXPORTING

     act_task                = l_task

     act_wfdkey              = l_wfdkey

   EXCEPTIONS

     internal_database_error = 1

     OTHERS                  = 2.

Regards

Sandy

[Former Member · Accepted solution]

Hi Sandy,

The consistency was checked using SWUD which is the same thing. In dev client, it's all green, in test client it says "Workflow definition does not exist", like before.

A colleague gave the same hint of transporting the workbench TR in test client, but because it's workbench, SCC1 fell into error, so no luck there.

Thanks for the program suggestions! RSWDACT0 refused to activate, so I debugged it and found out there were ghost locks from user WF-BATCH, on two versions of the WF definition at the same time. I removed them in SM12. It didn't seem to solve the issue, so there must also be another issue, but at least this is one out of the way, thank you!

We eventually resorted to transporting to quality system. Everything seems fine over there, we'll run some tests to be sure. In the end we'll still have to find out what's wrong in dev, but at least we can move on for now. I'll let you guys know when we get more explanation about what's wrong in test client.

Regards,

Jonathan

[SandySingh · Accepted solution]

Hi Jonathan

If the WF definition was locked then use FM SWD_WFD_DEQUEUE to unlock it. Then activate it in client 600 and run swu_obuf in both Client 600 and 100.

May be manual deletion via SM12 is not working as expected.

We will wait for your response.

If nothing works then I agree with Karri suggestion to open up the client and activate.

Regards

Sandy

[Former Member · Accepted solution]

Hi Sandy,

Indeed SM12 didn't act as I thought. At first it didn't show the locks anymore after I deleted them, but they reappared later - but still with the same old date, not the current one. On a hunch, we checked SM50 and found out there was an old job on WF_BATCH user (same than locks' owner) that started like a month ago and was still running.

We killed it, removed the locks, and at first it didn't seem to make a difference, but after I generated a new version of the WF template, everything is now fine. Activation works in both clients, and transactions aren't buggy anymore.

Hopefully this might help anyone facing similar troubles!

Thanks everyone for taking time to answer and setting us on the path to solve this!

Kr,

Jonathan

[SandySingh · Accepted solution]

Hi Jonathan

Thanks for your response. I am glad to hear that you finally managed to resolve this issue.

It makes a lot of sense why WF-BATCH should not be used as batch user responsible for WF background jobs. I have noticed in few customer sites, a separate batch user is used for WF background jobs.

Thanks

Regards

Sandy

[former_member185167 · Accepted solution]

Thanks for the update. What was this WF-BATCH job and do you know why it was still running?

[Former Member]

I remember having some strange problems between two clients. The development client was working fine, but the test client not so (the template was somehow corrupted in the test client). I can't remember the details, but finally I just opened the test client for configuration & development, did some small change to the WF template, and then activated the template. => Everything was back to normal. (Of course I had an unnecessary transport in a wrong client etc., but that was easy to clear out.)

Perhaps you already tried this, but if not, worth to try (in addition to the great hints from Rob, Mike and Sandy).

Kind regards,

Karri

[pokrakam]

Hi Jonathan,

Sounds like could be a corruption of sorts. In the bad old days (<=4.7) it happened more frequently but every now and again it still happens. It's unusual that it's client-dependent like that.

You didn't mention the results of going into SWDD in the iffy client and activating there, but if won't activate in SWDD, take out a chunk of the WF, try again. If it still doesn't work, undo and take out another chunk. Eventually isolate a a processing block (loop or whatever) that's gone wonky. Reactivate, rebuild loop or whatever by hand, be happy.

Last resort: copy to new template.

Last last resort: rebuild as new template.

Hope that helps,

Mike

[Former Member]

Hello Mike,

Our client 100 doesn't allow for modifications, so I can't activate there (SWDD gives warning message TK730 when opened).

Building a new template isn't really an option in our case, as it would require quite a bit of changes in other parts of our applications. Removing steps from the workflow until it activates properly is risky (really have to make sure we rebuild it properly afterwards), so it's a last resort as you say - but we'll keep it in mind, thanks!

Regards,

Jonathan

[pokrakam]

Hi Jonathan,

Building a new template isn't really an option in our case, as it would require quite a bit of changes in other parts of our applications. 

Don't tell me you have the template ID hardcoded all over the place? If so, consider it an opportunity to replace all your 'WS900000212' with a more maintainable constant ZCL_MYOBJECT=>APPROVAL_WF

Otherwise perhaps you are overestimating the implications? All it should mean is a new template, the tasks stay the same. Any reports that look for results of task TS900000234 (which you should have a constant for ZCL_MYOBJECT=>APPROVAL_TASK in any case), should run as before.

Removing steps from the workflow until it activates properly is risky (really have to make sure we rebuild it properly afterwards)

Not really that risky. Removing steps is version-dependent, so just create a new version and play around with that one. It might be worth asking for the other client to be opened to speed things along. Once you have found the offending block (assuming this is the problem), revert back to the earlier version and generate another new version from that one. Delete the loop or whatever, rebuild it. (A technique here is to add a dummy section to your WF, copy/paste all the steps from the corrupt section into it, delete the corrupt section, recreate and paste your steps back in).

As before, all tasks etc should stay the same and external reports work as before. This should normally be an hour's exercise at most.

Hope that helps,

Mike

[Former Member]

Hello Mike,

Fortunately, I was indeed overestimating the impact. The constant already existed, but wasn't used yet in two spots only. A quick check with the source scan, it this was corrected. Now we'll have it easier if it comes to creating a new template.

Thanks for reminding me about creating a new version as backup, it did indeed help. I cut and pasted the steps around, and it eventually revealed that an old loop and a decision triggered errors ("illegal line ID in LVAL table", "illegal node ID in line table", stuff like that). I deleted them, then recreated them using the backup as model, and now the errors are gone.

In the test client, the corrected version now appears as active in PFTC - however, the consistency check continues to give the "Workflow definition does not exist" error. Clearing the buffers etc like before doesn't seem to help. So we're a step closer, but not completely safe yet. I'll keep trying, maybe I missed another faulty step.

Thanks for your help!

Regards,

Jonathan

[pokrakam]

Hi Jonathan,

Glad you're making progress. You've probably tried this, but: have you generated a completely new version and seen if that appears in the test client?

Failing that I'd debug he WF builder. Get the message number, SWDD, "/h", generate. When the debugger appears, set a breakpoint at the message ID/number. Then let it go, and hopefully it will stop where the message is raised. Perhaps the code will point to a missing table entry or something...

Regards,

Mike

[former_member186746]

Hi Jonathan,

In some rare cases "something" goes wrong when importing a workflow definition.

For these cases SAP has provided the function module SWD_WFD_REPLICATE_FROM_9999

Check if this solves the problem.

If not then you might have to raise an oss message with SAP.

Kind regards, Rob Dielemans

[former_member186746]

I just read that it is the same machine but different clients.

Agent assignment is client specific. You can add them in a transport with report RHMOVE30 and also try to use /$tab and /$sync for weird problems.

Regards, Rob.

[Former Member]

Hello Rob,

Thanks for taking time to answer. Indeed it's the same system, so we don't transport.

I didn't know about $tab and $sync, thanks! Unfortunately that didn't make a difference.

Regards,

Jonathan