Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
We're using GIS to send IDocs into SAP, and are switching over to using file-based rather than tRFC due to some file size issues.
Can someone clarify for me why EDI_DATA_INCOMING needs a file port for loading (makes sense to me), but the receiver port (RCVPOR) value in the IDoc control record has to be SAP<sid> for the IDoc to load properly? I would expect that having a receiver port equal to the file port that we're receiving files via would be correct.
The receiver port is the port of the receiving system. In this case, your R/3 system is receiving the IDoc, thus the SAP<sid> is correct for the receiver. The sender port would represent the source system (your file port).
The receiver port is the port of the receiving system. In this case, your R/3 system is receiving the IDoc, thus the SAP<sid> is correct for the receiver. The sender port would represent the source system (your file port).
The receiver port is the port of the receiving system. In this case, your R/3 system is receiving the IDoc, thus the SAP<sid> is correct for the receiver. The sender port would represent the source system (your file port).
Why does EDI_DATA_INCOMING need a file port for loading?
The file port is used to determine the file type of the input file whether is flat or XML file.
If the file type is XML, then FM EDI_DATA_INCOMING will call FM IDOC_XML_FROM_FILE to process inbound IDoc file. Otherwise, it will call FM IDOC_INBOUND_FROM_FILE for processing the IDoc input flat file.
So am I correct in saying that the file port used in EDI_DATA_INCOMING and the receiver port value in the IDoc control records represent different entities? For example, the file port represents the place to get files from, but the receiver port represents the actual system doing the receiving?
Bluesky
