730870 - FAQ XI 3.0/ PI 7.0/ PI 7.1/ PI 7.11/ PI 7.2/ 7.3 RFC Adapter
Q 1: What is discussed in this document?
A: This document discusses questions about the XI 3.0 RFC Adapter, NW 7.0 RFC Adapter, NW PI 7.1 RFC Adapter, NW PI 7.10 EhP1 RFC Adapter.
Q 2: Is there more than one version of a XI RFC Adapter ?
A: There are two kinds of RFC Adapters. The first one came with XI 2.0 and was part of the Adapter Engine. With XI 3.0 this Adapter Engine was renamed to 'J2SE Plain Adapter Engine'. It does not contain an RFC Adapter any more. Instead, with XI 3.0, there is new Adapter Engine called 'J2EE Adapter Engine'. It is based on the SAP J2EE Application Server and contains a new RFC Adapter, which runs as a Service of the J2EE Server. This document only describes the J2EE RFC Adapter.
Q 3: How can the RFC Adapter be started and stopped?
A: The RFC Adapter is implemented as a J2EE Service and can be started and stopped. The start/stop affects the whole RFC Adapter. The adapter can be started/stopped from:
Q 4: Where can the RFC Adapter communication channels be configurated?
A: The channels for the RFC Adapter can be configurated within the XI Integration Builder: Configuration (Integration Directory). Choose tab 'Objects' and open 'Service without Partner' -> 'Business-System'. Open the business system for which you want to communicate via RFC and choose 'New' from the context menu on the node 'Communication Channel'. Enter a name for the new channel and choose 'Create'. For 'Adapter Type' you have to choose 'RFC' (via the F4-help).
Q 5: What's about cache memories within the RFC Adapter?
A: The RFC Adapter has a cache for the metadata of function modules. This means it caches the definition of function modules, structures and other datatypes. A separate cache is used for each communication channel. When the particular data is needed during runtime, the cache is filled from the configured RFC metadata repository. Once if a particular metadata has entered the cache, only this one is used and no lookups to the RFC metadata repository are made for this type of metadata. If the communication channel is changed within the Integration Directory and gets replicated to the appropriate Adapter Engine (see Environment -> Cache Notifications...), this metadata cache is cleared. The caches for all communication channels are cleared when the J2EE Engine is restarted, the RFC Adapter J2EE Service 'SAP XI Adapter: RFC' is restarted or a J2EE Service on which the RFC adapter service is dependent ('SAP XI AF CPA Cache', 'SAP XI AF Messaging') is restarted.
See also Q27.
Q 6: Is there a special handling of the '/' character in the names of function modules?
A: As the '/' character can cause conflicts within XML documents it is escaped with the sequence '_-'. A RFC sender channel will do the escaping of '/' to '_-' and a RFC receiver channel will do the opposite. This only will be done for the RFC-XML document.
Q 7: Can there be multiple function module calls within one transaction for RFC sender channels?
A: RFC Adapter only supports one call within one transaction (sometimes also called LUW). If an attempt is made to place a second call within the same transaction, an exception is raised. This is done because within XI there is no transactional context between messages and each RFC call is wrapped into one message.
Q 8: Is it possible to issue several RFC calls within one context for RFC receiver channels?
A: No, a context between several RFC calls can not be held. Each call will get it's own context because different connections to the receiving system are used.
Q 9: Which flavous of RFC are supported?
A: RFC Adapter supports synchronous RFC (sRFC, sometimes also called only RFC) and transactional RFC (tRFC). Queued RFC (qRFC) with inbound queues and asynchronous RFC (aRFC) are not supported. An sRFC will result in a synchronous best effort (BE) message; a tRFC in a asynchronous exactly once (EO) and vice versa. Messages with exactly once in order (EOIO) are not supported till and including XI 3.0 SP10.
With SP11 a XI EOIO-messages will result in a normal tRFC call. If a tRFC is sent to an SAP-system it will be executed directly (in other words synchronously) plus the tRFC exactly once handling. The order of the messages belonging to one EOIO-queue will be guaranteed by the Adapter Framework messaging layer.
Q 10: What's about BAPIs?
A: The following only applies to RFC receiver channels.
BAPIs can be implemented as RFC enabled function modules or IDocs. By their nature, RFC function modules are synchronous, and IDocs are asynchronous. Thus, if the communication should be asynchronous, it is a good idea to use the IDoc implementation of BAPI.
The RFC function module implementation of a BAPI will not only report it's result in a synchronous response, it will also report it's execution status (like Success, Error, etc). If the RFC call to such a function module was asynchronous, there will be no response and also no knowledge about the execution status. Even if the RFC call was synchronous, the RFC Adapter does no special handling for this values. It will treat a response value of any kind as a successful execution because it does not implement some BAPI application logic.
Nevertheless the RFC Adapter will treat each RFC call like described in Q 9: A XI message with QoS BE will lead to a (synchronous) sRFC call, a message with QoS EO will lead to a (asynchronous) tRFC call.
BAPIs with a database update or write functionality expect a special form of commit (ABAP application COMMIT WORK) to actually fulfill their tasks because they (often) use the SAP update technique. Within RFC Adapter there is no special handling of transactions like a commit, so database update BAPIs may have a problem. If the BAPI RFC function module is called (asynchronous) via tRFC, the tRFC-subsystem of the SAP-System will issue a database commit by itself (no ABAP COMMIT WORK). So direct database updates will be possible but no updates via the SAP update process. Also the problem with the missing execution result persists.
The following can be considered to use BAPIs with RFC Adapter regarding the interpretation of the execution result and the commit of the transaction. If it is required that one update BAPI is called, it can be put in a wrapper RFC function module which first calls this BAPI, does the interpretation of the execution result and than does the commit or rollback of the transaction. If it is required that multiple update BAPIs get committed together within one transaction, these BAPIs can be encapsulated in a wrapper RFC function module which first calls the BAPIs and at the end does the commit of the transaction depending on their execution result. In either case the wrapper RFC function module can be called by RFC Adapter.
Anyway you have to keep in mind that this can compromise the quality of service (QoS) which was guaranteed by the original message. Imagine these two possibilities: a synchronous message with QoS BE or a asynchronous message with QoS EO.
As of XI 3. 0 SP 14, support for commit handling for single BAPI calls was added to the RFC Adapter receiver channel. If activated in the receiver channel setting, the received XI message will be executed as synchronous RFC (sRFC) in the receiving system. This is also true for asynchronous (QoS EO) XI messages to receive and analyze the execution result by the RFC Adapter.
The received response is parsed by the RFC Adapter to get the BAPI return parameter with the name "RETURN". This return parameter can be of type: BAPIRETURN, BAPIRET1 or BAPIRET2. The "RETURN" parameter is checked for a response status (field TYPE) which can have the following values:
1. 'S' : Success
2. 'I' : Information
3. 'W' : Warning
4. '' : Empty String
5. 'A' : Abort
6. 'E' : Error
If the response contains one amongst the first four response status, then it implies that the BAPI was successfully executed. If the response contains one amongst the last two response, then it means that the BAPI execution failed. If the BAPI "RETURN" parameter is not of type "ABAP structure" and is rather of type "ABAP table", an empty table is also considered as successful execution result.
In case of a successful execution of the BAPI function module, a "BAPI_TRANSACTION_COMMIT" is called within the same context to trigger the commit of the BAPI. For release higher that NW PI 7.10 SP7, please also refer Note 1342143.
In case of a failure, the BAPI function module "BAPI_TRANSACTION_ROLLBACK" is executed by RFC Adapter which rolls back the changes.
If the XI request message was of QoS BE, the result of the BAPI execution is sent back as an XI response. In case of a QoS EO request message, nothing is sent back as response.
Q 11: Is there something to know about the module processor?
A: Any adapter need an EJB to communicate with the module processor of the Adapter Engine. The EJB used by the RFC Adapter is called 'localejbs/RfcAFBean'. This can be configured in the Integration Directory for each communication channel on the tab 'Module'. If the list on this tab is empty, it defaults to the EJB named above and nothing has to be done. So if no modules should be used, everything will work without a special configuration. If some custom modules are configured to be used, the last module always has to be the RFC Adapter module. This will establish the communication between the adapter and the Adapter Engine.
Q 12: How can tracing be enabled for RFC Adapter?
A:
a) For XI 3.0 SP X, NW 7.0 SP X and NW 7. 0X SP X: Open the J2EE Visual Administrator, log into the J2EE Engine and choose tab 'Cluster'. Open the server node for which tracing should be enabled and open Services->Log Configurator. Choose tab 'Locations' and open com->sap->aii->af then choose the location 'rfc'. In the right frame the name 'com.sap.aii.af.rfc' shows up with the current serverity. Set this serverity level to 'Debug' and also click on the button 'Copy severity to subtree'. After this click on the 'Apply' button (save symbol) so save the changes. For an RFC sender channel also choose 'SAP XI Adapter: RFC' beneath 'Services' in the left frame.
Set the properties 'traceExceptionListener' and 'traceServerErrorListener' to 'true' (in the right frame). Save these changes with the save button. Notice that the RFC Adapter J2EE service has to be restarted to affect this changes. A dialog box will open upon save which can perform the restart after choosing 'Yes'. After enabling the traces the scenario can be reproduced and the default traces can be found at "\usr\sap\<SYSID>\<INSTANCEID>\j2ee\cluster\server0\log" folder.
b) For NW PI 7.10 SPX and NW PI 7.1X SPX: Launch the NetWeaver Administrator through: http://host:port/nwa. Goto Problem Management --> Logs & Traces --> Log Configuration. Change the 'Show' dropdown, to 'Tracing Location'. In the Window below, look for com.sap.aii.adapter.rfc. Change it to debug, copy to subtree and save your changes.
Goto RFC Adapter's Service Properties as described in Q3. Set the properties 'traceExceptionListener' and 'traceServerErrorListener' to 'true'. Save these changes with the save button. Notice that the RFC Adapter J2EE service has to be restarted to affect this changes. After enabling the traces the scenario can be reproduced and the default traces can be found at "\usr\sap\<SYSID>\<INSTANCEID>\j2ee\cluster\server0\log" folder.
Q 13: What is the correct value within the field 'Application server service (Gateway)' for sender channels?
A: This value has to be the name of the service port which is running the gateway. Normally this will be a name like sapgwXX, where XX is the system number of the particular system. This value also can be looked up in the gateway monitor. Open transaction SMGW and choose Goto -> Parameters -> Display. Beneath Attributes there will be the entries 'gateway hostname' and 'gateway service'.#
Q 14: During a synchronous RFC call to the RFC Adapter (sender channel) the error message "call to messaging system failed: com.sap.aii.af.ra.ms.api.MessageExpiredException" comes up. For receiver channels a similar error messages is shown. What does this mean and what could be done about it?
A: At the beginning of a synchronous RFC call the RFC Adapter (sender channel) builds up the XI request-message and sends it to the Adapter Engine with a timeout. After this it waits till the response-message reaches or the timeout expires. In case of timeout the exception named above is thrown. The timeout used by RFC Adapter for synchronous calls can be configured for the whole RFC Adapter as a property of the RFC Adapter J2EE Service. To change this value, open the service properties sheet like described in Q3 and change the value of "syncMessageDeliveryTimeoutMsec". Notice that this value is specified in milliseconds. After changing the property store the properties by clicking the save-button (disk symbol) on top of the page.
From NW PI 7. 2 onwards, you can also configure a channel based timeout. This value(also in milliseconds) can be entered in the Sender RFC channel's Advanced Tab. The value entered here preemts the value entered in the NetWeaver Administrator. This value can also be supplied as a module parameter to the RFC Adapter's module, RfcAfBean with the name "syncTimeout".
If a similar error messages is shown for a receiver channel the timeout setting is done in the inbound XI-Adapter of the Adapter Engine and not via the above described setting in the RFC-Adapter. The value of xiadapter.inbound.timeout.default from J2EE Service 'SAP XI Adapter: XI' is used in this case. Note 791379 will explain this in detail.
Q 15: Whats wrong when the error message "lookup of alternativeServiceIdentifier via CPA-cache failed" shows up while sending a RFC call to the RFC Adapter?
A: An RFC sender channel is located beneath a service within the Integration Directory. Within this service, choose "Service" -> "Adapter-Specific Identifiers". The values in the fields "R/3 System ID" and "Client" has to be maintained with the correct values of the system, that sends the RFC call to the RFC Adapter. It normally only makes sense to have these values filled for services of type "Business System". If maintained in SLD, this fields will be filled automaticaly for services of type "Business System" and can be updated with the button "Compare with System Landscape Directory".
If a non-ABAP system is used to send RFC-calls to the RFC-Adapter sender channel it may not be possible to set the SYS-ID and CLIENT values in this external RFC client. The checking of these values can be disabled in the 'RFC Server Parameter' settings in the RFC sender channel. Choose 'Advanced Mode' and deselect 'Verify Sender System'.
Q 16: While sending a message to the RFC Adapter the error "... functiontemplate from repository was <null>" is shown. What is the reason?
A: After receiving a message from the Adapter Engine, the RFC Adapter extracts the payload from the message. Normally this should be an XML document in the RFC-XML format. In this format the root element of the XML document represents the name of the function module and is enclosed in the fixed RFC namespace 'urn:sap-com:document:sap:rfc:functions'. But this only will be checked at a later point, when the conversion from XML to native RFC is done. As prerequisite of this conversion the structures and types of the function module parameters has to be known. This is also called metadata or function template. To get this function template the name of the function module is extracted from the root element of the XML document and is queried against the metadata repository of the communication channel. If the metadata repository doesn't have a function module with this name, the exception named above is thrown. Possible reasons are
Q 17: How can settings affecting the whole RFC Adapter be made?
A: The RFC Adapter is implemented as a J2EE Service and thus the properties of this service must be changed. This will affect the whole RFC Adapter and can be done from the J2EE Engines Visual Administrator or the Visual Administrator as described in Q3. Since the J2EE server can run as a cluster with several server nodes, the configuration can be changed for each single node independently or global for the whole cluster. Normally the configuration is equal on each cluster node.
When you are connected to the J2EE Engine with the J2EE Visual Administrator do the following for:
Select the property which you intend to change and it is copied into the input box at the bottom of the window. Now you can change this properties value and accept it with the 'Update' button. This can be done for any property belonging to the service. To actually apply the changes, the properties have to be saved with the disk symbol button on top of the window. To apply the new properties the service must be restarted. Confirm the following dialog to do the restart.
Q 18: The function module works fine with my parameters when I execute it in transaction SE37. Why do I get errors when sending the same data via RFC Adapter?
A: Parameters are treated different when SAPGUI is used. A detailed description of this problem can be found in note 206068. See also Q 24 which is related to this one.
Q 19: While sending a RFC call to the RFC Adapter I get a error message like "com.sap.aii.af.rfc.afcommunication.RfcAFWException: lookup of binding via CPA-cache failed..." or "com.sap.aii.af.rfc.afcommunication.RfcAFWException: senderAgreement not found: lookup of binding via CPA-cache failed...". What is missing?
A: The RFC Adapter tries to find a Sender Agreement for this RFC call but the lookup failes. The values used for this lookup are:
Q 20: It is not possible to send RFC calls to the RFC Adapter sender channel and the RFC Adapter is not registered at the SAP Gateway. RFC Adapter receiver channels report a error like "RFC Adapter: receiver channel not in list of running clientPools..." in the Message Audit Log of the Adapter Engine. What happened?
A: The RFC Adapter checks the configuration of each channel during the start of this channel. This is done during startup of the whole RFC Adapter (J2EE service) or when the RFC Adapter receives a new (or changed) channel from the Integration Directory. Mainly the RFC client parameter are checked with a connect/disconnect to the remote system. In receiver channels this is done for the client parameter and the metadata repository parameter, in sender channels only for the metadata repository parameter. If this check fails the channel is marked as failed and will not be used for sending or receiving of RFC calles within RFC Adapter. The test is done again each time when the channel is updated in the Integration Directory or after a restart of the RFC Adapter. The status of each channel in the RFC Adapter can be monitored in the Adapter Monitor. Note 769791 describes this in detail.
There may be situations where the check of the connection will fail due to a temporary error (like network, ...). The channel will not be usable despite the temporary error may disappeared when the first message should be delivered through this channel. If this is common in the environment where the RFC Adapter is used, the check can be disabled for the whole RFC Adapter. Set the RFC Adapter J2EE service property 'initialRfcClientConnectCheck' from 'true' to 'false'. The changing of J2EE properties is discussed in Q 17. This parameter was introduced in XI 3.0 SP9.
Q 21: What's to know about performance?
A: The RFC Adapter implementation does instrument the JARM performance monitoring. This is described in detail in note 746971.
Note that if tracing is enabled in the J2EE service 'Log Configurator' (not performance tracing!), this will have a bad effect on performance at all. So turn off tracing to increase performance. See also note 777356 on this issue.
The results can be viewed with the J2EE Visual Administrator in the service 'Performance Tracing' (tab 'JARM'). In 'Component Overview' the component names from below can be found directly. All entries from RFC Adapter are prefixed with 'XI:RFC Adapter:'.
Sender channel asynchronous
In 'Request Overview' the starting point is "com.sap.mw.jco.JCO.Server" and "XI:RFC Adapter:RfcServer.onCommit()".
XI:RFC Adapter:RfcServer. handleRequest() => Overall handling of this RFC request
XI:RFC Adapter:RfcServer.tRFC.handleRequest. convertRFC2XML => Convert JCO RFC Java objects to RFC-XML
XI:RFC Adapter:RfcServer.onCommit() => Overall commit handling for all RFC request received before
XI:RFC Adapter:RfcServer.tRFC.onCommit. sendAsynch2AF => Send the XI message asynchronously with the RFC-XML document as payload to the AF (incl. Module Processor)
Sender channel synchronous
In 'Request Overview' the starting point is "com.sap.mw.jco.JCO.Server".
XI:RFC Adapter:RfcServer. handleRequest() => Overall request handling for this RFC request
XI:RFC Adapter:RfcServer.sRFC.handleRequest. convertRFC2XML => Convert JCO RFC Java objects to RFC-XML
XI:RFC Adapter:RfcServer.sRFC.handleRequest. sendSync2AF => Send the XI message synchronously with the RFC-XML document as payload to the AF (incl. Module Processor)
XI:RFC Adapter:RfcServer.sRFC.handleRequest. identifyXmlDocumentType => Identify the type of XML-document that was received as response
XI:RFC Adapter:RfcServer.sRFC.handleRequest. convertXML2RFC => Convert RFC-XML to JCO RFC Java objects
Receiver channel synchronous
In 'Request Overview' the starting point is "XI:MessagingSystem:RequestConsumer.onMessage()".
XI:RFC Adapter:RfcClientPool. processRequest() => Overall processing of this XI message/RFC call
XI:RFC Adapter:RfcClientPool.processRequest. getClient => Retrieve a JCO.Client connected to the backend system from JCO.Pool
XI:RFC Adapter:RfcClientPool.processRequest. getFunctionRequest => Get the function metadata from the RFC metadata repository (may perform calls into the backend for the first retrieval)
XI:RFC Adapter:RfcClientPool.processRequest. convertXML2RFC => Convert RFC-XML to JCO Java objects
XI:RFC Adapter:RfcClientPool.processRequest. syncExecute => Actually call the backend system (incl. receive the result as JCO Java objects)
XI:RFC Adapter:RfcClientPool.processRequest. convertRFC2XML => Convert the JCO Java objects to RFC-XML
Receiver channel asynchronous
In 'Request Overview' the starting point is "XI:MessagingSystem:RequestConsumer.onMessage()".
XI:RFC Adapter:RfcClientPool. processRequest() => Overall processing of this XI message/RFC call
XI:RFC Adapter:RfcClientPool.processRequest. getClient => Retrieve a JCO.Client connected to the backend system
XI:RFC Adapter:RfcClientPool.processRequest. getFunctionRequest => Get the function metadata from the RFC metadata repository (may perform calls into the backend for the first retrieval)
XI:RFC Adapter:RfcClientPool.processRequest. convertXML2RFC => Convert RFC-XML to JCO RFC Java objects
XI:RFC Adapter:RfcClientPool.processRequest. convertTID => Create the TID used for tRFC
XI:RFC Adapter:RfcClientPool.processRequest. asyncExecute => Actually call the backend system
Q 22: Which value should be chosen for the field 'Program ID' for RFC sender channels?
A: A RFC Adapter sender channel registers itself with this Program ID as a RFC-Server at the SAP Gateway. The sending system uses the same Program ID to identify the RFC-Server at the SAP Gateway. If the sending system is an SAP system, this Program ID has to be maintained in the RFC destination (transaction SM59).
While sending, the system sends some RFC calls, the SAP Gateway will search its registration list for the Program ID supplied by the sending system. If there are more than one RFC-Server registered with the same Program ID, it will automaticaly schedule the RFC calls to each of the RFC-Servers using the round robin approach. This is done to distribute the load over all RFC-Servers equally.
To identify an XI RFC Adapter sender channel within the SAP Gateway it is important that its Program ID is unique within this Gateway. So try to avoid using common phrases as Program ID like 'RFC Adapter' or 'rfcToXmb'.
To check which Program IDs are registered at the SAP Gateway the gateway-monitor can be used via transaction SMGW. Select Goto -> Logged on Clients. Registered RFC-Servers have a System-Type of 'REGISTER_TP'. The Program ID of the registered RFC-Server can be found in column 'TP name'. Unfortunately the list within SMGW only shows the truncated version of the Program ID (column 'TP name'). To get the full name, the details of an entry have to be selected. As an alternative the report RSGETALL_REG_SERVERS can be executed in transaction SE38. The output of this report will show the full names of the Program ID in column 'Registered PROGID'. This functionality is also available in the function module GWY_READ_CONNECTED_SYSTEMS which can be executed in transaction SE37.
Note that if the RFC sender channel is configured to use more than one connection to the SAP Gateway, there will be one registration at the SAP Gateway for each connection. If the RFC Adapter runs on a J2EE cluster with more than one server node, the number of registrations at the SAP Gateway is the number of connections configured in the RFC sender channel multiplied by the number of cluster nodes on which the RFC Adapter runs.
Q 23: How can the payload of a XI message be normalized to the RFC-XML format? Is it possible to remove unwanted XML-Namespace declarations from a RFC-XML document?
A: While sending a message to an RFC-Adapter receiver channel an error is thrown during RFC-XML-document parsing. The RFC-XML document looks like it has the correct RFC-XML format but there are some additional XML elements (e.g. XML-Namespace declarations). These elements can't be understood by the RFC-XML parser of the RFC-Adapter. This parser only is suitable for the correct RFC-XML documents (like created by a RFC-Adapter sender channel or the SAP JCO).
To remove the unneeded elements from the RFC-XML document a message mapping within the Integration Server can be used. The attached file rfcnormalizer.jar contains a XSLT-Stylesheet which can be used for this purpose.
Q 24: It seems that the RFC-Adapter does not convert every parameter of the function module between native RFC and RFC-XML. It looks like some parameter is lost or empty. Why does this happen?
A: The conversion between native RFC and RFC-XML is done by using the metadata provided by the metadata repository, which is an SAP-system. Before the first call to one function module it's metadata is retrived from the SAP-system and stored in a local RFC-Adapter cache memory. Each successive call to the same function module uses this cache which is much faster.
If the signature of the function module is changed in the SAP-system this change also has to be done in the RFC-Adapter's cache memory. The possible solutions do accomplish this are described in Q5.
In case of an RFC receiver channel, the called function module in the SAP system can be debuged with the ABAP debugger. This way the actual used parameter values of the request and the response can be viewed in the ABAP debugger. Note 668256 describes the procedures for ABAP remote debugging.
See also Q 18 which is related to this one.
Q 25: An RFC sender channel is registered at an SAP Gateway which is shutdown. Does the RFC sender channel automatically reconnect to the SAP Gateway after it is available again?
A: The SAP Gateway is shutdown due to e.g. offline backup of the R/3 database while a RFC-Adapter sender channel is registering at this SAP Gateway. After restarting the SAP Gateway, the RFC sender channel does not seem to automatically perform a reconnect.
Actually the RFC sender channel will try to reconnect to the SAP Gateway. If this reconnect fails, the next reconnect attempt is made after a waiting period of 1 second. If the next reconnect fails also, the waiting period is doubled and so on. This will lead to a reconnect timing of 1, 2, 4, 8, ..., 3600 seconds. Saving recources is the aim of this technique.
Once the maximum time is reached, the RFC channel does not stop connecting. It continues to try connecting indefinitely. The waiting period is a constant interval of the maximum time that is set, i.e. after every 3600seconds.
If not configured, the maximum waiting time is defined in the middleware layer of SAP JCO, which is 3600 seconds. But this maximum time can be configured for each RFC sender channel in the XI Integration Directory. Open the Advanced Mode for the RFC Server Parameter.
See also Q 31 which is related to this topic.
Q 26: During sending an RFC call to a sender channel the following error message comes up in the sending SAP system: 'alternativeServiceIdentifier: party/service from channel configuration are not equal to party/service from lookup of alternativeServiceIdentifier...' What does this mean?
A: When an RFC call is sent from an SAP system to the RFC sender channel, the SYS-ID and the Client of the sending system are also transfered. During processing of this RFC call the sender channel does a lookup for these values in the Integration Direcory (partyless service, alternative identifiers for RFC) to find the XI service which correspond to the SYS-ID and Client.
The sender channel itself is located beneath a partyless XI service. If this XI service and the one found via the lookup are not equal the described error is issued.
This situation indicates a wrong configuration either within XI or the sending SAP system. Each SAP system (a combination of SYS-ID and Client) should have a corresponding partyless service within the XI Integration Directory. Also for each client in one SAP system at least one unique 'Program ID' is needed (see Q22).
Q 27: Can the RFC-Metadata-Repository be different from the RFC-sender/-receiver channel in terms of Unicode?
A: The RFC-Metadata-Repository has to match the sender/receiver channel in terms of Unicode. It is not possible to mix a Unicode sender/receiver channel with a non-Unicode metadata repository (or vice versa).
See also Q5.
Q.28 : While sending an RFC call to the Sender Channel the following error message comes up in the Sending SAP system:'Wrong Sender Agreement:The Sender agreement does not have channel channelName configured for the functionmodule' What does this mean?
A: When an RFC Sender Channel is created in the Integration Directory and later gets transferred to CPA Cache, it registers itself at the Gateway with PROGRAMID mentioned in the Channel Settings. Hence when an RFC call is made with a destination having the same PROGRAMID ,this call can be directly routed through this channel without any mandatory lookup of Sender Agreement. This implies that RfC adapter knows its channel since startup.
Till SP15 during lookup if a Sender Agreement was found, the processing continued without any check whether the found channel from Agreement equals the one from startup time. This was the reason why interfaces could be sent over a channel which is not configured in the agreement. To have atleast one Sender Agreement fitting the interface was sufficient.For instance if two channels (A & B) were configured beneath the same Business Service and Sender Agreement was created which pointed to Channel A.,it was also possible to send the RFC calls over channel B although it is not configured in the Agreement.
To over come this limitation since SP16 a stricter verification of Sender Agreement is done to check if the configured channel in agreement is equal to the channel through which the RFC call is made. If not then the above mentioned exception is thrown.
Also this stricter verification can be disabled by setting the J2EE Service Property 'verifySenderAgreement' for RFC adapter to false. Setting this property to false in the Visual Administrator/NetWeaver Administrator will prevent such a check for all the RFC calls made through the RFC Adapter.
Q 29: When a function module is changed in the backend, are the changes published to the runtime at real-time?
A: No, an update made to a function module in the backend is not informed to the runtime. This is because the function module metadata is cached by the system during the first invocation of the module. All the subsequent references to this function module are directed to the cache. Any update made to the function module in the backend will not be notified to the runtime, unless the cache is cleared.
The cache is cleared when any of the following happen:
- The corresponding RFC channel is restarted
- The RFC channel is changed in the Integration Directory
- The RFC adapter service is restarted
- The Dependent J2EE services are restarted (MessagingSystem, CPACache, and so on)
- The J2EE server is restarted
Q 30: A scenario is using principal propagation. There is an upgradation of R/3 system that takes place. Once the upgrade is completed, principal propagation does not work. An error " ERROR => Recipient system name does not match with current system" is got. What does this mean?
A: The error that you were facing is due to the fact that the system id needs to be validated when the principal propagation is activated. In earlier case before the upgradation, there was no validation that was done to check for the system id and hence this scenario works correctly without any parameters being introduced.
In the latest versions, there has been an introduction of the validation of the system id at the ABAP side. Hence as a result the system id needs to be passed for the scenario to work correctly.
To avoid the error after upgradation, in the receiver channel configuration below RFC Client Parameter, select the 'Advanced Mode' option and enter the parameter 'jco.client.r3name' in the table in the Name column and enter the SYSID of the receiver R/3 system in Value column. Then save and activate the changes and re-execute the scenario.
This process is valid only for the 7.0 and lesser releases.
Q 31: You observe that the Program Id for an RFC Sender Channel is no longer registered at the SAP Gateway to which the channel should be connected. The TCP/IP destination used to send messages to the RFC Sender Channel does not work anymore and you get the following error: "ERROR: program <PROGID> not registered". At the same time there are no error messages displayed in the Runtime Workbench Channel Monitoring page, the RFC Sender Channel is green and no reconnection attempts are made.
A: This situation can be observed in the cases when the used SAP Gateway and the Adapter Engine (AE) for the RFC Sender Channel are on remote systems, possibly connected via multiple network devices (switches/routers/firewalls). The issue appears when the TCP/IP connection socket between the registered RFC Sender Channel's AE and the SAP Gateway is closed without signaling the interruption to the RFC Sender Channel's AE. Thus the TCP/IP socket is not closed on the operating system's network layer at the RFC Sender Channel's AE side and the channel does not recognize the error and keeps listening for incoming messages. To correct this, the RFC Sender Channel should be registered again to the SAP Gateway by manually restarting (stop/start) the channel. However, if this issue occurs often, the general recommendation is to use SAP Gateway to register the RFC Sender Channel that is on the same host as the RFC Sender Channel's AE (or at least on a host in the same network segment). In the Central Adapter Engine case, you may use the SAP Gateway of your XI/PI ABAP system; and in the De-central Adapter Engine case you may install an additional standalone SAP Gateway.
For more information regarding the possible causes and the solution you can also refer to SAP Note 1494757 - 'Improving stability of registered RFC server connections' (section 'Minimizing the network route').
Q 1: What is discussed in this document?
A: This document discusses questions about the XI 3.0 RFC Adapter, NW 7.0 RFC Adapter, NW PI 7.1 RFC Adapter, NW PI 7.10 EhP1 RFC Adapter.
Q 2: Is there more than one version of a XI RFC Adapter ?
A: There are two kinds of RFC Adapters. The first one came with XI 2.0 and was part of the Adapter Engine. With XI 3.0 this Adapter Engine was renamed to 'J2SE Plain Adapter Engine'. It does not contain an RFC Adapter any more. Instead, with XI 3.0, there is new Adapter Engine called 'J2EE Adapter Engine'. It is based on the SAP J2EE Application Server and contains a new RFC Adapter, which runs as a Service of the J2EE Server. This document only describes the J2EE RFC Adapter.
Q 3: How can the RFC Adapter be started and stopped?
A: The RFC Adapter is implemented as a J2EE Service and can be started and stopped. The start/stop affects the whole RFC Adapter. The adapter can be started/stopped from:
- For XI 3.0 SP X, NW 7.0 SP X and NW 7.0X SP X: J2EE Engines Visual Administrator. When you are connected to the J2EE Engine choose the tab 'Cluster' and open the appropriate server node in the tree. Then open the 'Services' node. There you can see the entry 'SAP XI Adapter: RFC'. When you open the context menu on this entry you can start/stop the service.
- For
NW PI 7.10 SPX and NW PI 7.1X SPX: Launch the NetWeaver Administrator
through: http://host:port/nwa. Goto Operation Management --> Systems
--> Start & Stop --> Java EE Services --> XPI Adapter: RFC.
In the screen below, you get the buttons to start/stop the service.
To access the RFC Adapter's Service Properties, Goto Configuration Management --> Infrastructure --> Java System Properties --> Services. Look for "XPI Adapter: RFC". The screen in the bottom with the heading "Extended Details" displays the RFC Adapter's service property.
Q 4: Where can the RFC Adapter communication channels be configurated?
A: The channels for the RFC Adapter can be configurated within the XI Integration Builder: Configuration (Integration Directory). Choose tab 'Objects' and open 'Service without Partner' -> 'Business-System'. Open the business system for which you want to communicate via RFC and choose 'New' from the context menu on the node 'Communication Channel'. Enter a name for the new channel and choose 'Create'. For 'Adapter Type' you have to choose 'RFC' (via the F4-help).
Q 5: What's about cache memories within the RFC Adapter?
A: The RFC Adapter has a cache for the metadata of function modules. This means it caches the definition of function modules, structures and other datatypes. A separate cache is used for each communication channel. When the particular data is needed during runtime, the cache is filled from the configured RFC metadata repository. Once if a particular metadata has entered the cache, only this one is used and no lookups to the RFC metadata repository are made for this type of metadata. If the communication channel is changed within the Integration Directory and gets replicated to the appropriate Adapter Engine (see Environment -> Cache Notifications...), this metadata cache is cleared. The caches for all communication channels are cleared when the J2EE Engine is restarted, the RFC Adapter J2EE Service 'SAP XI Adapter: RFC' is restarted or a J2EE Service on which the RFC adapter service is dependent ('SAP XI AF CPA Cache', 'SAP XI AF Messaging') is restarted.
See also Q27.
Q 6: Is there a special handling of the '/' character in the names of function modules?
A: As the '/' character can cause conflicts within XML documents it is escaped with the sequence '_-'. A RFC sender channel will do the escaping of '/' to '_-' and a RFC receiver channel will do the opposite. This only will be done for the RFC-XML document.
Q 7: Can there be multiple function module calls within one transaction for RFC sender channels?
A: RFC Adapter only supports one call within one transaction (sometimes also called LUW). If an attempt is made to place a second call within the same transaction, an exception is raised. This is done because within XI there is no transactional context between messages and each RFC call is wrapped into one message.
Q 8: Is it possible to issue several RFC calls within one context for RFC receiver channels?
A: No, a context between several RFC calls can not be held. Each call will get it's own context because different connections to the receiving system are used.
Q 9: Which flavous of RFC are supported?
A: RFC Adapter supports synchronous RFC (sRFC, sometimes also called only RFC) and transactional RFC (tRFC). Queued RFC (qRFC) with inbound queues and asynchronous RFC (aRFC) are not supported. An sRFC will result in a synchronous best effort (BE) message; a tRFC in a asynchronous exactly once (EO) and vice versa. Messages with exactly once in order (EOIO) are not supported till and including XI 3.0 SP10.
With SP11 a XI EOIO-messages will result in a normal tRFC call. If a tRFC is sent to an SAP-system it will be executed directly (in other words synchronously) plus the tRFC exactly once handling. The order of the messages belonging to one EOIO-queue will be guaranteed by the Adapter Framework messaging layer.
Q 10: What's about BAPIs?
A: The following only applies to RFC receiver channels.
BAPIs can be implemented as RFC enabled function modules or IDocs. By their nature, RFC function modules are synchronous, and IDocs are asynchronous. Thus, if the communication should be asynchronous, it is a good idea to use the IDoc implementation of BAPI.
The RFC function module implementation of a BAPI will not only report it's result in a synchronous response, it will also report it's execution status (like Success, Error, etc). If the RFC call to such a function module was asynchronous, there will be no response and also no knowledge about the execution status. Even if the RFC call was synchronous, the RFC Adapter does no special handling for this values. It will treat a response value of any kind as a successful execution because it does not implement some BAPI application logic.
Nevertheless the RFC Adapter will treat each RFC call like described in Q 9: A XI message with QoS BE will lead to a (synchronous) sRFC call, a message with QoS EO will lead to a (asynchronous) tRFC call.
BAPIs with a database update or write functionality expect a special form of commit (ABAP application COMMIT WORK) to actually fulfill their tasks because they (often) use the SAP update technique. Within RFC Adapter there is no special handling of transactions like a commit, so database update BAPIs may have a problem. If the BAPI RFC function module is called (asynchronous) via tRFC, the tRFC-subsystem of the SAP-System will issue a database commit by itself (no ABAP COMMIT WORK). So direct database updates will be possible but no updates via the SAP update process. Also the problem with the missing execution result persists.
The following can be considered to use BAPIs with RFC Adapter regarding the interpretation of the execution result and the commit of the transaction. If it is required that one update BAPI is called, it can be put in a wrapper RFC function module which first calls this BAPI, does the interpretation of the execution result and than does the commit or rollback of the transaction. If it is required that multiple update BAPIs get committed together within one transaction, these BAPIs can be encapsulated in a wrapper RFC function module which first calls the BAPIs and at the end does the commit of the transaction depending on their execution result. In either case the wrapper RFC function module can be called by RFC Adapter.
Anyway you have to keep in mind that this can compromise the quality of service (QoS) which was guaranteed by the original message. Imagine these two possibilities: a synchronous message with QoS BE or a asynchronous message with QoS EO.
- A message is sent synchronously with QoS BE (which will result in a synchronous RFC call, also called sRFC). The call reaches the receiver system and the function module is executed successful with the commit at the end. But while sending the return value a problem occurs (like network, ...). This can also happen if there is no return value in the function module, because the receiver system at least will send back an indication that the execution has finished. So the RFC Adapter will generate an error (like timeout, ...) and send it back to the sender of the message. As seen in this example the sender will not know if the message (containing the RFC call) has reached the receiver system and also if the execution happened in the receiver system.
- A message is sent asynchronously with QoS EO (which will result in a transactional RFC call, also called tRFC). The call reaches the receiver system and the function module is executed successful with the commit at the end. But while sending back the indication that the RFC call was executed (which actually will be synchronous) a problem occurs (like network, ...). The RFC Adapter will generate an error and send it back to it's persistency layer, the Adapter Framework Messaging. The message now marked as erroneous will be scheduled for a new execution because for messages with QoS EO the delivery will be guaranteed. When sent again, the receiving system's tRFC implementation checks whether the call was already successfully received or not. This guarantees the exactly once handling of the tRFC implementation.
As of XI 3. 0 SP 14, support for commit handling for single BAPI calls was added to the RFC Adapter receiver channel. If activated in the receiver channel setting, the received XI message will be executed as synchronous RFC (sRFC) in the receiving system. This is also true for asynchronous (QoS EO) XI messages to receive and analyze the execution result by the RFC Adapter.
The received response is parsed by the RFC Adapter to get the BAPI return parameter with the name "RETURN". This return parameter can be of type: BAPIRETURN, BAPIRET1 or BAPIRET2. The "RETURN" parameter is checked for a response status (field TYPE) which can have the following values:
1. 'S' : Success
2. 'I' : Information
3. 'W' : Warning
4. '' : Empty String
5. 'A' : Abort
6. 'E' : Error
If the response contains one amongst the first four response status, then it implies that the BAPI was successfully executed. If the response contains one amongst the last two response, then it means that the BAPI execution failed. If the BAPI "RETURN" parameter is not of type "ABAP structure" and is rather of type "ABAP table", an empty table is also considered as successful execution result.
In case of a successful execution of the BAPI function module, a "BAPI_TRANSACTION_COMMIT" is called within the same context to trigger the commit of the BAPI. For release higher that NW PI 7.10 SP7, please also refer Note 1342143.
In case of a failure, the BAPI function module "BAPI_TRANSACTION_ROLLBACK" is executed by RFC Adapter which rolls back the changes.
If the XI request message was of QoS BE, the result of the BAPI execution is sent back as an XI response. In case of a QoS EO request message, nothing is sent back as response.
Q 11: Is there something to know about the module processor?
A: Any adapter need an EJB to communicate with the module processor of the Adapter Engine. The EJB used by the RFC Adapter is called 'localejbs/RfcAFBean'. This can be configured in the Integration Directory for each communication channel on the tab 'Module'. If the list on this tab is empty, it defaults to the EJB named above and nothing has to be done. So if no modules should be used, everything will work without a special configuration. If some custom modules are configured to be used, the last module always has to be the RFC Adapter module. This will establish the communication between the adapter and the Adapter Engine.
Q 12: How can tracing be enabled for RFC Adapter?
A:
a) For XI 3.0 SP X, NW 7.0 SP X and NW 7. 0X SP X: Open the J2EE Visual Administrator, log into the J2EE Engine and choose tab 'Cluster'. Open the server node for which tracing should be enabled and open Services->Log Configurator. Choose tab 'Locations' and open com->sap->aii->af then choose the location 'rfc'. In the right frame the name 'com.sap.aii.af.rfc' shows up with the current serverity. Set this serverity level to 'Debug' and also click on the button 'Copy severity to subtree'. After this click on the 'Apply' button (save symbol) so save the changes. For an RFC sender channel also choose 'SAP XI Adapter: RFC' beneath 'Services' in the left frame.
Set the properties 'traceExceptionListener' and 'traceServerErrorListener' to 'true' (in the right frame). Save these changes with the save button. Notice that the RFC Adapter J2EE service has to be restarted to affect this changes. A dialog box will open upon save which can perform the restart after choosing 'Yes'. After enabling the traces the scenario can be reproduced and the default traces can be found at "\usr\sap\<SYSID>\<INSTANCEID>\j2ee\cluster\server0\log" folder.
b) For NW PI 7.10 SPX and NW PI 7.1X SPX: Launch the NetWeaver Administrator through: http://host:port/nwa. Goto Problem Management --> Logs & Traces --> Log Configuration. Change the 'Show' dropdown, to 'Tracing Location'. In the Window below, look for com.sap.aii.adapter.rfc. Change it to debug, copy to subtree and save your changes.
Goto RFC Adapter's Service Properties as described in Q3. Set the properties 'traceExceptionListener' and 'traceServerErrorListener' to 'true'. Save these changes with the save button. Notice that the RFC Adapter J2EE service has to be restarted to affect this changes. After enabling the traces the scenario can be reproduced and the default traces can be found at "\usr\sap\<SYSID>\<INSTANCEID>\j2ee\cluster\server0\log" folder.
Q 13: What is the correct value within the field 'Application server service (Gateway)' for sender channels?
A: This value has to be the name of the service port which is running the gateway. Normally this will be a name like sapgwXX, where XX is the system number of the particular system. This value also can be looked up in the gateway monitor. Open transaction SMGW and choose Goto -> Parameters -> Display. Beneath Attributes there will be the entries 'gateway hostname' and 'gateway service'.#
Q 14: During a synchronous RFC call to the RFC Adapter (sender channel) the error message "call to messaging system failed: com.sap.aii.af.ra.ms.api.MessageExpiredException" comes up. For receiver channels a similar error messages is shown. What does this mean and what could be done about it?
A: At the beginning of a synchronous RFC call the RFC Adapter (sender channel) builds up the XI request-message and sends it to the Adapter Engine with a timeout. After this it waits till the response-message reaches or the timeout expires. In case of timeout the exception named above is thrown. The timeout used by RFC Adapter for synchronous calls can be configured for the whole RFC Adapter as a property of the RFC Adapter J2EE Service. To change this value, open the service properties sheet like described in Q3 and change the value of "syncMessageDeliveryTimeoutMsec". Notice that this value is specified in milliseconds. After changing the property store the properties by clicking the save-button (disk symbol) on top of the page.
From NW PI 7. 2 onwards, you can also configure a channel based timeout. This value(also in milliseconds) can be entered in the Sender RFC channel's Advanced Tab. The value entered here preemts the value entered in the NetWeaver Administrator. This value can also be supplied as a module parameter to the RFC Adapter's module, RfcAfBean with the name "syncTimeout".
If a similar error messages is shown for a receiver channel the timeout setting is done in the inbound XI-Adapter of the Adapter Engine and not via the above described setting in the RFC-Adapter. The value of xiadapter.inbound.timeout.default from J2EE Service 'SAP XI Adapter: XI' is used in this case. Note 791379 will explain this in detail.
Q 15: Whats wrong when the error message "lookup of alternativeServiceIdentifier via CPA-cache failed" shows up while sending a RFC call to the RFC Adapter?
A: An RFC sender channel is located beneath a service within the Integration Directory. Within this service, choose "Service" -> "Adapter-Specific Identifiers". The values in the fields "R/3 System ID" and "Client" has to be maintained with the correct values of the system, that sends the RFC call to the RFC Adapter. It normally only makes sense to have these values filled for services of type "Business System". If maintained in SLD, this fields will be filled automaticaly for services of type "Business System" and can be updated with the button "Compare with System Landscape Directory".
If a non-ABAP system is used to send RFC-calls to the RFC-Adapter sender channel it may not be possible to set the SYS-ID and CLIENT values in this external RFC client. The checking of these values can be disabled in the 'RFC Server Parameter' settings in the RFC sender channel. Choose 'Advanced Mode' and deselect 'Verify Sender System'.
Q 16: While sending a message to the RFC Adapter the error "... functiontemplate from repository was <null>" is shown. What is the reason?
A: After receiving a message from the Adapter Engine, the RFC Adapter extracts the payload from the message. Normally this should be an XML document in the RFC-XML format. In this format the root element of the XML document represents the name of the function module and is enclosed in the fixed RFC namespace 'urn:sap-com:document:sap:rfc:functions'. But this only will be checked at a later point, when the conversion from XML to native RFC is done. As prerequisite of this conversion the structures and types of the function module parameters has to be known. This is also called metadata or function template. To get this function template the name of the function module is extracted from the root element of the XML document and is queried against the metadata repository of the communication channel. If the metadata repository doesn't have a function module with this name, the exception named above is thrown. Possible reasons are
- The XML document, which was sent to the RFC Adapter, is not a RFC-XML document. So the root element name of this document is not the name of a function module and thus can't be found in the metadata repository.
- The metadata repository doesn't contain an entry for this function module name. Normally the metadata repository will be an R/3 system and it's function module repository can be searched with the transaction SE37.
Q 17: How can settings affecting the whole RFC Adapter be made?
A: The RFC Adapter is implemented as a J2EE Service and thus the properties of this service must be changed. This will affect the whole RFC Adapter and can be done from the J2EE Engines Visual Administrator or the Visual Administrator as described in Q3. Since the J2EE server can run as a cluster with several server nodes, the configuration can be changed for each single node independently or global for the whole cluster. Normally the configuration is equal on each cluster node.
When you are connected to the J2EE Engine with the J2EE Visual Administrator do the following for:
- Global configuration: Choose tab 'Global Configuration' and then tab 'Server'. Open the tree node 'Services' and select 'SAP XI Adapter: RFC'.
- Single node configuration: Choose tab 'Cluster' and open the appropriate server node in the tree. Then open the tree node 'Services' and select 'SAP XI Adapter: RFC'.
Select the property which you intend to change and it is copied into the input box at the bottom of the window. Now you can change this properties value and accept it with the 'Update' button. This can be done for any property belonging to the service. To actually apply the changes, the properties have to be saved with the disk symbol button on top of the window. To apply the new properties the service must be restarted. Confirm the following dialog to do the restart.
Q 18: The function module works fine with my parameters when I execute it in transaction SE37. Why do I get errors when sending the same data via RFC Adapter?
A: Parameters are treated different when SAPGUI is used. A detailed description of this problem can be found in note 206068. See also Q 24 which is related to this one.
Q 19: While sending a RFC call to the RFC Adapter I get a error message like "com.sap.aii.af.rfc.afcommunication.RfcAFWException: lookup of binding via CPA-cache failed..." or "com.sap.aii.af.rfc.afcommunication.RfcAFWException: senderAgreement not found: lookup of binding via CPA-cache failed...". What is missing?
A: The RFC Adapter tries to find a Sender Agreement for this RFC call but the lookup failes. The values used for this lookup are:
- Sender Party/Sender Service: The values from Party and Service belonging to the sender channel.
- Sender Interface: The name of the RFC function module.
- Sender Namespace: The fix RFC namespace urn:sap-com:document:sap:rfc:functions
- Receiver Party/Receiver Service: These fields are empty. This will match the wildcard '*'.
Q 20: It is not possible to send RFC calls to the RFC Adapter sender channel and the RFC Adapter is not registered at the SAP Gateway. RFC Adapter receiver channels report a error like "RFC Adapter: receiver channel not in list of running clientPools..." in the Message Audit Log of the Adapter Engine. What happened?
A: The RFC Adapter checks the configuration of each channel during the start of this channel. This is done during startup of the whole RFC Adapter (J2EE service) or when the RFC Adapter receives a new (or changed) channel from the Integration Directory. Mainly the RFC client parameter are checked with a connect/disconnect to the remote system. In receiver channels this is done for the client parameter and the metadata repository parameter, in sender channels only for the metadata repository parameter. If this check fails the channel is marked as failed and will not be used for sending or receiving of RFC calles within RFC Adapter. The test is done again each time when the channel is updated in the Integration Directory or after a restart of the RFC Adapter. The status of each channel in the RFC Adapter can be monitored in the Adapter Monitor. Note 769791 describes this in detail.
There may be situations where the check of the connection will fail due to a temporary error (like network, ...). The channel will not be usable despite the temporary error may disappeared when the first message should be delivered through this channel. If this is common in the environment where the RFC Adapter is used, the check can be disabled for the whole RFC Adapter. Set the RFC Adapter J2EE service property 'initialRfcClientConnectCheck' from 'true' to 'false'. The changing of J2EE properties is discussed in Q 17. This parameter was introduced in XI 3.0 SP9.
Q 21: What's to know about performance?
A: The RFC Adapter implementation does instrument the JARM performance monitoring. This is described in detail in note 746971.
Note that if tracing is enabled in the J2EE service 'Log Configurator' (not performance tracing!), this will have a bad effect on performance at all. So turn off tracing to increase performance. See also note 777356 on this issue.
The results can be viewed with the J2EE Visual Administrator in the service 'Performance Tracing' (tab 'JARM'). In 'Component Overview' the component names from below can be found directly. All entries from RFC Adapter are prefixed with 'XI:RFC Adapter:'.
Sender channel asynchronous
In 'Request Overview' the starting point is "com.sap.mw.jco.JCO.Server" and "XI:RFC Adapter:RfcServer.onCommit()".
XI:RFC Adapter:RfcServer. handleRequest() => Overall handling of this RFC request
XI:RFC Adapter:RfcServer.tRFC.handleRequest. convertRFC2XML => Convert JCO RFC Java objects to RFC-XML
XI:RFC Adapter:RfcServer.onCommit() => Overall commit handling for all RFC request received before
XI:RFC Adapter:RfcServer.tRFC.onCommit. sendAsynch2AF => Send the XI message asynchronously with the RFC-XML document as payload to the AF (incl. Module Processor)
Sender channel synchronous
In 'Request Overview' the starting point is "com.sap.mw.jco.JCO.Server".
XI:RFC Adapter:RfcServer. handleRequest() => Overall request handling for this RFC request
XI:RFC Adapter:RfcServer.sRFC.handleRequest. convertRFC2XML => Convert JCO RFC Java objects to RFC-XML
XI:RFC Adapter:RfcServer.sRFC.handleRequest. sendSync2AF => Send the XI message synchronously with the RFC-XML document as payload to the AF (incl. Module Processor)
XI:RFC Adapter:RfcServer.sRFC.handleRequest. identifyXmlDocumentType => Identify the type of XML-document that was received as response
XI:RFC Adapter:RfcServer.sRFC.handleRequest. convertXML2RFC => Convert RFC-XML to JCO RFC Java objects
Receiver channel synchronous
In 'Request Overview' the starting point is "XI:MessagingSystem:RequestConsumer.onMessage()".
XI:RFC Adapter:RfcClientPool. processRequest() => Overall processing of this XI message/RFC call
XI:RFC Adapter:RfcClientPool.processRequest. getClient => Retrieve a JCO.Client connected to the backend system from JCO.Pool
XI:RFC Adapter:RfcClientPool.processRequest. getFunctionRequest => Get the function metadata from the RFC metadata repository (may perform calls into the backend for the first retrieval)
XI:RFC Adapter:RfcClientPool.processRequest. convertXML2RFC => Convert RFC-XML to JCO Java objects
XI:RFC Adapter:RfcClientPool.processRequest. syncExecute => Actually call the backend system (incl. receive the result as JCO Java objects)
XI:RFC Adapter:RfcClientPool.processRequest. convertRFC2XML => Convert the JCO Java objects to RFC-XML
Receiver channel asynchronous
In 'Request Overview' the starting point is "XI:MessagingSystem:RequestConsumer.onMessage()".
XI:RFC Adapter:RfcClientPool. processRequest() => Overall processing of this XI message/RFC call
XI:RFC Adapter:RfcClientPool.processRequest. getClient => Retrieve a JCO.Client connected to the backend system
XI:RFC Adapter:RfcClientPool.processRequest. getFunctionRequest => Get the function metadata from the RFC metadata repository (may perform calls into the backend for the first retrieval)
XI:RFC Adapter:RfcClientPool.processRequest. convertXML2RFC => Convert RFC-XML to JCO RFC Java objects
XI:RFC Adapter:RfcClientPool.processRequest. convertTID => Create the TID used for tRFC
XI:RFC Adapter:RfcClientPool.processRequest. asyncExecute => Actually call the backend system
Q 22: Which value should be chosen for the field 'Program ID' for RFC sender channels?
A: A RFC Adapter sender channel registers itself with this Program ID as a RFC-Server at the SAP Gateway. The sending system uses the same Program ID to identify the RFC-Server at the SAP Gateway. If the sending system is an SAP system, this Program ID has to be maintained in the RFC destination (transaction SM59).
While sending, the system sends some RFC calls, the SAP Gateway will search its registration list for the Program ID supplied by the sending system. If there are more than one RFC-Server registered with the same Program ID, it will automaticaly schedule the RFC calls to each of the RFC-Servers using the round robin approach. This is done to distribute the load over all RFC-Servers equally.
To identify an XI RFC Adapter sender channel within the SAP Gateway it is important that its Program ID is unique within this Gateway. So try to avoid using common phrases as Program ID like 'RFC Adapter' or 'rfcToXmb'.
To check which Program IDs are registered at the SAP Gateway the gateway-monitor can be used via transaction SMGW. Select Goto -> Logged on Clients. Registered RFC-Servers have a System-Type of 'REGISTER_TP'. The Program ID of the registered RFC-Server can be found in column 'TP name'. Unfortunately the list within SMGW only shows the truncated version of the Program ID (column 'TP name'). To get the full name, the details of an entry have to be selected. As an alternative the report RSGETALL_REG_SERVERS can be executed in transaction SE38. The output of this report will show the full names of the Program ID in column 'Registered PROGID'. This functionality is also available in the function module GWY_READ_CONNECTED_SYSTEMS which can be executed in transaction SE37.
Note that if the RFC sender channel is configured to use more than one connection to the SAP Gateway, there will be one registration at the SAP Gateway for each connection. If the RFC Adapter runs on a J2EE cluster with more than one server node, the number of registrations at the SAP Gateway is the number of connections configured in the RFC sender channel multiplied by the number of cluster nodes on which the RFC Adapter runs.
Q 23: How can the payload of a XI message be normalized to the RFC-XML format? Is it possible to remove unwanted XML-Namespace declarations from a RFC-XML document?
A: While sending a message to an RFC-Adapter receiver channel an error is thrown during RFC-XML-document parsing. The RFC-XML document looks like it has the correct RFC-XML format but there are some additional XML elements (e.g. XML-Namespace declarations). These elements can't be understood by the RFC-XML parser of the RFC-Adapter. This parser only is suitable for the correct RFC-XML documents (like created by a RFC-Adapter sender channel or the SAP JCO).
To remove the unneeded elements from the RFC-XML document a message mapping within the Integration Server can be used. The attached file rfcnormalizer.jar contains a XSLT-Stylesheet which can be used for this purpose.
Q 24: It seems that the RFC-Adapter does not convert every parameter of the function module between native RFC and RFC-XML. It looks like some parameter is lost or empty. Why does this happen?
A: The conversion between native RFC and RFC-XML is done by using the metadata provided by the metadata repository, which is an SAP-system. Before the first call to one function module it's metadata is retrived from the SAP-system and stored in a local RFC-Adapter cache memory. Each successive call to the same function module uses this cache which is much faster.
If the signature of the function module is changed in the SAP-system this change also has to be done in the RFC-Adapter's cache memory. The possible solutions do accomplish this are described in Q5.
In case of an RFC receiver channel, the called function module in the SAP system can be debuged with the ABAP debugger. This way the actual used parameter values of the request and the response can be viewed in the ABAP debugger. Note 668256 describes the procedures for ABAP remote debugging.
See also Q 18 which is related to this one.
Q 25: An RFC sender channel is registered at an SAP Gateway which is shutdown. Does the RFC sender channel automatically reconnect to the SAP Gateway after it is available again?
A: The SAP Gateway is shutdown due to e.g. offline backup of the R/3 database while a RFC-Adapter sender channel is registering at this SAP Gateway. After restarting the SAP Gateway, the RFC sender channel does not seem to automatically perform a reconnect.
Actually the RFC sender channel will try to reconnect to the SAP Gateway. If this reconnect fails, the next reconnect attempt is made after a waiting period of 1 second. If the next reconnect fails also, the waiting period is doubled and so on. This will lead to a reconnect timing of 1, 2, 4, 8, ..., 3600 seconds. Saving recources is the aim of this technique.
Once the maximum time is reached, the RFC channel does not stop connecting. It continues to try connecting indefinitely. The waiting period is a constant interval of the maximum time that is set, i.e. after every 3600seconds.
If not configured, the maximum waiting time is defined in the middleware layer of SAP JCO, which is 3600 seconds. But this maximum time can be configured for each RFC sender channel in the XI Integration Directory. Open the Advanced Mode for the RFC Server Parameter.
- Before XI 3.0 SP 12: Add a line to the table and use 'jco.server.max_startup_delay' as name and the maximum number of seconds to wait between reconnect attempts as value.
- Since XI 3.0 SP 12: Enter the maximum number of seconds to wait between reconnect attempts in the field Maximum Reconnect Delay.
See also Q 31 which is related to this topic.
Q 26: During sending an RFC call to a sender channel the following error message comes up in the sending SAP system: 'alternativeServiceIdentifier: party/service from channel configuration are not equal to party/service from lookup of alternativeServiceIdentifier...' What does this mean?
A: When an RFC call is sent from an SAP system to the RFC sender channel, the SYS-ID and the Client of the sending system are also transfered. During processing of this RFC call the sender channel does a lookup for these values in the Integration Direcory (partyless service, alternative identifiers for RFC) to find the XI service which correspond to the SYS-ID and Client.
The sender channel itself is located beneath a partyless XI service. If this XI service and the one found via the lookup are not equal the described error is issued.
This situation indicates a wrong configuration either within XI or the sending SAP system. Each SAP system (a combination of SYS-ID and Client) should have a corresponding partyless service within the XI Integration Directory. Also for each client in one SAP system at least one unique 'Program ID' is needed (see Q22).
Q 27: Can the RFC-Metadata-Repository be different from the RFC-sender/-receiver channel in terms of Unicode?
A: The RFC-Metadata-Repository has to match the sender/receiver channel in terms of Unicode. It is not possible to mix a Unicode sender/receiver channel with a non-Unicode metadata repository (or vice versa).
See also Q5.
Q.28 : While sending an RFC call to the Sender Channel the following error message comes up in the Sending SAP system:'Wrong Sender Agreement:The Sender agreement does not have channel channelName configured for the functionmodule' What does this mean?
A: When an RFC Sender Channel is created in the Integration Directory and later gets transferred to CPA Cache, it registers itself at the Gateway with PROGRAMID mentioned in the Channel Settings. Hence when an RFC call is made with a destination having the same PROGRAMID ,this call can be directly routed through this channel without any mandatory lookup of Sender Agreement. This implies that RfC adapter knows its channel since startup.
Till SP15 during lookup if a Sender Agreement was found, the processing continued without any check whether the found channel from Agreement equals the one from startup time. This was the reason why interfaces could be sent over a channel which is not configured in the agreement. To have atleast one Sender Agreement fitting the interface was sufficient.For instance if two channels (A & B) were configured beneath the same Business Service and Sender Agreement was created which pointed to Channel A.,it was also possible to send the RFC calls over channel B although it is not configured in the Agreement.
To over come this limitation since SP16 a stricter verification of Sender Agreement is done to check if the configured channel in agreement is equal to the channel through which the RFC call is made. If not then the above mentioned exception is thrown.
Also this stricter verification can be disabled by setting the J2EE Service Property 'verifySenderAgreement' for RFC adapter to false. Setting this property to false in the Visual Administrator/NetWeaver Administrator will prevent such a check for all the RFC calls made through the RFC Adapter.
Q 29: When a function module is changed in the backend, are the changes published to the runtime at real-time?
A: No, an update made to a function module in the backend is not informed to the runtime. This is because the function module metadata is cached by the system during the first invocation of the module. All the subsequent references to this function module are directed to the cache. Any update made to the function module in the backend will not be notified to the runtime, unless the cache is cleared.
The cache is cleared when any of the following happen:
- The corresponding RFC channel is restarted
- The RFC channel is changed in the Integration Directory
- The RFC adapter service is restarted
- The Dependent J2EE services are restarted (MessagingSystem, CPACache, and so on)
- The J2EE server is restarted
Q 30: A scenario is using principal propagation. There is an upgradation of R/3 system that takes place. Once the upgrade is completed, principal propagation does not work. An error " ERROR => Recipient system name does not match with current system" is got. What does this mean?
A: The error that you were facing is due to the fact that the system id needs to be validated when the principal propagation is activated. In earlier case before the upgradation, there was no validation that was done to check for the system id and hence this scenario works correctly without any parameters being introduced.
In the latest versions, there has been an introduction of the validation of the system id at the ABAP side. Hence as a result the system id needs to be passed for the scenario to work correctly.
To avoid the error after upgradation, in the receiver channel configuration below RFC Client Parameter, select the 'Advanced Mode' option and enter the parameter 'jco.client.r3name' in the table in the Name column and enter the SYSID of the receiver R/3 system in Value column. Then save and activate the changes and re-execute the scenario.
This process is valid only for the 7.0 and lesser releases.
Q 31: You observe that the Program Id for an RFC Sender Channel is no longer registered at the SAP Gateway to which the channel should be connected. The TCP/IP destination used to send messages to the RFC Sender Channel does not work anymore and you get the following error: "ERROR: program <PROGID> not registered". At the same time there are no error messages displayed in the Runtime Workbench Channel Monitoring page, the RFC Sender Channel is green and no reconnection attempts are made.
A: This situation can be observed in the cases when the used SAP Gateway and the Adapter Engine (AE) for the RFC Sender Channel are on remote systems, possibly connected via multiple network devices (switches/routers/firewalls). The issue appears when the TCP/IP connection socket between the registered RFC Sender Channel's AE and the SAP Gateway is closed without signaling the interruption to the RFC Sender Channel's AE. Thus the TCP/IP socket is not closed on the operating system's network layer at the RFC Sender Channel's AE side and the channel does not recognize the error and keeps listening for incoming messages. To correct this, the RFC Sender Channel should be registered again to the SAP Gateway by manually restarting (stop/start) the channel. However, if this issue occurs often, the general recommendation is to use SAP Gateway to register the RFC Sender Channel that is on the same host as the RFC Sender Channel's AE (or at least on a host in the same network segment). In the Central Adapter Engine case, you may use the SAP Gateway of your XI/PI ABAP system; and in the De-central Adapter Engine case you may install an additional standalone SAP Gateway.
For more information regarding the possible causes and the solution you can also refer to SAP Note 1494757 - 'Improving stability of registered RFC server connections' (section 'Minimizing the network route').
No comments:
Post a Comment