Need to set up 2 config scenarios on 1 QAS client

[AndyW]

Hi

We are running R/3 4.6C and XI 3.0.

I have the following BPM scenario:
RFC -> BPM -> SOAP -> Non-SAP system (NSS) -> SOAP -> IDoc.

Our R/3 landscape is: 2 Dev clients (030 and 041), 1 QAS client (010) and 1 PRD cleint (010). Our XI landscape is: 1 Dev/QAS (XID) server and 1 PRD server (XIP).

The NSS currently has a UAT environment which I have successfully working against QAS . However, a new requirement has been raised to set up a Training system (TRN) on the NSS and they want to hook this into QAS. This needs to run concurrently with the UAT environment.

I thought this would be simple enough to do - just create a new RFC destination in R/3 and setup a new configuration scenario in XI etc. However, this won't work because I can only create one Receiver Determination for the RFC on QAS (only 1 client so only 1 Business System). This RD can therefore either point to the UAT BPM or the QAS BPM but not both.

I have considered the following solutions - none of which fill me with joy:

1. Try to pass a parameter to the RFC from the ABAP that calls it that allows me to use the conditions in the RD i.e. if flag = X then use QAS otherwise use TRN. Not sure that this is even possible though.
2. Create a second copy of the RFC so I can create a second RD. But this would mean creating new design time objects for mapping etc.
3. For the UAT and TRN scenarios, make use of the Receiver Service field in the RD to allow multiple RDs for the RFC in QAS - assuming I've understood correctly how this field works

Hope that all makes sense - any comments on these solutions or suggestions for a fourth way would be gratefully appreciated!

Thanks

Andrew

[Baz]

have you looked at the extended receiver determination?

This may serve your purpose.

[AndyW]

Hi Baz

I hadn't but I have now. However, I don't think this will help because I know the names of the receivers at config time i.e they don't need to be determined dynamically. The problem is more about identifying which one to use. Unless I'm missing the point - which is always a possiblity. I could use the 'conditions' of the Standard option for this but can't figure out how to tell which route (UAT or TRN) to take.

I'll try creating two Receiver Determinations; one with a Receiver Service specified in the key for the UAT BPM and another for the TRN BPM. I've tried this before but without much success so not very hopeful!

Cheers

Andy

[Baz]

Andy

how are you go to determing with system to post to?
Is there a field in the payload?

How about the option of creating a new QA client? or is that too drastic?

[AndyW]

Hi Baz

In answer to your 1st question...
I've got two RFC destination set up on R/3 with two unique Program IDs. This allows me to have two RFC sender adapters for QAS and I've consequently got 2 configuration scenarios, the idea being that one will connect QAS to UAT and one will connect QAS to TRN.

At the moment I have the following RD:
Sender Service = QAS
Sender Interface = Z_RFC
Receiver Service = *
With a Configured Receiver = BPM_UAT

I obviously can't duplicate this exactly with a configured receiver = BPM_TRN. However, would the following work...
Sender Service = QAS
Sender Interface = Z_RFC
Receiver Service = UAT_SYSTEM
With a Configured Receiver = BPM_UAT

Sender Service = QAS
Sender Interface = Z_RFC
Receiver Service = TRN_SYSTEM
With a Configured Receiver = BPM_TRN

By not using the wildcard in the Receiver Service I can create unique RDs for UAT and TRN. That's my theory anyway!

In answer to your second...
There is a field in the payload but it doesn't contain any data. Hmm, better explain that. The sole purpose of the RFC is to trigger a call to the SOAP web service at regular intervals. There is an Import param. on the RFC (because I think there has to be) and interestingly I pass a value to it when the ABAP calls the Function but this never appears in the payload. This has made me question my understanding of how RFCs work with XI because it seems to me that although the inital function call is made in an ABAP, XI is actually doing the call...maybe.

In answer to your 3rd question...
I wish. It was raised recently but I can;t see it ahppenign any time soon.