Synchronization & Integration Testing

*********************************************************************************************************************
THIS DOCUMENT IS NOT RELEASED IN MDK 3RD EDITION!!!
*********************************************************************************************************************

In this section, we will:

Synchronization Process

The main characteristics of Smart Synchronization process is as follows:

Since it is helpful to understand the synchronization process and mechanism of Smart Synchronization to a certain extent for conducting a synchronization test, the following sections will discuss the overview of Smart Synchronization process and mechanism.

Overview of Runtime Synchronization Components

The diagram below illustrates how the various components interact with each other with respect to the data syncrhonization:

@@@ GRAFIC

The important aspects of Smart Synchronization data synchronization are as follows:

The following table describes the role of each component described in the diagram above in certain details:

Component

Description
Smart Sync API When a client application calls Smart Sync API to add, modify or delete a SyncBO instance, the action is logged so that the new state of the SyncBO is uploaded to the Web Application Server in the next synchronization.
Generic Sync API Smart Synchronization uses the services offered by Generic Sync. That means that the Generic Synchronization is responsible for handling the data synchronization between the MI Client and Web AS. When a synchronization is triggered on a client device, the following is performed:1. Creating data update messages for the SyncBO instances where the state is changed on the device since the last synchronization The sequence number, which is incremented by 1, is assigned to each synchronization message. The update message for a SyncBO instance is based on the state of the instance at the time of the synchronization.2. Creating the “delta” data request message for each SyncBO defined in the meta-data (SyncBOs used in the application) The sequence number, which is incremented by 1, is assigned to each synchronization message.3. Then, the messages created in the steps 1 and 2 are sent to the Web Application Server4. The Generic Sync API of the MI client obtains the messages from the Web Application Server (stored in the outbox of the Web Application Server), processes them and updates the local object store on the client device accordingly In the case of synchronization errors, the message text (RTN message content) is logged in the following folder (MeRepErrorContainer.txt):<Me root>\webapps\me\WEB-INF\wwwroot\data\meRep
Receiver When the Generic Sync receives the update and “delta” data request messages from a device, the messages are validated in the Receiver component of Smart Synchronization and stored in the inbox. At the same time, the Receiver creates the Handler and Synchronizer worklist items for each message and sends a notification to the Handler to notify the arrival of the new messages (worklist items) to be processed.
Handler

The Handler looks up the Handler worklist items and check if one of the associated messages has the sequence number that is bigger by one from the last processed sequence number for a device. If the expected message is in the Inbox, the following is performed; otherwise, it waits for the next synchronization to receive the expected message:

  1. Calls the Downloader Synchronizer for each Handler worklist (for both update and “delta” data request messages) if the synchronization type of a SyncBO is not uploada. After the execution of the Downloader Synchronizer, a RTN message and a “delta” data message (object state of the delta data) are created and stored into Smart Synchronization outboxb. Then, the Sender worklist item is created
  2. Calls the Uploader Synchronizer if the associated message of a Handler worklist item is an update message (an object is updated on the device)
  3. After handling all the Handler worklist items for a device, the last processed sequence number is updated
  4. Sends the notification to the Sender to process the Sender worklist items
Synchronizer

Depending on the type of a Synchronizer function module, the processing is different:

Downloader

  • If the synchronization type is download, the following is performed:
    1. The delta data is identified from the Replica DB with taking care of the filtering criteria
    2. The Handler creates a RTN message or a message for the delta data if any delta is detected
  • If the synchronization type is timed 2-way, the following is performed:
    1. The delta data is identified from the Replica DB with taking care of the filtering criteria
    2. If the associated message is update, it is checked whether the updated object is in the delta data identified; if exists, a conflict is detected
    3. If the associated message is update, it is also checked whether the state of the object in the Replica DB is the same as the state of the object in the backend system with calling the GetDetail BAPI wrapper for the object; if they are different, a conflict is detected
    4. If a conflict is detected, the Handler creates a RTN message for the conflict and a message describing the current state of the conflict object in the backend system; otherwise, the Handler creates a RTN message or a message for the delta data if any delta is detected
  • If the synchronization type is 2-way, the following is performed:
    1. The GetList and GetDetail BAPI wrapper functions are called first
    2. The result of the function calls is compared with the Replica DB to detect the delta data and conflicts in the case that the updated object on the device is in the delta data detected (updated in the backend as well)
    3. If a conflict is detected, the Handler creates a RTN message for the conflict and a message describing the current state of the conflict object in the backend system; otherwise, the Handler creates a RTN message or a message for the delta data if any delta is detected

Uploader

When the object is updated on a device, the Uploader Synchronizer for the corresponding SyncBO is called, which performs the following:

    1. Calls the corresponding update BAPI wrapper (Create/Change/Delete)
    2. Updates the Replica DB
    3. Creates a RTN message as well as a message that describes the current state of the specified object in the backend system at the time of executing the BAPI wrapper, and puts them into Smart Synchronization outbox
    4. Creates a Sender worklist item

Replicator

This Synchronizer is called typically from the scheduled job to update the Replica DB, which performs the following:

  1. Calls the GetList BAPI wrapper
  2. Calls the GetDetail BAPI wrapper3. Updates the Replica DB for the SyncBO if the delta between the Replica DB and the backend system is detected
BAPI Wrapper The BAPI wrappers are called within the Synchronizer function modules.
Sender

The Sender looks up the Sender worklist items and transfers the items in Smart Synchronization outbox to the Generic Sync outbox of the Web Application Server with transforming them appropriately.

Two types of messages are sent to the device in the next synchronization:

  • RTN: This message describes the result of the processing of messages; in case of errors, the message content is logged as a text file on the device
  • Object state: This message contains the current state of the specified object(s) in the Replica DB as a result of identifying the delta data and updating the object in a backend system

 



Rules of Synchronization

Overview

The following table describes the summary of the actions performed by Smart Synchronization depending on the states of the business objects on a device and in the backend system:

No

State of SyncBO Instance Description Action Performed during Synchronization

Device WebAS
1 Present Present A BO instance exists both on the device and in the backend system in the exactly same state None
2 Created Not present A new BO instance is created on the device Creates the BO in the backend system
3 Not present Created A new BO instance is created in the backend system Creates the BO on the device
4 Updated Present A BO instance exists both on the device and in the backend system; however, the state of the BO is updated on the device Updates the BO in the backend system
5 Present Updated A BO instance exists both on the device and in the backend system; however, the state of the BO is updated in the backend system
Updates the BO on the device
6 Deleted Present A BO instance existed both on the device and in the backend system; however, the BO was deleted on the device Deletes the BO in the backend system
7 Present Deleted A BO instance existed both on the device and in the backend system; however, the BO was deleted in the backend system
Deletes the BO on the device
8 Deleted Deleted A BO instance existed both on the device and in the backend system; however, the BO was deleted both on the device and in the backend system
None
9 Updated Updated A BO instance exists both on the device and in the backend system; however, the BO was updated both on the device and in the backend system Takes the BO state in the backend as valid and updates the BO accordingly on the device
10 Updated Deleted A BO instance existed both on the device and in the backend system; however, the BO was updated on the device and was deleted in the backend system Takes the BO state in the backend as valid and thus deletes the BO on the device
11 Deleted Updated A BO instance existed both on the device and in the backend system; however, the BO was deleted on the device and was updated in the backend system Takes the BO state in the backend as valid and thus re-creates (updates) the BO accordingly on the device

 

Conflict between Device and Backend

When an object is modified or deleted on a client device, there might be cases that exactly the same object is updated in the backend system. Such a situation may happen, for example, when the object is modified on another device and uploaded to Smart Synchronization.

When Smart Synchronization detects that the object state is changed both in the backend and on a device, Smart Synchronization regards this as a conflict. In the table above, 3 cases (items 9 to 11) fall into this category of conflict. When a conflict is detected, Smart Synchronization performs the following:

Synchronization Error

The synchronization errors can fall into one of the following types:

Smart Sync Monitoring Tool

For information on the Smart Sync Monitoring tool, please consult the administrator's documentation for Smart Sync in the SAP Help Portal.

Basic Operations for Synchronization Test

This section describes the operations typically required in a synchronization/integration test.

The operations described in this section are referred from other sections of this document.

Operations on the WebAS

The following list describes the frequently used operations in Smart Synchronization during the test phase:

No

Description Procedure
(A) Creating Mobile Group
  1. Start the transaction merep_group
  2. Enter a unique Mobile Group
  3. Choose the Create icon or F5
  4. Enter description to Text
  5. Set a flag on the Enabled checkbox
  6. Choose the Save icon or Ctrl + S
(B) Creating Mobile ID

Prerequisites: Mobile Group is created

  1. Start the transaction merep_pd
  2. Choose the Mobile ID tab
  3. Enter a unique Mobile ID
  4. Choose the Register icon or F5
  5. Enter a Mobile Group to which the Mobile ID should belong
  6. Enter R/3 User ID to the User column of the R/3 User ID tab
  7. Choose the Save icon or Ctrl + S
(C) Removing Mobile ID
  1. 1. Start the transaction merep_pd
  2. Choose the Mobile ID tab
  3. Enter the Mobile ID to be deleted
  4. Copy your Mobile GUID
  5. Start transaction se37 and enter MEREP_MOBILE_UNREGISTER
  6. Choose F8
  7. Enter MOBILEGUID and USERID
  8. Choose F8
  9. Start the transaction merep_pd
  10. Choose the Mobile ID tab
  11. Enter the Mobile ID to be deleted
  12. Choose the Delete icon or Shift + F2
(D) Enabling a SyncBO
  1. 1. Start the transaction merep_pd
  2. Choose the Synchronizer tab
  3. Enter a SyncBO ID, and choose Enter
  4. Select the SyncBO from the list if not selected
  5. Choose the Display <-> Change icon or F5
  6. Set a flag on the Enabled column
  7. (Optional) Choose “A” (Always) on the Save data column
  8. Choose the Save icon or Ctrl + S
(E) Disabling a SyncBO
  1. Start the transaction merep_pd
  2. Choose the Synchronizer tab
  3. Enter a SyncBO ID, and choose Enter
  4. Select the SyncBO from the list if not selected
  5. Choose the Display <-> Change icon or F5
  6. Uncheck the Enabled column to disable the SyncBO
  7. Choose the Save icon or Ctrl + S
(F) Running the Replicator
  1. Start the transaction merep_ex_replic
  2. Enter a SyncBO ID for which the Replicator should be run If SyncBOs have a relationship, the parent SyncBO should be selected first. For more information on SyncBO relationship, refer to Data Structure of SyncBO.
  3. Enter a Log Level. Enter 2 in a production system.
  4. Choose the Execute icon from the application bar or F8
  5. Check the result, and choose the Back icon or F3
(G) Purge log, worklist, inbox and/or outbox
  1. Start the transaction merep_purge
  2. Enter a Mobile ID where the log should be purged
  3. Uncheck the Test run
  4. Select one of the Purge target
  5. Choose the Execute icon or F8
  6. Repeat 4-5 for all the purge targets required
(H) Reset sequence number for a device
  1. Start the transaction se38
  2. Enter a program: MEREP_DEVICE_REFRESH
  3. Choose the Execute icon or F8
  4. Enter Mobile ID and User for which the sequence number will be reset
  5. Choose the Execute icon or F8
(I) Refresh data download history for a device
  1. Start the transaction se38
  2. Enter a program: MEREP_SAP_ADM001_MAIN
  3. Choose the Execute icon or F8
  4. Enter Mobile ID and SyncBO ID for which the data download history will be refreshed
  5. Choose the Execute icon or F8
(J)
Modifying last processed message number for a device
  1. Start the transaction merep_pd
  2. Select the Mobile ID tab
  3. Enter a Mobile ID and choose Enter
  4. Choose the Display <-> Change icon from the application bar or Shift + F1
  5. Modify the Last processed in the Statistics tab. It is possible only to increment the value.
  6. Choose the Save icon or Ctrl + S

 

Operations on Client Device

The following list describes the frequently used operations in a client device during the test phase:

No

Description Procedure
(a) Starting MI Client Procedure
  • PC: Launch MI icon on your desktop
  • PDA: The MI is automatically started at system start
(b) Stopping MI Client Procedure
  • PC: Right-click on MI icon in system tray and select stop
  • PDA: Only through Task Manager. For MI restart, see (c)
(c) Restarting MI Client Procedure
  • Perform (b) and then right-click on the MI icon and select start.
  • PDA: ^Soft-reset the device
(d) Setting Gateway URL
  1. (a), login and navigate to “My settings”
  2. Enter required values
(e) Getting Device ID The Device ID is automatically drawn at first synchronization of a device, irrespective of user.
(f) Copying meta-data XML

Prerequisites: The meta-data XML file is generated (Refer to Generate Meta-data XML for Client)

  1. Remove all the .obj files and meRepMeta.xml if exists under <Me root>\data\<conv.id>
  2. Copy meRepMeta.xml to <Me root>\webapps\me\WEB-INF\wwwroot\data\meRep@@@???
  3. Perform (c)
  4. Perform (d)

 

Redoing Initial Data Download without Resetting Sequence Number

During the test phase, it is often necessary to repeat the initial data download test. Since Smart Synchronization keeps track of the current status of a client device, some preparatory task is necessary to repeat the test.

Two ways for redoing the initial data download exist depending on whether or not to reset the sequence number. The more convenient way is not to reset the synchronization message sequence number.

Prerequisites (Server-side)
Procedure (Server-side)
Prerequisites (Client-side)
Procedure (Client-side)
  1. Delete the .obj files under \data\<conversation ID of app+user> other than meRepMeta.obj and meRepSeqNo.obj files
  2. Perform (c) to restart the Tomcat as described above
  3. Perform (d) to go to the MI home page as described above and synchronize
  4. After a while, synchronize again to download the data

This approach assumes that the sequence number is correct. When performing the synchronization from the device and the message stays in I-Waiting status in the Worklist Monitor, it is necessary to perform one of the following:

Redoing Initial Data Download with Resetting Sequence Number

The other way of redoing the initial data download is to create the same circumstance both on the server and device as when the data synchronization is to be performed for the first time after the client application is deployed. That is, the sequence number of the first synchronization message is expected to be 1, and thus, Smart Synchronization needs to be configured in the way that it expects the message from the target device where the sequence number is 1.

Prerequisites (Server-side)
Procedure (Server-side)
  1. Perform (G) for all the purge targets to purge the log, worklist, inbox and outbox data as described above
  2. Perform (H) to reset the sequence number for the target device as described above
  3. Perform (I) to refresh the download data information as described above
Prerequisites (Client-side)
Procedure (Client-side)
  1. Delete all the .obj files under <Me root>\data\<conv.id>@@@???
  2. Perform (h) to copy the meta-data XML file as described above
  3. Perform (c) to restart the Tomcat as described above
  4. Perform (d) to go to the MI home page as described above and synchronize
  5. After a while, synchronize again to download the data

Incrementing Last Processed Sequence Number

Especially in the testing phase, it could happen that some worklist items never move from the I-Waiting status. One of the most probable reasons why this happens is that the sequence number of the last processed message is not equal to the sequence number of the incoming message less one.

If it is happening because the sequence number of the last processed message is smaller than that of the first incoming message by more than 1, it is possible to start processing the messages stopped in the I-Waiting status by incrementing the sequence number of the last processed message.

Decrementing the sequence number of the last processed message is not supported because it corrupts the mechanism of keeping track of the device status. In such a case, the device information needs to be reset to perform the re-initial data download. For more information on re-performing the initial data download, refer to Redoing Initial Data Download with Resetting Sequence Number.

Prerequisites

The sequence number of the last processed message must be smaller than the smallest sequence number of the incoming messages (worklist items) from a device, which are in the I-Waiting status

The following procedure will include the check of the sequence numbers.

Procedure
  1. Check the smalest “Seq. no.” of the worklist items from a device that are in the I-Waiting status in the Worklist Monitor.
    For more information on checking the value of the “Seq. no.” column, refer to Viewing Worklist Items.
  2. Perform (J) to check the sequence number of the last processed message and to increment the value to [the smallest “Seq. no.” checked above] minus 1
  3. Go back to the Worklist Monitor and trigger the Handler
    For more information on triggering the Handler, refer to Triggering Handler.

Synchronization / Integration Test Cases

After completing the unit/component test of individual building blocks (BAPI wrapper, client application and SyncBO), the system integration test needs to be performed. The following is a list of fundamental test cases:

The following sections describe these test cases briefly.

Application Deployment

This test case covers the following test items:

Prerequisites

Prior to conducting the test, the following needs to be completed:

Server / Client

Prerequisites
Server
  1. SyncBOs used in the client application are generated and enabled (Refer to Synchronizer Generation and Enabling a SyncBO)
  2. Replicator is run for the Download and timed 2-way SyncBOs (Refer to Running the Replicator)
  3. Mobile ID is created (Refer to Creating Mobile ID)
  4. Download information for the Mobile ID is refreshed (Refer to Redoing Initial Data Download with Resetting Sequence Number)
  5. Mobile application is uploaded to the Web AS via the MI Web Console. The application’s .war file includes the meta-data XML
Client
  1. MI is installed on the target device
  2. MI settings are maintained under My Settings.

    Make sure the application is not yet installed. It is necessary to remove all the .obj files and meRepMeta.xml if exists under <MI root>\data\<conv.id>

 

Procedure
  1. Start MI
  2. Choose the Synchronize icon in the MI home page on the device
  3. Restart the MI on the device
  4. Go to the MI home page on the device
Result

The application is downloaded to the device. The MI home page now has a link to the downloaded application, and the data files are created from the meta-data XML file under <Me root>\data

Initial Data Download

This test case covers the following test items:

Prerequisites

Prior to conducting the test, the following needs to be completed:

Server / Client

Prerequisites
Server
  1. SyncBOs used in the client application are generated and enabled (Refer to Synchronizer Generation and Enabling a SyncBO)
  2. Replicator is run for the Download and timed 2-way SyncBOs (Refer to Running the Replicator)
  3. Mobile ID is created (Refer to Creating Mobile ID)
  4. Download information for the Mobile ID is refreshed (Refer to Redoing Initial Data Download with Resetting Sequence Number)
Client
  1. MI is installed on the target device (Refer to Installing MI on PC and PDA)
  2. Device ID is obtained (Refer to Getting Device ID)
  3. Meta-data XML is copied (Refer to Copying meta-data XML)
  4. (Optional) Application is installed (Refer to Copying Application)
  5. (Optional) Add a link to the application in the MI home page (Refer to Copying meta-data XML)

Procedure
  1. Start MI and go to MI home on a device (Refer to Accessing MI home page)
  2. (Optional) Navigate to some screens of the application on the device
  3. Choose the Synchronize icon in the MI home page on the device
  4. Check the synchronization status on the Worklist Monitor of Smart Synchronization (Refer to Smart Synchronization Monitoring Tool)
  5. Choose the Synchronize icon on a device when all the SyncBOs are in the O-Sent status
Result

If successful, the downloaded data can be viewed in the application and the size of the .obj files under <Me root>\data\meRep on the device is increased.

To redo the initial data download, follow the steps described in Redoing Initial Data Download without Resetting Sequence Number.

Data Upload

This test case covers the following test items:

Prerequisites

Prior to conducting a test, the following needs to be completed:

Procedure
  1. Start MI and go to MI home on a device (Refer to Accessing MI home page)
  2. Navigate to the application on the device
  3. Create, modify and/or delete data on the device
  4. Go to MI home page on a device
  5. Choose the Synchronize icon on the device
  6. Check the synchronization status on the Worklist Monitor of Smart Synchronization (Refer to Smart Synchronization Monitoring Tool)
  7. Check the status of the business object in the backend system
  8. Choose the Synchronize icon on a device when all the SyncBOs are in the O-Sent status
Result

If an object is created, the object key(s) assigned in the backend should be visible in the client application after the second synchronization.

In the case of the error processing the uploaded message either in Smart Synchronization or in the backend system, the state of the uploaded object on the device reflects the current state in the backend system after the second synchronization. In addition, the RTN message content is logged as a text file under @@@<Me root>\webapps\me\WEB-INF\wwwroot\data\meRep.

Delta Download

This test case covers the following test items:

Prerequisites

Prior to conducting a test, the following needs to be completed:

Procedure
  1. Create, modify and/or delete an object in the backend system or perform data upload test from another device.
    Alternatively, change the filtering criteria or default values, so that different set of data is downloaded to the device.
  2. Run the Replicator for the SyncBO that is associated with the object updated in the step 1 if the synchronization type of the SyncBO is download or timed 2-way
    Changing the filtering criteria does not require running the Replicator.
  3. Start MI and go to MI home on a device (Refer to Accessing MI home page)
  4. Choose the Synchronize icon on the device
  5. Check the synchronization status on the Worklist Monitor of Smart Synchronization (Refer to Smart Synchronization Monitoring Tool)
  6. Choose the Synchronize icon on a device when messages for all the SyncBOs are in the O-Sent status
Result

If a new object is created, it is downloaded to the client device in the second synchronization. If an object is updated and had existed in the device, it is modified. If an object is deleted and had existed in the device, the object is deleted in the device.

Conflict Resolution

This test case covers the following test items:

Prerequisites

Prior to conducting a test, the following needs to be completed:

Procedure
  1. In the backend system, modify and/or delete an object that exists in the device or perform data upload test for the same object from another device
  2. Run the Replicator for the SyncBO that is associated with the object updated in the step 1 if the synchronization type of the SyncBO is download or timed 2-way
  3. Start MI and go to MI home on a device (Refer to Accessing MI home page)
  4. Modify and/or delete the same object on the device
    If the object was deleted on the server, modify the same object on the device. If the object was modified on the server, delete the same object or modify it on the device.
  5. Choose the Synchronize icon on the device
  6. Check the synchronization status on the Worklist Monitor of Smart Synchronization (Refer to Smart Synchronization Monitoring Tool)
  7. Choose the Synchronize icon on a device when messages for all the SyncBOs are in the O-Sent status
Result

The corresponding conflict object reflects the current state in the backend system after the second synchronization. In addition, the RTN message content for the conflict is logged as a text file under <Me root>\webapps\me\WEB-INF\wwwroot\data\meRep.

System Benchmark

The system benchmark is a combination of the following tests with simulating a certain number of the client devices synchronizing a certain amount of data volume with Smart Synchronization and the backend system(s):

This test is typically performed with simulating the expected number of devices synchronizing an average amount of data volume with Smart Synchronization and the backend system(s) in a production environment. This allows collecting the following information:

In addition, the performance of the scheduled job(s) for updating the Replica DB for SyncBOs where the synchronization type is download or timed 2-way needs to be measured with the expected frequency of running the Replicator job(s) in a production environment.