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

  1  2  3  4  5  6  7  8  9  10  11   

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

Ø [длинная ветка, 16.07.18 - 11:50]
ВетИС уже скоро
Я
   Звездец
 
02.05.18 - 16:38
Ветис уже скоро. А что-то вокруг тишина. В программах даже что-то появилось, а на ИТС ни одной инструкции. Все ждут? или может кто-то что-нибудь делает для подготовки?
 
 
   tciban
 
801 - 03.07.18 - 14:33
ну да, ошибся...
   tciban
 
802 - 03.07.18 - 14:37
Заработал Меркурий то кого?
   spectre1978
 
803 - 03.07.18 - 14:47
(802) Да, похоже отживел.
   mishaPH
 
Модератор
804 - 03.07.18 - 14:48
гасить ВСд начал входящие
   NSSerg
 
805 - 03.07.18 - 14:50
(781) у нас десятки тысяч (если не сотни) запросов в день, и такая ошибка (и подобные) возникают постоянно.
В модуле они обрабатываются, и через паузу делается повторный запрос.
   NSSerg
 
806 - 03.07.18 - 14:52
+ (805) все обработки на ссегодняшнюю отгрузку произошли без сбоев. Точнее сбой был, только один - недопустимый символ «<« в xml. Сделал автозамену недопустимых символов.
   spectre1978
 
807 - 03.07.18 - 14:54
(805) Это все понятно, но там немножко не то было. С половины двенадцатого и практически посейчас система вообще не реагировала ни на какие раздражители. Можно было бы послать сотню запросов через паузу, и все они отлупились бы. Вы бы просто впустую потратили время.
   NSSerg
 
808 - 03.07.18 - 14:58
Нетушли только те всд, где страна в товаре не соответствует стране в площадке производителя, в те точки где нет гуида площадки, и в те точки в которые из-за глюка меркурия не проходит регионализация. Естественно это всё обработки отслеживают автоматически (ответы на инвентаризации, регионализации), человеческого участия не требуется. Так же автоматически проверяются ответы на исходящие всд. Спустя примерно час - два после выписки. Если нет положительного ответа, считаем что всд не прошла.
   NSSerg
 
809 - 03.07.18 - 15:01
(807) обработка впустую :)
Десять попыток с ошибками связи, и у меня стоит ассерт (пр=0/0;)
Но мы выписывали ночью, обработка доработала до конца без сбоев.
Примерно 10000 всд выписали.
   NSSerg
 
810 - 03.07.18 - 15:02
(809) не мы впустую потратили время, а обработка.
 
 Рекламное место пустует
   ProxyInspector
 
811 - 03.07.18 - 15:59
У меня пока "REJECT" выдает на все запросы
   hawksib
 
812 - 03.07.18 - 16:25
(809) сколько очередей всд выписывают?
   NSSerg
 
813 - 03.07.18 - 16:38
(812) Одна, в один поток. На второе число выписывал в два потока, а на третье в один справилась. Но у меня ассинхрон. Получила гуид тикета, и пошла дальше. Ответы получаю потом.
   timurhv
 
814 - 03.07.18 - 16:48
(813) Ошибку с блокировкой записи не получаете? Или это уже в Меркурий починили?
   NSSerg
 
815 - 03.07.18 - 16:53
(814) у меня на все ошибки - повторный запрос.
Я даже не фиксирую что за ошибка, потому что их много разных.
Но пока не получила гуид в ответ на всд - дальше не идет. Учитывая что не застряла, и все всд с гуидами (тикета, не самой всд) - то в итоге каждая всд прошла. Потом, если в момент пакетной печати по тикету не получила гуид самой всд (не важно в процессе, или отклонена) - считаю что всд нет.
   spectre1978
 
816 - 03.07.18 - 16:53
(814) так можно после блокировки перекурить и новый запрос послать.
   timurhv
 
817 - 03.07.18 - 17:08
(816) Не очень быстрая отправка так получается. Были клиенты, которым по 1000 транспортных в час (с 20-50 SKU) надо отработать, там не укладывались в это время с переотправкой запроса в случае ошибки.
В итоге 3 дня убил на обмозгование алгоритма с одним потоком, более чем устроил результат, стали укладываться в 34-45 минут.
Но 1С сервер постоянно под нагрузкой из-за обмена с Ветис.API (не расчитана ИМХО платформа на такой мазахизм). Есть мысль написать сервис в виде приложения, работающий как прокси для общения с Меркурием на каком-нибудь GoLang.
   hawksib
 
818 - 03.07.18 - 17:14
(817) в 1 поток 1 твсд отправляется 4 секунды, получается 15 в минуту, или 900 в час. это идеальные условия, накладываем погрешность получаем 500 сертификатов
   timurhv
 
819 - 03.07.18 - 17:16
(817) Если ЗСЖ не пересекаются, то у меня алгоритм это анализирует и составляет очередь отправки на основе этого. Никогда ошибку блокировки записи не получал. Между ТВСД с разными ЗСЖ время отправки доходило до 0.7 сек в один поток.
   hawksib
 
820 - 03.07.18 - 17:18
(819) зсж расшифруй пожалуйста?
   NSSerg
 
821 - 03.07.18 - 17:19
(817) у меня больше 1000 в час успевает.
   NSSerg
 
822 - 03.07.18 - 17:20
Почти 10000 транспортных всд вчера вшло 3 часа.
   timurhv
 
823 - 03.07.18 - 17:20
(819) запись складского журнала
(821) мне не нравится загрузка ЦПУ в это время со стороны 1С
   hawksib
 
824 - 03.07.18 - 17:22
(821) ну у тебя асинхрон, а я говорю про обработку ответа сразу после отправки запроса,тогда минимум 4 секунды, если мерк ответ быстро вернет
   hawksib
 
825 - 03.07.18 - 17:26
(821) (822) нам надо их не только послать, но ещё и потом квадратные штрихкоды на весь документ распечатать, причем СРАЗУ, поэтому делаем пока всё по потокам
   hawksib
 
826 - 03.07.18 - 17:28
за ночь 11 к твсд, ошибки ловим, пробуем ещё
   NSSerg
 
827 - 03.07.18 - 17:42
(823) загрузка равна нулю, повторы через паузу. Sleep.
   NSSerg
 
828 - 03.07.18 - 17:45
(825) у нас есть как минимум час между окончанием формирования и распечаткой.
   NSSerg
 
829 - 03.07.18 - 17:50
Нет надобности слать винескольео потоков.
Если нужно полкчить ответы быстро, можно слать например по 20 запросов подряд, потом получать 20 ответов на тикеты.
   hawksib
 
830 - 03.07.18 - 17:53
(829) вы регионализацию захешировали?
   NSSerg
 
831 - 03.07.18 - 18:28
(830) нет. По клиенту(точке)  регионализация, в одном запросе список всех тнвэд из накладных, ждем полного ответа, а потом по всем строкам всех накладных выписываем всд с указанием нужных данных, а во всд уже ответа не ждем, только тикет.
   hawksib
 
832 - 03.07.18 - 18:41
(831) ну регионализация же на каждый вид продукции нужен, или нет?
т.е. вы группируете все наименования по видам и запросами получаете регионализацию, или что-то не так понимаю?
   NSSerg
 
833 - 03.07.18 - 20:10
(832) в одном запросе можно указать весь необходимый список.
В ответе так же группируется по тнвэд.
 
 
   NSSerg
 
834 - 03.07.18 - 20:10
(832) на один адрес, и на несколько кодов тнвэд - один запрос.
   NSSerg
 
835 - 03.07.18 - 20:21
На все коды тнвэд из накладных по одной точке - один запрос.
   NSSerg
 
836 - 04.07.18 - 17:29
Как через API создать ввести остаток продукции на которую не заведен производитель - нет гуида площадки (предприятия) производителя? Импортного.
ResolveDiscrepancyOperation v2.0 требует ГУИД площадки
<vd:producer>  dt:Producer  [1..*]  Производитель продукции.  
Вдобавок Страна в инвентаризации должна соответствовать Стране в площадке производителя.
Нас Россельхоз уверял что все производители, продукция которых импортировалась в прошлом - будут заведены. В итоге их нет. Что делать? Может есть какая-то другая операция, которой я могу ввести остатки по товару без GUID производителя?
   EuVod
 
837 - 04.07.18 - 18:12
(836) мы не нашли... кажется поставили какой-то супчик тайландский как отечественный...


а что за фигня - все время возвращает отлупы - мерк поломался?:

Error 401--Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8)....
   NSSerg
 
838 - 04.07.18 - 18:36
(837) У нас нет такой ошибки, точнее если даже есть - я не вижу, у меня просто идет автоматически повторный запрос.
Сейчас всё работает, сбоев нет.
   spectre1978
 
839 - 04.07.18 - 18:45
(837) у нас сегодня вроде работало ровно.
(836) ну на худой конец можно его попытаться завести. По сути то же создание площадки. Нет?
   NSSerg
 
840 - 04.07.18 - 19:12
(839) А есть право создание площадок не Российских?
И чтоб нормально завести площадку, нужно и ХС импортного завести. И еще момент - если даже можно, нас за это не накажут?
   spectre1978
 
841 - 04.07.18 - 19:27
(840) Это все нуждается в уточнении, но в принципе а) площадку, как думается, можно создать без ХС, он там в обязательном порядке нигде не требуется; б) площадок понасоздавали уже сотни тысяч всяких, разных, и никого за это до сих пор не наказали. Наверняка будет масса ситуаций, когда, например, импортируют что-то с большим сроком годности, а производителя уже не существует, разорился или его купили. Предприятия это ведь такая штука, появляются, исчезают... Невозможно все заранее создать.
   NSSerg
 
842 - 04.07.18 - 22:05
(841) Нас просто уверили что РСХН сам создал по всем кто поставлял в РФ. Не сейчас поставляет, а когда либо поставлял.
   NSSerg
 
843 - 04.07.18 - 22:05
Но это не так, как оказалось.
   spectre1978
 
844 - 04.07.18 - 22:19
(842) дык они много в чем уверяли. Но есть то что есть...
   NSSerg
 
845 - 04.07.18 - 22:56
Еще один вопрос. Точки, на которые при регионализации ругается с ошибкой
<apl:error code="APLM20001">Не удалось загрузить сведения о производственной площадке с GUID:
На неё и без регионализации нельзя отгрузить из-за ошибки
<apl:error code="MERC02180">Обслуживаемое предприятие с указанным идентификатором не найдено в реестре РСХН, либо идентификатор не соответствует установленному формату.
При этом все запросы и по ХС, и по Предприятию/площадке проходят по этой точке нормально.
Есть ли менее кривой способ отследить такие площадки, чем попытаться сделать регионализацию на все точки в базе?
   big
 
846 - 05.07.18 - 06:10
Меркурий лежит уже 2 часа. На профильном форуме народ с ума сходит. )  Сети выламывают руки, им плевать на проблемы "негров".

Эхххх... сдается мне, что всем этим "власовцам" меркурианцам отдельные котлы в аду уже припасены.
   kofeinik
 
847 - 05.07.18 - 08:17
APLM0012 - An unexpected error has occurred while invoking target service operation. (REJECTED) еще со вчерашнего вечера сыпется.
   spectre1978
 
848 - 05.07.18 - 08:31
Самое странное, что у нас сегодня вроде нормально. С шести утра уже сделали производство, перевозку своего и несколько десятков отгрузок выписали, вроде живет...
   spectre1978
 
849 - 05.07.18 - 08:33
(845) а что у этих точек со свойством active?
 
 Рекламное место пустует
   spectre1978
 
850 - 05.07.18 - 08:34
у меня одна с такой ошибкой была, но она была в тесте. В продуктиве пока не попадалось. Но у нас не так много клиентов, так что это не показатель.
   NSSerg
 
851 - 05.07.18 - 10:01
(850)  У нас вал таких уже проставленных в соответствие, и еще больше в закаченных площадках меркурий (для того чтоб выбирать соответствие)
Общего у них похоже то что созданы до середины 2017 года.
(849) true. Все точки получены  GetActivityLocationList, других не бывает. Вообще обычные точки, есть адрес из классификатора и адрес строкой. Статус 100.
   Chieftain
 
852 - 05.07.18 - 11:18
(847) Еще вчера они писали:

Система Меркурий работает штатно, включая ее web-интерфейс, замедлений в работе не зафиксировано. В интеграционном шлюзе остается ограничение для выравнивания нагрузки в виде ответов с кодом APLM0012.


http://www.fsvps.ru/fsvps/news/27188.html
   Chieftain
 
853 - 05.07.18 - 11:22
+(852) Судя по форуму - шлюз на из стороне работает штатно только за счет "выравнивания нагрузки" - режут часть запросов с кодом APLM0012
   NSSerg
 
854 - 05.07.18 - 11:28
Поиск по базе ответов - одна ошибка с кодом code="APLM0012"
На 61466 ответов в папке (ответы остались за сутки с небольшим, вчера удалил старые)
Всё-таки у меня она не обрабатывается, засчитала исходящую ВСД как отклоненную, и не стала печатать. Но при этом естественно отправила её.
   spectre1978
 
855 - 05.07.18 - 11:47
(853) судя по всему, они эти 012-е вдупляют только тем, кто создает серьезную нагрузку. У меня с утра пока не было ни одного, но у меня и документов мало.
   birkoFFFF
 
856 - 05.07.18 - 11:55
У меня уже скоро будет целый цитатник имени Власова.

"все хорошо с МЕРКУРИЕМ и это очевидно любому не идиоту" (с) Власов

Ветка на официальном форуме просто эпичная http://vetrf.ru/vetrf-forum/posts/list/8354.page

Обещание все наладит через 1-2 недели это вообще круть.
Человек живет в параллельной вселенной, там где розовые пони скачут по радуге.
   spectre1978
 
857 - 05.07.18 - 12:02
(856) А в остальном, прекрасная маркиза, все хорошо, все хорошо (с) :) Ему лучше в оперетте выступать
   timurhv
 
858 - 05.07.18 - 13:11
(856) Прочитал, при Сталине за такой подход в ГУЛАГ бы отправили. А сейчас, даже если на ковер вызовут - отчитается что производители и сети просто не хотят работать в Ветис и саботируют работу, а у них все хорошо.
   mishaPH
 
Модератор
859 - 05.07.18 - 13:19
создал производственную ВСД. дата ВСД сегодня. дату пр-ва поставил завтра.
Спокойно создал транспорты СВСд на другую фирму с датой пр-ва завтра...

Значит доки все можно создавать вперед? и не нагружать систему после 00 часов.

У нас все доки заказов идут на след день и отгрузка начинается только ночью. Производство начинают сегодня но реально завершается и поступает на отгрузку только под сборку и отправку. Исполнять весь пакет производства получается что не нужно перед отправкой авто. А можно заранее на день раньше...
   timurhv
 
860 - 05.07.18 - 13:22
(859) По-факту ведь не знаете до кг сколько выйдет.
   mishaPH
 
Модератор
861 - 05.07.18 - 13:48
(860) мы всегда выпускать будем + 5-10% от заказа. что не отгрузили будет списано.
   NSSerg
 
862 - 05.07.18 - 15:43
(855) За три часа 61466 - ответов из меркурия - это не много?
Думаю что дело в другом, дело например в попытке получения ответа на тикет в цикле без пауз. Да еще и в кучу потоков.
Ответ не может прийти быстро, поэтому после запроса можно сделать паузу на одну секунду перед получением ответа, и в цикле пока ответа нет делать паузу и повторный запрос.
У меня например так и написано
отв="";
Пока отв="" Цикл  
    глПауза(1000);
    отв=ПолучитьОтвет(Ид,ТЗПартий);
КонецЦикла;
Если отв="REJECTED" Тогда
// отв="", когда не REJECTED и не ACCEPTED
При обработке ошибок у меня так-же, пауза и повторная попытка.
Попытка
    WinHttp.Send(POST_STRING);
Исключение
    сообщить(""+счетчикошибок+" Не удалось отправить сообщение! "+ОписаниеОшибки());
    глПауза(ПаузаОшибка);
    Перейти ~NP;
КонецПопытки;    
...
Попытка
    Если WinHTTP.Status<>200 Тогда
                сообщить(""+счетчикошибок+" Не удалось выгрузить по WinHTTP.Status: код ошибки "+СокрЛП(WinHTTP.Status));
        глПауза(ПаузаОшибка);
        Перейти ~NP;
    КонецЕсли;
Исключение
        сообщить(""+счетчикошибок+" Не удалось получить ответ на запрос! "+ОписаниеОшибки());  
    глПауза(ПаузаОшибка);
    Перейти ~NP;
КонецПопытки;
....
Для ИндексОшибок=0 По УзлыОшибок.length-1 Цикл
    ТекстОшибки = УзлыОшибок.item(ИндексОшибок).text;
    КодОшибки = УзлыОшибок.item(ИндексОшибок).getAttribute("code");
    Если кодОшибки="APLM0012" Тогда
        Сообщить(""+счетчикошибок+" Ошибка слишком частых запросов: "+КодОшибки+" "+ТекстОшибки);
        глПауза(32000);
        Перейти ~NP;
    КонецЕсли;
КонецЦикла;
...
и т.д.
   ProxyInspector
 
863 - 05.07.18 - 16:00
Я подправил немного логику формирования запросов и ответов к Меркурию, ну и проблемы с  "APLM0012" прекратились.
  Раньше при ошибке "APLM0012" считалось, что наступил полный пипец и надо начинать все сначала. Теперь ошибка "APLM0012" считается вполне нормальной ситуацией и надо просто подождать и попытаться через 3 сек. Ну и поставил ограничение на общее время ожидания ответа от Меркурия 120 сек.
   ProxyInspector
 
864 - 05.07.18 - 16:04
Скорость гашения Входящих ВСД - 1..2 сек /шт
Время получения списка Входящих ВСД - 20-30 сек по одному XC.
   Не случайно разработчики Меркурия пишут, что ошибка "APLM0012" - это вполне рабочая ситуация и попытка сбалансировать нагрузку на систему
   NSSerg
 
865 - 05.07.18 - 16:30
(863) Учитывая что за последние сутки у меня была только одна такая ошибка - я поставил паузу в 32 секунды. (см код выше)
Пауза у меня после первой ошибки 0,5 секунды, после каждой следующей удваивается, пока не дойдет до 32 секунд. Всего 10 ошибок, и делю ноль на ноль - после чего обработка с ошибкой падает (называется assert, чтоб не дай бог что-нибудь не испортила когда вернет не то и не туда функция получающая ответ от сервера).
С 31 числа когда начали работать в продуктиве - падение было один раз, сегодня утром после пяти утра. При пакетной печати ВСД - в момент печати получает guid трансортной ВСД в ответ на тикет.
(864) Только это нужно было довести до сведения разработчиков. Что именно эту ошибку нужно обрабатывать не как отклонение запроса на транспортную ВСД например.
   NSSerg
 
866 - 05.07.18 - 16:32
+ (865) У меня при падении при пакетной печати, один раз проскочила ошибка APLM0012, и в итоге ВСД обработкой была засчитана как отклоненная, так как REJECTED. На печать она не пошла, все хвосты были подтерты.
   spectre1978
 
867 - 05.07.18 - 20:09
(862) За три часа 61466 - ответов из меркурия - это не много?
Ну вообще-то некисло. В пересчете на секунду выходит около 17 ответов только на одно ваше предприятие. Я не думаю, что у них там группировка серверов как у Гугла :)
   spectre1978
 
868 - 05.07.18 - 20:11
собственно, в помянутой тут ветке Власов ответил - 80 серверов. Не сказать чтобы сильно много.
   Chieftain
 
869 - 05.07.18 - 20:21
(868) "Я бы сказал 80 серверов на виртуальной машине компа Власова."(с) из той же ветки ))
   big
 
870 - 05.07.18 - 20:34
(862) Если я правильно понял, то у тебя 7.7?

А какие размеры файлов у тебя ходят?

У меня уже на 120-150 кБ ооочень ощутимые тормоза, вплоть до обрубания процессов в диспетчере задач. Пришлось в спешном порядке перекраивать алгоритмы на cUrl.

Прикол в том, что ответ на транспортную накладную в 83 строки весил 527 кБ. На WinHttp я бы в жизни её не получил.

А вот про 012 ошибку надо тоже внести коррективы.
   NSSerg
 
871 - 05.07.18 - 20:39
(870) без ограничений. Я спокойно получаю все справочники по 1000 записей.
Передаю из http в xml через файл.
   NSSerg
 
872 - 05.07.18 - 20:42
+ (871) если передавать не через файл, а напрямую - то 1с просто падает. Но это давно известно.
   NSSerg
 
873 - 05.07.18 - 20:55
(867) наврал я, не за три часа, я же справочники тяну из меркурия и обновляю, не во время выписки всд.
   spectre1978
 
874 - 06.07.18 - 08:58
Я смотрю, APLM0012 может вылететь и в ответ на eceiveApplicationResultRequest, необязательно только на submitApplicationRequest?
   spectre1978
 
875 - 06.07.18 - 08:58
* receive
   NSSerg
 
876 - 06.07.18 - 10:41
(874) я вставил проверку во все ответы.
то есть в саму процедуру которая используется для отсылки всех запросов с получением ответа.
   spectre1978
 
877 - 06.07.18 - 10:58
Если приходит в ответ на ReceiveApplicationResultRequest, то это надо понимать как сбой всей заявки (надо перевыставлять заявку) или как сбой получения результата (надо заново запросить результат по той же заявке)?
   spectre1978
 
878 - 06.07.18 - 11:06
полагаю, что первый случай
   NSSerg
 
879 - 06.07.18 - 11:31
(877) неважно в ответ на что пришло, нужно заново повторить запрос.
   NSSerg
 
880 - 06.07.18 - 11:32
(877) Тот запрос на который пришло ACCEPTED  - повторять не надо.
   spectre1978
 
881 - 06.07.18 - 11:48
(880) Вы меня не совсем поняли. Итак:

На submitApplicationRequest пришло ACCEPTED - начинаем запрашивать результат выполнения с помощью receiveApplicationResultRequest.

Поначалу все хорошо, IN_PROCESS, но третий или четвертый запрос receiveApplicationResultRequest дает APLM0012.

Вопрос: мы в этом случае продолжаем ожидать ответа на заявку (receiveApplicationResultRequest) или полагаем, что заявка не прошла, и вновь делаем submitApplicationRequest ?
   ProxyInspector
 
882 - 06.07.18 - 12:06
В функции receiveApplicationResultRequest мы получаем ответ на ранее поданный запрос.
Выполняем в цикле эту функцию с задержкой 3 сек пока не получим либо COMPLETE либо REJECT (что маловероятно, так как запрос уже принят в обработку) либо наступит Timeout (у меня он стоит 60 - 120 сек).
   ProxyInspector
 
883 - 06.07.18 - 12:08
Функцию submitApplicationRequest
Выполняем в цикле эту функцию с задержкой 3 сек пока не получим либо ACCEPTED либо REJECT либо наступит Timeout
  При таком раскладе все работает великолепно
   NSSerg
 
884 - 06.07.18 - 12:12
(881) Почему это не понял? Я всё понял.
Повторяем тот запрос на который пришло APLM0012.
На submitApplicationRequest пришло ACCEPTED, этот запрос прошел, тикет уже есть.
Теперь ты должен дождаться либо ACCEPTED на Тикет, ли REJECTED на него, но не с кодом ошибки APLM0012.
APLM0012 - такой же сбой как и все остальные, просто повторяешь запрос на который пришло в ответ, так же как если код ответа не равен 200 например.
   NSSerg
 
885 - 06.07.18 - 12:15
Если пришло APLM0012 на submitApplicationRequest, то повторяем его естественно, так как тикета то нет.
   spectre1978
 
886 - 06.07.18 - 12:35
(882) Очень даже вероятно Reject получить. С кодом APLM0012.
   spectre1978
 
887 - 06.07.18 - 12:37
Насколько я понял, в случае реджекта и APLM0012 в ответ на receiveApplicationResultRequest надо повторять исходный запрос.
   spectre1978
 
888 - 06.07.18 - 12:38
т.е. если вы получили эту ошибку в процессе получения ответа на заявку, то уже не имеет значения, была ли заявка ACCEPTED или нет. Выполнена она не будет. Надо делать новую заявку.
   NSSerg
 
889 - 06.07.18 - 12:43
(888) Нет! Нужно только повторить непосредственно тот запрос на который получена ошибка APLM0012.
Если ты сделал транспортную ВСД, и получил на неё тикет - всё, она сделана. Дальше ты получаешь по тикету её Гуид. И если REJECTED с кодом ошибки  APLM0012, то ты повторяешь именно тот запрос на который пришла ошибка, то есть еще раз по тикету пытаешься получить ВСД.
А если REJECTED с любой другой ошибкой, то значит ВСД не сделана. И нужно с самого начала получать тикет.
Но я уже сам не уверен.
   spectre1978
 
890 - 06.07.18 - 12:52
(889) как мне объяснили, все-таки нет. Если при получении ответа пришел REJECTED, то по факту это означает, что заявка, на которую ожидаем ответ, не будет обработана. Код ошибки значения не имеет. Если REJECTED - значит, все, можно курить бамбук и готовиться отправлять повторно.
   NSSerg
 
891 - 06.07.18 - 12:56
(890) Да, для любого кода ошибки кроме APLM0012
   spectre1978
 
892 - 06.07.18 - 12:58
(889) это достаточно легко проверить. Если вы правы, то после REJECTED на APLM0012 какой-то из следующих ответов по тому же тикету должен вернуть COMPLETED. Если такого не происходит, то... значит, дело обстоит не так.
   Prog111
 
893 - 06.07.18 - 13:05
Подскажите, пожалуйста, обратился знакомый клиент, спросил про Меркурий, а я вообще ни сном, ни духом. У него розничный магазин (от хлеба до пельменей) - товароучетной системы нет. Так вот, хочу спросить - в Рознице 2.2 есть что-нибудь связанное с Меркурием? То есть стоит ли поизучать, что есть в Рознице, связанное с Меркурием и посоветовать внедрить её в магазине?
   spectre1978
 
894 - 06.07.18 - 13:07
891 + (892) Провел натурные эксперименты. Как только какой-то из ответов завершается с REJECTED и APLM0012, все последующие валятся с той же ошибкой. Думаю, что у вас должно наблюдаться то же самое и вы в реальности все равно делаете перезапрос заявки, но в результате истечения числа неуспешных попыток. Проверьте, как будет время, вопрос на самом деле интересный...
   NSSerg
 
895 - 06.07.18 - 13:09
(892) Четно говоря я не понимаю зачем.
Если бы она кучу времени подряд выдавала бы REJECTED с кодом ошибки APLM0012 -у меня бы обработка принудительно упала с assert-ом. Но падений обработки не было. Значит на повторные запросы приходит ответ без кода ошибки APLM0012.
Чем этот  ответ не устраивает? Если там REJECTED, то значит тикет отклонен, если нет, значит принят.
   spectre1978
 
896 - 06.07.18 - 13:10
(895) тем не менее она кучу времени подряд выдает REJECTED с кодом ошибки APLM0012. Точнее, постоянно после первого неудачного ответа с таким кодом. Я только что видел это своими глазами.
   NSSerg
 
897 - 06.07.18 - 13:13
(896) А ты без паузы повторные запросы шлешь?
У меня так одна такая ошибка (APLM0012) и осталась, от пятого числа. Когда засчитала что ВСД отклонена. Поэтому у меня статистики нет.
   spectre1978
 
898 - 06.07.18 - 13:17
(897) мало того что с паузой, так сейчас еще и под отладкой. Т.е. между ответами сейчас проходило секунд 10.
   NSSerg
 
899 - 06.07.18 - 13:26
Меркурий походу лёг.
   spectre1978
 
900 - 06.07.18 - 13:37
у меня только что возвращал остатки. Я на них и тренируюсь в обработке ALPM0012.
  1  2  3  4  5  6  7  8  9  10  11   

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