Exception : SyncBo is IN_SYNC: CHANGED_GLOBAL_INSYNC

[Former Member]

Hi ,

Right now we are facing a problem in our SmartSync MI application while modifying an item instance of one of the SyncBO. For that particular syncbo , we have only one header instance and a number of item instances.And the another thing is , there is a chance for the modification of same data both in the MI client and MI server(back end) , hence a chance for conflict while synchronizing.

But in the application (using mi_msd) , we have checked the "Framework" by default, against the Error handling and Conflict handling ,and "Data consolidated by client" in the View of Synchronizer Business Object data for data-facade.

Actually we got a conflict while syncing for this particular syncbo.At this time the server side data overwrites the client data.But the problem is , for the consecutive syncs , the delta determination is working perfectly in the MI server end ,but that changes are not reflected in the MI client device.In the outbound worklist , we can see the status as "S" for this delta data.

<u>From the MI client trace ,,</u>

<b>Start Processing message with processor TOP_DELTA_MODIFY using PersistenceWriter

[20060808 10:15:58:640] D [MI/Persistence ] PersistenceManagerImpl.get(IClassDescriptor,IAttributeDescriptor,Object):(IClassDescriptor(Name: cZSYNCBO_TOP)),(IAttributeDescriptor(Name: state)),18687574

[20060808 10:15:58:640] I [MI/Smartsync ] Ignoring modify message for SyncBo cZSYNCBO_TOP with key 18687574 because SyncBo is IN_SYNC: CHANGED_GLOBAL_INSYNC</b>

<u>From application ,,</u>

<b>

The same exception is getting while modifying the particular syncbo using our application.

com.sap.ip.me.api.smartsync.ModificationNotAllowedException: Creation on Field cZSYNCBO_020_UNRESTRICTED with value 250 is not allowed because SyncBo of Row 0018687739 is CHANGED_GLOBAL_INSYNC and CreateInputQualifyType is FORBIDDEN.</b>

But after sync, the status of the outbound worklist for the last sync response is replaced with "S".But we got the above mentioned exception in the MI client device for the last worklist data. But why the status changed to "S" in the MI server end even if the modification of the same data failed in the MI client end. Could it be a bug?. How can we assure the security of data here?

We are using error handling in our application. From this we can see the SyncStatus as INCONSISTENT for this particular syncbo.

We are sure that , we are using the code for modifying the particular Item instance.I tried to search for the same problem in SDN. But we have not yet discussed this type of problem in the SDN except the one which is not valid in this context.

Thanks & Regards

Aryan

[Former Member]

There is probably a bug in SAP code. Particularly

com.sap.ip.me.smartsync.data.AbstractRow

Method: protected boolean verifyFieldInputQualifierType(FieldDescriptorImpl field, Object fieldValue)

throws ModificationNotAllowedException;

[Former Member]

hello aryan,

first regarding the ModificationNotAllowedException,

i think this is because the field UNRESTRICTED has a

FORBIDDEN CreateInputQualifyType defined in your metadata.

try removing it.

second regarding the ignored modify messages.

i think this is by design. when the error/conflict is set

to framework_resolve, server state always wins. this is

just what you have described. in case when the client uploaded

an update at the same time receive a modify message from

the server for the same syncBo instance, the framework will

not process this message since the instance is in INSYNC

state. this is actually a conflict which is detected on

the client. but the framework will not handle this rather

it will wait for the server's response since the delta

uploaded into the MI server will cause a conflict.the

server will send a conflict message with the latest image

of the SyncBo instance. it's this conflict message response

that the framework will process and replace the client

data with the server image. that's why you will see this

kind of logs in your trace file.

take note that there is a row merge feature in MI as well

which is only applicable on certain conditions and when

enabled. for example, adding an item to a SyncBo in the

client and adding an item as well for the same SyncBo

instance in the server will not cause a conflict, rather

they will be merged and the latest SyncBo image will be

sent to the client.

just a clarification:

you first mentioned,

>But in the application (using mi_msd) , we have checked

>the "Framework" by default, against the Error handling

>and Conflict handling ,and "Data consolidated by client"

>in the View of Synchronizer Business Object data for

>data-facade.

then

>We are using error handling in our application. From

>this we can see the SyncStatus as INCONSISTENT for this

>particular syncbo.

is your MCD for ERROR set to application_resolve and

CONFLICT to framework_resolve?

lastly, which version of MI are you using?

regards

jo

[Former Member]

Hi Jo,

Thanks ..

Sorry to mention the SP levels in the previous post.

We are using MI 2.5 SP 15 in our MI server and MI client.

<<

s your MCD for ERROR set to application_resolve and

CONFLICT to framework_resolve?

>>

Both Error and Conflict handling is FrameWork Controlled.

Our application has the facility to dispaly the Status of all the SyncBos. From this we can find the status of each syncbo after each sync.

<<<

first regarding the ModificationNotAllowedException,

i think this is because the field UNRESTRICTED has a

FORBIDDEN CreateInputQualifyType defined in your metadata.

try removing it.

>>>

In our MODIFY BAPI Wrapper , we have mapped the field.

But im still in doubt , what u meant with<b> FORBIDDEN CreateInputQualifyType</b> ?..

Regards

Aryan

[Former Member]

hello aryan,

i mean that your field has the following child element in

it. <Input type="create">false</Input>

when you create a syncBo i.e. LOCAL state and try to

modify its field having this attribute which is

FORBIDDEN, you will get this exception.

the same thing applies also when the SyncBo is in INSYNC state. both the create and modify input types are being

checked.

regards

jo

[Former Member]

Hi Jo,

Thanks.

For this SyncBO , we have only GETLIST , GETDETAIL and MODIFY Bapi Wrappers (without create) since we are not creating any fresh instances from the MI client itself.

But we have to modify the particular instance , which is coming from the Back End.

We cross checked our meRepMeta.xml(metada file) file with what u have mentioned in your last reply.From that we found that ,

<SyncBO id="ZSYNCBO" version="13" type="twoWay" allowCreate="false" allowModify="true" allowDelete="false" reqDirectSync="false" downloadOrder="12">

....

- <Field name="UNRESTRICTED" type="P" length="15" decimalLength="3" signed="true" isKey="false" isIndex="false">

<Input type="create">false</Input>

</Field>

....

....

</SyncBO>

But it was working properly in normal cases except in this conflict situation.

Any clues ?.

Regards

Aryan

[Former Member]

Hi Jo,

Thanks.

We have almost solved the problem by editing the meRepData.xml file and upload the WAR file with this updated meRepMeta.xml. We have found out that , MI client is using the .dat files which are located in the .../data/<Conversation ID of the particular MCD>/(meta_childRow.dat ,meta_field.dat,meta_field.dat) while running the application.(which has been created using the meRepMeta.xml file present in the WAR file at the time of downloading the application ).

In this case , the metadata present in the MI Client and the MI server are different. So we have to confirm whether this will create some problems in future.

Regards,

Aryan

[Former Member]

Hi Aryan & Jo,

I am having a problem similar to this.

Aryan, is your problem solved now? please let me know how you did it?

Regards

Divya

[prashantha_hj]

Hi Aryan,

Just a small info, There is no need to redeploy the client after replacing the xml file. A client data reset will do. It will reprocess the xml file and creates new dat files.

Regards,

Prashanth

[Former Member]

Hi Prasanth,

If i regenrate and store it in same place while at the time of creation of application, then what you say is correct.

Just tell me if i have regenerated the .xml and have changed the location of it, then how will i reflect this settings in MI framework.

divya

[prashantha_hj]

Hi Divya,

You need to put the xml file the /MIHOME>/webapps/<APP> directory and do a client data reset. The MI will always search in this place for processing the xml file.

You cannot change this location and it should be always in the above specified directory.

Regards,

Prashanth

[Former Member]

Hi Prashantha,

I am getting

Creation on Field cZMI_ASSG1_010_STATUS with value Processing is not allowed because SyncBo of Row 0001000476 is CHANGED_GLOBAL_INSYNC and CreateInputQualifyType is FORBIDDEN

can you please explain this exception.

This SyncBO has Modify BAPI wrapper. at the field name it says

<Input type="create">false</Input>

but the syncBO has allowModify="true"

am I getting error bcoz create at Field level is 'false'

pls correct me at this.

Aryan: is your problem solved? if yes, will you tell us how?

Message was edited by:

Divya Sarraju

[prashantha_hj]

Create and modify is in respect of the SyncBo and not of the child Row.

This means changing a field (also on child Row) of a global SyncBo is a modifcation while changing a field (also on child Row) of a local SyncBo is a creation.

If you want to create the field, allowCreate=true.

Regards,

Prashanth

[Former Member]

Hi Prashantha,

That really helped.let me summerize.

1. I was trying to create a new item while allowCreate=false.

2. so I alternatively set some default value to the field in the table and run the same code which is now working.

Regards

Divya