EDI Ack - wrong 997 Separator channel selected by PI

[Former Member]

Hello Everyone,

With our inbound EDI interfaces using the B2B add-on, we are seeing this issue of the wrong separator sender comm channel being selected for the '997' acknowledgement. Even though we have eliminated the wild card * entry where possible, there is still more than one channel with the same select criteria for 997.  For example, more than one 997 separator sender channel configured like this one:

When the separator receiver splits the inbound message, and PI searches for the 997 separator sender using the fields shown above, it finds more than one channel, and may not select the channel defined in the integrated configuration.  Even if there is another channel configured like this one, but with a sender ID, and it still defaults the one above first.  So when the correct 997 sender channel doesn't get identified, processing doesn't flow through the desired integrated configuration, receivers or receiver comm channels.           

More information that might be helpful - We have developed more than one EDI inbound interface per transaction set.  The reason for multiple interfaces is to meet business requirements for mapping, file archiving, and timing.  Our installation is PI 7.31 single stack.  We use the SFTP adapter to transmit files between our VAN and PI through a DMZ server.  Our interface configuration uses a business system as the communication component, and we use the X12 converter module with ANSI X12.    

I would greatly appreciate any thoughts on how to correct the 997 ack processing.  I did search the forums, but just found basic how to on setting up a 997 ack.  

Thank You.

Robin Aufleger

[Former Member · Accepted solution]

I opened an incident with SAP on this.  Their reply was that the EDI separator sender channel will use the criteria in the channel for selection, and that is the only criteria it will use.

So it appears that if you have more than 1 separator sender channel per EDI transaction set you must differentiate completely using qualifier and/or sender / receiver id.  There is no other way to  control which channel PI will select.

[Former Member]

Hi Robin,

Can you explain why you have used * for interchange sender and receiver id?

I think you need to specify value, sender id and receiver id (You can get from ISA06 & ISA08).

Are you doing multiple inbound scenarios with same partners and different partners?

[Former Member]

We have multiple inbound scenarios, all using the same business system in the configuration.  Within a scenario, the inbound EDI file sender and receiver identifiers may vary, thus the use of '*' in the separator channel.  The design behind the multiple '997' channels is so each interface scenario can have it's own integrated configuration for the outbound 997 acknowledgement.  This way the files should flow to the correct archive folder, and be placed in  the correct location back on the DMZ server, to be sent back to the originator.

Recently, we saw this issue happen: - a new inbound interface was constructed for the actual '997' transaction set.  This scenario had only 2 integrated configurations.  The first int. config. had a separator receiver that said 'no ack required'.  However, because we have multiple separator senders for 997 with the '*', PI actually ignored the 'no ack required', and instead of processing the 997 as an inbound interface, it turned around and sent a 997 file back out.  So we have quite a problem it appears.
       

[Former Member]

Recently, we saw this issue happen: - a new inbound interface was constructed for the actual '997' transaction set.  This scenario had only 2 integrated configurations.  The first int. config. had a separator receiver that said 'no ack required'.  However, because we have multiple separator senders for 997 with the '*', PI actually ignored the 'no ack required', and instead of processing the 997 as an inbound interface, it turned around and sent a 997 file back out.  So we have quite a problem it appears.

---> Obviously, how PI will differentiate your previous scenarios and new scenario.

Here you are using same business system, * as id. So i think system will confuse to select respective 997 channel.

Normally, we used to create business sysem based on business & trading partners, you need to design the scenario little bit effective way i think. It's just my openion.

[Former Member]

Thank you Sruthi for your reply.

I tried using a new business system for the separator receiver and sender, in an attempt to differentiate it from the other interface scenarios.   
PI does not use 'service' as it searches for channels having the same transaction set, receiver and sender ID's.  My interface still selected separator sender comm channels that were attached to a different business sytem than what I have in my inbound separator receiver.  

[Former Member]

Actually, after doing several full cache refreshes, the interface did start to select the separator channel from the desired business system used in the receiver.  Don't know for sure if it will work that way consistantly. 

[Former Member]

Ok. Thats good to know

[Former Member]

More testing revealed that using business system does not work consistently.