Separation of iFlows using iDoc party setup? PI AEX

[JaySchwendemann]

Hi all,

we have the following situation. We are sending ORDERS.ORDERS05 IDocs from ERP to PI 7.4 AEX and from there to multiple receivers. Some go to SNC, other do "direct communication" with the respective supplier

1. ERP (IDoc) --> PI --> SNC (ABAP Proxy)

2. ERP (IDoc) --> PI --> Supplier 1 (HTTP_AAE)

3. ERP (IDoc) --> PI --> Supplier 2 (HTTP_AAE)

...

The control records of the IDocs that are sent from ERP look like this:

1. To SCN

MESFCT = SNC

SNDPOR = ERPSYS

SNDPRN = LOGERP

SNDPRT = LS

SNDPFC = <empty>

RCVPOR = PISYS

RCVPRN = 1234 (Party number of one supplier that is handled by SNC)

RCVPRT = LI

RCVPFC = LF

2. To Supplier 1

MESFCT = EDI

SNDPOR = ERPSYS

SNDPRN = LOGERP

SNDPRT = LS

SNDPFC = <empty>

RCVPOR = PISYS

RCVPRN = 4321(Party number of the supplier 1 that does direct communication)

RCVPRT = LI

RCVPFC = LF

The first scenario to SNC already existed and was built using an iFlow and standard XI Content provided by SAP (SNC inbound interface is ReplenishmentOrderNotification_In). Let's assume the name is "iFlow_SNC"

Now if i want to add the second scenario with direct communication to supplier to a new iFlow (say "iFlow_EDI_1") NWDS doesn't let me do this because the sender service and sender interface are already in use by "iFlow_SNC". I know I can just add interfaces to that iFlow_SNC and use receiver split with XPath to route to the correct receiver but I hesitate to do so because when looking into future we may have say 100 suppliers and the iFlow will get hard to maintain by then.

Questions:

1. Are there any best practice to deal with such situations (Same IDoc sender system / service to multiple receiver)

2. I fiddled around with parties (assigning the business system of ERP to a party and then creating a new iFlow based on that) but as you might expect, still iFlow_SNC gets chosen and routing fails because there is no rule for supplier 1 there. Is Party setup the right way here? If so, what did I do wrong?

Many thanks and kind regards

Jens

[engswee · Accepted solution]

Hi Jens

As you are using partner type LI for the IDoc partner profile, your scenario is exactly the type of scenario that should use party object and virtual receiver.

Please refer to the following threads where I have the usage of virtual receiver for interfaces that have same sender system and sender IDoc but different receiver.

Unfortunately, not many organisation/developer is aware of this concept, and the workarounds to enable multiple receivers end up being difficult to maintain/extend. The two common approaches are:

1) Use single receiver determination with multiple conditions for each receiver - adding/removing new receivers require editing this "common" object which sometimes can lead to unwanted results (i.e. transporting a condition that is not ready for Production yet into Production!)

2) Using enhanced receiver determination to use a message mapping to perform RFC/JDBC lookup on a database table to determine receiver.

Anyway, to cut the story short, for each IDoc partner

i) create a Party to represent the partner and maintain the IDoc partner details under the Party identifier

ii) create a separate iFlow object which uses the Party above as a virtual receiver

The Wiki by Harish also elaborates more on this.

Also, you do not need a Party object for the ERP business system. So the generated ICO will have something like this:-

Sender Party = <blank>

Sender Component = ERP

Sender Interface = ORDERS05 (with IDoc namespace)

Virtual Receiver Party = Party object (i.e. for RCVPRN 1234 to SNC)

Note also that the actual Receiver Component in the Receiver Determination step of the ICO does not necessarily have to be the same value of the Virtual Receiver.

Rgds

Eng Swee

[JaySchwendemann · Accepted solution]

Hi Eng Swee / all

thanks a heap for the very detailed explanation. Great information as always. I'm wondering why this great feature isn't more widely known / adopted. Granted that SAP managed to give us a slightly hard time to set this up correctly which may be part of the answer already given

Anyways, I'm currently trying to get this  working. However, I'm struggling on 2 points.

1. Is virtual receiver supported by iFlows? Don't seem to find it. If not, is there a workaround / hack to use virtual receivers with ICO and still have a iFlow "kind of visual representation, even if that means I had to maintain this in swing tools"? Generally I'm headed over to NWDS using iFlow and would like to see configuration there and not having to switch to SWING tools. Of course, this easily could be a limitation of NWDS, and there may be no workaround. Just asking and being that curious pain in the neck type of guy as always

2. Would I also need to adapt the current iflow (or ICO, see bulletpoint 1) for SNC also with virtual receivers for the whole lot to function or should the system be able to cope with one "ordinary" ICO (iflow) and say 10 virtual receiver ICOs.?

Many thanks and a nice weekend to all

Cheers

Jens

[engswee · Accepted solution]

Hi Jens

I've also wondered why this has not been widely adopted. I've been at organizations where the initial design for B2B integration using IDocs were done by SAP Consulting, and even they themselves did not use this approach - which then of course leads to all sorts of issue when extending/maintaining these interfaces... sigh

Anyway, to answer your questions:-

1) Yes, this is supported in iFlow - although as per my experience as well, features in iFlow are sometimes "buried" within certain contexts and not that intuitive or easily found!

You can find it under Properties tab if you select the Sender Business System/Component

2) Yes, it should be possible to have 1 common ICO and multiple virtual receiver ICOs. The system would try to resolve the correct party object from the IDoc control data and determine which virtual receive ICO to use. If it cannot resolve, then it should fall back to the common ICO.

You might need to test out this part a bit because I'm not sure for the common ICO, you can use a normal ICO with virtual receiver (which will have blank values for receiver party/component) or you need to have * wildcards for receiver party/component as shown below. You can refer a bit more to the SAP note mentioned by Tom in the thread above.

If you will indulge me a lil bit more, I would like to suggest some further tweaks to your design - you can assess if it's feasible. Since the IDoc to SNC is considered an A2A scenario (as compared to IDoc to external party which is B2B), I'd suggest that for those IDocs to SNC, it uses a Logical System (LS) partner profile representing the SNC system. If you go this route, then the "ordinary" ICO to SNC does not require virtual receiver as virtual receiver resolution is only done for non-LS IDocs.

Rgds

Eng Swee

[JaySchwendemann · Accepted solution]

This message was moderated.

[JaySchwendemann · Accepted solution]

Hi Eng Swee / all,

sorry for the delay in answering, had get another project going 🙂

I yesterday composed a quite extensive post about the current situation. However, that got rejected for unknown reasons by the mods. Anyhow, I'll try again.

It seems that setting the value ResolveVirtualReceiver = true from the note http://service.sap.com/sap/support/notes/1941832 has quite a big impact on how this works on an PI 7.4 AEX (SP 7).

Reminder: I now have the following setup:

• iFlow_SNC = Old iFlow, points to SNC, does not use virtual receivers
• iFlow_Supplier1 = New iFlow, points to Supplier1, uses virtual receivers

Case 1 - ResolveVirtualReceiver = false (default):

XPI Inspector Trace:

Location	Message
~onUtil.InboundPartnerConversionUtil	⇦ with (<ERPSYS>, <ERP Client>, <LOGERP>, LS, )
~versionUtil.getInboundSenderService	Quering for service with technical system identifier <ERP SID>#<ERP Client>
~versionUtil.getInboundSenderService	Found service with name <ERP Business System> and id <Some ID>
~nboundProcessor.findPartyAndService	Sender service found: <ERP Business System>
~onversionUtil.getInboundSenderParty	No party as sender partner type isLS

==> So I think virtual receivers just getting ignored.

Case 2 - ResolveVirtualReceiver = true:

XPI Inspector Trace:

<same logging as in case 1>

Location	Message
<same logging as in case 1>
~onversionUtil.getInboundSenderParty	No party as sender partner type isLS
~versionUtil.getVirtualReceiverParty	Found party with name <Supplier 1 party> and id <some ID>
~versionUtil.getVirtualReceiverParty	⇨ with com.sap.aii.af.service.cpa.impl.object.PartyImpl@eb2fb694 with ID=<some ID>
~nboundProcessor.findPartyAndService	Receiver party found: <Supplier 1 party>
~oundProcessor.findBindingAndChannel	⇦
~oundProcessor.findBindingAndChannel	[EXCEPTION] com.sap.aii.af.service.cpa.CPAObjectNotFoundException: Couldn't retrieve inbound binding for the given P/S/A values: FP=;TP=<Supplier 1 Party>;FS=<ERP Business System>;TS=;AN=ORDERS.ORDERS05;ANS=urn:sap-com:document:sap:idoc:messages;

==> So now the party gets derived from the virtual receivers which is great. But the TS (ToService) is empty. However, when assigning the virtual receiver to the iFlow I had to have a business component for that party set up in NWDS. Else it wouldn't show the party in the selection window. Also there doesn't seem to be the posibility to just erase the business component in virtual receiver assignment within NWDS. Is this a limitation?

I also discovered that with ResolveVirtualReceiver = true for EVERY IDoc which could not be derived to a party the message on PI will contain the party number as a party (which is excpected as described in the note http://service.sap.com/sap/support/notes/1941832), hence all messages that should just got to SNC will fail, or I would need to setup like 300 parties for them. I think this is not feasible. Eng Swee, you wrote about LS partner profile and the "ordinary" ICO but I didn't quite understand that, I'm afraid. Would we need to change our partner profiles in ERP for that?

Currently the IDocs / partner profiles that need to go to the suppliers (B2B) only differ in message function (MESFCT) which is "EDI" for B2B and "SNC" for A2A process.

So I'm still kinda stuck here. My guts feeling is that AEX is operating slightly different than Dual Stack when it comes to party (B2B) setup, also I may have some work to do on the partner profiles in ERP.

Many thanks in advance. I would really appreciate some additional advice. Lucky me, this integration is not time-critical so I may play a little with the features of PI.

Cheers

Jens

[engswee · Accepted solution]

Hi Jens

Sorry for the late response, I've been away for a while too. Hope this integration has not become time critical in the meantime

The IDoc partner profiles in the ERP system have to be adjusted too.

For SupplierX,Y,Z, use partner type LI - this would trigger the virtual receiver resolution in PI/AEX

For SNC, use partner type LS - this would not trigger the virtual receiver resolution, therefore you don't need to setup the 300 parties for SNC.

For the party setup, yes you do need at least 1 business component under a party for it to be available for selection. From PI's perspective, sender/receiver systems are always at component level - the additional party is just to indicate that the component belongs to an "external" company.

I think you are nearly there, just need to tweak the ERP partner profile part.

Rgds

Eng Swee

[JaySchwendemann · Accepted solution]

Hi Eng Swee,

thanks again for your valuable input. I managed to switch the partner for SLD to use Logical System. That was a little harder than thought but that's a subject for another story (maybe I'll blog about that some time)

So with "ResolveVirtualReceiver = true" the system *nearly* behaves as wanted.

• If I send an IDoc with partner type = LS it gets processed by SNC iFlow (the one without Virtual Receiver setup). So that is working now
  --> Awesome
  
• If I send an IDoc with partner type = LI it doesn't get processed by Supplier 1 iFlow. I get this error within nwa/logs I already experienced on my former tests:
  

  
  Couldn't retrieve inbound binding for the given P/S/A values: FP=;TP=<Supplier 1 Party>;FS=<ERP Business System>;TS=;AN=ORDERS.ORDERS05;ANS=urn:sap-com:document:sap:idoc:messages;
  

  --> Not so awesome
  

As already said, problem here is that message is sent with TS = "", which funnily enough is mentioned in the note http://service.sap.com/sap/support/notes/1941832 and also given a "solution"

Excerpt:

The receiver service is always set as empty in the XI message header, it can be matched with a binding with * as a virtual receiver service

The problem now seems to be that NWDS / iFlow doesn't let you put in a "*" (asterisk) for a virtual receiver communication component. Also trying to trick the system by simply creating a communication component named "*" under "Supplier 1" party is not allowed.

I could even verify that the underlying PI stuff works by creating an ICO manually in ID with the following data:

Sender Party       = <empty>

Sender Component   = <ERP Business System>

Sender Interface   = ORDERS.ORDERS05

Sender Namespace   = urn:sap-com:document:sap:idoc:messages

--> Use Virtual Receiver

Receiver Party     = <Supplier 1 Party>

Receiver Component = *

Conclusion:

It seems that the inability to input a asterisk to the virtual receiver communication component result in the error given above. I will raise an incident for this, I suppose. I'm currently on NWDS 7.3 SP12 PAT0000. Maybe you or someone else could verify that this problem exists / is solved in a later release of NWDS?

I will let you know about the outcome of the incident. Many thanks again for the great help so far.

Wouldn't have thought that this'd be so hard but it's also encouraging to learn something new and know about the limitations of the system

Cheers

Jens

[JaySchwendemann · Accepted solution]

Being curious I installed NWDS 7.3 SP15 PAT0002 this mornging - even though not being officially supported with my NW 7.4 AEX SP 7 PI (http://service.sap.com/sap/support/notes/1791485). But in this mildly frustrating situation, I'm being a liiiitle like...

Anyways, in the new NWDS release, the input fields for Virtual Receiver Party and Communication Component are indeed editable, so I could just leave the component empty like this:

After activating the iFlow and sending an IDoc with partner type = LI it actually worked:

"Le me" right now (I think I just might call it a day):

Thanks again to all participated, especially Eng Swee for the time spent on explaining how this works. Definitely not being taken for granted. Owe you one.

Cheers

Jens

[engswee · Accepted solution]

BRILLIANT!!! Really pleased to hear that it's finally working now.

Nice little trick on using the latest NWDS to edit the Virtual receiver fields. I've only started using iFlow in the past 6 months and not working on any IDoc scenarios, so I didn't realize the limitation of iFlow on earlier versions of NWDS - thanks for sharing on that.

Rgds

Eng Swee

PS: Looking forward to your blog on the switch for SNC to Logical System - could learn a thing or two from there

PPS: Nice emoticons!!

[JaySchwendemann · Accepted solution]

Jens Schwendemann wrote:

I managed to switch the partner for SLD to use Logical System.

This, of course should read "I managed to switch the partner for SNC to use Logical System".

Sorry for any confusion that might have been created by this error 🙂

Cheers

Jens

[bhavesh_kantilal · Accepted solution]

and  , I stumbled on this thread trying to figure out why my IDOC_AAE was not resolving the Virtual Receiver and did I not have fun reading this!

Wish we had more such threads on SCN with more discussions and analysis! Great Job Guys! This thread has been bookmarked to re-read when I forget my fundamentals

Regards,

Bhavesh

[Harish]

Hi Jens,

1. Are there any best practice to deal with such situations (Same IDoc sender system / service to multiple receiver)

-->> The best practice is having one receiver determination or iflow for one sender interface and system. But in your case it would be good to create a new iflow to avoid customization of standard object.

2. I fiddled around with parties (assigning the business system of ERP to a party and then creating a new iFlow based on that) but as you might expect, still iFlow_SNC gets chosen and routing fails because there is no rule for supplier 1 there. Is Party setup the right way here? If so, what did I do wrong?

-->> you can use the concept of virtual receiver and add party or service as virtual receiver. It will work for your case. and you need to maintain the receiver determination condition in all iflows.

Please refer below wiki for reference

Virtual Receiver use in Receiver Determination B2B(Idoc to (File,Idoc or any other system)) - Proces...

regards,

Harish

[former_member182412]

Hi Jens,

>>>>>1. Are there any best practice to deal with such situations (Same IDoc sender system / service to multiple receiver)

Another approach is with enhanced receiver determination with operation mapping, with in the mapping based on RCVPRN you can create receiver then you can achieve this with one interface.

Enhanced Receiver Determination in SAP XI - Process Integration - SCN Wiki

Regards,

Praveen.

[engswee]

I've already mentioned enhanced receiver determination in my previous reply.

The setback of this approach is that the single iFlow/ICO still becomes difficult to maintain if the receiver increases in the future. Plus such a design violates the Open Close principle. Each time a change is involved (add, change, remove receivers), the "common" object (i.e. Operation Mapping or iFlow) needs to be modified and any incorrect changes might potentially affect other existing interfaces.

Also, if there is an ongoing development for multiple receivers at the same time (which is very common in B2B landscapes), it increases the complexity during deployment. You need to remove the logic for receivers that are in Dev but not ready for Production, transport that change to Production, then reintroduce the logic back in Dev. Such a process can become prone to errors.

[JaySchwendemann]

Thanks Praveen for pointing to the wiki page. As you see I'm still trying to get the party approach working. Nevertheless your post might be helpful for somebody specifically looking for or needing ehnanced receiver determination approach 🙂

Cheers

Jens