|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Как задавать сдвиг времени в функциях, принимающих промежуток времени в качестве параметра  XML
Индекс форума » Компонент МЕРКУРИЙ
Автор Сообщение
ПользовательRex


Зарегистрирован: 06/06/2017 07:48:13
Сообщений: 38
Оффлайн

Добрый день!

Скажите, пожалуйста, какой сдвиг времени нужно задать в ситуации, когда я меняю остатки на складе и хочу узнать последние изменения с помощью GetStockEntryChangesListOperation v2.0.
Например, выписываю тр ВСД в Уфе в 12.02.2018T13.30.10+???? , если 13.30.10 - это местное , Уфимское время.
Что нужно написать вместо ????, чтобы получить изменившиеся складские записи за интервал 12.02.2018T13.20.10 - 12.02.2018T13.40.10 по Уфе?
Vladimir2017

[Avatar]

Зарегистрирован: 02/10/2017 14:31:03
Сообщений: 362
Оффлайн

ПользовательRex wrote:Добрый день!

Скажите, пожалуйста, какой сдвиг времени нужно задать в ситуации, когда я меняю остатки на складе и хочу узнать последние изменения с помощью GetStockEntryChangesListOperation v2.0.
Например, выписываю тр ВСД в Уфе в 12.02.2018T13.30.10+???? , если 13.30.10 - это местное , Уфимское время.
Что нужно написать вместо ????, чтобы получить изменившиеся складские записи за интервал 12.02.2018T13.20.10 - 12.02.2018T13.40.10 по Уфе?


Берите московское время, отмеряйте сутки назад и скачивайте все что выдаст. Старые записи обновляете, новые добавляете. Можно работать по updateDate последней записи, но я не очень доверяю датам и времени в Меркурии.
lalex23


Зарегистрирован: 10/03/2016 14:26:10
Сообщений: 375
Оффлайн

Vladimir2017 wrote:
ПользовательRex wrote:Добрый день!

Скажите, пожалуйста, какой сдвиг времени нужно задать в ситуации, когда я меняю остатки на складе и хочу узнать последние изменения с помощью GetStockEntryChangesListOperation v2.0.
Например, выписываю тр ВСД в Уфе в 12.02.2018T13.30.10+???? , если 13.30.10 - это местное , Уфимское время.
Что нужно написать вместо ????, чтобы получить изменившиеся складские записи за интервал 12.02.2018T13.20.10 - 12.02.2018T13.40.10 по Уфе?


Берите московское время, отмеряйте сутки назад и скачивайте все что выдаст. Старые записи обновляете, новые добавляете. Можно работать по updateDate последней записи, но я не очень доверяю датам и времени в Меркурии.

у меня площадки в разных временнЫх зонах, МСК, МСК+1, МСК+2, в любой из зон при получении запроса период определяю как:
начала интервала = дата окончания предыдущего запроса - 4 часа
окончание интервала = текущее время + 4 часа
дальше как написал коллега - обрабатываем актуальные записи

Это сообщение было редактировано 1 раз. Последнее обновление произошло в 12/02/2018 15:28:50

Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

lalex23 wrote:окончание интервала = текущее время + 4 часа

Это-то зачем? Не указывайте вовсе - придет "до последней записи".

2 Vladimir2017: вот как раз тут я бы Меркурию вопрос с датами на откуп отдал. В противном случае нужно не -4 часа ставить, а "начиная с Петропавловска Камчатского", в котором, как известно всем радиослушателям, полночь.

Кстати, если считать, что Меркурий содержит местное время (да Боже ж ты мой! Это в документации (ась? что это такое? не, не слышали) должно быть написано, а не догадываться совместным конвульсиумом интеграционщиков), получится такая каша:

1. Некий ХС из Петропавловска Камчатского отправляет Вам партию продукции, его время +9 от Москвы, например, это оказалось 17 часов (в Москве - 17-9=8 утра).
2. Некий ХС из Москвы отправляет Вам партию продукции, например, в 10 утра.
3. Вы в Москве читаете записи (от предыдущего (какого-то) -4 часа), получается 6 утра, Вам приходит запись из Петропавловска (17 часов) и Москвы (10 часов).
4. Некий ХС из Калининграда отправляет Вам партию продукции, его время -1 от Москвы, например, это оказалось 11 часов (в МСК - 10).
5. Вы в Москве читаете записи (от предыдущего (максимальное время в базе - 17 часов, Петропавловск) -4 часа), получается 13 часов, Вы теряете запись из Калининграда (там было 10 по местному, а Вы читаете от 13 часов).

Это сообщение было редактировано 1 раз. Последнее обновление произошло в 12/02/2018 15:51:28

lalex23


Зарегистрирован: 10/03/2016 14:26:10
Сообщений: 375
Оффлайн

Владимир Игнатов wrote:
lalex23 wrote:окончание интервала = текущее время + 4 часа

Это-то зачем? Не указывайте вовсе - придет "до последней записи".

объём получаемого пакета, при большом числе транзакций - пухнет как но дрожжах,
в какой-то момент я ради проверки корректности работы получения изменений запустил на тесте два запроса:
получение изменений от начала времён и получение актуального списка записей, затем сравнивал результаты
как это не странно - совпали результаты, но таким дроблением промежутков я гарантирую себе более-менее вменяемый пакет от сервера.
в любом случае - не человек же тыркает кнопку, а регламентное задание трудится
Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

lalex23 wrote:
объём получаемого пакета, при большом числе транзакций - пухнет как но дрожжах,
в какой-то момент я ради проверки корректности работы получения изменений запустил на тесте два запроса:
получение изменений от начала времён и получение актуального списка записей, затем сравнивал результаты
как это не странно - совпали результаты, но таким дроблением промежутков я гарантирую себе более-менее вменяемый пакет от сервера.
в любом случае - не человек же тыркает кнопку, а регламентное задание трудится

А Вам в любом случае придет только <bs:count> документов, которые Вы заказали. Следующий пакет запрашивать отдельно, с нового <bs:offset>. Кроме того, Вы же изменения "от начала времен" не выкидываете, значит, в след. раз приедет меньше записей. Так постепенно все и выкачаете. Ну, я выкачал же. И теперь - пара минут на актуализацию.
Vladimir2017

[Avatar]

Зарегистрирован: 02/10/2017 14:31:03
Сообщений: 362
Оффлайн

Владимир Игнатов wrote:2 Vladimir2017: вот как раз тут я бы Меркурию вопрос с датами на откуп отдал. В противном случае нужно не -4 часа ставить, а "начиная с Петропавловска Камчатского", в котором, как известно всем радиослушателям, полночь.


Я один раз столкнулся с тем что не смог выкачать свою же ВСД используя такой механизм. Поскольку мы оба должны обновляться с атомных часов, точность которых на три порядка точнее значений времени в БД, это меня слегка смутило

Но вобщем механизм по updateDate правильный, добью тестирование переведу на него, благо подправить надо одну строчку. Но запас все равно нужен, как мне кажется.

Кстати, наверное было бы здорово создать отдельный FAQ для разработчиков, чтобы те кто начнут разработку весной , не ходили по нашим граблям.
Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

Vladimir2017 wrote:Я один раз столкнулся с тем что не смог выкачать свою же ВСД используя такой механизм. Поскольку мы оба должны обновляться с атомных часов, точность которых на три порядка точнее значений времени в БД, это меня слегка смутило

В тестовом контуре была ошибка, что если ЭВСД оформлен, прочитан через API ...ChangesList, а затем аннулирован, он не приходит еще раз при запросе. Т.е., у него не меняется changeDate. Хотя если очистить свою таблицу и принять "от начала времен", такой ЭВСД приходит, и состояние у него "аннулирован".

Vladimir2017 wrote:Кстати, наверное было бы здорово создать отдельный FAQ для разработчиков, чтобы те кто начнут разработку весной , не ходили по нашим граблям.

За ним следить надо, иначе будет как с официальной документацией: нагромождение уже давно протухших сведений и мнений.
 
Индекс форума » Компонент МЕРКУРИЙ
Перейти:   

Powered by JForum 2.1.8 © JForum Team