Smart Sync Tutorial | Smart Sync Admin Tools | In-Outbound Handling
In this section, we will first discuss the definition process for SyncBO and then elaborate on all required steps in detail, that means
A SyncBO can be defined using Smart Sync SyncBO Builder. The overview of the typical steps for defining a SyncBO is as follows:
The following definitions are required to be set per SyncBO (the numbering corresponds
to one in the diagram above):
Steps for defining a SyncBO |
Description |
|
Operations allowed from client devices must be defined per SyncBO. Depending on the synchronization type selected, the methods (BAPI wrappers) required for the SyncBO will be different. (For details, refer to Synchronization Type) |
|
The data structure used for the data exchange between the mobile clients and the Mobile Infrastructure server can be specified by defining the meta-data of the SyncBO. The exchanged data fields are normally selected from GetList Export parameter (HEADER) and from GetDetail Tables parameters (ITEM), with an exception of the SyncBO where the synchronization type is upload. (For details, refer to Mapping) |
|
Some fields may not be necessary to be exposed to the clients; however, the fields can be the mandatory fields when the BAPI wrappers are called (mainly in Create and Change functions). In such a case, the field can be set as “default“ and its default value can be assigned. The default values need to be assigned also for the selection criteria parameter(s) of GetList BAPI wrapper function, which is used to pre-filter data being stored in the Replica DB of Smart Synchronization. The default value can be set for SyncBO, for Mobile Group (user-defined organizational group) and/or for device. (For details, refer to Mapping and Assigning Values to “Default” Fields) |
|
To reduce the number of records on client devices, for example, to avoid downloading unnecessary data, the data filtering function can be used to filter the data downloaded from the Replica DB of Smart Synchronization. This can be set per SyncBO, per Mobile Group (user-defined organizational group) or per device. Maximum 3 fields of the HEADER structure in the BAPI wrapper can be mapped as a filtering field. (For details, refer to Mapping and Assigning Filtering Criteria) |
|
- Smart Synchronization can be connected to any release of R/3 system as the backend where BAPI wrappers are defined. The RFC destination to the backend system can be defined differently per SyncBO or can be set to use the default RFC destination. |
The following diagram describes what the meta-data definition is for and how
default values are used when BAPI wrappers are called. In essence, the meta-data
corresponds to the client view of the SyncBO. In other words, it is the data
structure visible from the clients. On the other hand, the fields set as “default”
are not visible to the clients. However, they are used when the mapped BAPI
wrappers are called.
The client view of a SyncBO (Meta-data) can be viewed from the SyncBO Builder initial screen. For more information, refer to Display Data Model (Meta-data).
The following diagram illustrates how the selection criteria of the GetList BAPI wrapper is used to pre-filter the backend data and how the filtering criteria is used to further filter the pre-filtered data for a client device. Essentially, the selection criteria of the GetList function are used to remove the backend data that will never be used by any of the client devices, whereas the filtering criteria are used to filter the data in the Replica DB of Smart Synchronization for each device.
Prior to creating a SyncBO for the first time, it is necessary to define the default target backend system where most of the BAPI wrappers being used in the SyncBOs reside.
![]() |
|
In addition to these, it is recommended to create a Mobile Group and a Mobile ID at this point, so that the parameter settings specific to a Mobile Group or a Mobile ID can be tested in the development phase.
The target backend system can be created from the Profile Dialog screen. Prior to this, however, it is necessary to maintain an RFC destination for the target backend system in the transaction sm59.
The following steps are necessary to set a default target backend system:
Empty text in RFC Destination text box means that the default target system is the same system as the one you are currently working on.
A Mobile Group is a sort of an organizational unit where multiple mobile IDs can belong. You can define different filtering criteria and/or default values for a different Mobile Group.
To create a Mobile Group, perform (A) Creating Mobile Group described in Basic Operations for Synchronization Test.
A Mobile ID is an identifier for Smart Synchronization to uniquely identify Smart Synchronization client devices. Each Mobile ID belongs to one Mobile Group. It is possible to set different filtering criteria and/or default values for each Mobile ID.
To create a Mobile ID, perform (B) Creating Mobile ID described in Basic Operations for Synchronization Test.
After the basic configurations for Smart Synchronization, the first step in defining SyncBO is to create a new SyncBO. This can be done in 2 ways:
To create a SyncBO follow the steps described here. The default backend connection is defined in the Profile Dialog (transaction merep_pd) -> Synchronizer -> Destination.
After specifying the synchronization type and function group, you will be asked to select an RFC destination. If you would like to immediately enable the connection to the system, set a flag on SyncBO Specific. If this flag is not set, Smart Synchronization uses the default target backend system as the target system for the SyncBO until the flag is set in Edit ->SyncBO Edit ->RFC Destination from the initial screen.
In the creation of a SyncBO, the first step is to select the synchronization type of the SyncBO. Depending on the synchronization type selected, what the role of the SyncBO will be different and BAPI wrappers required will be different.
The following types are available:
Synchronization Type of SyncBO |
Description |
Download |
Downloads multiple BOs to a mobile client from the server. This type does not allow to uploading data from the mobile clients.
|
Upload | Only allows to uploading BO from a mobile client to the server. |
2-way | Executes both data download and upload in each access from a client to the server. The delta BO determination between the application DB in the backend system and the mobile client local DB is triggered in each access. This means it is based on the latest state of the backend system at the point of each access. However, the performance can be low, as it is synchronously performed. |
Timed 2-way | Executes both data download and upload in each access from a client to the server. Since the delta BO determination between the application DB in the backend system and the Replica DB for the device in Smart Synchronization is executed via periodical job, the performance is high. However, there might be cases where the Replica DB is not most up-to-date at the time of an access from the device. |
Backend driven 2-way | Executes both data download and upload in each access from a client to the server. Since the delta BO determination between the application DB in the backend system and the Replica DB for the device in Smart Synchronization is controlled by the backend system, the performance is high. However, there might be cases where the Replica DB is not most up-to-date at the time of an access from the device. |
In the runtime, the synchronization process is different if the synchronization
type is different.
For each synchronization type, the BAPI wrappers required to the SyncBO will be different. The following table describes the required BAPI wrappers:
Synchronization Type |
GetList | GetDetail | Create | Change | Delete |
Download - obsolete | Required | Optional | Not Allowed | Not Allowed | Not Allowed |
Upload | Not Allowed | Not Allowed | Required | Not Allowed | Not Allowed |
2-way | Required | Required | Optional | Optional | Optional |
Timed 2-way | Required | Required | Optional | Optional | Optional |
Backend driven 2-way | Required | Required | Optional | Optional | Optional |
After specifying the synchronization type, it will ask which function group should be used for the generated function modules when the synchronizer of the SyncBO is generated.
The following 3 options are available:
Options for Function Group Setting |
Description |
Unique to this SyncBO | The generated synchronizer will be created to a function group unique to the SyncBO you created. The code generator will automatically create a new function group “Z_MBL_FUNCG_XXX_YYYYYYYYYY” (XXX: Synchronization type; YYYYYYYYYY: SyncBO name). |
Unique to this sync type | The generated synchronizer will be created to a function group unique to the synchronization type. The code generator will automatically assign the generated function module to the function group “Z_MEREP_XXX_______________” (XXX: Synchronization type). |
Specify a function group | The code generator will create a new function group you specified and will assign the generated function module to the specified function group. In this case, the function group name must start from ‘Z’ or ‘Y’. |
![]() |
Unique to this SyncBO option is recommended in most cases. |
After specifying the synchronization type and the function group, the SyncBO Attribute screen will be displayed. In this screen, you will enter the description of the SyncBO, define BAPI wrappers for the SyncBO and set the administration flags.
Field name |
Description |
Description | This is a mandatory field. Enter the description of the SyncBO (maximum length is 50 bytes). |
BAPI Wrapper | Depending on the synchronization type selected, enter the name of the BAPI wrappers to the corresponding textbox. Note that the BAPI wrappers specified here need to exist on the target backend system. |
Administration | Three options are available for administration. Set the flag depending on what administrative options should be enabled. The following describes what each option means:
|
The next step after specifying the synchronization type and some SyncBO attributes is to define the following in the Mapping Setting screen:
Please go to SAP Help Portal for additional information on field mappings.
To display the Mapping Setting screen, double-click on any of the red-colored text named Importing, Exporting or Tables under the BAPI wrapper name, in the Mapping screen.
In the Mapping Setting screen, the following settings are required:
The following sections describe the concrete steps required for mapping in each type of BAPI wrapper and refer to the numbering ((A), (B) etc.) in the table above for the detailed steps required in each step.
The first step is to define the HEADER (TOP) structure by mapping fields for the GetList BAPI wrapper parameters. If the SyncBO is of synchronization type 'Upload', the mapping for Create BAPI wrapper determines the HEADER structure.
The following needs to be performed in the mapping setting screen:
When mapping is completed, you can view the client view of the SyncBO (Meta-data) from the SyncBO Builder initial screen. For more information, refer to Display Data Model (Meta-data).
The next step is to define the ITEM (010, 020…) structure(s) for the SyncBO that uses a GetDetail BAPI wrapper. If the SyncBO is of synchronization type 'Upload', mapping for Create BAPI wrapper determines the ITEM structure(s).
The following needs to be performed in the Mapping Setting screen:
The Value ID column in the Import tab is normally not used.
When mapping is completed, you can view the client view of the SyncBO (Meta-data) from the SyncBO Builder initial screen. For more information, refer to Display Data Model (Meta-data).
If a Create BAPI wrapper is defined in the SyncBO, the following needs to be performed in the Mapping Setting screen:
If the synchronization type of the SyncBO is upload, mapping for Create BAPI wrapper determines the HEADER and ITEM structures of the SyncBO.
The Related SyncBO column in the Import/Tables tab is not used if the synchronization type is NOT upload.
If a Change BAPI wrapper is defined in the SyncBO, the following needs to be performed in the Mapping Setting screen:
If a Delete BAPI wrapper is defined in the SyncBO, the following needs to be performed in the Mapping Setting screen:
The Value ID column in the Import tab is normally not used. For more information, refer to Special Cases of Setting Value IDs.
The next step after mapping is to generate the synchronizer. This can be executed from the SyncBO Builder initial screen. When the generation is successfully executed, you will see a text indicating the successful generation on the message bar at the bottom of the screen. The synchronizer will be generated as function module(s) in the function group you defined during the first step of the SyncBO creation. The following table shows the function modules generated for each synchronization type.
Synchronization Type |
Replicator |
Downloader |
Uploader |
Download (D01) | Generated |
Generated |
- |
Upload (U01) | - |
- |
Generated |
Time 2-way (T01) | Generated |
Generated |
Generated |
2-way (S01) | - |
Generated |
Generated |
Backend driven 2-way (T51) | Generated |
Generated |
Generated |
The synchronizer is the core of the runtime components.
Follow the instructions provided here. This will generate the respective runtime components and put them into the function group defined in the SyncBO attributes.
2 types of custom logic can be added to modify the default behavior of Smart Synchronization:
In both cases, the knowledge of ABAP is required.
SyncBO specific custom logic can be added, for example, to handle the following cases:
To disable a SyncBO, start the Profile Dialog (transaction merep_pd), choose the Synchronizer tab and uncheck the box in column Enable for your SyncBO.
Added custom logic will remain even if the synchronizer is re-generated.
An example of a dynamic filtering is to filter the business objects downloaded where the value of a date field is in the range between the date of the synchronization and one month later.
The following shows how to determine whether to download each entry in the Replica DB to a client device: Add an Exit at <X:400000> of the Downloader of a download, 2-way or timed 2-way SyncBO.
*<X:400000> Synchronization block: Start position * ldt_rdb_h = Filtered (based on filtering criteria) HEADER data from Replica DB * ldt_rdb_p = ITEM data under the HEADER data * The following LOOP will remove the data that should not be downloaded to a client device LOOP AT ldt_rdt_h INTO lds_rdb_h . * Accessible parameters: * ldt_rdb_h, ldt_rdb_p * Import parameter or Tables parameter that will be used as an input to the downloader * Add a logic here to remove an entry from ldt_rdb_h and/or ldt_rdb_p unless the data should be downloaded to the device END LOOP . *</>
BAdI can be used to handle the following case:
For Smart Synchronization, 2 BAdIs are available:
Technical name of BAdI |
Description |
MEREP_RSLTHNDL2 | This is called whenever Smart Synchronization creates a log or RTN message within any Synchronizer function module. Within this BAdI, the accessible data includes the Mobile ID, SyncBO ID and the position ID within the Syncrhonizer function module. The BAdI can be implemented to perform, for example, the following: modifying the RTN message content, starting a workflow or collecting statistic data. 2 methods are available:
|
MEREP_RUNTM_LD2 |
|
After the generation of the synchronizer and before unit testing the SyncBO, it is necessary to assign a concrete default value to the Value ID defined in the mapping step. The default value can be changed later.
The valid area of a Value ID is determined by the option selected from Depends on options when the Value ID is created. The following list describes the options available and the valid area for each option:
Depends on ... |
Description |
SyncBO Only | The assigned value is valid for any Mobile ID (user) that uses the SyncBO. |
Mobile Group Only | The assigned value is valid for any Mobile ID (user) that uses the SyncBO and that belong to the Mobile Group for which the value is defined. |
Mobile ID Only | The assigned value is valid for the Mobile ID (user) that uses the SyncBO and for which the value is defined. |
SyncBO or Mobile Group | The same as for Mobile Group Only. In addition, if the value is not defined for a Mobile Group, the value for the SyncBO is used for any Mobile ID (user) that belongs to the Mobile Group. |
SyncBO, Mobile Group or Mobile ID | The same as for Mobile ID Only. In addition, if the value is not defined for a Mobile ID, it will be the same as for SyncBO or Mobile Group, for the Mobile Group where the Mobile ID belongs. |
The following describes the default value of a value ID (DIVISION) when the value ID uses SyncBO, Mobile Group or Mobile ID option for Depends on:
Note that the value of a Mobile ID is used if it is defined (A1). If it is not defined, then the value of the Mobile Group where the Mobile ID belongs is used (A2). If this is also not defined, then the value of the SyncBO is used (B1).
The valid default values are as follows:
Default value type |
Description |
Static text | A static text that is surrounded by single-quotation marks (for example, ‘0000001’ and ‘’ for empty text). The text must be based on the internal format of the system (e.g. internal format of a date (2002/12/31) is ‘20021231’). |
System variable | Any of the ABAP system variables can be entered as the default value (for example, SY-DATUM, SY-UZEIT). In this case, the text should NOT be surrounded by single-quotation marks. |
MI variable | Similar to system variable, currently following variables can be entered as the default value:
In this case, the text should NOT be surrounded by single-quotation marks. |
After the generation of the synchronizer and before unit testing the SyncBO, it is possible to assign filtering criteria for the SyncBO to narrow down the number of instances to be downloaded to client devices, if some fields in the HEADER (TOP) structure are marked as filtering field.
The filtering criteria can be changed later. Assigning the filtering criteria is equivalent to defining a logical expression or where-clause in SELECT statement of ABAP.
The following shows the values on the Filtering criteria screen and its actual expression:
Expression: (START_DATE GE sy_datum OR NOT (COUNTRY NE ‘JP’))
The filtering criteria can be defined for SyncBO, for Mobile Group, and/or for Mobile ID. Unlike the case for the default value assignment, the criteria for a SyncBO, for a Mobile Group and for a Mobile ID are combined implicitly (AND operation).
The following describes how the filtering criteria can be combined for different Mobile Group and ID:
For Mobile ID A1, the filtering criteria for the Mobile ID, Mobile Group and SyncBO are combined by AND operation, whereas the filtering criteria used for Mobile ID B1 is the same as the one for the SyncBO because the filtering criteria for the Mobile ID and Mobile Group are not defined.
The valid values for the Value column are as follows:
Filter value type |
Description |
Static text | A static text that is surrounded by single-quotation marks (for example, ‘0000001’ and ‘’ for empty text). The text must be based on the internal format of the system (e.g. internal format of a date (2002/12/31) is ‘20021231’). |
System variable |
Any of the ABAP system variables can be entered as the default value (for example, SY-DATUM, SY-UZEIT). In this case, the text should NOT be surrounded by single-quotation marks. |
MI variable | Similar to system variable, currently following variables can be entered as the default value:
In this case, the text should NOT be surrounded by single-quotation marks. |
Any time after mapping, this functionality can be used to check the meta-data of the SyncBO.
TOP stands for the HEADER structure, and 0n0 where n=1,2,3… stands for the ITEM structure. The first 7 fields (STRUCT_ID etc.), which are the technical key fields used during the synchronization, are common in any structure. All the fields besides 6 out of 7 technical key fields in a structure will be the fields visible from the clients. That is, they are the fields used for data synchronization.
Among these 7 fields, SYNC_KEY field is the only field visible from the client. SYNC_KEY is the primary key that specifies the instance of the structure.
Following the procedure above, look at the meta-data of the sample “Country” SyncBO (SyncBO ID: SAP_EXM002) available in any Basis 6.20 system.
This SyncBO has one HEADER (TOP) structure and 2 ITEM (010 and 020) structures. The HEADER structure has 10 fields (and 7 technical key fields) for data synchronization with client devices. The 010 ITEM structure has 2 fields and the 020 ITEM structure has 6 fields.
After fixing the SyncBO structure for data synchronization by mapping, the SyncBO structure information can be generated in the form of XML. This XML document will be used by the MI JAVA APIs to access and manipulate the local SyncBO data downloaded from Smart Synchronization.
A client application developer typically looks into the generated XML document for implementing the data access layer of a client application.
The complete process for generating the meta-data XML file is described here.