cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Error - Inconsistent workflow definition: Node/step no. 152 is not avaiable

glauco
Active Contributor
0 Likes
1,198

Friends,

I've changed a workflow geting out this task that was a wait for event type in a fork's leg. I've activated and I'm testing it but it now is geting this error message:

"Inconsistent workflow definition: Node/step no. 152 is not available"

"ROLLBACK WORK executed (SWP_CALLBACK_WI_DONE item 6)"

I'm sure that the workflow was activated and no errors is shown by it.

Why is it geting error if I deleted this task ? It is happening for workflows started before the request had beem transported to test system.

Is it about version management ? Because version is always 000 ?

I'm using 46C.

Message was edited by:

Glauco Kubrusly

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Likes

also,

if you delete a step in a definition, let's say step 152. And this step number is used in another wf step, then this will cause errors.

Kind regards, Rob Dielemans

Answers (2)

Answers (2)

Former Member
0 Likes

Hi GLauco,

This is probably caused by an error in the workflow definition, maybe the development system uses local objects, or maybe not all of the objects were trasnsported.

Check the transport log to for errors.

you can also enter the workflow definition in PFTC, then click display and then in the menu goto --> Workflow builder --> Choose version, to select a version and see it in the builder.

Kind regards, Rob Dielemans

glauco
Active Contributor
0 Likes

Hi Rob,

I forgot to tell you that I think it is happening because I'm testing the workflow in the test system yet and I haven't transportate it yet (This is the same development system. I develop it on 200 and test it on 220 by copying the changes by scc1. It isn't a transport but a copy of mandants).

Thanks for your help and I will try to transport to production. After that we can talk again.

pokrakam
Active Contributor
0 Likes

What, no QA system? Crikey, you guys do like living on the edge - that's just asking for trouble!

glauco
Active Contributor
0 Likes

Yes, The transport path pass by QA System too.

pokrakam
Active Contributor
0 Likes

Hello Glauco,

Yes thi sis because in DEV it will not automatically generate a new version. Therefore old workflows still use the same version and try to execute a step which you have deleted.

Always use new workflows for testing in DEV. A new version is automatically generated in the TARGET system on transport so this should not be a problem. A good practice if you are unsure when transporting to QA, is to make sure you have a workflow started just before transport. Run this to completion after trasport (dont' forget SWU_OBUF) and make sure everything works. If not, you're probably better off copying your WF to a new one.

Hope this helps,

Mike

glauco
Active Contributor
0 Likes

Hi Mike, as you have said that this should not be a problem, I'm afraid of it happen yet.

I've changed on developement system and I have tested it on test system, that is the same system but different client and I had copied it by scc1 transaction.

Do you steel thinking the same...that this should not be a problem when transport to production ?

One extrange thing is that I can't see what is the version in production on PFTC because there I can't display my workflow. I don't know why is it happening because it had beem transported and it is working since last August. On PFTC I can select WS type and put the task number, but when I click on display, this get me a message saying that it doesn't exist.

pokrakam
Active Contributor
0 Likes

Hi Glauco,

Yes, removing a step should not cause a problem when you transport it if you're not doing much else. Have a look at note 125000 (I think - just search for "modifying workflow" if it's not the one).

If in doubt about whether a change is compatible, copy to a new workflow. Your error message is a bit odd - perhaps you can get to the transaction but are missing some authorizations?

Cheers,

Mike

glauco
Active Contributor
0 Likes

Hi Mike, Are you sure that this error won't occur in production ? Can I transporte it ?

I'm afraid of that.

About the note, I didn't find any note about it.

pokrakam
Active Contributor
0 Likes

Hi Glauco,

OK, so the number was wrong, but not difficult to find. I went to OSS and typed in "modifying workflow" and the first result was:

125400 Modifying a productive Workflow

As I suggested if you are in any doubt whatsoever then test. Make sure you started a WF in QA before transporting your change. If you have any problems or are still unsure then copy your WS to a new workflow, deactivate the old one and use the new one. Normally deleting a step is no problem (unless you also delete the object method) since the template definition is version dependent.

Cheers,

Mike

glauco
Active Contributor
0 Likes

Hi Mike,

This discussion is very interesting to me.

I think it was a good idea copying the WS...But I will try it only in last instance.

I think it is happening because I'm testing the workflow in the test system (This is the same development system. I develop it on 200 and test it on 220 by copying the changes by scc1. It isn't a transport but a copy of mandants).

I think you said about the target system that creates a new version after transport and has a good logic and I think we can try it before another solutions.

thank you very much.

pokrakam
Active Contributor
0 Likes

Hi Glauco,

Glad you found it useful. You are correct, if you are testing in the same SYSTEM then you will have problems that you do not have when you transport. This is because it doesn't generate new versions. Either: always test with a new workflow, or generate a new version before making any major changes. Generating a new version is good practice in any case as you can go back through the changes you've made.

Cheers,

Mike