Properties Related to RFC Servers (Sender Channels)

The Following Properties are Related to RFC Servers (Sender Channels)

Name

Description

writeXmlPreambleToPayload

Value type: Boolean

Default: true

The RFC adapter creates an RFC-XML document from an RFC request (RFC sender channel).

If this property is set to true, the RFC-XML document will contain an XML preamble.

If this property is set to false, the RFC-XML document will not contain an XML preamble.

pathToSNCLibraryDefault

Value type: String

Default: not set

This is the setting for the default name (with absolute path) of the SNC library you have to use for RFC communication over SNC. It can be overridden by the channel configuration setting in the Integration Directory (SNC advanced mode).

Even if you do not specify anything neither for this property nor in the channel configuration, the RFC layer will be able to find the SNC library, for example, by using settings in the process environment. This depends on the used platform.

monitorHistoryLength

Value type: Integer

Default: 5

The number of entries to be displayed in the channel history of RFC channels in the adapter monitor.

A value of 0 will turn off the channel history.

RfcServer.maxRequestSizeOfLUW

Value type: Integer

Default: 1

This property affects the behavior of tRFC transactions (also called LUW) of an RFC server. The RFC server limits the number of RFC calls in one transaction to the set value. If the value is set to 0, there is no limitation within the RFC adapter. If a value less than 0 is chosen, the internal default of 1 will be set. Use this property with care.

If the property is set to values greater than 1, duplicate detection cannot be guaranteed. It is not recommended to change this property. Refer to SAP Note 774705 before changing this property.

If this property is changed to a value other than 1, the property RfcServer.TIDconversionMode is internally changed, too. For more information, refer to the description of the property.

RfcServer.TIDconversionMode

Value type: Fixed text: calculate/create

Default: calculate

This property affects the tRFC behavior of an RFC server. To ensure quality of service Exactly Once (EO) and duplicate detection the tRFC transaction identifier (TID) is used to calculate the XI message ID. It guarantees that one TID is always translated to the same XI message ID.

If this property is set to create, a new XI message ID is created for each tRFC call. Guaranteed EO handling or duplicate detection is not carried out.

It is not recommended that you change this property as long as you also change the property RfcServer.maxRequestSizeOfLUW.

If the property RfcServer.maxRequestSizeOfLUW is set to a value other than 1, this property is internally set to the value create. This is necessary since one tRFC LUW only has one TID and each tRFC call is transformed into one XI message. Each XI message needs a unique message ID and they cannot be calculated from one TID.

RfcServer.duplicateCeck

Value type: Fixed text swallow/sendback

Default: swallow

When an RFC server sends a tRFC call as an XI message to the Adapter Framework, it uses the module processor. The last module in the module chain must be the RFC adapter module (localejbs/ RfcAFBean). Within this module, the XI message is sent to the Adapter Framework messaging which carries out a duplicate detection, among other things.

If this property is set to swallow, a detected duplicate will be ignored and the success is indicated to the sender system. In this way the EO contract is fulfilled. If the sender system wants to handle these duplicates on its own, the property can be set to the value sendback. The Java exception describing the detected duplicate is sent back to the sender system of the tRFC call.

The internal default is the same as shown above.

RfcServer.TIDmanagementMode

Value type: Fixed text: weak/strict

Default: weak

When a tRFC transaction (LUW) is finished, the sender of this transaction can inform the RFC server that this transaction will never be sent again. This process is called confirmTID. The confirmTID signal must not be sent during transaction execution; it can be sent later.

This property controls the behavior of an RFC server when the confirmTID signal is received. If it is set to weak, the internal tRFC buffers are cleared; if it is set to strict, a check is performed:

If the confirmTID signal is received and the transaction (TID) is processed immediately beforehand by exactly the same RFC server, the internal tRFC buffers are cleared (unless an exception is thrown). Since the internal tRFC buffers are only stateful pertaining to one transaction, this function is not used to administer the internal TID management for duplicate detection. The duplicate detection for the RFC adapter takes place in the Adapter Framework messaging and its persistency layer.

The internal default is the same as shown above.

RfcServer.bufferMode

Value type: Fixed text: normal/compatible

Default: normal

When a tRFC transaction (LUW) is committed or rolled back, the internal tRFC buffers can be cleared, because they are no longer used.

If this property is set to normal, the buffers are cleared as described above.

If it is set to compatible, the buffers are only cleared when a confirmTID signal is sent to the RFC server or a new transaction (LUW) is processed by the same RFC server. This enhancement saves memory especially in environments where large messages are rarely exchanged.

The internal default is the same as shown above.

poolCheckRate

Value type: Integer

Default: 3600 ( time in secs.)

The RFC adapter creates a pool of RFC servers for each sender channel. The value initial connections from the sender channel affects the number of RFC servers started initially. The value of maximum connections affects the number of RFC servers which can be started dynamically.

This property defines how often the RFC adapter checks the configured RFC server pools. The pool does not increase its size itself, but it is increased, if a pool check is performed. During this check, another RFC server is started for a pool. The pool check produces load, therefore it should not be started too frequently. A check rate of 0 means that no check is performed.

poolLoadThreshold

Value type: Integer

Default: 0

A new RFC server is only started if a threshold is reached.

This property is used to calculate it. If the current size of the pool (available servers) minus the value of this property is less or equal than the number of currently working servers, a new RFC server is started. A value of 0 means that a new server is only started if all available servers (current size of the pool) are working. If it is larger, a new server is started before all available servers are working.

verifySender

Value type: Boolean

Default: true

When an RFC server receives an RFC call it only has some identification information about the sender system involved (SYS-ID and Client).

It has to find the values for the sender party and the sender service to send a message through the Integration Server.

If set to true, the Integration Directory is queried for the adapter specific identifiers for RFC to find these values. If set to false, the values specified in the sender channel are used.

This property should only be changed when the sender system cannot provide identification information. If set to false, every client with access to the SAP gateway, at which the RFC server is registered, can send RFC calls to this server without further checks.

You can override this setting with the Verify Sender System setting of the channel configuration (advanced mode) in the Integration Directory.

The internal default is the same as shown above.

onlyPartylessServiceAsSender

Value type: Boolean

Default: true

If set to true, an RFC server only permits XI messages to be sent when configured as a sender channel related to a service without a party in the Integration Directory. This is done because RFC has no concept of parties. If set to false, configurations with parties are also allowed.

Changing this property will affect the party-less semantic of RFC.

It is not recommended that you change this property.

The internal default is the same as shown above.

syncMessageDeliveryTimeoutMsec

Value type: Integer

Default: 300000 (time in msec.)

When an RFC server sends an sRFC call as a synchronous XI message to the Adapter Framework, it uses the module processor. The last module in the chain must be the RFC adapter module (localejbs/ RfcAFBean). Within this module, the XI message is sent to the Adapter Framework messaging.

This property sets the timeout, which is used to send the message and wait for a response. If the given time has elapsed, an exception is thrown by the Adapter Framework and sent back to the sender system.

The internal default is the same as shown above.

RfcServer.AFCommunicationMode

Value type: Fixed text: dynamic/static/compatible

Default: dynamic

To send a message from the RFC server to the Adapter Engine, you require a special J2EE application thread from the J2EE Engine. This property controls the allocation of this thread:

·         dynamic: The thread is allocated from the J2EE Engine’s thread pool every time it is needed to send a message to the Adapter Engine. Afterwards, it is returned to the thread pool to save resources in the J2EE Engine. This is done for each message.

·         static: The thread is allocated from the J2EE Engine’s thread pool during startup of the RFC server (sender channel) and is kept during the whole lifetime of this channel to send messages to the Adapter Engine. The thread is only returned to the thread pool if the RFC server is shut down.

·         compatible: Corresponds to static, except that another technique is used to synchronize the thread communication. This option is provided for compatibility reasons only.

The dynamic setting saves thread resources, since a thread is only allocated and held as long as it is used. The static setting is slightly faster but occupies a thread even when it is not used.

It is recommended that you use the dynamic setting.

The internal default is dynamic.

This property has been introduced with XI 3.0 SPS14. The behavior of RFC servers prior to SPS14 is the same as the behavior in compatible mode.