Lesson 6: Transaction Synchronization 

In this lesson, you learn how to synchronize single-frame and multi-frame transactions.

The previous lessons in this tutorial assumed that users running Web transactions from a Web browser navigate using only hyperlinks and pushbuttons defined in the HTML template. This guarantees consistency between HTML templates in the Web browser and screens in the R/3 transaction, but does not take into account what might happen if the user navigates using the buttons available in the Web browser.

If a user starts a Web transaction from a Web browser and navigates with one of the Web browser buttons, R/3 screens can get out of step with their corresponding HTML templates, since no screen change is triggered in R/3. This means that the Internet Transaction Server (ITS) cannot pass data to the R/3 System, because the data does not match the current status of the system. As a result, data input can get lost.

Suppose the user starts a Web transaction, passes through several screens, but then returns to a previously viewed page using the Web browser‘s Back button.

In this case, the Web browser retrieves the required HTML page from a memory cache rather than accessing R/3 using an HTTP request. This is because the Internet was originally intended to distribute static information, and memory cache functions are ideal for speeding up access time and reducing the pressure on networks.

Synchronization problems can occur in any Web transaction, because a stateless medium (the Web browser) is trying to interact with a status-dependent medium (the R/3 System).

By synchronizing the transaction, you ensure that the HTML template displayed in the Web browser always corresponds to the correct R/3 screen.

How ITS Synchronization Works

When you start a Web transaction, the ITS generates HTML templates that correspond to R/3 screens. These HTML templates contain forms and hypertext links that send data back to the ITS, which in turn passes it on to the R/3 System. In R/3, the corresponding R/3 screen processes the data.

Since the ITS keeps track of the R/3 screen needed to process the data, it can detect when the R/3 screen and the HTML template do not match. When this happens, synchronization is required.

You can resolve the synchronization problem in various ways. The method you choose depends on the transaction and the ease of use you wish to offer the user.

Synchronization occurs in two steps:

  1. The ITS notifies R/3 that the R/3 screen does not match the HTML template.

    2. To do this, the ITS sends a special function code, and the transaction executes a subroutine called SYNCHRONIZE. This subroutine calls the function module ITS_GET_SYNC_INFO to get information (screen number and module pool) about the screen to which synchronization is needed. It is the responsibility of the R/3 transaction to change to the main screen (and subscreens) requested by the ITS.

  2. When the transaction has been successfully synchronized, the ITS posts all data received from the Web browser to R/3.

Changing to the screen that can process the Web browser data is not always sufficient, because the information posted from the Web must be sufficient to reconstruct the complete state of the transaction at the time the original page was created. For some transactions this may not be possible due to the large amount of information required.

In these cases, it is advisable to disable synchronization by setting the ~SyncBehaviour parameter in the ITS service file to NoResync. This setting causes a warning message to be displayed in the browser if the user navigates to a previous HTML page with the Back button. Generally, it is good application design to offer navigation buttons in your Web application.

Example Transactions

The next three example transactions in the tutorial progressively demonstrate the synchronization problem in three scenarios showing single frames, multiple frames, and multiple frames with update.