on 10-01-2015 10:11 AM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
User | Count |
---|---|
81 | |
10 | |
10 | |
9 | |
7 | |
6 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.