Вход | Регистрация

  1  2  3  4  5  6  7  8  9  10  11   

ВетИС уже скоро

Ø [длинная ветка, 16.07.18 - 11:50]
ВетИС уже скоро
Я
   Звездец
 
02.05.18 - 16:38
Ветис уже скоро. А что-то вокруг тишина. В программах даже что-то появилось, а на ИТС ни одной инструкции. Все ждут? или может кто-то что-нибудь делает для подготовки?
 
 
   EuVod
 
901 - 06.07.18 - 13:48
у нас какие-то другие проблемы - не доходит даже до получения APLM - через раз отказывает в http авторизации с 401 ошибкой - как в (837) писал. Никто больше не сталкивается?
может это у нас проблема такая?  (через SOAP GUI тоже самое) - правда это только по справочникам (как минимум на ХС и на единицах измерения). У нас просто часто по ходу получения данных из мерка запросы к справочникам на обновления
   spectre1978
 
902 - 06.07.18 - 13:55
(901) 401 не видел, но вообще HTTP ошибки бывают. 502 чаще всего.
   NSSerg
 
903 - 06.07.18 - 14:01
Я не уверен, но похоже что если в getProductItemByUuidRequest
Подставить реальный GUID товара, то получаем http ответ не 200, а 500.
error code="20022" В реестре РСХН не найдено подходящих наименований продукции.
   NSSerg
 
904 - 06.07.18 - 14:05
В моем случае вместо UUID подставляется GUID товара с  active=false
У нас бывает что вместо GUID поставщик присылает UUID.
Поэтому если запрос на GUID выдал что такого нет, то пробуем проверить не UUID ли это.
По GUID функция вернула что такого товара нет (из-за active=false), а запрос getProductItemByUuidRequest выдает ошибку 500.
   NSSerg
 
905 - 06.07.18 - 14:20
Это уже просто жесть.
А если к GUID добавить еще знак, например я дописал в конец "3", то вместо того чтоб дать нормальный ответ, опять падает с HTTP ответом 500
string value
'57796bf2-ea12-47f4-b3dc-b54f3af1009f3'
does not match pattern for UUID in namespace
   NSSerg
 
906 - 06.07.18 - 14:33
Походу у них действительно сломался метод. Теперь если UUID в базе есть, то отдает всё по формату, с кодом ответа 200, если UUID нет, то получаем код ответа 500, и внутреннюю ошибку сервера.
   NSSerg
 
907 - 06.07.18 - 15:47
Транспортная ВСД. Не знаю есть она или нет, но была выписана 02/07, и был получен GUID ВСД.
Сейчас при попытке получить ВСД по тикету выдает HTTP ответ 500.
Получается я должен и при HTTP 500 обрабатывать полученную XML?
   NSSerg
 
908 - 06.07.18 - 15:58
Они что-ли все старые тикеты порезали в базе?
   spectre1978
 
909 - 06.07.18 - 16:05
хмм... я, честно говоря, никогда и не рассчитывал на то что тикеты будут храниться сколько-то долгое время. Это же невероятный объем мусора. Кому надо - перезапросят.
   NSSerg
 
910 - 06.07.18 - 16:12
(909) Как можно перезапросить?
У тебя при создании транспортной ВСД дается тикет.
Потом по тикету ты получешь GUID ВСД.
Если тикет удален, как ты теперь ссылку на ВСД получишь? Еще одну ВСД выписать?
 
 Рекламное место пустует
   spectre1978
 
911 - 06.07.18 - 16:14
(910) я постоянно мониторю ответы по тикетам и записываю данные сразу как ответ положительный, после чего тикет мне не нужен.
   NSSerg
 
912 - 06.07.18 - 16:15
Я бы с логов поднял обработкой. Но я их стер. :(
Не велика конечно потеря, но неплохо было бы где-нибудь получить полную документацию, в каких случаях HTTP ответ 500, в каких 200. Что хранится на сервере и сколько времени, что уничтожается и т.д.
По уму ошибки 500 быть не должно. Ошибка 500 - то это их внутренняя ошибка.
   NSSerg
 
913 - 06.07.18 - 16:16
(911) А у меня получает номер ВСД в момент печати по тикету, и нигде он не сохраняется.
Конечно допишу чтоб сохраняла, но честно говоря я не понимаю как продукт в таком состоянии можно было запускать в продуктив в масштабах страны.
   Вафель
 
914 - 06.07.18 - 16:21
(912) так они просто xml валидируют, поэтому  (905) и не проходит
   NSSerg
 
915 - 06.07.18 - 16:24
(914) Если дать uuid по формату, но которого нет в базе - то тоже внутренняя ошибка. Хотя это ненормально.
Должна же быть проверка, есть ли uuid в базе, и она не должна падать с ошибкой. А код ответа http 500 - это по сути и есть падение.
   Вафель
 
916 - 06.07.18 - 16:25
(915) тут согласен
   spectre1978
 
917 - 06.07.18 - 16:26
(912) ошибка 500 это ошибка веб-сервера, которая не определена явно другими 5ХХ ошибками. Похоже что они пихнули туда результаты валидации XML, который им приходит в SOAP-пакетах. Собственно, я не вижу причин почему так делать нельзя.
   NSSerg
 
918 - 06.07.18 - 16:27
(917) Потому что так делать не принято.
Это соответствует их описанию, но так не делают.
   spectre1978
 
919 - 06.07.18 - 16:33
(913) я сохраняю UUIDы ВСД. Привязываю их к накладной. Это статическая штука, я думаю что они будут храниться по крайней мере до тех пор, пока существует партия. Что касаемо тикетов - то это та фигня, которая отдается после submitApplicationRequest? Я правильно понял? Тогда я бы не рассчитывал на то что это будет доступно долго.
   NSSerg
 
920 - 06.07.18 - 16:40
(919) Теперь и я сохраняю. А все старые похерены.
   spectre1978
 
921 - 06.07.18 - 16:40
как думается мне, их нужно передавать в некое фоновое задание, которое будет немедленно добиваться по ним ответа. Как только ответ есть - данные записываются в базу, тикет уничтожается. Т.е. есть очередь тикетов, в хвост пристраиваются новые, а голова постоянно очищается путем получения ответов. Как-то так. При завершении программы юзер должен дожидаться чтобы все тикеты были отработаны, иначе ругаться громко и матом - ибо по факту это будет означать что результаты выполнения всех необработанных заявок будут утеряны.
   spectre1978
 
922 - 06.07.18 - 16:45
это я про тикеты. А UUIDы я сохранял изначально. Помимо UUIDов, я подбираю из веток еще кое-какое барахлишко для локальной печати веток (без участия Меркурия).
   NSSerg
 
923 - 06.07.18 - 17:13
(921) Зачем? У меня и так всё отлично работает. Я их в любом случае получаю в момент печати. Без него же не распечатать. Теперь как получил буду сохранять.
(922) И тикеты в любом случае нужно сохранять, если ассинхрон как у меня. Конечно сохраняются.
   NSSerg
 
924 - 06.07.18 - 17:30
Короче в итоге вернул обратно - код 500 у меня опять равносилен либо пустому запросу, либо REJECTED. Даже не разбираю его. Что конечно-же неправильно.
   spectre1978
 
925 - 06.07.18 - 20:11
Вопрос. "Зелененькую машинку" кто-нибудь на API реализовывал? Т.е. возможно ли API двойкой как-нибудь получить все непогашенные входящие? Пока приходит в голову только getVetDocumentListChangesRequest за ближайшие несколько дней и ручками отобрать из массива непогашенные. Но это какое-то извращение...
   spectre1978
 
926 - 07.07.18 - 17:39
Похоже, что ответ на мой вопрос кроется в версии API 2.1. Чует мое сердце, что надо переползать...
   spectre1978
 
927 - 07.07.18 - 21:15
Довольно интересная прессуха, если кто не видел https://www.youtube.com/watch?time_continue=887&v=CCsPt3uNvdg
   spectre1978
 
928 - 08.07.18 - 09:55
По (925) вопрос снят, разобрался
   ProxyInspector
 
929 - 08.07.18 - 14:24
(927) Интересная встреча. Но это только десяток крупнейших производителей и сетей.Каждый из которых вбухал по 100 млн. руб и имеет процент гашения на уровне 30% - 70%. А каково остальным сотням тысяч предприятий. И что будет с системой Меркурий, когда эти предприятия начнут активно работать.
   ProxyInspector
 
930 - 08.07.18 - 14:27
Лично у нас распределительный центр на 50 магазинов. На сегодняшний день мы получаем только на 10% продукции входящие ВСД, и изготовляем 0% исходящих ВСД
   timurhv
 
931 - 09.07.18 - 12:09
(927) Магнит в касте избранных? Похоже из 80 серверов - половина у них. Имхо, нечестная конкуренция и попытка задавить частные сети. Власов всех затыкал, когда разговор заходил не в то русло, а им минут 10 дал поболтать совсем не по-делу.
И да, все кругом идиоты, а у них все шикарно без ошибок.
   spectre1978
 
932 - 09.07.18 - 12:32
(931) Вот что животворящий выкуп акций ВТБ делает! :)
   mishaPH
 
Модератор
933 - 09.07.18 - 12:40
(931) вы думаете они х5 задавят.

Я не понял. оборудование меркурия на площадках магнита или на их серверах крутится? или все это магнит задумал
 
 
   spectre1978
 
934 - 09.07.18 - 12:42
(933) там странная история. Вы статистику смотрели? Магнит обрабатывает четверть всего трафика ВСД. А Х5 - несколько процентов.
   mishaPH
 
Модератор
935 - 09.07.18 - 12:50
(934) обрабатывает или использует ВСД?
   spectre1978
 
936 - 09.07.18 - 12:55
(935) http://www.vetrf.ru/vetrf/news/27218.html
Я, правда, не очень понимаю с какой целью Магниту оформлять ВСД, если это розница. Ему их гасить надо... Поэтому все это выглядит странно.
   mishaPH
 
Модератор
937 - 09.07.18 - 12:57
(936) Элементарно. Это их распредцентры генерят.

Поставщики отдают товар не по магазинам а на РЦ, у х5 РЦ меньший траффик видимо.

а ВСД формировать то надо от РЦ в магазин. т.к. перевозка хоть и без смены владельца.
   Genayo
 
938 - 09.07.18 - 12:59
(937) Видимо, у x5 прямых поставок в магазины больше, чем у Магнита.
   spectre1978
 
939 - 09.07.18 - 13:01
(937) да, точняк. Но тогда тем более интересно, почему такое различие между Х5 и Тандером. Тандер раньше начал, да. Они требовали ЭВСД еще в середине прошлого года.
(938) Не исключено. Х5 загонять своих поставщиков на РЦ в обязательном порядке стали не так давно как Тандер.
   mishaPH
 
Модератор
940 - 09.07.18 - 13:05
(938) видимо
(939) судя по моим знакомым. тандер стал еще с июня требовать ВСД.
2. с чего. не все возможно в РЦ загнать. У Магнита кстати логистика построена видимо через РЦ. более. чтобы не отвлекать народ в магазинах на поставки. да и поставка на РЦ всегда цена ниже. чем поставщик развозит по магазинам. и у Тандера остается больше бабла.
   ProxyInspector
 
941 - 09.07.18 - 13:08
У Магнита может быть куча распределительных центров, куча магазинов, все от разных юр.лиц. При этом гасить ВСД магазины не могут чисто физически. Получается ситуация как у нас.
  Распределительный склад + 50 магазинов должны генерить 10 млн. ВСД в год. При количестве номенклатуры 1000 позиций.
  А у сетей и магазинов и позиций поболее. Поэтому для крупных сетей  количество ВСД может достигать мрлд. в год.
  Не завидую я им
   mishaPH
 
Модератор
942 - 09.07.18 - 13:11
(941) если прибавить еще алкоголь. то Ит трафик у магазина огого
   timurhv
 
943 - 09.07.18 - 13:12
(933) Я думаю, либо они часть серверов сами купили и поставили Россельхозу под Меркурий под свои нужды, либо пришла директива выделить им сервера чисто под них. Иначе ситуация когда никто не может получить ВСД, а у них все хорошо - выглядит странной.
   spectre1978
 
944 - 09.07.18 - 13:13
(943) ну да. Причем если Галицкий еще мог заупрямиться, то теперь-то там зеленая улица. Скажут - сделают.
   ProxyInspector
 
945 - 09.07.18 - 13:14
Либо они сами не понимают в какой ж-пе находятся.
   mishaPH
 
Модератор
946 - 09.07.18 - 13:18
(943) ну это да. что-то тут явно не так
   mishaPH
 
Модератор
947 - 09.07.18 - 13:47
для компаний у кого РЦ тут ве проще. Им не надо в одночасье выплевывать всд в магазины. главное чтобы в РЦ пришло все с ВДС. А далее они оформят когда будет свободно..

Это если поставщик в магазин приводит должно быть уже ВСД. а для своих то поставок такой спешки явно нет. и авто едет из РЦ порой сутки. всегда есть время.

А вот компании которые не на РЦ везут из за того. чо свой сбыт и до РЦ дальше чем до магазина. вот тут уже засада
   timurhv
 
948 - 09.07.18 - 13:50
(947) Больше всех производители страдают, как собственно обычно.
   mishaPH
 
Модератор
949 - 09.07.18 - 13:53
(948) производителю до РЦ тоже не проблема сделать. хоть в ручную.

а вот если у производителя свой распределенный сбыт. тут вот уже проблема
 
 Рекламное место пустует
   timurhv
 
950 - 09.07.18 - 14:02
(949) Между площадками при производстве ничего не перевезешь толком. Через дорогу перевезти - тоже нужно ВСД выписать.
   mishaPH
 
Модератор
951 - 09.07.18 - 16:09
(950) знаю. у нас 3 завода 2-4 км друг от друга. и все 3 находятся в разных раонных ветслужбах.
   ProxyInspector
 
952 - 09.07.18 - 16:22
У меня сейчас Ветис умер. При этом умер он на функции getProductByGuid. Это основополагающая функция. Если она умирает, тогда останавливается весь Ветис. При этом умирал он медленно. Сначала умерла функция getProductByGuid, а через несколько минут - Ветис
   NSSerg
 
953 - 09.07.18 - 16:27
(952) У меня если продукт не может получить по guid-у (а проверяет active обязательно, ибо выводят из базы продукцию), тогда инвентаризация, и отгрузка по ТНВЭД (третьему уровню). Ничего не останавливается.
   NSSerg
 
954 - 09.07.18 - 16:29
И, кстати, только что делал большую ВСД на 41 позицию - всё нормально, ушло с гуидами. Значит getProductByGuid работает.
   NSSerg
 
955 - 09.07.18 - 16:55
Сейчас массово
<apl:error code="APLM0017" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">An unexpected error has occurred while processing target service response.</apl:error>

Как на неё реагировать? Это в ответ на запрос по тикету.
   Genayo
 
956 - 09.07.18 - 18:07
(954) Похоже, что у них в разных регионах разные сервера, и балансировка нагрузки не очень работает...
   spectre1978
 
957 - 09.07.18 - 19:08
(955) Вроде позавчера 12 было... Чет новое?
   ProxyInspector
 
958 - 10.07.18 - 11:44
По поводу getProductByGuid ошибочка у меня вышла.
Оказывается что
Родитель второго уровня это  GetProductByGuid
Родитель третьего уровня это это  GetSubProductByGuid
    И если по GUID элемент не найден, тогда возвращается код ошибки 500 - сервис не доступен.
   NSSerg
 
959 - 10.07.18 - 13:18
(957) Да. Причем ночью опять всё штатно отработало.
Буду писать список кодов при которых нужно пытаться перевыписать ВСД (ошибка со стороны меркурия), и список с которыми нужно разбираться.
   NSSerg
 
960 - 10.07.18 - 13:25
Часть накладных не уехало, потому что по непонятной причине не дало выписать от имени уполномоченного сотрудника, с ошибкой
"MERC02386" Данная транзакция не может быть оформлена, так как роль пользователя не позволяет оформлять ВСД
ПО ТНВЭД
d99981f8-b4a3-4d13-867c-01ed252edb1b
желированные продукты из мяса и субпродуктов (1602)
Это продукция прошедшая термообработку, из 646 приказа.
   timurhv
 
961 - 10.07.18 - 13:26
(960) Назначение какое указали?
   NSSerg
 
962 - 10.07.18 - 13:31
(961) Как и все остальные. Реализация в пищу людям
   NSSerg
 
963 - 10.07.18 - 14:36
(960) Это была ошибка в меркурии, вроде по нашему обращению поправили. Действительно под этим ТНВЭД уполномоченным не давала выписывать. Завтра проверим.
   NSSerg
 
964 - 12.07.18 - 15:46
Что-то ветка затихла.
Насчет APLM20001 - битые площадки.
Вывели полный список - у нас их сотни. И оказалось что проблема решаемая, сотрудником РСХН с достаточными правами. Чтоб решить проблему нужно изменить что-либо в площадке и пересохранить. GUID площадки при этом не меняется. Единственная проблема в правах.
   spectre1978
 
965 - 12.07.18 - 16:23
(964) очевидно, все как-то приноровились и работают...
   birkoFFFF
 
966 - 12.07.18 - 16:55
Назначить обновление на пятницу 13-ое это сильно.
https://www.vetrf.ru/vetrf/news/27290.html
Всем причастным к этой загашочной планете рекомендую в выходные не пить, из города не уезжать и быть на связи.
Так хотелось отдохнуть, а придется вздрагивать от каждого звонка. 146% что всё ляжет.
   spectre1978
 
967 - 12.07.18 - 17:10
(966) та ладно, с чего такой пессимизм. Оно уже не раз обновлялось и не десять, а ложилось в редких случаях
   spectre1978
 
968 - 12.07.18 - 17:11
вот про лабораторные исследования надо уточнить. По-моему, я при запросе партий это дело проверяю, но я работаю через getStockEntryList, не через Changes. Так что меня коснуться не должно
   spectre1978
 
969 - 12.07.18 - 17:18
Кстати, рекомендую почитать список обновлений уважаемому NSSerg. Там первое обновление как раз по его душу - появилась возможность указывать иностранное предприятие-поставщика без указания его GUID для входящей партии.
   NSSerg
 
970 - 12.07.18 - 17:35
(965) У нас на такие площадки в день сотни ВСД, выписать на них невозможно в принципе. Эти площадки не выбираются в меркурии, через API на них не сделать ни регионализацию, ни транспортную ВСД.
(969) Мы закачали справочник иностранных площадок, и во всех товарах проставили площадку производителя. Хотя ИМХО почему бы этот справочник просто не выложить? Почему РСХН его не выкладывает? Там по каждой стране всего лишь несколько сотен площадок. Все наши площадки там есть.
   ProxyInspector
 
971 - 13.07.18 - 14:56
Есть ли в Меркурии функция получения описания ошибки по ее коду через API
  А то посылаешь запрос на гашение, а тебе в ответ
REJECTED   ERR  MERC13286
В ВИКИ есть http://help.vetrf.ru/wiki/IncomingOperation
описание. Но хочется как то более цивильно
   NSSerg
 
972 - 13.07.18 - 15:30
(971) нет. У меня тот же вопрос, но походу нет, у тебя вместе с ошибкой возвращается её текстовое описание.
   spectre1978
 
973 - 13.07.18 - 15:36
(971) так вроде в BusinessError возвращаются текстовые описания. Или у вас провайдер, а не API?
   ProxyInspector
 
974 - 13.07.18 - 15:40
У меня в IncomingOperation - оформление входящей партии возвращает только КодОшибки.
   ProxyInspector
 
975 - 13.07.18 - 16:32
Кто нибудь сталкивался с такой ошибкой. MERC14023    В сведениях о принимаемой партии указана устаревшая версии записи вида продукции наименовании продукции.
Что то я не вижу способа обойти эту ошибку по API
   ProxyInspector
 
976 - 13.07.18 - 16:39
В справке написано "В запросе для номенклатуры продукции указан идентификатор устаревшей версии записи реестра РСХН" и как это перевести на русский язык?
   NSSerg
 
977 - 13.07.18 - 16:45
(975) это значит продукция выведена из реестра РСХН?
   ProxyInspector
 
978 - 13.07.18 - 16:45
Через WEB Я погасил эту ВСД. Где-то проскакивало, что в Меркурии утверждают, что такую ВСД можно погасить только через WEB интерфейс
   ProxyInspector
 
979 - 13.07.18 - 16:47
Через API не смог, хотя продукция полностью обновлена.
   spectre1978
 
980 - 13.07.18 - 18:59
(975)(976)(977) скорее всего это означает, что в запросе для продукции указали UUID продукции, а не GUID, и этот UUID является идентификатором непоследней версии продукции. Я не Ванга, но думаю, что произошло следующее: ваши контрики выписали ВСД, используя последний на тот момент UUID продукции. А потом, пока ВСД летел к вам, что-то подправили в справочнике для этой номенклатуры - название там поменяли или еще чего, может, просто ОК нажали. В результате для соответствующего GUID номенклатуры образовалась новая последняя версия с новым UUID, а тот UUID, который был в ВСД - стал неактуальным. Чтобы это полечить, наверно, нужно при приемке либо сменить UUID на последний, либо очистить его и заполнить GUID.
   spectre1978
 
981 - 13.07.18 - 19:01
Кстати! Ща скажу важную вещь, на которую напоролся. Если для какой-то версионной сущности в запросе заполнен и GUID, и UUID, приоритет у UUID! Так что если не хотите ловить ошибки с устаревшей версией, не пользуйтесь UUID без крайней необходимости.
   Garykom
 
982 - 13.07.18 - 19:02
В конфигурацию Розница (2.2.9.19) добавили работу с Меркурием, кто уже тестил?

Конечно функционал только для подписчиков ИТС.

И в УТ11 не в курсе когда?
   spectre1978
 
983 - 13.07.18 - 19:12
+ (979) чтобы было более понятно, как это работает, надо понимать, как работает механизм Versioning Entity в Ветис.АПИ. Грубо говоря, каждая номенклатура это связный список элементов, каждый из которых содержит GUID и UUID. GUID уникален для каждого элемента справочника номенклатуры, это типа как код в справочнике 1С. А UUID уникален для каждого элемента списка. Когда создается новый элемент номенклатуры, в списке создается первый элемент. Первая версия. Она активна и не содержит ссылок на предыдущие и следующие элементы. Потом решили ее подправить. Создается второй элемент списка, ссылающийся на первый. GUID у него тот же, а UUID уже другой. И теперь уже второй элемент активен, а первый нет. Второй ссылается на первый, первый на второй. Если запустили процедуру удаления - признак активности у последнего элемента снимается, т.е. все элементы в списке тупо неактивные, а физически ничего не удалилось. Старые документы могут ссылаться на неактивные версии номенклатуры, а новые нет - будет вот эта самая ваша ошибка с устаревшей версией. Как-то так это все работает...
   Обработка
 
984 - 13.07.18 - 19:13
У вас ВЕТИС у НАС ВС внедряют.
Виртуальный склад.
Скоро будут следить за всеми движениями товаров (((
   NSSerg
 
985 - 13.07.18 - 20:13
(983) у нас каждый день несколько Guid ( а не uuid) становятся неактуальными.
   spectre1978
 
986 - 13.07.18 - 20:22
(985) Т.е. вы уверены что используете GUID в запросе, но получаете ошибку неактуальной версии? Тогда, возможно, в цепочке вообще нет актуальных, т.е. номенклатура "удалена" хозсубъектом который ее завел.
   spectre1978
 
987 - 13.07.18 - 20:24
И надо проверить (981) - если вдруг вышло так что указали и GUID и UUID, то используется UUID
   Символ
 
988 - 13.07.18 - 21:19
(982) В УТ 11 уже давно.
Вот только у меркурия пока проблемы с APLM0012
   ProxyInspector
 
989 - 13.07.18 - 22:09
(988) У нас уже нет APLM0012. Эта ошибка на 80% проблема разработчиков интеграционных решений и на 20% Меркурия.
   Garykom
 
990 - 13.07.18 - 22:21
(988) Понятно, скоро знакомые колбасники с УТ11 начнут доставать по интеграции.
   spectre1978
 
991 - 13.07.18 - 22:24
(989) по-моему, все в точности наоборот. Проблемы с перегрузками связана с тем, что изначально разработчики меркурия сделали сверхтяжелые запросы вроде получения всех ветеринарок или всех партий практически без фильтрации или с минимальной. И когда все разработчики начали это себе выкачивать ввиду того, что у них просто не было других вариантов - все вполне ожидаемо прилегло отдохнуть. Лично мне это было очевидно еще в 2016 году, что так оно и будет.
   spectre1978
 
992 - 13.07.18 - 22:27
то же самое, кстати, подтвердил Власов на встрече с представителями бизнеса. И сейчас (конкретно в сегодняшнем обновлении) они уже пытаются повыкинуть из ответов часть данных, чтобы хотя бы снизить нагрузку на сеть.
   Символ
 
993 - 13.07.18 - 22:53
(989) Как вы решили вопрос с получением входящих документов без запросов списков?
   ProxyInspector
 
994 - 14.07.18 - 08:20
(993) Корректно сделали таймауты.
Запрос на получение списка вет сертификатов. Цикл с таймоутом 120 сек и задержкой между запросами 10 сек. Прерываемся только если COMPLETED. На все остальные ошибки не смотрим.
  Получение ответа на запрос. Цикл с таймоутом 120 сек и задержкой между запросами 3 сек. Прерываемся только если COMPLETED ИЛИ REJECTED. На все остальные ошибки не смотрим.
  Где то так примерно. Не могу посмотреть точно.
  Проблем с получением списка сертитификатов имеем если на протяжении 120 сек не смогли отправить запрос на получение. Но это происходит когда Меркурий совсем висит.
   spectre1978
 
995 - 14.07.18 - 08:51
(994) Ну хорошо, обошли. А вы сами как считаете, ожидания не в миллисекундах, а в десятках секунд для продуктивной системы уровня не много не мало федеральной - это вообще как? Я тут даже слово "нормально" не употребляю, потому что по-моему, это вообще за гранью добра и зла. И кто в этом виноват, интеграторы?
   ProxyInspector
 
996 - 15.07.18 - 21:56
Не так страшен черт.
У нас гашение входящих ВСД 1 машины занимает 30 секунд. Не очень много. Если взять распределительный склад уровня Метро, то у них не более 1000 машин в сутки. Вполне могут работать.
Интеграционное решение должно быть нормальным.
   ProxyInspector
 
997 - 15.07.18 - 21:58
Не случайно же на совещании по итогам первой недели работы был сделан вывод, что если Меркурий не висит мертво, то работать можно.
   ProxyInspector
 
998 - 15.07.18 - 22:05
Мы не производители, поэтому продукцию не заводим, а получаем из входящих ВСД. Ставим только соответствие между продукцией меркурия и нашей номенклатурой.
  Входящие ВСД можно получать в регламентном задании.
   NSSerg
 
999 - 15.07.18 - 22:49
(998) у нас после отмены молочки осталось 10000 ВСД транспортных в сутки, по бизнес-процессу они должны выписываться за полтора часа. То есть это нормально, что внедрение электронной сертификации взамен бумажной ухудшило процессы у дистрибьютеров? Я так не думаю. ИМХО это неудовлетворительно.
   NSSerg
 
1000 - 15.07.18 - 22:50
(999) есно исходящих
  1  2  3  4  5  6  7  8  9  10  11   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует