What on Earth is an SAP IDoc?

2.1   Port definition—WE21

A communication port in an SAP system is quite similar to an actual sea port. Except instead of ships dropping off or picking up their cargo, it is information flowing in and out of an SAP system. And just like ships from many countries that arrive at the same sea port, one IDoc port can be used for multiple outbound and inbound interfaces.

Ports are maintained in transaction WE21. On the left-hand side (Figure 2.1) we can see a list of the port types.

Figure 2.1: Port types

There is, of course, SAP documentation on the port definition but, in my opinion, it has too much information no one cares for yet lacks a clear and simple explanation of what all those port types are for. Although if SAP Help was perfect, then no one would need this book, so it is probably a good thing... Anyway, here is my “simplified” explanation of the available port types.

• Transactional RFC—This port type is used when two systems, or clients of the same SAP system, exchange data directly by establishing a remote connection and calling a special remote-enabled function (I briefly mentioned RFC in Chapter 1). The remote connection needs to be defined beforehand in transaction SM59. Note that the connection does not have to be between two SAP systems, it could be between an SAP system and a third-party application.

<li><b>File</b>—This port creates a plain text file in the specified directory. The file will have the segment names at the beginning of each line followed by a stream of data (usually unreadable). This port type seems to be rarely used these days as more preference is given to RFC and XML types.</li>

<li><b>CPI-C</b>—This port is used for R/2 systems, which is an old version of SAP ERP.</li>

<li><b>ABAP-PI</b>—This port triggers a custom ABAP function. ABAP-PI is short for “ABAP Programming Interface” and has nothing to do with the SAP Process Integration solution (which has already been renamed twice and is now called SAP PRO). In the outbound interfaces, function module OWN_FUNCTION may be used as a template for the custom function. In the inbound interfaces, the custom function must call function module IDOC_INBOUND_ASYNCHRONOUS to create the IDoc.</li>

<li><b>XML file</b>—This port creates an XML file in the specified directory. In the XML file, you will see the IDoc segments as nodes. This port type is used as an example in this book because it is easy to deal with and works well for illustration purposes.</li>

<li><b>XML HTTP</b>—This port is sort of an XML / RFC hybrid. No file is created, but data is transmitted in XML format using an HTTP connection.</li>

<p class="BoxTipText"><img alt="Tip" class="BoxImage" height="90" src="%%ATTACHMENT:114973%%" width="90" loading="lazy">SAP does not provide a web service port for IDocs. One might argue that if a web service can be used, then why bother with IDocs at all? There is a great blog titled “IDoc as Web Service” on SCN by Amaresh Pani that describes a possible solution (without SAP PI/PO/PRO) and also mentions a valid business scenario in the comments.</p>

For the File and XML port types, there are two choices for the directory where the file will be created: logical and physical. What is the difference and when or why use one or the other?

Physical directory

If we choose physical directory name then we need to enter the actual directory pathname on the application server. SAP application server directories can be viewed in transaction AL11. Note that some shared network directories can also be added there.

It is a good idea to check with the system administrator which directory should be used in the port definition.

Most of the examples in this book use a physical directory for simplicity, but in real life it is better to use a logical directory.

Logical directory

If we choose the logical directory option, then we need to use a logical file path. Logical file paths (i.e., directory and file names) are maintained in the transaction FILE. In a nutshell, these paths allow the use of a neutral identifier instead of specific physical location.

Why would anyone need that? In some cases, it is convenient because we can maintain path definition once and then use the logical path name in many ports (or other places—logical paths are used all over SAP). So if the actual (i.e. “physical”) directory changes then it is only necessary to make a change in only one place—logical path.

But, most importantly, logical names can be dynamic. For example, ‘/usr/DEV/temp’ is a static name, but ‘/usr//temp’ is dynamic. In the last case, is a variable that will be filled in with the system ID, so we can conveniently use the same logical path in DEV, QAS, and PRD systems and not worry about changing it.

Logical directories take some additional effort to set up, but they can be a life saver if the path names must be changed due to a server replacement, hosting provider switch, or any other technical reason.

Also, logical directories allow for some cool customization using a function module, see Section 6.4.

<p class="BoxTipText"><img alt="Watchout" class="BoxImage" height="90" src="%%ATTACHMENT:114974%%" width="90" loading="lazy">Note that in some operating systems (OS), such as UNIX and Linux, file names are case sensitive. To find which OS is used in your SAP system, go to the menu <span class="Screenelement">System • Status</span> from any screen and check the <span class="Screenelement">Operating System</span> field.</p>