Q 1: What is discussed in this document?
A: This document discusses questions about the XI 3.0 RfcAdapter, PI 7.0 RFC Adapter, PI 7.1 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' and does no longer contain a RFC Adapter. 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 RfcAdapter, which runs as a Service of the J2EE Server. This document only describes the J2EE RfcAdapter.
Q 3: How can the RfcAdapter be started and stopped?
A: The RfcAdapter is implemented as a J2EE Service and thus this service has to be started and stopped. This will affect the whole RfcAdapter and can be done from the 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 and stop the service.
Q 4: Where can the RfcAdapter communication channels be configurated?
A: The channels for the RfcAdapter 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 RfcAdapter?
A: The RfcAdapter 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 RfcAdapter J2EE Service 'SAP XI Adapter: RFC' is restarted or a dependend J2EE Service is restarted ('SAP XI AF CPA Cache', 'SAP XI AF Messaging')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: RfcAdapter will only support transactions (sometimes also called LUW) with one call. If an attempt is made to place a second call within one 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 is 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 can be used.
Q 9: Which flavous of RFC are supported?
A: RfcAdapter 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. A 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 SP10.
With SP11 a XI EOIO-messages will result in a normal tRFC call. If a tRFC is send to a SAP-system it will be executed directly (in other words synchronous) 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 the RFC functionen modules are synchronous, the IDocs are asynchronous. Thus, if the communication should be asynchronous, it is a good idea to use the IDoc implementation of a BAPI.
The RFC function module implementation of a BAPI will not only report it's result in the synchronous response. It also will report it's execution status (like Success, Error, ...). 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 RfcAdapter 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 RfcAdapter 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 RfcAdapter 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 RfcAdapter 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 calles 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 commited 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 RfcAdapter.
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.
The message was send synchronous 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 during the sending of the return value a problem occurs (like network, ...). This can also happen if there even is no return value in the function module, because the receiver system at least will send back a indication that the execution has finished. So the RfcAdapter will generate an error (like timeout, ...) and send this one 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 it will not know if the execution happened in the receiver system.
The message was send asynchronous 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 during sending back the indication that the RFC call was executed (which actually will be synchronous) a problem occurs (like network, ...). The RfcAdapter 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 send again, the receiving system tRFC implementation decides whether the call was already successfully received or not. This guarantees the exactly once protocol of the tRFC implementation.
To handle this behaviour the approach to call a BAPI via a wrapper function module will not solve the problems described above. Some mechanism within the application has to deal with this type of problems.
As of SP 14 support for commit handling for single BAPI calls was added to the RfcAdapter 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 RfcAdapter.
The received response is parsed by the RfcAdapter to get the BAPI return parameter with name "RETURN". This return parameter can be of BAPIRETURN, BAPIRET1 or BAPIRET2 types. The "RETURN" parameter is checked for the response status (field TYPE) which can take 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 successful. If the response contains one amongst the last two response then the BAPI failed. If the BAPI "RETURN" parameter is of not of type ABAP structure rather of type ABAP table, a empty table is also considered as successful execution result.
In case of a successful execution the BAPI function module "BAPI_TRANSACTION_COMMIT" is called within the same context to trigger the commit of the BAPI. 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 send back as XI response. In case of a QoS EO request message nothing is send back as response.
Q 11: Is there something to know about the module processor?
A: Any adapter need a EJB to communicate with the module processor of the Adapter Engine. The RfcAdapter will use one which is called 'localejbs/RfcAFBean'. This can be configured in the Integration Directory for each communication channel on the tab 'Module'. If the list is empty on this tab, 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 RfcAdapter module. This will establish the communication between the adapter and the Adapter Engine.
Q 12: How can tracing be enabled for RfcAdapter?
A: 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 RfcAdapter 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 "usrsapj2eeclusterserver0log" 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 RfcAdapter (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 RfcAdapter (sender channel) builds up the XI request-message and will send this to the Adapter Engine with a timeout. After this it will wait till the response-message reaches or the timeout expires. In case of timeout the exception named above is thrown. The timeout used by RfcAdapter for synchronous calls can be configured for the whole RfcAdapter as a property of the RfcAdapter J2EE Service. To change it's 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.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 RfcAdapter?
A: A 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 RfcAdapter. It normaly 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 is not 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 sender channel. Choose 'Advanced Mode' and deselect 'Verify Sender System'.
Q 16: While sending a message to the RfcAdapter the error "... functiontemplate from repository was " is shown. Which reasons are possible?
A: After receiving a message from the Adapter Engine, the RfcAdapter 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 send to the RfcAdapter, 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 transaction code SE37.
Q 17: How can settings affecting the whole RfcAdapter be made?
A: The RfcAdapter is implemented as a J2EE Service and thus the properties of this service must be changed. This will affect the whole RfcAdapter and can be done from the J2EE Engines Visual Administrator. 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 are 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 RfcAdapter?
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 RfcAdapter 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 RfcAdapter trys 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 RfcAdapter sender channel and the RfcAdapter is not registered at the SAP Gateway. RfcAdapter receiver channels report a error like "RfcAdapter: receiver channel not in list of running clientPools..." in the Message Audit Log of the Adapter Engine. What happened?
A: The RfcAdapter checks the configuration of each channel during the start of this channel. This is done during startup of the whole RfcAdapter (J2EE service) or when the RfcAdapter 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 RfcAdapter. The test is done again each time when the channel is updated in the Integration Directory or after a restart of the RfcAdapter. The status of each channel in the RfcAdapter can be monitored in the Adapter Monitor. Note 769791 describes this in detail.
May there are 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 RfcAdapter is used, the check can be disabled for the whole RfcAdapter. Set the RfcAdapter 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 RfcAdapter 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 RfcAdapter are prefixed with 'XI:RFCAdapter:'.
Sender channel asynchronous
In 'Request Overview' the starting point is "com.sap.mw.jco.JCO.Server" and "XI:RFCAdapter:RfcServer.onCommit()".
XI:RFCAdapter:RfcServer. handleRequest() => Overall handling of this RFC request
XI:RFCAdapter:RfcServer.tRFC.handleRequest. convertRFC2XML => Convert JCO RFC Java objects to RFC-XML
XI:RFCAdapter:RfcServer.onCommit() => Overall commit handling for all RFC request received before
XI:RFCAdapter: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:RFCAdapter:RfcServer. handleRequest() => Overall request handling for this RFC request
XI:RFCAdapter:RfcServer.sRFC.handleRequest. convertRFC2XML => Convert JCO RFC Java objects to RFC-XML
XI:RFCAdapter:RfcServer.sRFC.handleRequest. sendSync2AF => Send the XI message synchronously with the RFC-XML document as payload to the AF (incl. Module Processor)
XI:RFCAdapter:RfcServer.sRFC.handleRequest. identifyXmlDocumentType => Identify the type of XML-document that was received as response
XI:RFCAdapter: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:RFCAdapter:RfcClientPool. processRequest() => Overall processing of this XI message/RFC call
XI:RFCAdapter:RfcClientPool.processRequest. getClient => Retrieve a JCO.Client connected to the backend system from JCO.Pool
XI:RFCAdapter:RfcClientPool.processRequest. getFunctionRequest => Get the function metadata from the RFC metadata repository (may perform calls into the backend for the first retrieval)
XI:RFCAdapter:RfcClientPool.processRequest. convertXML2RFC => Convert RFC-XML to JCO Java objects
XI:RFCAdapter:RfcClientPool.processRequest. syncExecute => Actually call the backend system (incl. receive the result as JCO Java objects)
XI:RFCAdapter: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:RFCAdapter:RfcClientPool. processRequest() => Overall processing of this XI message/RFC call
XI:RFCAdapter:RfcClientPool.processRequest. getClient => Retrieve a JCO.Client connected to the backend system
XI:RFCAdapter:RfcClientPool.processRequest. getFunctionRequest => Get the function metadata from the RFC metadata repository (may perform calls into the backend for the first retrieval)
XI:RFCAdapter:RfcClientPool.processRequest. convertXML2RFC => Convert RFC-XML to JCO RFC Java objects
XI:RFCAdapter:RfcClientPool.processRequest. convertTID => Create the TID used for tRFC
XI:RFCAdapter: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 RfcAdapter 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 a SAP system, this Program ID has to be maintained in the RFC destination (transaction SM59).During the sending 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 calles 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 a XI RfcAdapter 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 'rfcadapter' 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-Servrer 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 RfcAdapter 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 RfcAdapter 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 a RFC-Adapter receiver channel a 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 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 a 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 sucessive call to the same function module will use 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 a 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: A RFC sender channel is registered at a 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.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 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 SP 12: Enter the maximum number of seconds to wait between reconnect attempts in the field Maximum Reconnect Delay.
Q 26: During sending a 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 the RFC call is send from the 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 : During sending a 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 a RFC Sender Channel is created in Integration Directory and later gets transferred to CPA Cache, it registers itself at the Gateway with PROGRAMID mentioned in the Channel Settings. Hence when a 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 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 will prevent such a check for all the RFC calls made through the RFC Adapter.