on 08-30-2007 4:11 PM
All,
Stuck with a few issues with Idoc Acknowledgments which I hope SDN can help me with. For ease of understanding the problem, am splitting this into 2 Scenarios ,
<u><b>Scenario 1</b></u>
<b>SAP R3 (Idoc ) - XI - File ( Business Service)</b>
R3 Triggers Idoc to XI and XI sends this as a File to the target Application. AleAdudits can be sent back to the R3 system as shown in <a href="/people/saravanakumar.kuppusamy2/blog/2005/01/20/configuration-tips-for-a-business-serviceintegration-process-to-send-back-ale-audit-idoc">this</a> blog by Saravana by adding the Logical System Name to the Business Service.
<u><b>Issue :</b></u>
R3 has configured Partner Profile with respect to XI and this cannot be changed. To send the Idoc Ack's back to R3 we need to add the Corresponding Logical System Name to the Business Service.
The problem is - what if the Idoc is to be sent to 2 Different Business Service / Systems. The R3 expects an Acknowledgment with XI as the sender partner but we cannot share the same logical system across different Business Systems / services . The easiest solution seems to be to create different partner profiles in R3, one for each Business System / Service. But this is not possible currently.
<u><b>Scenario 2: </b></u>
<b>R3 - XI - BPM - Target</b>
Idoc triggered from R3, are sent to a BPM and then from the BPM to a file. Everything works fine.
But, the problem lies that when the Ack needs to be sent back to R3, The ack errors out because no Logical System Name is associated with the BPM.
We do not want to add another logical system name to the BPM and thereby create another partner profile and the problem is similar to Scenario 1.
<u><b>Solutions Explored</b></u>
1. In the ACK_IDOCAdapter , I tried to select option Take Sender From Payload and Take Receiver from Payload.
But this does not seem to help. I can see the trace in MONI saying the ACK_IDOC adapter is choosen to send the ack back to R3 , but it does not take the Partner Names from the payload of the AleAdudit and errors out with error <i>Unable to convert..</i>
2. As this AleAduit is sent from XI back to R3 and is not a R3 (AleAduit) - XI - R3 (aleaduit) case, adding a entry as shown in Section 6 in
<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/903a0abc-e56e-2910-51a8-9dc616df56eb">this</a> document will not help.
Has anyone tried something of this sort. Any known solutions?
I hope the description of the problem made sense, if no, do let me know.
Regards
Bhavesh
higher,
I don't recommend the crude way of doing through ccBPM if you are on a higher version of SP Level. I think it should be possible through the idoc adapter parameters and probably some configurations are missing but unfortunately our systems are < sp 15 and hence I can't really figure out the exact problem.
<b>If you set the relevant indicator, the original partners from the IDoc request message are used for acknowledgments. This means you no longer have to maintain the alternative identifiers (for party conversion) in the Integration Directory.</b>..Did you check this indicator?
I would recommend you to raise a SAP note as you are on version SP14 than opting for a work around once you have explored the options.
How many BPM/Idoc interfaces are there ? Why you don't want to create seperate LS for different business service? Is there any rationale behind?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sravya,
The restore party for Original Ack's is available from SP 17 and we are on Sp 16. Am not sure of the exact use of this parameter though but I think this parameter is to send Idoc Ack's for Non LS Partner Profiles like KU etc ( Party ) and if my understanding is correct then this parameter is not going to help us.
Also, if our understanding is correct the options Take Sender From Payload and Take Receiver from Payload should have done the trick but it did not. Looks like an OSS with SAP is what we next need to look at. Thanks once again.
Will update if I do learn something new along the way.
Regards
Bhavesh
As for the other issue of multiple Business Services and not wanting to create multiple Partner Profiles, well I know it aint ideal but partner profiles are created with respect to XI and not with respect to the End Systems and it is too late ( as we have multiple interfaces in production) to make this change now.
But we are analysing this option as well and have not ruled it out.
Regards
Bhavesh
@ Sravya and all,
<b>The restore parties for Idoc Acknowledgements</b> does the trick.
We are on SP 16 so we cannot use this option but I tried this on another PI 7.0 SP 10 server and it works as needed. My understanding of Restore Parties for idoc ack's was incorrect.
It is actually used to swap the Sender Partner Name and Receiver Partner name of the source Idoc into the AleAudit's Receiver Partner Name and Sender Partner Name respectively.
Hope this info helps to all going forward.
Regards
Bhavesh
Bhavesh..let us chat over this in the weekend as that's better:)..Have a great weekend.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Bhavesh,
Your problem as i understand -> <i>The problem is - what if the Idoc is to be sent to 2 Different Business Service / Systems. The R3 expects an Acknowledgment with XI as the sender partner but we cannot share the same logical system across different Business Systems / services . The easiest solution seems to be to create different partner profiles in R3, one for each Business System / Service. But this is not possible currently.
</i>
If the IDOC is sent to 2 different business services/systems/Integration Processes, then it is very logical that an ALEAUDIT be sent for each of these business systems/services. Ideally, you SHOULD NOT look at sending a common ALEAUDIT for different recievers in XI, the reason being, failures could happen only for one receiver and NOT for others. Failure could be in the mapping/content conversion. I am assuming here that you are configuring XI to send back "ALEAUDITs" only for System Error Acks(hoping it is possible, since i see 3 XXXs in the IDXNOALE table).
So, it is logical that you configure a different LS in R/3 for each reciever system/service/IP, all these LS's will have one entry for ALEAUDIT in the Inbound params entered in WE20.
If your intention is to send ALEAUDITs back only in case of errors, it makes sense to create an entry for each receiver in R/3. If not, then it is a limitation.
Regards
Saravana
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Udo's design should still work in your case with slight tweaking even if your XI version is less than SP14.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sravya,
We are on SP 16. I tried the option, Take sender from Payload and receiver from Payload , but this does not seem to work with the AleAduits trigerred by XI automatically.
Maybe a bug?
@Madhu,
The Aleduits are triggered by XI . We cannot create a message as this is more of a System Ack triggered by XI automatically and so Receiver Determination for AleAduits is not needed and thereby no Receiver Agreements and no header mapping possible.
Regards
Bhavesh
which version of the stack ur in?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Bhavesh,
Why don't you try using Header mapping in Reciver agrrement ,there you can provide your original sender or reciver ,business Service or party.
Thanks,
Madhu
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Did you have a look at this /people/udo.martens/blog/2005/09/30/one-logical-system-name-for-serveral-bpm-acknowledgements
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sravya,
Thanks for the reply. I did explore that option explained by Udo in his blog.
The blog is specifically to one Scenario where a Synchronous Call is made to a Database and then from the BPM a ALEADUIT is manually populated in a mapping and sent back to SAP.
The AleAduits we are exploring is the ones that XI triggers automatically back to R3 as soon as the Business Process is complete in XI. ( More of a System Acknowledgement) . Udo in his blog explores Sending an Application Ack.
Regards
Bhavesh
Bhavesh
Could you not set up a generic business system in the SLD and share this between the two file locations? Then it could share the same Logical system name.
It may seem a bit "round peg for a square hole" but may fulfil your requirements.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Barry,
The understanding I got is, it is the Receiver Determination that plays a very important role.
Assume 3 Receiver Determinations,
SAP - XI - BPM A
SAP - XI - BPM B
SAP - XI - Business Service X .
When XI tried to send the AleAduits back, it tries to use the Corresponding Business Systems / Services in the Receiver determinations as the Sender Systems.
So, BPM A , BPM B and Business Service X --> All three act as the Sender Business Systems while sending ALEAUDITS back to R3 and I cant have 3 Logical System Names or keep increasing them every time I add a BPM to my implementations.
I am hoping and praying for a clean solution. Some solution which we/ I have not explored is what I am hoping for.
Regards
Bhavesh
User | Count |
---|---|
88 | |
10 | |
10 | |
9 | |
7 | |
7 | |
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.