УТ 11 . Но тема актуальна для любых обменов с использованием последних версий БСП. Обмен через локальный ресурс (каталог)
Сообщения закидываются в каталог туда регулярно вручную ответственным за это сотрудником.
Для автоматизации процесса созданы сценарии - сначала один загружает данные. Потом второй выгружает. Цикл - сутки.

Бывает так:

Выгружено сообщение 1
Сообщение из каталога забрано вручную, и позже помещен ответ от приемника об успешном получении
Сценарии загрузили подтверждение о получении сообщения 1 и выгрузили сообщение 2 (есть зарегистрированные изменения данных)
Сообщение забрано вручную, но ответ позже в каталог не помещен (человеческий фактор)
Выгружено сценарием сообщение 3 (есть зарегистрированные изменения данных)
Выгружено сценарием сообщение 4 (есть зарегистрированные изменения данных) + то, что содержалось в 3
Выгружено сценарием сообщение 5 (есть зарегистрированные изменения данных) + то, что содержалось в 3 + 4
Наконец, в каталог помещен ответ о получении приемником сообщения 2
Выгружено сценарием сообщение 6 (есть зарегистрированные изменения данных) + то, что содержалось в 3 + 4 + 5 (во всяком случае, мы на это очень надеемся, иначе головной боли не оберешься)

Вопрос: не проще было не выгружать 3, 4 и 5, пока не получен ответ о получении 2 ?

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

А когда наконец будет получен, то к шестому сообщению данные второго уже не приплюсуются, но это нас не спасет, ведь ответственный уже понес к приемнику номер 5, в которое включено все что накопилось, в том числе номер 2, и содержимое номер 2 полезет в базу-приемник по второму кругу.

Запуск обмена тем самым ответственным после закидывания сообщения в каталог не предлагать. Его квалификация максимум, что позволяет - перенести файл.

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

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

(3) что значит "настроить автоматом" ?  Комп с базой-приемником вообще в другом городе находится. Конечно, это не мешает воспользоваться любыми прогрессивными способами, от ftp-доступа до удаленных хранилищ, но в данном случае ручной перенос сообщений - пожелание руководства.

И вообще, смотрите на проблему шире. Речь о том, что типовой механизм обмена в принципе не умеет выполнять проверку на успешную загрузку. Где-то этот момент можно обойти, например организовав бесперебойный автоматический перенос файла-сообщения, а где-то - нельзя. И вообще, любой "бесперебойный" механизм поднимает лапки, как только местный провайдер ненароком оставляет вас без связи. Это вообще не панацея.

>>механизм поднимает лапки
ты еще забыл электриков, которые ненароком оставляют вас без света. вот где бидапичяль

ну вот, ну сам же понимаешь, что ерунду предложил

электрики, провайдеры, симпатичный курьер, задержавший ответственную работницу по пути к серваку... Лишняя проверка никогда не помешает. Кому, как не программистам это знать.

А тут... никакой проверки

так сделай!

(0) ты как-то забываешь, что обмен может быть не только двусторонним. И что? Тормозить все 20 узлов из-за того, что в Ебенидырске кто-то не скинул нужный файлик?

И вообще, CAP-теорема тебе в помощь

(7) то, что пересылается 2 раза - это и есть дополнительная проверка. А то, что вы предлагаете - это как раз полная ж.па. Потому что если сотрудник, например просто забыл скопировать этот файлик 2, или просто не донес его, эти данные потеряются навсегда.

(8) писал же - позиция заказчика мешает

(12) и странная вообще ситуация, файлик там максиму 2мбайта, чтобы скинуть его по почте и положить в нужную папку, надо 40 секунд. Где ваш сотрудник ходит 2 дня с этим файлом?

(9) не совсем въехал, о чем речь...  зачем тормозить другие узлы? Тормозятся только те узлы, у которых не было успешной загрузки.  И действительно, такие задержки для некоторых организаций могут быть чреваты.  Но это уже проблемы тех, кто принял решение поручить перенос человеку.

(11) То, что пересылается 2 раза - своего рода страховка, согласен. Несущая дополнительные расходы в виде увеличенного размера файла, времени, затрачиваемого на загрузку в базе-приемнике и т.д.

Если сотрудник потерял файлик, обмен не запустится, покуда сотрудник снова не "сходит" к базе-приемнику за новой копией. И делов-то.
Никаких потерь данных не будет в принципе, ведь мы не меняем алгоритмы обмена и механизм подтверждений 1С' ки . Только отсекаем лишние выгрузки, абсолютно не имеющие смысла.

Ну е-мое, ну вспомните, ведь в некоторых конфах на обычных формах еще остались старые формы обмена - там всегда были эти галки - "Выгружать данные при успешной загузке".  Я обожаю УФ и свежие технологии. Но накопленный опыт-то зачем отметать?

(0)  может один раз напрячься и вести учет в одной базе и решить вопрос с доступом к ней.... Имха - не первый раз натыкаюсь на вынос мозга с урбд. Да в коце концов загнать всех  в типовую на УФ и вебсервак.

(13)  ну человеческий фактор, ну я не утверждаю, что это будет регулярно. Да и причем тут сотрудник? Передача файла может осуществляться самыми разными способами.

Речь о том, что в принципе сценарии обмена не имеют вообще каких бы то ни было дополнительных настроек проверок и взаимодействия друг с другом. Вот расписание имеет аж 4 вкладки, и еще дополнительные параметры, получаемые из других форм. А сценарии - даже без проверки успешности загрузки.

Ведь каждый столкнется с этим рано или поздно.

окупится с лихвой... А пока - выгрузки ...загрузки.... и так целыми днями..где здесь суть ?

(16) Зачем сталкиваться с выносом мозга ?

(15) Да там не УРБД... Да какая разница. Галка была. Галки не стало. А актуальности она не потеряла.

Веб-сервак был бы вообще идеален в данном случае.  Не хотят.

Ладно, господа. Все понятно. Думал, мож недопонимаю чего, но по высказываниям вашим понял, что ситуация ясна до безобразия.  Буду озвучивать подробности в кабинетах.

Эх, опять поднимется какой-нибудь умудренный большим опытом товарищЧ и скажет, что вот мол, нафига нам были эти свежие идеи, обновленные программы, вот в старых как все было по путю, и галки все были, какие надо...

(19) А насчет того что свет оключат ,провайдер  отвалится т.е. ограничение доступа к каналу - это пусть специальнообученные люди занимаются .Они обычно в циско шарят , в договорах с ростелекомом и прочее.

(19) вообще-то такой ситуации, как в (0) не может случиться:

Выгружено сценарием сообщение 3 (есть зарегистрированные изменения данных)
Выгружено сценарием сообщение 4 (есть зарегистрированные изменения данных) + то, что содержалось в 3
Выгружено сценарием сообщение 5 (есть зарегистрированные изменения данных) + то, что содержалось в 3 + 4

когда записывается сообщение (4) сообщение (3) стирается, а когда запишется (5), сотрется (4). То есть на самом деле ваш сотрудник заберет после 2 только сообщение 6.

(20) от автоматических каналов отказались по соображениям безопасности, и не думаю, что этот вариант еще вообще будет рассматриваться

(21)  сотрудник, принеся наконец  подтверждение приема сообщения номер , обнаружит лежащее 5, и заберет его прежде, чем оно будет заменено на 6

А уж внутри 5 будет и накопившееся 2, и 3, и 4 и т.д.

* подтверждение приема сообщения номер 2

(23) у сотруника тоже ведь сценарий: загрузка-выгрузка. То есть принеся сообщение и загрузив его, он не будет брать сообщение 5. Ну если он не полный придурок. Он сделает выгрузку и заберет сообщение 6, в котором не про 2.

(23) все правильно. либо в сообщение обмена будут записываться все изменения на момент создания сообщения, либо ты будешь вынужден загружать все обновления подряд без пропусков.

и 2 полезет в приемник  по второму кругу.  А там некоторые моменты надо вручную проверять. И бухи возмутятся: какого хрена мы будем по второму разу одно и тоже проверять. И будут правы.

Верно все-таки сказал zulu_mix .  Бидапичяль.

(25) спасибо, я посмеялся.

Кстати, Вам спасибо, Вы не первый раз помогаете советами.

(26) правильно тут было бы только одно: отказ выгрузки, если не было загрузки

все остальное - головная боль.  опять спасибо разработчикам

>>бухи возмутятся: какого хрена мы будем по второму разу одно и тоже проверять
значит правила кривые. надо писать так, чтобы после загрузки ничего руками пыркать не пришлось

(30) не согласен, правила типовые. И регулярно бывает, что что-то надо проверять/править. Это уже от конкретных обстоятельств зависит.

А если б загружалось без сообщений об ошибках и необходимости что-либо вручную контролировать, тогда не смутила бы необходимость подождать подольше из-за второй раз пришедших данных?

внезапно в мозгу нарисовалась картина дальнейших событий после того, как сотрудник уволок номер 5. Итак:

Наконец, в каталог помещен ответ о получении приемником сообщения 2 и забрано сообщение 5
Выгружено сценарием сообщение 6 (нашлись новые зарегистрированные изменения данных) + то, что содержалось в 3 + 4 + 5
В каталог помещен ответ о получении 5 и забрано сообщение 6 (то есть содержимое 5 поехало в приемник по второму кругу)

В итоге я уже молчу о том, что дай Бог, чтобы при всей этой заварушке корректно прошла передача 3 и 4. И тем более о том, что, как справедливо замечено в (9) , обмен на самом деле двусторонний, а главное, сотрудник может опять же задержаться с ответом о получении 5...

Нет, однозначно, тот, кто убрал галку, знает толк в извращениях.

(32) все мозг продолжает выносить  :)

(22) :)