cancel
Showing results for 
Search instead for 
Did you mean: 

Significance of sync key for a Sync Bo

Former Member
0 Kudos

Hi,

What is meant by the sync Key in MI Client application. How is it used to identify a particular sync BO instance.

Is it the same as that of the key field selected in the syncbo mapping.

If the syncbo has multiple key fields what would be the sync key in the application

Regards

Raja Sekhar

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Raja,

A synckey is unique key generated internally either on the client or the middleware depending on where the syncBo instance was created.

It is not any field/key of the syncBo.

It is used for internal processing and the developer need not worry about it.

Kindly get bakc to me if you require any more info.

Regards,

Rahul

Message was edited by: Rahul Gavande

Answers (4)

Answers (4)

Former Member
0 Kudos

hi,

Kishore and Jo, Thanks for your replies.

We have an requirement where the technician creates local orders in Asset management. If we would like to display the list of all the local orders on the device, can we use the sync key < 100000 condition for finding out the locally created orders. Can you provide me the code to find out the same.

Regards

Raja Sekhar

kishorg
Advisor
Advisor
0 Kudos

Hi Raja,

You can query the syncbo instances using the SmartSync query.

just follow like this..

<b>SyncBoDescriptor sbd = descriptorFacade.getSyncBoDescriptor(<syncBoName>);

SmartSyncQueryFactory queryFactory =

SmartSyncRuntime.getInstance().getQueryFactory();

RowDescriptor rd = sbd.getTopRowDescriptor(); // For top row

//RowDescriptor rd = sbd.getRowDescriptor(<010 or 020 like that>); // for particular items 010;

FieldDescriptor fdPayType = rd.getFieldDescriptor("SYNC_KEY");

String synKey = "0000100000";

Condition cdSyncKey =

queryFactory.createCondition(fdSyncKey, RelationalOperatorType.LOWER_THAN,

synKey);

Query syncBoQuery = queryFactory.createQuery(sbd, cdSyncKey);

MeIterator iteratorSyncBos = dataFacade.getSyncBos(syncBoQuery).iterator();</b>

This MeIterator instance you have to handle properly in the TableController.java file

Regards

Kishor Gopinathan

Former Member
0 Kudos

Hi,

Thanks for all the replies.

Few more queries

1.

In the client app, there is a function modifyRowinDB which is used to modify the syncbos.

public void modifyRowInDB(String syBName,String syncKey,

String newValue,int col);

I assume that this function needs to be invoked to change a particular syncbo.

For example, there are a lot of work orders downloaded to the mobile device.

I open one work order and update it. Should I call this function to update the corresponding syncbo representing that work order. If yes, do I need to know the sync key to update it.

2. How is the syncbo organized in the mobile device. What is the significance of rows?

Does each row represent one instance of syncbo.

I assume that each row will have a header and multiple items.

For example each work order would be a row in the work order syncbo.

The fields declared in the getlist bapi wud be part of header and fields in the Getdetail bapi be the items.

if Getdetail bapi consists of fields from different tables, how are these mapped to the item.

Please validate my understanding

Regards

Raja Sekhar

kishorg
Advisor
Advisor
0 Kudos

Hi Raja,

<<<1>>>

Anyway u will not have any difficulty to find out the SyncKey. It is coming as the first field of the SyncBO instance ,whether it is an item instance or header instance.

just go throught this..

For modifying one syncbo instance ,

in the meRepMeta.xml file corresponding to that SyncBo , allowModify="true".This must be satisfied.

For modifying one syncbo instance , u can do it like described below..

Here u must need the sync key of the header .u have to find out this sync key using one of the standard methods(first entry of a row is sync key of that sync bo instance).

Then to modify the header instance .

-


1) u can use the standard method <b>modifyRowInDB</b> . here the input parameters are SyncBo name , Sync Key , Value and index of the Column. But the limitation of this method is ,if u have more than one field to modify , then u have to use this method inside the loop. In this method , we are explicitely calling the commit() method . So during looping if one of the modification fails for particular sync bo instance , then we have to manually do the rollback for the previous transactions.

we can change the method like this..

public void modifyHeaderOfSyncBo(String syncBoName,String syncKey,String headerFieldNames[],String headerFieldValues[])throws SmartSyncException, PersistenceException

{

SyncBo syncBo = getSyncBoInstance(syncBoName, syncKey);

SmartSyncTransactionManager transactionManager;

transactionManager = dataFacade.getSmartSyncTransactionManager();

if (!transactionManager.isTransactionStarted())

transactionManager.beginTransaction();

for (int c = 0; c < headerFieldNames.length; c++) {

setHeaderFieldValue(syncBo, headerFieldNames[c], headerFieldValues[c]);

}

//Commit the transaction

transactionManager.commit();

}

To modify the Item Instance

-


In two ways

-


1) If we know the sync key of the header and there is only one item instance.

Here using the header Sync key , we have to find out the SyncBo instance -->> then find out the item instance / instances

-->> then modify the item.

public void modifyItemOfSyncBo(String syncBoName,String headerSyncKey,String itemName,String itemFieldNames[],String itemFieldValues[])throws SmartSyncException, PersistenceException

SyncBo syncBo = getSyncBoInstance(syncBoName, headerSyncKey);

Row [] itemRows = getItemInstances(syncBo,itemName);//this is the standard method.

// itemRows[0] is the one and only item instance

SyncBoDescriptor sbd =

descriptorFacade.getSyncBoDescriptor(syncBoName);

RowDescriptor rd = sbd.getRowDescriptor(itemName);

SmartSyncTransactionManager transactionManager;

transactionManager = dataFacade.getSmartSyncTransactionManager();

if (!transactionManager.isTransactionStarted())

transactionManager.beginTransaction();

for (int c = 0; c < itemFieldNames.length; c++) {

FieldDescriptor fdDesc = rd.getFieldDescriptor(itemFieldNames[c]);

setItemFieldValue(fdDesc, itemRow[0], itemFieldValues); // this method is given below

}

transactionManager.commit();

}

2) If we know the Sync key of the item instance.

Here what u have to do is find out the particular sync bo item instance and then modify as mentioned above.

Here we know the Sync Key of the item instance ,so here we will get the exact item row instance.So after retrieving the item row instance just modify this item row instance with new values as mentioned above.

This method is for setting values in item instance.Just follow this method

private void setItemFieldValue(FieldDescriptor fd, Row item, Object value)

throws SmartSyncException, PersistenceException {

BasisFieldType bft = fd.getFieldType();

// integer oprator

if (bft == BasisFieldType.N) {

NumericField nf = item.getNumericField(fd);

if (nf != null) {

BigInteger ii = new BigInteger(value.toString());

// nf.setValue(ii);

item.setFieldValue(fd, ii);

}

}

// charactor operator

if (bft == BasisFieldType.C) {

CharacterField cf = item.getCharacterField(fd);

if (cf != null) {

// cf.setValue(newValues<i><i></i>toString());

item.setFieldValue(fd, value);

}

}

// decimal operator

if (bft == BasisFieldType.P) {

DecimalField df = item.getDecimalField(fd);

if (df != null) {

if (value.equals(""))

value = "0";

BigDecimal bd = new BigDecimal(value.toString());

// df.setValue(bd);

item.setFieldValue(fd, bd);

}

}

if (bft == BasisFieldType.D) {

DateField df = item.getDateField(fd);

if (df != null) {

if (value.equals("")) {

Date syDatum = new Date(System.currentTimeMillis());

value = syDatum.toString();

}

Date dat = Date.valueOf(value.toString());

item.setFieldValue(fd, dat);

}

}

}

<<<<<<<<<<<<<<<<

2. How is the syncbo organized in the mobile device. What is the significance of rows?

Does each row represent one instance of syncbo.

>>>>>>>>>>>>>>>>

Ur understanding is correct. Data is organized in the form of header and item.

One Header instance can have 0 , one or more item instances.

I dont know , how exactly that link is maintained in bw HEADER and ITEM instance. Because i could see only this SYNC_KEY field in the instances.

I think it might be handled by the SmartSync Framework itself.

<<<<<<

For example each work order would be a row in the work order syncbo.

The fields declared in the getlist bapi wud be part of header and fields in the Getdetail bapi be the items.

>>>>>>

Number of rows returned by the GETLIST BAPI Wrapper actually represents the HEADER instances in the SmartSync.

We may have 0 , one or more ITEM instances for particular HEADER instance.

(During Sync , First GETLIST collects all HEADER instances . Then looping though each HEADER instance , corresponding GETDETAIL is executed).

<<<<<<

if Getdetail bapi consists of fields from different tables, how are these mapped to the item.

>>>>>>

I didnt get ur question exactly.

Anyway... ,,

For creating ITEM tables for GETDETAIL , we have to DEFINE one structure , which contain the fields from all tables.

This structure is including as a TABLE parameter of ur GETDETAIL Wrapper. And u will be filling values in these fields that are present in ur STRUCTURE which is included as a TABLE param .

While Creating SncBOs using SyncBO Builder , u are mapping ur required fields. Only these fields are visible in the client device. Depending upon the

ugage (i meant whether CREATE Wrapper , MODIFY , DELETE ) , u can create , modify and Delete these instances.

Refer these links also .. I have already given some sample codes in these forums.... refer these .. In the generated code itself , some null pointer exceptions are not handled.

In this sample code , that is handled..

Regards

Kishor Gopinathan

Former Member
0 Kudos

hello raja,

in a very brief description, it is a unique synchronization

key for every SyncBo instances of a specific device.

existing SyncBo instances downloaded to the client device

during the initial sync has a global synckey which is

usually is greater than 100000 while those SyncBo

instances created from a certain device will be assigned

with an incremented integer from 0000000001 uniquely and

is mapped on the MW with its global key...

regards

jo

kishorg
Advisor
Advisor
0 Kudos

Hi Jo,

<<usually is greater than 100000 while those SyncBo

instances created from a certain device will be assigned

with an incremented integer from 0000000001 uniquely and

is mapped on the MW with its global key...>>

Jo , how that value is stored in the MI Client. Is there any repository for storing values like this ?.

one more doubt ..

In the client , corresponding to each header and item instances , we can see the SYNC_KEY and other mapped fields and no other fields are there to map the relation between one header and its item instances . Using the SmartSync API , we can query the items instances of a header instance using header's syncKey. Where that relation is maintained ?.

While Sync also , we can see , if one modification is there for one item instance , then the corresponding header instance and its modified item instance is passed to the client device. But i have not yet found any fields that is linking the particular header and item instance ? . how this also maintained..

Regards

Kishor Gopinathan

Former Member
0 Kudos

hello kishor,

the synckey value of the SyncBo instances that are downloaded

to the client during the INITIAL data download have the

global key value i.e. value greater than 100000. if a new

SyncBo instance is created from a client, it will be assigned

with a local key which starts from 000000001 till the Integer.MAX

value. when the SyncBo is uploaded into the MW, it is

assigned/mapped with the global key. so every devices

uploading a new SyncBo instance having the same 0000000001

value won't have any conflict... the mapped global key for

locally created instances are not kept in the client; it

is only in the MW. the middleware checks the synckey value

of an updated instance if it is local (i.e. < 100000).

does this answer your question?

regards

jo

kishorg
Advisor
Advisor
0 Kudos

Hi Jo,

thanks for your valuable answer.

i have (Raja too) one more doubt.

In the client , corresponding to each header and item instances , we can see the SYNC_KEY and other mapped fields and no other fields are there to map the relation between one header and its item instances . Using the SmartSync API , we can query the items instances of a header instance using header's syncKey. Where that relation is maintained ?.

While Sync also , we can see , if one modification is there for one item instance , then the corresponding header instance and its modified item instance is passed to the client device. But i have not yet found any fields that is linking the particular header and item instance ? . how this also maintained..

Regards

Kishor Gopinathan

Former Member
0 Kudos

hello kishor,

>But i have not yet found any fields that is linking the

>particular header and item instance?

the header and child records are linked using the persistence

APIs. you can have a look at the

com.sap.ip.me.api.persist.core.PersistedObject

for details.

regards

jo

kishorg
Advisor
Advisor
0 Kudos

Hi Raja,

A SyncBO has a single technical key field for each header and item structure . This is called SYNC_KEY.

It is a specific key field created by the MI Server or by the MI client.It is used by the Smart Sync framework to uniquely identify instances of a SyncBO.

In the MI server , corresponding to particular mobile ID (this is for an application and user) and paricular SyncBO , this can varry. This is purely a number generator in the in the MI server .

MI server is keeping the details of the last Sync key generated for a mobile id. We have RFC's to find out that.

But in the client device , SyncKey generation start from

0000000001 itself. This will heppen at the time of creation of the first instance of a sync bo in the client device.

After exporting the metadata , we can see that , that SYNC_KEY is also included in the metadata of the SyncBo header and item.

Regards

Kishor Gopinathan