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:
- Message queuing – one synchronization is completed when the contents
of the queues are delivered to the other end and received from the other end
(Inbox/Outbox)
- Asynchronous – messages received by Smart Synchronization are processed
asynchronously
- Sequential – messages are processed only in the order of the sequence
number in each message, which is incremented by 1
- Delta data synchronization – only the different business objects between
a backend system and a client device are transferred to/from Smart Synchronization
- Synchronization initiated by a client device
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:
- In each synchronization initiated from a device, the messages transferred
to the Web AS consists of the following:
- Messages that request the update (create/change/delete) of business
object(s)
- Messages that request the “delta” data download to the device
for each SyncBO
- In one synchronization between a client device and Smart Synchronization,
the following is performed:
- Transfer the messages from the device to the inbox of Smart Synchronization
on the Web AS
- Transfer the messages, which are in the Generic Sync outbox on the Web
AS, to the device
- The messages transferred to Smart Synchronization inbox are not processed
immediately but asynchronously
- Maximum 3 types of worklist items (Handler/Synchronizer/Sender) are created
for each synchronization message, which instruct what needs to be performed
in Smart Synchronization to process each message
- Synchronization messages from a device are processed based on the sequence
number of a message and the last processed sequence number maintained in Smart
Synchronization
- Although it is not illustrated in the diagram above, it is also important
that the Synchronizer does not always call the BAPI wrapper; that is, depending
on the type of a Synchronizer and on the SyncBO synchronization type, it may
just look up the Replica DB and create the response message(s) for the device
- The messages transferred from Smart Synchronization to a device consists
of the following:
- RTN messages that describe the result of the processing such as conflict
detected, no delta data identified and update successful in the backend
- Messages that describe the current state of the object(s) in Smart Synchronization
Replica DB, which are related to the messages processed such as delta
data identified and object(s) that are updated in the backend system
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:
- 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
- Calls the Uploader Synchronizer if the associated message of a Handler
worklist item is an update message (an object is updated on the device)
- After handling all the Handler worklist items for a device, the
last processed sequence number is updated
- 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:
- The delta data is identified from the Replica DB with taking
care of the filtering criteria
- 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:
- The delta data is identified from the Replica DB with taking
care of the filtering criteria
- 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
- 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
- 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:
- The GetList and GetDetail BAPI wrapper functions are called
first
- 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)
- 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:
- Calls the corresponding update BAPI wrapper (Create/Change/Delete)
- Updates the Replica DB
- 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
- Creates a Sender worklist item
Replicator
This Synchronizer is called typically from the scheduled job to update
the Replica DB, which performs the following:
- Calls the GetList BAPI wrapper
- 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:
- Creates a RTN message specifying the conflict and the relevant object SYNC_KEY,
where the content is logged as a text file on the client device
- Creates a message describing the current state of the object in the Replica
DB
Synchronization Error
The synchronization errors can fall into one of the following types:
- Application error as a result of BAPI wrapper function call failure
- System error
- Communication error
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 |
- Start the transaction merep_group
- Enter a unique Mobile Group
- Choose the Create icon or F5
- Enter description to Text
- Set a flag on the Enabled checkbox
- Choose the Save icon or Ctrl + S
|
(B) |
Creating Mobile ID |
Prerequisites: Mobile Group is created
- Start the transaction merep_pd
- Choose the Mobile ID tab
- Enter a unique Mobile ID
- Choose the Register icon or F5
- Enter a Mobile Group to which the Mobile ID should belong
- Enter R/3 User ID to the User column of the R/3 User ID tab
- Choose the Save icon or Ctrl + S
|
(C) |
Removing Mobile ID |
- 1. Start the transaction merep_pd
- Choose the Mobile ID tab
- Enter the Mobile ID to be deleted
- Copy your Mobile GUID
- Start transaction se37 and enter MEREP_MOBILE_UNREGISTER
- Choose F8
- Enter MOBILEGUID and USERID
- Choose F8
- Start the transaction merep_pd
- Choose the Mobile ID tab
- Enter the Mobile ID to be deleted
- Choose the Delete icon or Shift + F2
|
(D) |
Enabling a SyncBO |
- 1. Start the transaction merep_pd
- Choose the Synchronizer tab
- Enter a SyncBO ID, and choose Enter
- Select the SyncBO from the list if not selected
- Choose the Display <-> Change icon or F5
- Set a flag on the Enabled column
- (Optional) Choose “A” (Always) on the Save data column
- Choose the Save icon or Ctrl + S
|
(E) |
Disabling a SyncBO |
- Start the transaction merep_pd
- Choose the Synchronizer tab
- Enter a SyncBO ID, and choose Enter
- Select the SyncBO from the list if not selected
- Choose the Display <-> Change icon or F5
- Uncheck the Enabled column to disable the SyncBO
- Choose the Save icon or Ctrl + S
|
(F) |
Running the Replicator |
- Start the transaction merep_ex_replic
- 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.
- Enter a Log Level. Enter 2 in a production system.
- Choose the Execute icon from the application bar or F8
- Check the result, and choose the Back icon or F3
|
(G) |
Purge log, worklist, inbox and/or outbox |
- Start the transaction merep_purge
- Enter a Mobile ID where the log should be purged
- Uncheck the Test run
- Select one of the Purge target
- Choose the Execute icon or F8
- Repeat 4-5 for all the purge targets required
|
(H) |
Reset sequence number for a device |
- Start the transaction se38
- Enter a program: MEREP_DEVICE_REFRESH
- Choose the Execute icon or F8
- Enter Mobile ID and User for which the sequence number will be reset
- Choose the Execute icon or F8
|
(I) |
Refresh data download history for a device
|
- Start the transaction se38
- Enter a program: MEREP_SAP_ADM001_MAIN
- Choose the Execute icon or F8
- Enter Mobile ID and SyncBO ID for which the data download history
will be refreshed
- Choose the Execute icon or F8
|
(J) |
Modifying last processed message number for a device |
- Start the transaction merep_pd
- Select the Mobile ID tab
- Enter a Mobile ID and choose Enter
- Choose the Display <-> Change icon from the application bar
or Shift + F1
- Modify the Last processed in the Statistics tab. It is possible
only to increment the value.
- 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 |
- (a), login and navigate to “My settings”
- 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)
- Remove all the .obj files and meRepMeta.xml if exists under <Me
root>\data\<conv.id>
- Copy meRepMeta.xml to <Me root>\webapps\me\WEB-INF\wwwroot\data\meRep@@@???
- Perform (c)
- 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)
- Mobile Group is created (A)
- Mobile ID is created (B)
- SyncBOs are enabled (D)
- Replicator is run (F)
- Synchronization was performed from the target client device
Procedure (Server-side)
- Perform (H) to refresh the download data information as described above
Prerequisites (Client-side)
- Device ID is obtained from Smart Synchronization
- MI is restarted after copying the meta-data XML
- Synchronization was performed from the device after restarting the MI
Procedure (Client-side)
- Delete the .obj files under \data\<conversation ID of app+user> other
than meRepMeta.obj and meRepSeqNo.obj files
- Perform (c) to restart the Tomcat as described above
- Perform (d) to go to the MI home page as described above and synchronize
- 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:
- Perform (J) to increment the last processed sequence number and trigger
the handler in the Worklist Monitor (For more information, refer to Incrementing
Last Processed Sequence Number)
- Redoing initial data download with resetting the sequence number (refer
to the next section)
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)
- Mobile Group is created (A)
- Mobile ID is created (B)
- SyncBOs are enabled (D)
- Replicator is run (F)
- Synchronization was performed from the target client device
Procedure (Server-side)
- Perform (G) for all the purge targets to purge the log, worklist, inbox
and outbox data as described above
- Perform (H) to reset the sequence number for the target device as described
above
- Perform (I) to refresh the download data information as described above
Prerequisites (Client-side)
- Device ID is obtained from Smart Synchronization (g)
Procedure (Client-side)
- Delete all the .obj files under <Me root>\data\<conv.id>@@@???
- Perform (h) to copy the meta-data XML file as described above
- Perform (c) to restart the Tomcat as described above
- Perform (d) to go to the MI home page as described above and synchronize
- 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
- 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.
- 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
- 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:
- Application deployment
- Initial data download
- Upload of SyncBO instance(s) that are created, changed and/or deleted on
the client application
- Delta download – changes made in the backend or changes of default
values and/or filtering criteria of SyncBO(s)
- Conflict resolution
- System benchmark
The following sections describe these test cases briefly.
Application Deployment
This test case covers the following test items:
- Downloading an Smart Synchronization application to a device
- Automatically creating a link to the application on the MI home page
- Automatically deploying the meta-data XML file
Prerequisites
Prior to conducting the test, the following needs to be completed:
Server
/ Client |
Prerequisites |
Server |
- SyncBOs used in the client application are generated and enabled
(Refer to Synchronizer Generation and Enabling a SyncBO)
- Replicator is run for the Download and timed 2-way SyncBOs (Refer
to Running the Replicator)
- Mobile ID is created (Refer to Creating Mobile ID)
- Download information for the Mobile ID is refreshed (Refer to Redoing
Initial Data Download with Resetting Sequence Number)
- Mobile application is uploaded to the Web AS via the MI Web Console.
The application’s .war file includes the meta-data XML
|
Client |
- MI is installed on the target device
- 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
- Start MI
- Choose the Synchronize icon in the MI home page on the device
- Restart the MI on the device
- 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:
- Downloading complete set of application data required on a device
- Synchronization performance on a device
- Synchronization performance on the server-side (Smart Synchronization and
backend system) for one device
Prerequisites
Prior to conducting the test, the following needs to be completed:
Server
/ Client |
Prerequisites |
Server |
- SyncBOs used in the client application are generated and enabled
(Refer to Synchronizer Generation and Enabling a SyncBO)
- Replicator is run for the Download and timed 2-way SyncBOs (Refer
to Running the Replicator)
- Mobile ID is created (Refer to Creating Mobile ID)
- Download information for the Mobile ID is refreshed (Refer to Redoing
Initial Data Download with Resetting Sequence Number)
|
Client |
- MI is installed on the target device (Refer to Installing MI on
PC and PDA)
- Device ID is obtained (Refer to Getting Device ID)
- Meta-data XML is copied (Refer to Copying meta-data XML)
- (Optional) Application is installed (Refer to Copying Application)
- (Optional) Add a link to the application in the MI home page (Refer
to Copying meta-data XML)
|
Procedure
- Start MI and go to MI home on a device (Refer to Accessing MI home page)
- (Optional) Navigate to some screens of the application on the device
- Choose the Synchronize icon in the MI home page on the device
- Check the synchronization status on the Worklist Monitor of Smart Synchronization
(Refer to Smart Synchronization Monitoring Tool)
- 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:
- Uploading one or more application data created, modified and/or deleted
on a device
- Synchronization performance on a device
- Synchronization performance on the server-side (Smart Synchronization and
backend system) for one device
Prerequisites
Prior to conducting a test, the following needs to be completed:
- Initial data download test (Refer to Initial Data Download)
Procedure
- Start MI and go to MI home on a device (Refer to Accessing MI home page)
- Navigate to the application on the device
- Create, modify and/or delete data on the device
- Go to MI home page on a device
- Choose the Synchronize icon on the device
- Check the synchronization status on the Worklist Monitor of Smart Synchronization
(Refer to Smart Synchronization Monitoring Tool)
- Check the status of the business object in the backend system
- 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:
- Downloading one or more application data created, modified and/or deleted
in the backend system, for example, as a result of data upload from another
device
- Downloading one or more application data as a result of the changes in Smart
Synchronization (default value setting and filtering criteria)
- Synchronization performance on a device
- Synchronization performance on the server-side (Smart Synchronization and
backend system) for one device
Prerequisites
Prior to conducting a test, the following needs to be completed:
- Initial data download test (Refer to Initial Data Download)
Procedure
- 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.
- 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.
- Start MI and go to MI home on a device (Refer to Accessing MI home page)
- Choose the Synchronize icon on the device
- Check the synchronization status on the Worklist Monitor of Smart Synchronization
(Refer to Smart Synchronization Monitoring Tool)
- 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:
- Handling the case when one or more application data uploaded from a device
have been also modified and/or deleted in the backend system
- Synchronization performance on a device
- Synchronization performance on the server-side (Smart Synchronization and
backend system) for one device
Prerequisites
Prior to conducting a test, the following needs to be completed:
- Initial data download test (Refer to Initial Data Download)
Procedure
- 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
- 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
- Start MI and go to MI home on a device (Refer to Accessing MI home page)
- 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.
- Choose the Synchronize icon on the device
- Check the synchronization status on the Worklist Monitor of Smart Synchronization
(Refer to Smart Synchronization Monitoring Tool)
- 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):
- System Load Test
- System Performance Test
- Stress Test
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:
- Reasonable hardware specification to meet the requirements
- Performance bottleneck in the system landscape
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.