Rows 1-300 and 300-500 good, work 1-500 bad

[Former Member]

Hi, i have one syncbo ONLY of type S01... I sync rows 1-500 but appear in column I-Partial... So, i change the code for row 1-200, sync and work fine... After, i chang the code for row 200-500, sync and work fine... But row 1-500 appear in I-Partial, what coould be the problem?

Thanks,

[Former Member · Accepted solution]

Hi VIctor,

You will get the data in I partial for S01 when ever you have large number in records in Backend.So one option is you should try to optimize you code.You can execute the FM in the backend and check how much time its taking to get you the output.

Second you can try to define some filter criteria in backend or use mobile group in Middleware to limit the amount of data .

Third Are you uing the application on PDA via GPRS?Please check the bandwidth or try via USB too..

fourth:implementing distributor might help to download data on a periodic basis rather than downloading it directly..

Thanks

Regards

Devendra

[Former Member · Accepted solution]

The problem is... sometimes appear problems in SyncBO 1, other in Syncbo 4, other in Syncbo5...

I´m using WIFI and USB, appear problems in PC or in PDA...

Now appear an error because i sync in auto sync with about 2000rows...

Thanks,

[Former Member · Accepted solution]

Hi Victor,

The background sync overlapping shouldnot be a problem..The issue can be amount of data you are trying to download,networkspeed and performance of function modules in the backend.So i suggest you to execte the getlist FM in the backendc for which there are 2000 records and check the time taken.

Then wither change the syncBO type ..either use T01 ,T51 or try some flter criteria in Middleare to restrict the amount of data.On PDA you should be verycarefull reagrding amount of data download...

Thanks

Regards

Devendra

[Former Member · Accepted solution]

Hi Victor,

the problem is you implementation and S01 type....... as I described a few times above. The rest is just making it a little more stable, but does not solve the issue!

Ok, there are a ew things in the last posts you should try to understand before we proceed - cause this should give you a better understanding why error occures in different BOs.

There was the sentence: --- run the handler in the backend, calculate how long it takes -

---

see that: as I described earlier: you are running 500 requests. 500*2sec - just nearly 2 minutes handler runtime in the backend. On top: processing, network traffic, persist, overhead,....... You end up easily with 5-10min. just for one BO in processing - PER SYNC and PER DEVICE and PER BO!!!!! So: 10 devices sync - 100minuts processing time!!!!!!!!!!!!!!!

Change the type of BO to T51 or T01!!!!!!!!

In both cases you can handle the select by user and the request time for 10 devices by 500 entris goes down to perhaps 10min........

It is not the connection between device and middleware! It is the type of BO in the backend and the way of the process. So: check there!

All other issues are caued by this problem described above!

If you need 10min - your MI client runs into a sync timeout - then an error is thrown that is not cought clearly and then the complete processing stops. You realise that with items standing in I-PARTIAL for ages for example.

So: change the type of bo to be able to handle this amount of data. S01 is for less then 100 items that change extremely often and where you need these changes immediately on the deice. All of that is not the cse in your scenrio!

Regards,

Oliver

[Former Member · Accepted solution]

And what could be the time in T51?

Thanks,

[Former Member · Accepted solution]

For 500 entries? Usually less then 1 min - cause all data is alreay on the middleware!

[Former Member]

Hi Victor,

Also please check if there are any dumps in ST22.

Thanks

Regards

Devendra

[Former Member]

Hi,

why S01???

Have in mind:

T01 for example has all data in Middleware. So the select goes just to the middleware and the data is there immediately.

S01: go backend - run GETLIST - then run a loop from 1 to 500 and select details for each of these 500 entries - get them directly form the backend and then store them in MI for sync to device.

Well, in that behaviour it is clear, it takes a while to process it. So it runs into a timeout. You can check the timeout settings inside J2EE - well, basis has to do that, cause it is in the admin tool of J2EE.

But even with higher timouts zou have to wait ages for the result. Change the BO type to T01 or T51 - that will cure the issue.

Regards,

Oliver

[Former Member]

I´m in admin tool, but, Where parameter in timeout settings??

Thanks,