Skip to Content

Let us start with some definitions I used here:

  • SAP-ALE is part of SAP-Netweaver being a matured and widley used technology for cross-system communication.
    SAP-ALE is built on the SAP-Standards SAP-IDOC and SAP-tRFC.
  • SAP-IDOC’s describe messages (structured text files) used for communication of applications
  • SAP-tRFC is used as communication infra structure by SAP-ALE to send/receive SAP-IDOC-messages. For external systems SAP provides the SAP-RFC-SDK which is distributed with SAP-GUI disks, or by SDN.

    The tRFC implements an asynchronous method to call function on a remote system. The tRFC is per definition transaction save -> that means the tRFC implementation ensures that a remote function call is done in a save way and guaranted to be executed once. tRFC is able to handle network failures, temporary missing partners et cetera by using message queues and unique transactions ID’s (= TID) for each call. The use of tRFC is a must if you want to change data at the target system (FI, documents, master data, SD documents, material movments …)

  • transaction = a event which causes a secured change in databases. The system ensures that a transactions data base change is done once. 

    My definition of a SAP-ALE-message using tRFC is that each remote-call to transfer IDOCs gets a unique transaction ID from SAP-tRFC-Modules and is allowed to be executed exactly once in the target system.

I testet serveral SAP-Systems and I can show a unexpeted behavior. I could force all systems to process the same TID / IDOC-Message as many times as I want.

Therefore I say SAP-ALE is not transaction safe and SAP-Users using this technology are endangered to screw up all data in their system because the SAP-System does not check for processed TIDs. If any System resends tRFC-calls because of any problem the SAP-System processes this calls again and again instead of blocking the all subsequent calls.

Detailed information is here  http://www.wa-mozart.eu/SAP-ALE_check.pdf

Bernhard Lascy

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Paul Joyce
    Here is my interpretation of the situation based on my understanding of tRFC, I hope it helps….

    When developing external applications that integrate with SAP using tRFC, I have always implemented this with the understanding that tRFC is purely to control the communication of a ‘data package’ between the 2 components and therefore the control (TID) only needs to exist until the communication has successfully completed.  I guess the phrase permanent is used as the TID may have to exist across more than one LUW, rather than meaning it should be kept for ‘a long time’.

    Given the above, here are my thoughts on the issue described in your document.  As the MLS server is acting as a tRFC client, I have been trying to map the sequence design diagram onto the tRFC client calls to understand the scenario.  I have deduced the following;

    1 = RfcCreateTransID.  
    3,4,5  = RfcIndirectCallEx (as this would be a synchronous call).
    6 = Record TID as successful on client side.

    What I cannot determine is where the call to the RfcConfirmTransID is implemented, this is important as it is the call invokes the deletion of the TID on the R/3 database (as the tRFC server).  From your diagram I think that it should happen after step 6 has successfully completed.  If step 6 fails, as you have highlighted, you should not call the RfcConfirmTransID, this will leave the TID in the SAP TID database and hence any data with this TID would be recognised as a duplicate.

    (0) 
    1. Bernhard Lascy Post author
      Hello Paul,
      I want to say thank you for your effort. Your thoughts are good, but I would also consider following:

      * SAP-ALE is an open interface for complementary software. Having an interface like that it should be as fail-save as possible. The TID is recorded permanent in the ALE-Application but not in tRFC layer. I think that is very dangerous because SAP accepts the same TID over and over. Why has a sending system to obtain a unique TID if the tRFC layer does not use it permanent? Instead of that it would be easier to use a unique parter name.

      * the system would be much more save if the TID would be stored permanent in the tRFC-Layer. After a system failure it would be much easier to synchronize the systems because you wouldn’t have to worry about resended messages.

      Best regards
      Bernhard

      (0) 
      1. Paul Joyce
        Hi Bernhard,

        I agree that it could be a fail safe if the TID was permanently stored, but this would be purely catering for limitations in the RFC client or trapping errors due to bugs in the client.  The TID is used to control the actual synchronous communication between the 2 components.  Once the communication has successfully finished the TID has completed its ‘job’ and hence it’s no longer needed.  The RFC client should never attempt to resend the TID again.

        So my question is, if everything is designed correctly and bug free, why should the TID be stored after the communication has successfully completed?  It certainly should not be necessary for normal operation.
        By designed correctly I mean that the deletion of the TID from SAP is the very last thing to happen, and specifically after the ‘local’ TID management is complete. 

        Paul.

        (0) 
        1. Bernhard Lascy Post author
          Hello Paul,
          I think your and my arguments are right, the difference is an philosophical. In my opinion the system landscape changed a lot. Today you have many different systems communicating with each other. Therefore each system should be as fail safe as possible.

            * you might be right that it is not SAPs duty to check for ‘failures’ of the client. I say why not if its as easy as that. This case showed up in production after having tested a lot. The client is now on some sites for more than 3 years productive. Even if its a bug of the client it does not help the owner of the SAP-System to say the client had a bug if the problem caused lots of wrong database changes in the SAP-System.

          Your question about storing the TID:
            SAP stores the TID on SAP-ALE-Level. Why there. Is it to show that a client had a bug but sorry now the SAP-System has now lots of wrong records, in this case IDOCs.

          Another Scenario could be, that the software fetches the TID’s and queues the rfc-Calls. Than another thread just does the sending. Because of a database problem you might have to reload the database with a backup -> SAP has this scenario for their software. Having this situation how do you synchronize the systems again without having lots of analysis. Why could not all messages resent without manual checks and the target system decides on its database if the message has to be processed.

          My concerns are about worst cases and how to solve problems fast having no time and doing your job under stress with out failures. Systems should help as much as possible.

          (0) 

Leave a Reply