Smart Sync Tutorial  |  Smart Sync Admin Tools  |  In-Outbound Handling

 

Defining Synchronizer Business Objects (SyncBO)

In this section, we will first discuss the definition process for SyncBO and then elaborate on all required steps in detail, that means

SyncBO Definition Process

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
  1. Method definition
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)
  1. Meta-data definition (Client view of SyncBO)
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)
  1. Default value setting
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)
  1. Filtering setting
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)
  1. Backend system definition
- 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.

Basic Configurations for Smart Synchronization

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.

  • This is not necessary, if Smart Synchronization and BAPI wrappers are located in the same system.
  • It is possible to create a SyncBO with a different backend from the default system. For more information, refer to Setting SyncBO ID and Synchronization Type.

 

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.

Setting Default Target Backend System

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:

  1. Start the transaction merep_pd
  2. Choose the Synchronizer tab
  3. Choose the Destination tab
  4. Choose the Destination button
  5. Set a cursor on RFC Destination text box and choose F4
  6. Select a RFC destination
  7. Choose the Save icon or Ctrl + S
  8. On the pop up dialog, choose the Continue icon
  9. Confirm that no error is found

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.

Creating Mobile Group

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.

Creating Mobile ID

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.

Setting SyncBO ID and Synchronization Type

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.

Synchronization Type

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.

This SyncBo type is obsolete and should not be used for any reason. Alternative SyncBo types are:

2-way, Timed 2-way, Backend driven 2-way.

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

 

Function Group

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.

 

Setting SyncBO Attributes

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:

  • Edit Lock: If this option is checked, the SyncBO can be editable only by the user who sets it.
  • Published flag: This option is not available at the time of creation. If this flag is set, no one can edit the SyncBO once it is saved. All SAP standard SyncBOs have this flag set (This flag should NOT be set when SyncBO setting is not completed: Use Edit g SyncBO Edit g Publish to publish a SyncBO).
  • Type Check: If this option is checked, each uploaded data value from a client is validated against the field type during the synchronization in the runtime. Setting this flag can be useful, for example, during the evaluation or testing phase.

 

Defining Field Mappings

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:

Step no.

Step name Description
(A) Field(s) visible to clients Set a flag on the Map column
“Map To: …” or “Map From: …” will be shown in the Map Description column.
(B) Field(s) with default values
  1. Set a cursor to the Value ID column and choose F4
  2. Choose the Create icon or F5 in the pop up dialog
  3. Enter the Value ID name (max. 16 bytes) and the text
  4. Select the area where the Value ID is valid by choosing one of the radio buttons (for details of Depends on options, refer to Assigning Values to “Default” Fields)
  5. Choose the Continue icon or F8 “

Mapped via Default Value” will be shown in the Map Description column.

(C) Field(s) used for filtering Set a flag on the Filter column
(D) Key field(s) Set a flag on the Itab Key column
(E) Mandatory field(s)
Set a flag on the "Mandatory fld" column
(F) Field to link to another SyncBO Select the related SyncBO on the Related SyncBO column
“Related to: …” will be shown in the Map Description column
(G) Mapping object key parameters to HEADER key fields
  1. Set a cursor to the Map Description column and choose F4
  2. Choose one of the key fields in GetList BAPI wrapper to map in the popup dialog
  3. Choose the Continue icon or F8

"From BAPI Field: …” will be shown in the Map Description column.

 

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.

Defining HEADER (TOP) Structure

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:

  1. Go to the Mapping Setting screen by double-clicking on any of the red-colored text named Importing, Exporting or Tables under the GetList BAPI wrapper name
  2. Perform (A) to define the client view of the HEADER (TOP) structure in the Tables tab
  3. Perform (B) to assign the Value ID for the selection criteria in the Import tab
    The SyncBO Only radio button is the only option available for the Depends on if the synchronization type is download or timed 2-way.
  4. Perform (C) to specify maximum 3 fields for filtering if necessary in the Tables tab
  5. Perform (D) to specify the R/3 key field(s) in the Tables tab
  6. Perform (E) to specify the mandatory field if its value cannot be empty in the Tables tab
  7. Perform (F) to specify the field holding a key field value of another SyncBO, if applicable, in the Tables tab

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).

Defining ITEM (010, 020…) Structure

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:

  1. Go to the Mapping Setting screen by double-clicking on any of the red-colored text named Importing, Exporting or Tables under the GetDetail BAPI wrapper name
  2. Perform (A) to define the client view of the ITEM structure for each table parameter in the Tables tab
  3. Perform (D) to specify the R/3 key field(s) for the ITEM structure in the Tables tab. Each item needs to be uniquely identified by the key field(s).
    If the type of a key field is NOT NUMC, a flag for the Map column is automatically set and the checkbox is grayed-out. This is because the field value needs to be specified externally (for example, by a client application) when an item object is created. On the other hand, if the type is NUMC, whether to set a flag for the Map column depends on whether the field should be visible to clients. However, when an item object is created, the field value is automatically assigned by Smart Synchronization, no matter what the value specified by a client application is. The numbering starts from 1 and incremented by 1 (for example, 1, 2, 3…).
  4. Perform (E) to specify the mandatory field if its value cannot be empty in the Tables tab
  5. Perform (F) to specify the field holding a key field value of another SyncBO if applicable in the Tables tab
  6. Perform (G) to map the HEADER key field to the corresponding Import parameter in the Import tab

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).

Mapping for Create BAPI Wrapper

If a Create BAPI wrapper is defined in the SyncBO, the following needs to be performed in the Mapping Setting screen:

  1. Go to the Mapping Setting screen by double-clicking on any of the red-colored text named Importing, Exporting or Tables under the Create BAPI wrapper name
  2. Perform (A) to map the fields in the HEADER (TOP) structure where the value can be provided from a client application in the Import tab
    Only the subset of the HEADER structure (fields mapped in the GetList Tables parameter) can be mapped, if the synchronization type is not upload.
  3. Perform (A) to map the fields in the ITEM structure(s) where the value can be provided from a client application in the Tables tab
    Only the subset of the ITEM structure(s) (fields mapped in the GetDetail Tables parameter(s)) can be mapped, if the synchronization type is not upload.
  4. Perform (B) to specify the fields with default values if some of the fields of the HEADER (TOP) structure need a default value in the Import tab
  5. Perform (B) to specify the fields with default values if any in the Tables tab
  6. Perform (D) to specify the R/3 key field(s) in the Export tab
    Smart Synchronization uses this key value exported from the Create BAPI wrapper to call the GetDetail BAPI wrapper in the runtime.
  7. Perform (D) to specify the R/3 key field(s) for the ITEM structure in the Tables tab
  8. If the synchronization type of the SyncBO is upload, perform (F) to specify the field holding a key field value of another SyncBO if applicable in the Import/Tables tab

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.

Mapping for Change BAPI Wrapper

If a Change BAPI wrapper is defined in the SyncBO, the following needs to be performed in the Mapping Setting screen:

  1. Go to the Mapping Setting screen by double-clicking on any of the red-colored text named Importing, Exporting or Tables under the Change BAPI wrapper name
  2. Perform (A) to map the fields in the HEADER (TOP) structure where the value can be provided from a client application in the Import tab
    Only the subset of the HEADER structure (fields mapped in the GetList Tables parameter) can be mapped.
  3. Perform (A) to map the fields in the ITEM structure(s) where the value can be provided from a client application in the Tables tab
    Only the subset of the ITEM structure(s) (fields mapped in the GetDetail Tables parameter(s)) can be mapped.
  4. Perform (B) to specify the fields with default values if some of the fields of the HEADER (TOP) structure need a default value in the Import tab
  5. Perform (B) to specify the fields with default values if any in the Tables tab
  6. Perform (D) to specify the R/3 key field(s) in the Import tab
    Smart Synchronization uses this key value to call the GetDetail BAPI wrapper after the Change BAPI wrapper execution in the runtime.
  7. Perform (D) to specify the R/3 key field(s) for the ITEM structure in the Tables tab

Mapping for Delete BAPI Wrapper

If a Delete BAPI wrapper is defined in the SyncBO, the following needs to be performed in the Mapping Setting screen:

  1. Go to the Mapping Setting screen by double-clicking on any of the red-colored text named Importing, Exporting or Tables under the Delete BAPI wrapper name
  2. Perform (D) to specify the R/3 key field(s) in the Import tab

The Value ID column in the Import tab is normally not used. For more information, refer to Special Cases of Setting Value IDs.

Synchronizer Generation

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.

Procedure

Follow the instructions provided here. This will generate the respective runtime components and put them into the function group defined in the SyncBO attributes.

Adding Custom Logic (Optional)

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.

Adding Custom Logic to SyncBO

SyncBO specific custom logic can be added, for example, to handle the following cases:

Prerequisites

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.

Procedure

  1. Start the transaction merep_sbuilder
  2. Enter the SyncBO ID and choose the Add exit icon from the application bar or Ctrl + F4
  3. Select a synchronizer function module in which you want to insert additional logic
  4. Choose one of the Create icons on the right of the text, which specifies the segment of the function module
  5. Add the ABAP coding
  6. Choose the Save icon
  7. Choose the Source code icon or F7 to view the source code of the selected function module and perform the syntax check by choosing the Syntax check icon
  8. Choose the Save icon if the function module is syntax free
  9. Choose the Back icon or F3
  10. Regenerate the synchronizer by choosing the Generate/Activate SyncBO icon from the application bar or Ctrl + F3

Added custom logic will remain even if the synchronizer is re-generated.

Example

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 .
*</>

Adding Business Add-In

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:

  • ADDITIONAL_HANDLING_PRE
  • ADDITIONAL_HANDLING_POST
MEREP_RUNTM_LD2


This is used when it is necessary to extend the data accessible in MEREP_RSLTHNDL2. 1 method is available:

  • ADDITIONAL_FUNCTION

 

Assigning Default Values

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.

 

Example

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:

  • MI-SYNC_USER
  • MI-MBL_ID

In this case, the text should NOT be surrounded by single-quotation marks.

 

Procedure

  1. Start the transaction merep_sbuilder
  2. Enter the SyncBO ID
  3. Choose Environment g Default values
  4. Enter text or system variable in the Value column for each Value ID defined in the SyncBO tab
  5. Select the Mobile Group tab
  6. Enter a Mobile Group
  7. Enter text or system variable in the Value column for each Value ID defined
  8. Repeat 6 and 7 for other Mobile Groups
  9. Select the Mobile ID tab
  10. Enter text or system variable in the Value column for each Value ID defined
  11. Repeat 9 and 10 for other Mobile IDs
  12. Choose Save from the application bar or Ctrl + S

Assigning Filtering Criteria

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.

Example

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).

Example

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:

  • MI-SYNC_USER
  • MI-MBL_ID

In this case, the text should NOT be surrounded by single-quotation marks.

 

Procedure

  1. Start the transaction merep_sbuilder
  2. Enter the SyncBO ID
  3. Choose Environment -> Filtering criteria
  4. Set filtering criteria for each tab if necessary
  5. Choose the Save icon from the application bar or Ctrl + S

Displaying the Data Model (Meta-data)

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.

Procedure

  1. Start the transaction merep_sbuilder
  2. Enter SyncBO ID
  3. Choose the Meta-data icon from the application bar or Ctrl + F6.
    This will display the meta-data on the screen.

Example

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.

Generating the Meta-data XML file

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.