Page History
...
The difference to RFC, tRFC implements an additional transaction handling. This transaction handling must guarantee that a transaction is executed exactly once. The following simple example shows how to use the transaction mechanism offered by SAP. The proper transaction control is implemented elsewhere (cf. in the E2E SAP module).
Figure: tRFC Service Use Case Diagram
...
The operation IDOC_INBOUND_ASYNCHRONOUS gets called when SAP is transmitting an IDoc to the E2E Bridge. The implementation of this operation can be found in the next section.
...
| Info | ||
|---|---|---|
| ||
Only inbound data flow is allowed for SAP tRFC functions. That is tables and importing parameters. Additionally, when implementing a tRFC function, the modeler can access the current transaction ID via the transactionID input parameter. |
tRFC Service Components
Builder 6 Each <<E2ESAPRFCService>> that uses tRFC contains at least two residents:
...
| Info | ||
|---|---|---|
| ||
The Model Compiler throws an error, if a composite service contains more than one <<E2ESAPRFCService>> component. This constraint is given by the very nature of a SAP gateway. Each operating system process must register exactly one program ID at the gateway, otherwise the dispatching of SAP requests to the RFC service is not unique. Now, each xUML service runs in its own Bridge process, thus unique dispatching can only be achieved by allowing only one RFC service - i.e. one program ID - per xUML service. |
tRFC Service Components of Builder Version 5.1
Deprecated since Builder 6.0
| Expand | ||
|---|---|---|
| ||
Each <<E2ESAPRFCService>> that utilizes tRFC contains at least two residents: One and only one <<E2ESAPTRFCCallbacks>> class holding operations to control transactional behavior (for instance the TRXLogging class beneath) and one or more <<E2ESAPRFCModule>> classes containing operations called by the SAP system to exchange data. For instance, see the IDocInterface class depicted in the deployment diagram beneath. The implementation of these operations is similar to the implementation of standard RFC operations. The only difference results from the asynchronous nature of tRFC operations - they handle input only. Figure: tRFC Service Component Diagram The components are manifested by their artifacts, which instantiating the components and annotating all configuration information to run these components on their target systems. The tRFCServiceDeployment has the following tagged values: | ||
| Tagged Value | Description | Mandatory/Optional |
| protocol | must be trfc when using the tRFC protocol | mandatory |
| tracePort | The same operations that are called by the SAP system can also be called by SOAP test tool if the configuration has been compiled in trace mode. However, the SOAP test tool requires an HTTP TCP/IP port. This port can be defined in the tracePort tagged value. If this value is not set, the trace port is given by controlPort + 50000. | optional |
| sapTrace | The effect of this flag being true is two fold: First, the SAP RFC libraries will write trace file information (.trc) into the directory the configuration has been deployed to. Second, by using the SAP transaction *SMGW (SAP gateway monitor) we can monitor the dataflow from and to the gateway the server is registered on. | optiona |
| Note | ||
|
Overview
Content Tools