Archive for February, 2014


STARTRFC – Start SAP RFC Function Modules From any Server Within Your Landscape

startrfc is a very easy SAP command line interface to start all of the implemented function modules of SAP systems.

SAP Kernel Programs

startrfc in a SAP System

How to download the latest version ?

startrfc online help with all supported command line options

startrfc in a SAP System
You can start any SAP function module, that is RFC-enabled. You can check this in transaction SE37 or SE80. There you either use existing function modules or create the ones of your desire.
You can start these function modules from any platform with the program startrfc. This program is part of SAP application server and of any SAP RFC SDK on the Presentation CD (SAPGUI CD). So, you can usually use and try this just from your PC connected to the network via TCP/IP to your SAP system. You just need an user for the SAP system and can start with the test. Later on, for the case, that you want to use this as permanent interface, you should change this user so that it can no longer log on in dialog to the SAP system.

startrfc works as follows:
startrfc -3 -h -s -c -l -u -p -F -E

An example for startrfc could look like as follows:
startrfc -3 -h hyperion -s 01 -c 000 -l D -u volker -p password -F SUBST_START_BATCHJOB -E JOBNAME=VOLKERJOB -E REPNAME=RSPFPAR

An example for startrfc with a saprouter string looks as follows:
startrfc -3 -h /H/saprouter/S/3299/H/hyperion -s 01 -c 000 -l D -u volker -p password -F SUBST_START_BATCHJOB -E JOBNAME=VOLKERJOB -E REPNAME=RSPFPAR
(There the saprouter is called “saprouter” and is running on the default port 3299)

On iSeries this would look as follows:
call pgm(startrfc) parm(‘-3’ ‘-h’ ‘hyperion’ ‘-s’ ’01’ ‘-c’ ‘000’ ‘-l’ ‘D’ ‘-u’ ‘volker’ ‘-p’ ‘password’ ‘-F’ ‘SUBST_START_BATCHJOB’ ‘-E’ ‘JOBNAME=VOLKERJOB’ ‘-E’ ‘REPNAME=RSPFPAR’)

This startrfc starts the function module SUBST_START_BATCHJOB, that is able to start a background job of any available report. As this creates a background job, you have to specify the jobname and the report name, that is called. The result is a background job, that creates a spool file of all SAP profile parameters any time you call this startrfc.
You can implement all RFC-enabled function modules with this technique.

How to download the latest version ?
You can download the latest version of all the SAP Executables in the SAP Service Marketplace. As the binaries are different for each platform, you should have a look at the following link:
Download Executable Patches on the SAP Service Marketplace

If you have some more ideas to this topic, please let us know via the Feedback Area.

saposcol online help with all supported command line options
RFC command line interface

Syntax :
startrfc [connect options]

function options =

-F =


where is a path name to read from (r)
or write to (w) the internal table.
If is -, stdin or stdout is used.

RFC connection options:

-d name of the RFC destination.
Necessary, if you are using a ‘sideinfo’ file.

-2 SNA mode on.
You must set this if you want to connect to R/2.
All other conection data must be suppplied by a
sideinfo file.

-3 R/3 mode on.
You must set this if you want to connect to R/3.
Specify the following options:

-h hostname of the R/3 target system.

-s system number of the target system.
this determines the TCP/IP service to be used to connect
to the R/3 system. The default value is 0 and the default
service being used then is sapgw00.

-gui start sapgui
to allow dynpro and graphics processing
(3.0C or later required on the target system).

Using an intermediate SAP gateway, specify:


(must not be used with -gui or -debug option).

-balanced load balancing mode.
Another way to connect to R/3, if the R/3 system is 3.0C
or later and workload balancing is active on that system.
Requests are automatically routed to the application server
having the best response times in the moment.
Specify the following options:

-h hostname of R/3’s message server.

-s name of the target system.
This determines the TCP/IP service to be used to connect
to the R/3 system.
The system name is a 3 letter word. If the system name
is XXX, the service being used is sapXXX.

-g name of application server group.
The default is PUBLIC.

-gui start sapgui
to allow dynpro and graphics processing.

additional options:

-t turn trace on.
all operations are written to the trace file ‘dev_rfc’

-debug turn ABAP/4 debugging mode on.
this can only be done, if sapgui is installed on the client
system and the target system has version 3.0C or later.

Using the ‘saprfc.ini’-file:

-D name of the RFC destination in saprfc.ini
Instead of using the connection and additional options
defined above, you can also work with the ‘saprfc.ini’-file
and all needed options must be defined in this file.
Using this feature, this program can run in an SNC

RFC logon data:

-u SAP userid.

-p password.

-c client.

-l logon language.

further options:



-? “this text”



02 2014

ALE / EDI / IDoc T-Codes

Important IDoc Transaction Codes

SALE – IMG ALE Configuration root
WE20 – Manually maintain partner profiles
BD64 – Maintain customer distribution model
BD71 – Distribute customer distribution model
SM59 – Create RFC Destinations
BDM5 – Consistency check (Transaction scenarios)
BD82 – Generate Partner Profiles
BD61 – Activate Change Pointers – Globally
BD50 – Activate Change Pointer for Msg Type
BD52 – Activate change pointer per change.doc object
BD59 – Allocation object type -> IDOC type
BD56 – Maintain IDOC Segment Filters
BD53 – Reduction of Message Types
BD21 – Select Change Pointer
BD87 – Status Monitor for ALE Messages
BDM5 – Consistency check (Transaction scenarios)
BD62 – Define rules
BD79 – Maintain rules
BD55 – Defining settings for IDoc conversion
WEDI – ALE IDoc Administration
WE21 – Ports in Idoc processing
WE60 – IDoc documentation
SARA – IDoc archiving (Object type IDOC)
WE47 – IDoc status maintenance
WE07 – IDoc statistics

BALE – ALE Distribution Administration
WE05 – IDoc overview
BD87 – Inbound IDoc reprocessing
BD88 – Outbound IDoc reprocessing
BDM2 – IDoc Trace
BDM7 – IDoc Audit Analysis
BD21 – Create IDocs from change pointers
SM58 – Schedule RFC Failures

Basic config for Distributed data:
BD64: Maintain a Distributed Model
BD82: Generate Partner Profile
BD64: Distribute the distribution Model

RBDMIDOC – Creating IDoc Type from Change Pointers
RSEOUT00 – Process all selected IDocs (EDI) -> WE14
RBDAPP01 – Inbound Processing of IDocs Ready for Transfer
RSARFCEX – Execute Calls Not Yet Executed
RBDMOIND – Status Conversion with Successful tRFC Execution
RBDMANIN – Start error handling for non-posted IDocs
RBDSTATE – Send Audit Confirmations
For testing you can use WE19

Tags: , ,


02 2014

Basic ALE Customizing

To find out which version of the basic type is best suited to your SAP system’s
release level, ALE → ALE Development → IDoc → IDoc Type Development→ IDoc Type for Message (transaction WE82).

For an overview of all the message types, go to Tools → ALE → ALE Development → Logical Messages (transaction WE81).

You can create new model views in Customizing. To do this, in the IMG, go to SAP NetWeaver → SAP Web Application Server → IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Maintain Distribution Model and Distribute Views or call the distribution model directly via transaction BD64.

For your ALE scenarios, you create RFC destinations for all the partner systems in each system involved. To do this, select in the ALE Customizing IDoc Interface / Application Link Enabling (ALE) → Communication → Create RFC Connections or use transaction SM59.

Hint: If you give the RFC destination the same name as the logical target system, you can have the system carry out certain settings automatically later on.

In order to use ALE scenarios later on, the RFC must be assigned to a port. The sender uses the port to determine the communication channel to the recipient. You can create ports manually or – if the logical target system and the RFC destination have the same name – have the sender system create them.

Note: There are different types of port in SAP systems. ALE always uses RFC ports. In EDI scenarios, you can also use file ports in addition to RFC ports.

In the SAP system, you can set tRFC parameters for the relevant connection in table RFCDES (for connection types T, 3, I) (SM59):
• Suppress batch job in the event of communication errors (manual start with transaction SM58 required)
• Number of connection attempts
• Interval in minutes between repeated attempts to transfer data

For a model view to be distributed to all the partner systems, the sender system must contain outbound partner profiles for message type SYNCH for all the affected recipient systems. This message type is used only for determining the RFC destination for the target system. If the name of the logical target system and its RFC destination are the same, the sender system can automatically create a port with the appropriate RFC destination and generate the partner profiles for the message types of a model view. The authorization object for distributing model views is B_ALE_MODL.


For an overview of the segment structure of a basic type, see transaction WE30 (IDoc Type Development).

The structure of the basic types provided by SAP is documented in detail in SAP R/3 and mySAP ERM. To call this documentation, go to Tools → ALE → ALE Administration → Services → Documentation → IDoc Types and Segments or call transaction WE60.

The line type of the internal table is determined by the ABAP Dictionary structure type EDIDD.

•Regardless of how the IDoc was created, it is first saved to the sender system’s database (status value 01).
• If all the information required for sending has been obtained from the recipient, then the IDoc receives the status “ready for dispatch” (status value 30).
• If the outbound partner profiles specify that the IDoc is to be transferred immediately to the port stored in the relevant message type, then the IDoc is sent and receives a corresponding status (status value 03). However, it is also possible to send multiple IDocs bundled together at a later time.
• The IDoc is saved to the target system’s database (status value 50).
• If all information about further processing is known, the IDoc can be transferred to the application (status value 64).
• If the inbound partner profiles specify that the IDoc is to be transferred to the application immediately, the target system attempts to post the IDoc data (status value 62). If the inbound processing is successful, the IDoc receives status value 53.

All the Customizing settings you need for cross-system Customizing comparison and subsequent synchronization can be found with transaction SALE. In the menu, select IDoc Interface/Application Link Enabling (ALE) → Modelling and Implementing Business Processes → Synchronization of Customizing Data.
You can call the relevant application transactions in SAP Easy Access via Tools → ALE → ALE Administration → Services → Customizing Data. Here you will find a program for matching Customizing tables in the sending and target systems, known as the “Customizing Cross-System Viewer” (transaction SCU0), and transaction for generating and further processing ALE transport requests for Customizing synchronization. The sending system creates IDocs of message type CONDA2 for the transport requests: these IDocs contain the core information about each request. Inbound processing of these IDocs controls the importing of request data in the target system: either a workflow is sent to the responsible
administrator requesting him or her to carry out the import, or the import is carried out automatically by a program executed in the background.

Synchronizing Customizing Settings with the SAP Solution Manager

There are standard ALE scenarios for distributing master data; these are documented in the SAP Library and in the IMG. You can use transaction SALE to find descriptions of how to set up certain master data distribution scenarios.

First, use this information to create a new view in the distribution model of one of the system’s involved. BD64

If RFC destinations already exist with the same names as the logical target systems, you can now have the system create the outbound partner profiles for the new model view. When it generates partner profiles, the system automatically creates an entry for the message type MATMAS and also an entry for message type SYNCH for each profile (ALE:Dummy Message Type for Determination of RFC Destinations). This message type is not used for generating IDocs: it is only used for determining the RFC destination of the relevant target system. The entry for message type SYNCH is a prerequisite for distributing model views.

Note: If your RFC destinations have different names to the target systems to which they lead, you need to first create the entry for message type SYNCH manually and then assign the RFC destination you require using the relevant port. After you have done this, you can have the system generate the remaining partner profiles.

Partners of the type “logical system” (LS) are always created for ALE scenarios.
The name of the partner is always the same as the logical system name.

In the outbound partner profile for a message type, store the following information:
• Receiver port: in ALE scenarios, the sending and target systems exchange data via RFC. You therefore need to use a port of the type “transactional RFC” in the outbound partner profiles for ALE scenarios; the RFC destination of this RFC leads to the target system, the partner in the profiles.
• Output mode: You can choose between Transfer IDoc Immed. and Collect IDocs.
• Package size: If you choose Transfer IDoc Immed., the IDocs are sent individually. If you choose Collect IDocs, multiple IDocs are collected in packages and sent together. Collecting IDocs to send together can improve performance. As a guideline, we recommended collecting between 20 and 100, depending on the size of the IDocs.
• Basic type: in this field, you need to enter the IDoc type that is compatible with the target system’s release level.
Note: If you select the Collect IDocs output mode, you need to execute the RSEOUT00 program to transfer the IDocs to the communication
layer. This program is usually scheduled as a periodic background job.
After you have created the outbound partner profiles for the target systems, you can distribute the new model view to these systems.

In the inbound partner profile for a message type, store the following information:
• Process code: the process code is a key that refers either to a function module or a workflow for processing the IDocs. The process code for message type MATMAS is MATM. If you double-click on the process code key, a screen appears containing the information as to which function module or which workflow is used for inbound IDoc processing. As a rule, function modules are used in ALE scenarios.
Note: There can be more than one process code for a message type (and, accordingly, more than one inbound function module
or workflow). For information about which process codes are assigned to which message types, see the Inbound process code
table (transaction WE42).
• Processing mode: you can choose between Trigger by background program and Trigger immediately. If you choose Trigger by background program, the IDocs are transferred to the ALE layer using the RBDAPP01 program. This program is usually scheduled as a periodic background job.
Figure 41: Processing Times You can define variants for the RSEOUT00 and RBDAP001 programs for collective background IDoc processing. You can find both programs in the IMG via transaction SALE, by going to IDoc Interface / Application Link Enabling (ALE) → System Monitoring → IDoc Processing → Dispatch Collected IDocs or Update IDocs in Receiver System.

You can check the current status of IDocs in SAP R/3 or mySAP ERM by using a status monitor. You can call this monitor with transaction BD87 or the menu path Tools → ALE → ALE Administration → Monitoring → IDoc Display → Status Monitor.

Sending and Requesting Master Data
The “Share Master Data” tool offers you a variety of application transactions for generating IDocs for distributing master data. You can find these transactions via menu path Tools → ALE → Master Data Distribution. You can also call all of the SMD transactions directly using transaction BALM.

You can send material masters directly using transaction BD10
In ALE scenarios, master data is normally sent from the maintenance system to the downstream systems. However, with cross-application master data (material, customer, vendor), it is also possible to retrieve data. Message type MATFET, for example, is used for fetching material masters. This message type is linked to the corresponding views in the distribution model (see figure). In the application menu, you can find transaction BD11 via Tools → ALE → Master Data Distribution → Cross-Application → Material → Get; the target system can use this transaction to request material masters from the sending system. Message type MATMAS is used for sending the material master IDocs.

Note: To view the change documents, use the report RSSCD100. You can also call the change documents from the application transaction
in question. To view the change pointers, see the database table view BDCPV

You can evaluate change pointers by using the program RBDMIDOC. This program is usually scheduled as a periodic background job. You can start the program for testing purposes with transaction BD21

You can display the
assignment of message type and function module for evaluating the the change pointer with transaction BD60

Data Filtering and Reducing the Scope of Data

If you would like to use segment filtering in an ALE scenario, you should first check the structure of the basic type you are going to use to determine the keys for the segments you would like to delete. If, for example, you want the sales area data for the customer masters (basic type DEBMAS0x) to be created in the sales branch system, you can use segment filtering to delete segment group E1KNVVM (Master stomer master sales data) from all communications IDocs for message type DEBMAS and recipient “Sales”. The customer masters are then distributed
to sales without the sales area data.

You can set up segment filtering in the IMG with transaction SALE, via IDoc Interface / Application Link Enabling (ALE) → Modelling and Implementing Business Processes→Master Data Distribution→Scope of Data for Distribution → Filter IDoc Segments.

Filter Objects
If you work with filter objects in ALE scenarios, you have to define conditions that need to be fulfilled for specific application data to be included in a communications IDoc. If the filter object corresponds to a required segment of the basic type in question, then a communications IDoc is only created if the condition is fulfilled.
In the example illustrated below, material masters (message type MATMAS) are distributed at regular intervals from the head office to sales and distribution and production. However, sales and distribution is only supposed to receive material masters for finished products whereas production requires the master records for the finished parts and the raw materials.

Note: Customers can enhance the list of filter objects provided by SAP with their own filter objects. The tables required for this can be found in the application menu along the path Tools → ALE → ALE Development → IDoc → Data Filtering.

If you would like to use classification as a filter method in an ALE scenario, you first need to carry out some basic settings in the class system itself. You need to mark one class type as the “distribution class type” and create at least one class for grouping your data in this class type. Then you can add the ALE-specific settings. You can activate the use of classification in an ALE scenario in the filter
object area of a model view (see above

Reduced Message Types
Some applications have such flexible programs for inbound and outbound processing that you can choose whether or not each optional segment field is to be transferred. To do this, you create what is known as a reduced message type in the customer namespace as a copy of a message type supplied by SAP; then you select the fields whose content you want to be transferred to a particular target system.

Tags: , ,


02 2014

cookielawinfo-checkbox-analytics11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional11 monthsThe cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance11 monthsThis cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy11 monthsThe cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.