Clarification. The timestamps on the central server are GMT. POS terminals are all in their local timezones. So we do get into a bit of trickiness around timestamps I think.
Here is the summary of what I'm doing: To setup the pull I create an entity sync record on the source (MCS) I load the recurrence rule and job on the target (POS) The pull launches, and sucks everything down from the server based on the EntityGroup defined on the MCS. During this process it appears as though the records are written to POS with the server timestamp. The sync process does not seem to change the timestamp to the local time on the POS terminal. This seems to be OK for data that is only pulled, because the next job that runs a pull will depend on logic running on MCS to determine what records to send down to POS. But then when we trigger the push, some entities are synched both ways, such as inventory. We did have one situation where inventory was overwritten on MCS with bad data. My theory is that the POS terminal pulled that data from the server initially with the server timestamp. Then on the push, since the server timestamp was in the future, the push process picked up those records as having been changed. This might explain why our initiial push takes forever. The pos terminals may be sending everything back to the server. I'll try setting all machines to the same timezone and see if it stabilizes the process. ----- Original Message ----- From: "David E Jones" <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, December 7, 2007 10:57:34 AM (GMT-0700) America/Denver Subject: Re: Strange behavior with Entity Sync Yeah, it doesn't sound like it's a time zone problem. As long at the timestamps in the databases are all GMT then it shouldn't be a bit deal. There could be other things going on though, like the last updated stamp for a certain record on the target server could be more recent than the one on the source server (if seed/initial data was loaded on the source and then on the target, even if the source was updated before the target was loaded) then it would not write the record. Of course, if that happens it will tell you that it did that and you'll at least see it in the summary numbers that come back from the remote call. It sounds like you have things far enough along that the only way to progress is with elbow grease. In other words pick a couple of records that you think should be transfered over but that are not getting copied, and then look at the data (on both source and target if applicable) and read through the code to see exactly what it would do with that data. -David On Dec 7, 2007, at 10:27 AM, Vince M. Clark wrote: > I don't know for sure that we are dealing with a timezone issue. > That is just one theory as we try to iron out some problems with > entity sync. The fact that the same records always seem to be > problematic gives us a pattern to pursue. I'll update the thread as > we research the problem. > > ----- Original Message ----- > From: "Adrian Crum" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, December 7, 2007 10:33:19 AM (GMT-0700) America/Denver > Subject: Re: Strange behavior with Entity Sync > > I don't know if the recent time zone work would have any affect on > this. It's a possibility. > > I'm not familiar with POS and entity sync, so I'll describe the > changes I made and maybe others who > are more familiar with Vince's setup can figure it out. > > The basic concept is: > > 1. Date/time String in UI (user's time zone) gets converted to > TimeStamp (which is referenced to > GMT), then it is stored. > 2. TimeStamp in storage (GMT) gets converted to date/time String for > UI (user's time zone). > 3. Only the screen widget and Freemarker template code was changed. > > You shouldn't have to set all of your terminals to the same time > zone as the server. If the problem > is in OFBiz, we should fix it. > > -Adrian > > > Vince M. Clark wrote: > >> Yes. I pulled it from trunk about a week ago. >> >> ----- Original Message ----- >> From: "Jacopo Cappellato" <[EMAIL PROTECTED]> >> To: [email protected] >> Sent: Friday, December 7, 2007 8:36:18 AM (GMT-0700) America/Denver >> Subject: Re: Strange behavior with Entity Sync >> >> Hi Vince, >> >> are you running a recent OFBiz revision? >> I guess that Scott asked you about the timezones because we have >> recently refactored the way datetimes are treated in OFBiz: Adrian >> Crum >> worked on this, and he could better explain, but the idea is that >> when a >> date field is edited it is converted from the user session locale >> to the >> system locale. >> I think that Scott could be right... Adrian, do you think that your >> work >> could have caused some side effects on the entity synch stuff? >> >> Jacopo >> >> >> >> Vince M. Clark wrote: >> >>> It could be a timezone issue. We will test a bit more and try to >>> nail down a pattern. We can isolate the problem to the same set of >>> records that always get pulled incomplete. >>> >>> The server is set to GMT and all the POS terminals are mountain. >>> When first setting up sync I had some difficulty getting the PULL >>> to start running and suspected it was due to the timezone being in >>> the future on the server. But we got past that. >>> >>> Given that we will have terminals in all US timezones it is not >>> really a good option to set them all to the same time as the server. >>> >>> ----- Original Message ----- >>> From: "Scott Gray" <[EMAIL PROTECTED]> >>> To: [email protected] >>> Sent: Thursday, December 6, 2007 11:32:11 PM (GMT-0700) America/ >>> Denver >>> Subject: Re: Strange behavior with Entity Sync >>> >>> Just a stab in the dark but do these issues arise if the server >>> and terminal >>> are in the same timezone? >>> >>> Regards >>> Scott >>> >>> On 07/12/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote: >>> >>>> BJ - your question is not ignorant, but I have no idea how to >>>> answer. >>>> We'll have to depend on others in the community much smarter than >>>> us. >>>> >>>> Entity Sync is a feature available in the system. We are using it >>>> and I >>>> can only assume that it works if configured properly. I have >>>> figured out the >>>> basics of push and pull synchronization. That is about as much >>>> intelligence >>>> as I can claim. >>>> >>>> I can get into the details of what I loaded and where if >>>> necessary, such >>>> as EnityGroup, EnittySync, RecurrenceRule, etc. >>>> >>>> ----- Original Message ----- >>>> From: "BJ Freeman" <[EMAIL PROTECTED]> >>>> To: [email protected] >>>> Sent: Thursday, December 6, 2007 4:35:09 PM (GMT-0700) America/ >>>> Denver >>>> Subject: Re: Strange behavior with Entity Sync >>>> >>>> ignorant question >>>> does not entity sync mess up the accounting. >>>> how are the ecas that are suppose to fire based on certain >>>> services, >>>> that do CRUD of the entity suppose to fire? >>>> >>>> am I missing some documentation on how this works? >>>> >>>> >>>> Vince M. Clark sent the following on 12/6/2007 1:58 PM: >>>> >>>>> We are using entity sync to keep POS terminals and a central >>>>> server >>>> >>>> synchronized. We are going direct from POS to MCS, no Per Store >>>> Server >>>> involved. We have a pull sync (MCS to POS) and a push sync (POS >>>> to MCS.) >>>> Some data such as inventory is going both ways. >>>> >>>>> A few issues: >>>>> 1) Records deleted on MCS are not deleted on POS. >>>>> 2) Pull sync is not getting complete records in some cases. Two >>>>> entities >>>> >>>> we see this consistenly is on Facility and InventoryItem. We get >>>> partial >>>> records sometimes. Note that this only seems to occur on the >>>> initial pull >>>> when we are first populating a new POS terminal from the central >>>> server. >>>> Once we identify a record, such as a facility, that didn't come >>>> down >>>> completely we can update the timestamp on the server and the next >>>> pull gets >>>> the complete record. >>>> >>>>> 3) Related to item 2. If a push occurs from the POS terminal >>>>> BEFORE we >>>> >>>> get the initial data correct, it overwrites the data on MCS. For >>>> example, if >>>> a facility record was pulled down and the store id is missing >>>> then when the >>>> terminal push occurs it trashes the facility record on the >>>> server. Strange >>>> thing is we aren't pushing facility data, only pulling. >>>> >>>>> Note that the server time is different than the terminals >>>>> (different >>>> >>>> timezones.) >>>> >>>>> Vince Clark >>>>> Global Era >>>>> The Freedom of Open Source >>>>> [EMAIL PROTECTED] >>>>> (303) 493-6723 >>>>> >>> >> >> >
