Сообщения, отправленные пользователем: user100000

Уполномоченное_лицо wrote:
Думаете это кого-то заинтересует?

просто поддерживаю топик и жду когда закончатся "2 недели"

26.09.2018 14:54:50: APLM0012: An unexpected error has occurred while invoking target service operation.
26.09.2018 15:27:39: APLM0012: An unexpected error has occurred while invoking target service operation.
26.09.2018 15:34:45: APLM0012: An unexpected error has occurred while invoking target service operation.
26.09.2018 15:34:51: APLM0012: An unexpected error has occurred while invoking target service operation.
26.09.2018 15:34:56: APLM0012: An unexpected error has occurred while invoking target service operation.
26.09.2018 15:35:02: APLM0012: An unexpected error has occurred while invoking target service operation.
26.09.2018 15:35:08: APLM0012: An unexpected error has occurred while invoking target service operation.
26.09.2018 17:08:55: HTTP/1.1 502 Bad Gateway
26.09.2018 17:22:03: HTTP/1.1 502 Bad Gateway
26.09.2018 17:23:54: HTTP/1.1 502 Bad Gateway
26.09.2018 17:28:10: HTTP/1.1 502 Bad Gateway
26.09.2018 17:29:05: HTTP/1.1 502 Bad Gateway
26.09.2018 17:30:07: HTTP/1.1 500 Internal Server Error
26.09.2018 17:30:12: HTTP/1.1 500 Internal Server Error
26.09.2018 17:32:44: HTTP/1.1 502 Bad Gateway
26.09.2018 17:34:08: HTTP/1.1 502 Bad Gateway
26.09.2018 17:35:54: HTTP/1.1 502 Bad Gateway
26.09.2018 17:35:59: HTTP/1.1 502 Bad Gateway
26.09.2018 17:36:04: HTTP/1.1 502 Bad Gateway
26.09.2018 17:36:10: HTTP/1.1 502 Bad Gateway
26.09.2018 17:36:19: HTTP/1.1 502 Bad Gateway
26.09.2018 17:36:24: HTTP/1.1 502 Bad Gateway
26.09.2018 17:54:54: HTTP/1.1 502 Bad Gateway
26.09.2018 17:58:32: HTTP/1.1 502 Bad Gateway
26.09.2018 17:58:37: HTTP/1.1 502 Bad Gateway
26.09.2018 17:58:50: HTTP/1.1 502 Bad Gateway
26.09.2018 17:58:55: HTTP/1.1 502 Bad Gateway

25.09.2018 2:24:02: HTTP/1.1 502 Bad Gateway
25.09.2018 3:24:45: HTTP/1.1 502 Bad Gateway
25.09.2018 3:38:35: HTTP/1.1 502 Bad Gateway
25.09.2018 5:17:53: HTTP/1.1 502 Bad Gateway
25.09.2018 5:17:58: HTTP/1.1 502 Bad Gateway
25.09.2018 5:30:57: HTTP/1.1 502 Bad Gateway
25.09.2018 6:00:33: HTTP/1.1 502 Bad Gateway
25.09.2018 6:01:40: HTTP/1.1 500 Internal Server Error
25.09.2018 6:01:45: HTTP/1.1 500 Internal Server Error
25.09.2018 6:01:50: HTTP/1.1 500 Internal Server Error
25.09.2018 6:55:37: HTTP/1.1 502 Bad Gateway
25.09.2018 6:57:29: HTTP/1.1 502 Bad Gateway
25.09.2018 7:14:30: HTTP/1.1 502 Bad Gateway
25.09.2018 7:25:44: HTTP/1.1 502 Bad Gateway
25.09.2018 7:29:27: HTTP/1.1 502 Bad Gateway
25.09.2018 7:40:40: HTTP/1.1 502 Bad Gateway
25.09.2018 7:55:31: HTTP/1.1 502 Bad Gateway
25.09.2018 8:05:06: HTTP/1.1 502 Bad Gateway
25.09.2018 8:16:41: HTTP/1.1 502 Bad Gateway
25.09.2018 8:21:04: HTTP/1.1 502 Bad Gateway

если по коду 1602, то оформляется только подсубпозиций 1602311100, 1602321100, 1602392100, 1602501000 и 1602906100

23.09.2018 9:25:30: HTTP/1.1 502 Bad Gateway
23.09.2018 10:24:52: HTTP/1.1 502 Bad Gateway
23.09.2018 10:27:04: HTTP/1.1 502 Bad Gateway
23.09.2018 10:27:09: HTTP/1.1 502 Bad Gateway
23.09.2018 10:33:25: HTTP/1.1 504 Gateway Time-out
23.09.2018 10:35:55: HTTP/1.1 502 Bad Gateway
23.09.2018 11:06:39: HTTP/1.1 502 Bad Gateway
23.09.2018 11:06:44: HTTP/1.1 502 Bad Gateway
23.09.2018 11:15:23: HTTP/1.1 502 Bad Gateway
23.09.2018 11:15:28: HTTP/1.1 502 Bad Gateway
23.09.2018 11:44:47: HTTP/1.1 502 Bad Gateway
23.09.2018 11:44:52: HTTP/1.1 502 Bad Gateway

christoffelsymbols wrote:
Брать нужно последнее время выполнения обмена. А само время запоминать с часовым поясом. Все даты в ВетИС хранятся именно в таком формате.

может последнее и минус пару секунд? или минуту для надежности?

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

user100000 wrote:

Владимир Игнатов wrote:
Я бы тоже указывал +05:00. Между шлюзом и WEB есть задержка. Даже между WEB и WEB есть задержка: из журнала продукции все "списали" в транзакцию, сертификат получили, а в журнале запись еще некоторое время (до минуты у меня) висит. Потом исчезает.

Владимир Игнатов wrote:
Финишную дату можно не указывать, будет последняя запись на сервере. Проблема часовых поясов решается сама, если ведение времени доверить серверу Ветиса, а спрашивать - сначала с 1970-01-01, а затем с последней возвращенной. Тогда максимум "дубли" будут в пределах этой первой секунды. Если только, конечно, у Ветиса между своими серверами время синхронизировано или если сервер один. Иначе может получиться, что разные люди (или шлюзы) на разных серверах добавляют записи по своему локальному времени, но эти записи могут оказаться "в прошлом" для "основного" сервера и, фактически, при запросе "от последней известной секунды" будут потеряны.

как все-таки лучше брать время?
достаточно ли взять период с max предыдущего и до текущего
или все таки взять назад еще несколько минут?

С предыдущего и без указания конечной даты. Получить пакет, оттуда получить количество записей к загрузке.

Ну ты сам пишешь, что возможно там разные сервера могут быть и записи могут оказаться в "прошлом" еще. Может все-таки хотя бы минуту назад брать?

Владимир Игнатов wrote:
Я бы тоже указывал +05:00. Между шлюзом и WEB есть задержка. Даже между WEB и WEB есть задержка: из журнала продукции все "списали" в транзакцию, сертификат получили, а в журнале запись еще некоторое время (до минуты у меня) висит. Потом исчезает.

Владимир Игнатов wrote:
Финишную дату можно не указывать, будет последняя запись на сервере. Проблема часовых поясов решается сама, если ведение времени доверить серверу Ветиса, а спрашивать - сначала с 1970-01-01, а затем с последней возвращенной. Тогда максимум "дубли" будут в пределах этой первой секунды. Если только, конечно, у Ветиса между своими серверами время синхронизировано или если сервер один. Иначе может получиться, что разные люди (или шлюзы) на разных серверах добавляют записи по своему локальному времени, но эти записи могут оказаться "в прошлом" для "основного" сервера и, фактически, при запросе "от последней известной секунды" будут потеряны.

как все-таки лучше брать время?
достаточно ли взять период с max предыдущего и до текущего
или все таки взять назад еще несколько минут?

christoffelsymbols wrote:

user100000 wrote:

Владимир Игнатов wrote:
Финишную дату можно не указывать, будет последняя запись на сервере. Проблема часовых поясов решается сама, если ведение времени доверить серверу Ветиса, а спрашивать - сначала с 1970-01-01, а затем с последней возвращенной. Тогда максимум "дубли" будут в пределах этой первой секунды. Если только, конечно, у Ветиса между своими серверами время синхронизировано или если сервер один. Иначе может получиться, что разные люди (или шлюзы) на разных серверах добавляют записи по своему локальному времени, но эти записи могут оказаться "в прошлом" для "основного" сервера и, фактически, при запросе "от последней известной секунды" будут потеряны.

как все-таки лучше брать время?
достаточно ли взять период с max предыдущего и до текущего
или все таки взять назад еще несколько минут?

Лучше в запросах указывать даты с часовым поясом. Кстати, именно в таком виде они возвращаются через API
Пример: 2013-02-25T18:25:10+03:00

до понятно что с часовым
вопрос в другом
если последний запрос было до 21.02 - то следующий запрос достаточно сделать с 21.02 или взять какой-то период назад

Владимир Игнатов wrote:
Финишную дату можно не указывать, будет последняя запись на сервере. Проблема часовых поясов решается сама, если ведение времени доверить серверу Ветиса, а спрашивать - сначала с 1970-01-01, а затем с последней возвращенной. Тогда максимум "дубли" будут в пределах этой первой секунды. Если только, конечно, у Ветиса между своими серверами время синхронизировано или если сервер один. Иначе может получиться, что разные люди (или шлюзы) на разных серверах добавляют записи по своему локальному времени, но эти записи могут оказаться "в прошлом" для "основного" сервера и, фактически, при запросе "от последней известной секунды" будут потеряны.

как все-таки лучше брать время getStockEntryChangesList?
достаточно ли взять период с max предыдущего и до текущего
или все таки взять назад еще несколько минут?

17.09.2018 22:05:04: HTTP/1.1 500 Internal Server Error
17.09.2018 22:05:45: HTTP/1.1 502 Bad Gateway
17.09.2018 22:05:50: HTTP/1.1 502 Bad Gateway
17.09.2018 22:15:25: HTTP/1.1 500 Internal Server Error

gorlanovmax wrote:На все заявки Контур возвращает 503 ошибку
Ошибка работы с Интернет: сервис не доступен (503)

Причем тут контур?
апи лежал около часа

полчаса уже 503 ошибка

17.09.2018 14:58:06: HTTP/1.1 502 Bad Gateway
17.09.2018 15:00:10: HTTP/1.1 502 Bad Gateway
17.09.2018 17:39:37: HTTP/1.1 502 Bad Gateway
17.09.2018 17:43:57: HTTP/1.1 502 Bad Gateway
17.09.2018 18:45:23: APLM0012: An unexpected error has occurred while invoking target service operation

в 1.4 можно было ставить
"Разрешение ветеринарного управления субъекта на ввоз/вывоз продукции" в
"Сведения о документах"
в 2.0
http://help.vetrf.ru/wiki/DocumentType_v2.0
нету такого теперь
или это "Ветеринарный сертификат на перемещение внутри РФ" ?