cancel
Showing results for 
Search instead for 
Did you mean: 

WORKFLOW_LOCAL_XXX gets deleted

former_member271560
Discoverer
0 Kudos

Hi,

To enable logon load balancing for our workflow, we have implemented SAP note "888279 - Regulating/distributing the workflow load" bullet point 2.

To do so we deleted the type L WORKFLOW_LOCAL_XXX destination in SM59 and recreated it as a type 3 (ABAP) connection instead, enabling load balancing via a logon group in which we have put the application servers where we want workflow to run. We had to do RFC enable in SMLG for that logon group as well.

It worked fine for a long time until someone needed to run SWU3, WORKFLOW Configuration again.

I don't know why it was needed to run the WF config again but what it did was obviously to check for the existence of a WORKFLOW_LOCAL_XXX destination of the type logical and when it did not find that (as ours is of type ABAP) it deleted the existing one and recreated it as destination, type L.

Is there any way to prevent this from happening again, in case someone needs to run the WF config. again?

One would think that SAP should be able to implement a check in SWU3, if the WF destination exists of any type, and if so, ask if it should use the already existing one or recreate the default type L destination.

Would be interesting to hear the thoughts from the world.

Thanks in advance!

Regards,

Dan Michaeli

Tetra Pak, Sweden

Accepted Solutions (0)

Answers (1)

Answers (1)

I042439
Employee
Employee
0 Kudos

Hi Dan

The answer to your query is referenced in your note (888279), in the related SAP Notes. Refer note: 1461891 - SWU3: Checking the RFC destination

Another work around is to restrict the access to SWU3 to Workflow Admins only (who knows that a separate Logical Destination of type 3 already exists). Normally, access to this transaction is not provided to  many users.

Regards,

Modak

former_member271560
Discoverer
0 Kudos

Hi Modak and thanks for your answer.

Yes, I found that note as well shortly after I posted my question.

Since we ran SWU3 the previous time, thus causing the issue I described above, we have upgraded our system to 7.40, so as far as I understand, we should have this note in the system.

I tested this in our QA system but the result puzzles me. When running SWU3, specifically the "Maintain RFC Destination" I still get an error saying two things:

     1) RFC Destination does not exist

     2) RFC Destination has wrong client

Neither one of these statements is correct and the end result is that the SWU3 run is marked as failed.

The good thing is that it at least did not delete teh type 3 connection but somehow we managed to make it reset the WB-BATCH password back to initial, so all WF started failing in the QA system after our test. 😞

Took some minutes before we had that figured out.

So now we are very cautious when testing/playing with this!

Am I wrong in assuming that the note is implemented in my system just because it is said that it is valid up to 7.20 and we are on 7.40? Or have I misunderstood something else?

By the way: SWU3 is very restricted, more or less to my team only, and it was actually one of the guys in my team running it without realizing the consequences it had. None of us did to start with.

Thanks for your assistance!

Regards,

Dan

I042439
Employee
Employee
0 Kudos

Hi Dan

Check what you have for SAP_BASIS component - 720 or 740?

We all learnt from this chance accident of yours 🙂

Regards,

Modak