Process

First, we need a couple of helper classes for managing the necessary unique identifiers required for all three types of communication:

public class RfcTID

public RfcTID()

Creates a new TID that can be used for tRFC and qRFC communication.

public RfcTID(String tidString)

Initializes an RfcTID object from a given 24-character TID string. This is useful for example in scenarios where you get the transaction payload and its associated TID from a third system (the .NET Connector program is playing the role of middle-tier system), or when you need to resend a failed transaction and have the already existing TID on record.

public RfcTID(System.Guid uuid)

Initializes an RfcTID object from a given Microsoft GUID. The 16 bytes of the GUID are converted to a 24-character string using a bijective algorithm. This is useful for scenarios where you get the transaction payload and its associated TID from another Microsoft based component.

public String ToString()

Returns a string representation of the TID, for example for storing it in database for transaction status management.

public System.Guid ToGuid()

Converts the 24-character representation of a tRFC TID to a 16-byte Windows GUID using a bijective algorithm. This is useful if you receive a transaction from the SAP backend system and want to pass it to another Microsoft component (e.g. BizTalk) keeping the relation (traceability) between the transaction inside the SAP system and the resulting transaction in the Microsoft component.

public class RfcUnitID

public RfcUnitID(RfcUnitType type)

Creates a new unit ID that can be used for bgRFC communication.

public RfcUnitID(RfcUnitType type)

Initializes a unit ID from an existing 16-byte Windows Guid.

public RfcUnitType unitType

Determines whether this unit ID specifies a transactional or a queued bgRFC unit. public System.Guid uuid The unique identifier.

public enum RfcUnitType {TRANSACTIONAL, QUEUED}

The following class is a special kind of data container that stores the RfcFunction objects comprising one logical unit of work (LUW). When you commit the RfcTransaction, all contained RfcFunctions will be executed by the SAP backend as an atomic unit in the order in which they were added to the RfcTransaction object. If you send the transaction via qRFC instead of tRFCs, then the backend first puts the LUW into an inbound queue, thus guaranteeing the relative execution order of several LUWs that were sent to the same queue.

public class RfcTransaction

public RfcTransaction()

Creates a new tRFC transaction. A TID for it will be created automatically. Read it and store it in a status management component!

public RfcTransaction(RfcTID tid)

Creates a new tRFC transaction with the given TID.

public RfcTransaction(String queueName)

Creates a new qRFC transaction. A TID for it will be created automatically. Read it and store it in a status management component!

public RfcTransaction(RfcTID tid, String queueName)

Creates a new qRFC transaction with the given TID.

public RfcTID Tid

The unique identifier.

(Read-only) public String QueueName

The transaction’s queue name, if this is a qRFC transaction, null otherwise.

(Read-only) public void AddFunction(RfcFunction function)

Adds another function module to the current LUW.

public void Commit(RfcDestination destination)

Sends the LUW into the specified SAP system. tRFC transactions are executed immediately (synchronously) and qRFC transactions are written into an inbound queue and executed by the QIN scheduler at a later point of time. If Commit() ends successfully, it means the following:

• tRFC: it is guaranteed that all function modules of the LUW have been executed successfully and in the order they were added to the RfcTransaction object.

• qRFC: it is guaranteed that the LUW has been written into the specified inbound queue and will be executed by the system as soon as possible. If Commit() throws an RfcCommunicationException, it means the following: A network error happened either on the way to the SAP system or on the way back. In any case you should resend the transaction at a later time and in case the transaction had already reached the backend system successfully before the network error, it will be guaranteed that the transaction will not be executed a second time (tRFC) or will not be written into the inbound queue a second time (qRFC). If Commit() throws an RfcSystemException, it means the following:

• tRFC: one of the function modules ran into an exception, and the work done by the previous function modules of the same LUW has been rolled back. In either case none of the function modules has been executed. • qRFC: there was an error writing into the inbound queue, and the transaction has not been inserted into the queue. In both cases resend the transaction with the same TID. Here is the analogous class for bgRFC communication:

public class RfcBackgroundUnit

public RfcBackgroundUnit(RfcUnitID uid)

Creates a new bgRFC unit of type ‘T’ with the given unit ID.

public RfcBackgroundUnit(RfcUnitID uid, RfcUnitAttributes attributes)

Creates a new bgRFC unit of type ‘T’ with the given unit ID and special attributes.

public RfcBackgroundUnit(RfcUnitID uid, String[] queueNames)

Creates a new bgRFC unit of type ‘Q’ with the given unit ID.

public RfcBackgroundUnit(RfcUnitID uid, String[] queueNames, RfcUnitAttributes attributes)

Creates a new bgRFC unit of type ‘Q’ with the given unit ID and special attributes.

public RfcUnitID UnitID

The unique identifier.

(Read-only) public String[] QueueNames

The unit’s queue names, if this is a type ‘Q’ unit, null otherwise.

(Read-only) public void AddQueueName(String queueName)

Adds another queue name to the list of queue names, if this is a type ‘Q’ unit. Otherwise it will throw an exception.

public void AddFunction(RfcFunction function)

Adds another function module to the current LUW.

public void Commit(RfcDestination destination)

Sends the LUW into the specified SAP system. For a detailed discussion of the semantics of the different possible exceptions see RfcTransaction.Commit(). RfcUnitAttributes can be used to modify unit behavior in the backend system or to provide additional detail information about the sender. Here is a discussion on how to use this structure in an RFC client application.

public struct RfcUnitAttributes

public bool kernelTrace

If set to true, the backend will write kernel traces, while executing this unit. Default is false.

public bool satTrace

If set to true, the backend will write statistics traces, while executing this unit. Default is false.

public bool unitHistory

If set to true, the backend will keep a unit history for this unit. Default is false.

public bool lock Used only for type Q:

If set to true, the unit will be written to the queue, but not processed. The unit can then be started manually in the ABAP debugger. Default is false.

public bool noCommitCheck

Per default the backend will check during execution of a unit, whether one of the unit's function modules triggers an explicit or implicit COMMIT WORK. In this case, the unit is aborted with an error, because the transactional integrity of this unit cannot be guaranteed. By setting noCommitCheck to true, this behavior can be suppressed, meaning the unit will be executed anyway, even if one of it's function modules "misbehaves" and triggers a COMMIT WORK. Default is false.

public String user

Sending user (optional). Default is current operating system User.

public String client

Sending client ("Mandant") (optional). Default is "000".

public String tCode

Sending ABAP transaction code (optional). Default is "". (Usually there is no useful meaning for this in external programs.)

public String program

Sending program (optional). Default is current executable name.

public String hostname

Hostname of the sending system. Do not set this. In the client case, the .NET Connector fills this automatically.

public DateTime sendingDateTime

Sending date and time in UTC (GMT-0). Do not set this. In the client case, the .NET Connector fills this automatically.