In this section you will learn how SAP uses an RFC destination to link to the subsystem program. If you have not yet installed a subsystem, you can skip this step and go to the next step, configuring the port definition.
This will not affect the EDI functionality in SAP. By skipping this step, you lose only the automatic start of the subsystem when an outbound IDoc file is created. In fact, some companies skip this step completely and schedule the subsystem program to run periodically and process the IDoc files. However, if you are planning to implement a real−time EDI scenario, you must perform this step. The following section starts with an introduction to the RFC concept, followed by details on maintaining an RFC destination.
Note Several applications besides ALE and EDI use RFC destinations. For example, they are used to access external print programs, fax programs, tax programs, and barcode readers. In fact, an RFC destination is used to start the online help program on your computer when you select Help, R/3 library from any menu in SAP.
What Is an RFC Destination?
An RFC destination is a logical name used to identify a remote system on which a function has to be
executed. In the RFC destination, you specify the characteristics of the remote system, such as the host name and the program containing the function to be executed. An RFC destination is used for the subsystem because the subsystem is an external system from SAP's perspective, no matter whether it resides on the same system as SAP or a separate system. The following two prerequisites apply when executing a function remotely.
The systems should be accessible to each other via TCP/IP or one of the supported network protocols.
An operating system−level SAP user ID should be able to start a program remotely on the destination system. This feature requires configuration at the operating system level.
•
The program that implements the functions must use RFC protocols to communicate with SAP. RFC protocols are implemented via a set of APIs (Application Programming Interfaces) that both the sending and receiving programs use.
•
Communication Settings
How the EDI Interface Uses an RFC Destination
The subsystem is considered a remote system because it is not an SAP program. It can be installed locally on the SAP box or on an external system. Hence, any communication between SAP and the subsystem requires the RFC destination (see Figure 6.4).
Figure 6.4: The RFC link between the SAP system and the EDI subsystem for the automatic start of the subsystem
For connectivity to occur, you must meet two prerequisites.
You must connect the systems via TCP/IP and maintain a "trusted user ID" on each system so that each can execute programs on the other system.
•
The subsystem vendors must write their subsystem programs using RFC protocols. You can
circumvent this problem by using the rfcexec program shipped with the standard SAP system. rfcexec is a program at the operating system level that acts as the RFC server and can respond to SAP's RFC requests. When it has to start the subsystem, SAP calls the function RFC_REMOTE_EXEC, which is implemented in the program rfcexec (refer to Figure 6.4). SAP passes the name of the shell script for the subsystem, and the RFC_REMOTE_EXEC function executes the shell script. This strategy means that the EDI subsystem program does not have to use RFC protocols.
Note SAP uses <SID>adm as the ID to access the operating system files and commands, where SID is the instance of your SAP system.
Tip RFC_REMOTE_EXEC is a function in the rfcexec program and, hence, cannot be seen in the function library on the SAP system via SE37.
•
The trusted user setting is necessary to allow the SAP system to trigger rfcexec remotely. Assume that you have two systems, one running SAP and the other running the EDI subsystem. Assume further that the TCP/IP host names of the two systems are hostsap and hostedi.
Before you proceed with any settings, make sure that the systems are configured at the TCP/IP level to see each other. You can execute the ping command at the OS level to verify that the two systems are connected and can see each other. After you verify the connection, you must set up the rhosts files and users on both systems. Because of the security implications of these settings, your system administrator and security specialists should participate in the design. A simplified example of this setup is as follows.
Set up a user ID on the hostedi system. Give that user ID the same name as the SAP user ID at the OS layer on the hostsap system, which is <SID>adm. Thus, if your SAP instance is DV1, the user ID will be dv1adm.
1.
Setting an RFC Destination
Create a home directory for this user on hostedi. The directory should be the same as the home directory on hostsap.
2.
Create an .rhosts file in both systems. This file allows you to create trusted users. The permissions on this file should be 600, which is read and write for the user ID only. Setting permissions to any other value will cause security vulnerability.
3.
In the .rhosts file on hostedi, enter hostsap, and in the .rhosts file on hostsap, enter hostedi. This step completes the configuration for trusted users.
4.
You can verify the trusted user setup by executing the following command at the OS level.
Execute remsh hostedi date from hostsap. This command should return the date from the hostedi system.
•
Execute remsh hostsap date from hostedi. This command should return a date from the hostsap system.
•
How to Set Up an RFC Destination in SAP
Transaction: SM59
Path: From the SAP standard menu: Tools, Administration, Administration, Network, RFC Destination
There are several types of RFC destinations. EDI uses type TCP/IP to connect to the subsystem. A default RFC destination (SERVER_EXEC) is shipped with SAP; that RFC destination starts the rfcexec server program on the SAP application server on which the process is executing. You can change this destination to suit your needs or create a destination from scratch. The attributes relevant to EDI configuration and their meanings follow (see Figure 6.5).
Figure 6.5: Attributes in a TCP/IP RFC destination (© SAP AG)
RFC Destination. This attribute is a unique name for your RFC destination.
•
Connection Type. Use type T to indicate TCP/IP.
Tip Pressing Enter after you put in the type and description of your RFC destination enables the fields necessary for connection type TCP/IP.
•
Activation Type. Click the Start button. The Registration button is used only when your EDI
subsystem is registered with a gateway, a technique used only for RFC−enabled EDI subsystems. For your purposes, do not assume an RFC−enabled EDI subsystem.
•
Setting an RFC Destination
Start On. Select either Application Server or Explicit Host, depending on where the subsystem is installed. An application server is usually local to the SAP environment, namely the saphost itself, and Explicit Host refers to a remote server. An explicit host can also be used for locally installed EDI subsystems. Check with your Basis people for this installation. If you select Explicit Host, the system lets you enter the TCP/IP host name of the system on which your EDI subsystem is installed.
Caution If you select the Application Server and have installed multiple application servers, make sure that they share the file system through some technique. A commonly used technique is NFS (Network File System), which allows a file system to be shared across multiple systems.
Tip You can view the list of application servers running in your instance by executing transaction SM51.
•
Program. Enter the RFC server program name rfcexec in this field.
Caution The program name and the server name are case sensitive.
Tip You can test the connectivity to the rfcexec program by clicking the Test button. If the result is successful, you have successfully connected to the system that has or will have the EDI subsystem.
•
Security Options. If you have SNC (Secure Network Communications) installed, the option will be active.
•
Local versus Remote Subsystems
If the subsystem is installed locally on the SAP server, you will have very few problems because SAP and the subsystem operate under one environment and share a common file system. IDoc files created by the SAP system are automatically available to the subsystem. However, this configuration is not always advisable because of the additional load created on the system. Thus, it's sometimes necessary to install the subsystem on a separate box.
If the subsystem is installed on a separate server, you must make sure that IDoc files created by SAP are accessible to the EDI subsystem and vice versa. The two options are NFS mounts and remote file copy. Check whether the subsystem can NFS mount the same directory where IDocs are created by SAP. (The Basis staff can help you with NFS mounting.) If so, the IDoc files are accessible.
Companies sometimes restrict the number of mount points for a file system. In this case, the subsystem does not have visibility into the IDoc file created by SAP. If the two systems are completely separate and have only a TCP/IP connection, you need a mechanism to copy the file from the SAP system to the subsystem.
Typically, a script using a remote copy command (such as an rcp command in UNIX) provides this
functionality, an FTP (File Transfer Protocol) mechanism is put in place, or a middleware software package is used.
The Port Definition
Transaction: WE21
Path: From the Area menu of EDI, choose IDoc, Port Definition.
The port defines the technical characteristics of the connection between SAP and the subsystem. It also defines the medium in which data is exchanged between the two systems.
Setting an RFC Destination
In the EDI process, IDocs are transferred to external systems via ports. Table 6.1 presents the types of ports available in release 4.6.
Table 6.1: SAP Release 4.6 Ports
Port Function
Transactional RFC Used for ALE communication
File Used by EDI
CPI−C Used to communicate with an R/2 system
Internet Used to connect with Internet applications
ABAP−PI Used for custom IDoc processing via ABAP programming interface
XML Used for processing files in IDoc/XML format
The EDI process uses the file port. The type of port also depends on the receiving side. If the receiver cannot accept data in the medium used by a port, the port cannot be used. For example, the tRFC port cannot be used for EDI unless the receiving subsystem has support for tRFC. Check with your vendor for the port supported.
All vendors support the file port, so don't pick up your phone unless you are interested in using another port.
A port is a client−independent object. The following are the parameters specified in a port definition. Figure 6.6 shows an example of how to specify the various attributes in a port definition.
Figure 6.6: Attributes in a file port definition (© SAP AG)
Port. The port name is any meaningful name that uniquely identifies the port.
•
Description. Any meaningful description of the port will suffice. This parameter is for documentation purposes only.
•
Version. You can control the release level of the IDoc being generated by SAP. In SAP, the internal structure of the IDoc has changed in every major release. For example, in release 4.0 and up, the IDoc name can be as long as 30 characters. To support backward compatibility, you set the version of the IDoc to be generated. Consider a scenario in which you have upgraded to SAP release 4.6, but your subsystem is still working with IDocs of SAP release 3.0. In this field, you specify the version to be generated, using the following values for R/3 versions prior to 4.6.
Format for R/3 2.2 IDocs 1.
•
Setting an RFC Destination
Format for R/3 4.0 and above IDocs 3.
The Outbound File
This tab specifies the name and location of the IDoc file generated for an outbound process. The various fields on the Outbound File tab (see Figure 6.6) are as follows.
Logical directory. The logical directory where the IDoc file will be generated. You define the logical directory by using transaction FILE.
•
Physical directory. The physical directory where the IDoc file will be generated. You define the physical directory name by entering the fully qualified directory path, ending with a forward slash for Unix systems or a backward slash for Windows systems.
Caution The directory path must be accessible to the SAP user ID <SID>adm. The SID is the system ID or the instance ID. Access to the directory path is usually not a problem for <SID>adm because <SID>adm is set up as the SAP Administrator who owns the directory and the files in it.
Tip If you are using a port for testing and you do not know of a directory path for your IDoc files, or if you are having permission problems, use the /tmp/ path on UNIX systems. This path is always present, and any user can write to this directory.
•
Function module. With this field, SAP provides a dynamic file−naming option that generates a file name at runtime. Several function modules ensure that a unique file is created for every IDoc that uses this port. You can select the function module that fits your needs. If these standard function modules do not meet your needs, you can create your own function module for naming the files. Execute transaction WE55 to add your custom function module for naming the files.
Caution If you use the Function Module option, the Outbound File field should be blank.
Tip If you are going to write your own function module, it's easiest to copy and modify an existing function module.
•
Outbound file. You can specify a fixed file name for your outbound IDocs. This file name is used for all outbound IDocs and is overwritten every time you create an outbound IDoc using this port. This option is useful during testing onlyin a production environment, you leave this entry blank and use dynamic file names generated via a function module.
•
The Outbound Trigger
The command file parameter specifies the program SAP uses to invoke the EDI subsystem. It is defined on the Outbound Trigger screen. This program is usually in the form of a shell script or batch file provided by your subsystem vendor. The various fields on the Outbound Trigger tab (see Figure 6.7) are as follows.
The Port Definition
Figure 6.7: Attributes of the command file used to start the subsystem (© SAP AG) Autom. Start Possible. The flag specifying whether SAP can start the subsystem.
•
RFC Destination. The name of the RFC destination defined in How to Set Up an RFC Destination in SAP. This field locates the system on which the subsystem is installed. If the subsystem is not
installed, you can use the default RFC destination SERVER_EXEC here.
•
Directory. The fully qualified directory path where the subsystem shell script is installed.
Tip The directory path must end with a forward slash (/) for UNIX or a back slash (\) for PC−based systems.
•
Command File. The name of the shell script supplied by the subsystem vendor. It is case sensitive for UNIX.
•
The Inbound File
Entries for the inbound file are optional. The entries specify the name and location of the IDoc file for an inbound process. Typically, you do not use these values because the subsystem provides a fully qualified path name and file name when it triggers the inbound process via startrfc. If the subsystem does not provide other values, these specified values are used. You also use these values during testing, so it might be worthwhile to specify this option for the test port. The various fields on the Inbound File tab (see Figure 6.8) are as follows.
The Port Definition
Logical Directory. This field defines the directory path where the IDoc file will be present. You define a logical directory by using transaction FILE.
•
Physical Directory. This field defines the physical directory path where the IDoc file will be present.
For the physical directory name, enter the fully qualified directory path.
Caution The directory path must be accessible to the SAP user ID specified in the startrfc command on the inbound process.
•
Function Module. SAP provides a dynamic file−naming option, which ensures that every file has a unique file name.
•
Inbound File. You can specify a fixed file name to be used for all your inbound IDocs. This item is useful during testing only. In a production environment, you leave this entry blank and use dynamic file names.
•
The Status File
Entries for the status file are optional. This setting specifies the name and location of the status file used to pass status information for an outbound IDoc. Again, the values are typically not used because the subsystem provides a fully qualified path name and file name when it triggers the process via startrfc. If the subsystem does not provide other values, these specified values are used. The various fields on the Status File tab (see Figure 6.9) are as follows.
Figure 6.9: Attributes of the status files imported into SAP (© SAP AG)
Logical Directory. This field defines the logical directory path where the status file will be present.
You use transaction FILE to define a logical directory.
•
Physical Directory. This field defines the physical directory where the status file will be present. You enter the fully qualified directory path for the physical directory name.
•
Function Module. SAP provides a dynamic file−naming option, which ensures that every file has a unique file name.
•
Status File. You can specify a fixed file name for your inbound status file. This item is useful during testing only. In a production environment, you leave this entry blank and use dynamic file names.
•
Caution The directory path must be accessible to the SAP user ID specified in the startrfc command.
The Port Definition
Strategies for Building Ports
The port is not simply a parameter that you have to completeyou can use strategies in port definitions. In the following situations, you might have to define multiple ports.
If you need to communicate with two separate systems and they use different IDoc formats (for example, one uses 3.0 IDocs, and the other uses 4.0), you have to create a separate port for each type.
•
You must create a separate test port for testing the process.
•
You might want to send the IDoc files to separate directories based on the type of EDI transaction.
For example, you might want outgoing invoices to be in a separate directory from the outbound sales order response.
•