1с не работает без интернета
Обновлено: 06.07.2024
Добрый день!
Пытаюсь потестить Мобильный клиент в автономном режиме.
Платформа: 8.3.17.1549 (Клиент-сервер). Конфигурация самописная. Но, думаю, неважно.
Платформа мобильного клиента: 8.3.17.1549. Сборка мобильного клиента собрана с включенной возможностью работы офф-лайн.
На 8.3.15 (без автономного режима) все ок, работает без проблем.
В свойствах конфигурации - три документа и справочник добавил (для теста) для возможности работы в оффлайн.
Может чего-то не хватает в настройках? У кого-то есть опыть работы с Мобильным клиентом?
Буду очень благодарен
Спасибо!
Если что-то можете конкретное сказать - то - пожалуйста
Куда уж конкретнее. В руководстве разработчика есть отдельный раздел - "Мобильный клиент с автономным режимом".
Откуда следует, что для автономного режима как минимум необходим план обмена.
Причина сабжевого "какого-то обновления" тоже четко описана: мобильный клиент пытается обновить автономную конфигурацию и делает это при каждом соединении/восстановлении соединения. Поскольку это первый запуск - то он пытается "засосать" всю автономную конфигурацию. Ясен пень, это может занять существенное время и возможно стоит просто подождать. И на всякий случай проверить, какой состав автономной конфигурации вы указали. Может, вы там все ERP засосать пытаетесь. И понятное дело, что пока автономная конфигурация не загружена, мобильный клиент в автономном режиме работать не сможет - у него еще тупо нет локальных метаданных.
ЗЫ. Если вам почему-то казалось, что автономный режим - это опция мобильного клиента которую "включил и полетели", то это немножко не так. Иногда полезно и РТФМ. (1)Пойдём от простого. Галочки-то поставили, что именно у вас в автономке может работать? (2) Да: "В свойствах конфигурации - три документа и справочник добавил (для теста) для возможности работы в оффлайн."
(1) насколько помню офлайн корректно должен работать с 8.3.16.
А до этого это просто возможность не закрывать приложение при отваливании интернета.
Также это новая технология, рекомендую отписать в 1С.
(3) На 8.3.16 тоже пробовали - та же картина. По-идее, технология рабочая - видел презентацию разработчиков платформы. Что-то, думаю, не так в настройках. Знать бы - что именно (1) Соответствующую главу из руководства разработчика прочитали? Все требования к первому запуску выполнили? Или "научный тык" + "форум" = "наше все"? (6) Все, что нужно для работы мобильно клиента, сделано. В обычном режиме на 8.3.15 (без автономного режима) работаем.Если что-то можете конкретное сказать - то - пожалуйста Все, что нужно для работы мобильно клиента, сделано. В обычном режиме на 8.3.15 (без автономного режима) работаем.
Если что-то можете конкретное сказать - то - пожалуйста
Куда уж конкретнее. В руководстве разработчика есть отдельный раздел - "Мобильный клиент с автономным режимом".
Откуда следует, что для автономного режима как минимум необходим план обмена.
Причина сабжевого "какого-то обновления" тоже четко описана: мобильный клиент пытается обновить автономную конфигурацию и делает это при каждом соединении/восстановлении соединения. Поскольку это первый запуск - то он пытается "засосать" всю автономную конфигурацию. Ясен пень, это может занять существенное время и возможно стоит просто подождать. И на всякий случай проверить, какой состав автономной конфигурации вы указали. Может, вы там все ERP засосать пытаетесь. И понятное дело, что пока автономная конфигурация не загружена, мобильный клиент в автономном режиме работать не сможет - у него еще тупо нет локальных метаданных.
ЗЫ. Если вам почему-то казалось, что автономный режим - это опция мобильного клиента которую "включил и полетели", то это немножко не так. Иногда полезно и РТФМ. в самой конфигурации могут быть процедуры которы пытаются соединиться с чем то при запуске, в модуле приложения проверьте процедуру "ПередНачаломРаботыСистемы" (4) Никаких процедур обновления нет (а, если и были, то отработали) и судя по скрину так и есть: конфигурация наличие обновлений для себя проверяет (5) Никаких процедур обновления нет (и на 8.3.15 все нормально работает. Естественно, без автономного режима) (7) Да причём тут созданные объекты. Я про то, что в свойствах конфы, если стоит "Приложение для мобильной платформы", активным становится меню "Состав автономной конфигурации". И вот там нужно галочками проставить ваши объекты и выбрать приоритет основной сервер или автономный сервер. Просто у вас нигде не сказано, что это сделано. (12) Я это и имел ввиду - все это есть - настроено: "В свойствах конфигурации - три документа и справочник добавил (для теста) для возможности работы в оффлайн."
Что тут непонятно написано? (17) Упс. Этот момент я тоже как-то проглядел. Извиняюсь. Тогда странно. И сколько времени висит это самое "Database configuration update"? (17) можно попробовать выгрузить конфу в файлы и ужа там посмотреть проставлены флаги или нет
это на тот случай если баг действительно есть
По сути МК с автономным это два в одном (МП и МК в одной конфе/базе) и надо самому прописывать что делать при потере связи.
Метаданные дублируются - пока есть связь то обычный МК работает и МП на своих метаданных.
Связи нет - все МК пропадает и только что в МП синхронизировал осталось доступно.
Не вижу смысла особого в МК с автономным, когда можно ваять обычное МП и на опубликованных в центральной базе сервисах синхронизироваться с ней.
Мобильный клиент с автономным режимом совмещает в себе две этих технологии. Помимо обычного мобильного клиента он содержит локальный сервер с файловой базой данных. В рамках адаптации конфигурации под мобильный клиент с автономным режимом часть функциональности конфигурации может быть перенесена на мобильное устройство. Это, конечно, потребует некоторых трудозатрат, но это может оказаться проще, чем создавать с нуля приложение на мобильной платформе. В мобильном клиенте с автономным режимом можно реализовывать только ту автономную функциональность, которую критично иметь в офлайне, и реализовывать ее не всю сразу, а постепенно, по мере необходимости и доступности ресурсов (разработчиков). Мы ожидаем, что на практике затраты на решение задачи работы мобильного клиента при плохой связи / отсутствии связи при помощи мобильного клиента с автономным режимом будут существенно меньше по сравнению с разработкой приложения на мобильной платформе. При этом у мобильного клиента с автономным режимом будет возможность работы и офлайн (с доступом только к реализованной для офлайна функциональности), и онлайн (с полной функциональностью).
Переход в автономный режим осуществляется автоматически при исчезновении WiFi и мобильного интернета; пользователь может также включить его вручную в случае неустойчивой связи.
В рамках адаптации конфигурации под мобильный клиент с автономным режимом можно указать, какие данные конфигурации будут необходимы в автономном режиме:
Состав автономного режима можно задавать вплоть до реквизитов объектов. Например, в каком-то справочнике в определенном реквизите может находиться большой объем данных, который нецелесообразно скачивать на мобильное устройство.
В составе автономного режима также указывается приоритет открытия форм. В соответствии с приоритетом при открытии формы данные в нее будут грузиться с основного либо с автономного сервера.
Для обработки ситуации потери связи с основным сервером на клиенте появилось событие ПриИзмененииДоступностиОсновногоСервера.
С помощью метода ОсновнойСерверДоступен можно в любой момент проверить, есть ли соединение с основным сервером.
При наличии соединения возможны межсерверные вызовы; мобильный сервер вызывает основной сервер, аналогично как это бы сделал мобильный клиент. Через контекст ОсновнойСервер доступны все серверные модули, которые можно вызывать из клиента.
На основании состава автономного режима создается мобильное приложение с соответствующей структурой локальной базы. Это мобильное приложение может работать в одном из трех режимов (выбираемых пользователем для конфигурации в целом):
Обычный: объекты работают с приоритетом, заданным разработчиком в составе автономного режима.
Автономный (офлайн): приложение работает только с локальным сервером. Работа идет только с локально доступными объектами, остальные объекты недоступны. Стандартные команды интерфейса автоматически подстраиваются под офлайн режим (соответствующие пункты меню становятся недоступны).
Плохое соединение: приоритеты, заданные разработчиком в составе автономного режима, игнорируются, и все объекты, доступные локально, работают с локальным сервером. Например, в приведенном выше примере справочник Контрагенты откроется локально, даже если есть связь.
Рассмотрим ситуацию, когда мы открыли форму с основного сервера, и соединение с сервером после этого пропало. Эта форма станет недоступной до восстановления связи, но можно работать с другими формами, доступными локально. А если аналог открытой на основном сервере формы доступен локально – эту форму можно переоткрыть с локального сервера и продолжить с ней работать.
Обратная ситуация возникает, когда мы работаем с локальной формой, и соединение с сервером восстанавливается. Нам хочется открыть форму с сервера, потому что на ней доступно больше реквизитов. Для этого мы сделали механизм переоткрытия форм.
Переоткрыть форму можно программно вызовом метода Переоткрыть в обработчике события формы ПриИзмененииДоступностиОсновногоСервера. У уже открытой формы вызывается обработчик ПередПереоткрытием, у новой открываемой формы вызывается разработчик ПриПереоткрытии. В обработчиках этих событий можно проинициализировать вновь открываемую форму с учетом данных, введенных (но не сохраненных) на закрываемой форме. Перенести данные можно вручную кодом или автоматически методом ЗаполнитьПриПереоткрытии. Метод ЗаполнитьПриПереоткрытии вызывается автоматически после ПриПереоткрытии если параметр СтандартнаяОбработка = Истина. У метода ЗаполнитьПриПереоткрытии есть ограничения; если реквизиты имеют сложные типы (например, табличный документ или диаграмма) – скопировать их не получится (потому что, в частности, состояние табличного документа на клиенте доступно не полностью). В этом случае метод не скопирует ничего и сгенерирует исключение.
Процесс обмена данными между основным и локальным серверами в текущей реализации целиком возлагается на разработчика, адаптирующего конфигурацию под мобильный клиент с автономным режимом. С помощью планов обмена разработчик может вести учет изменений данных, и синхронизировать изменения, например, с помощью фоновых заданий. Это аналогично разработке приложения на мобильной платформе с обменом данными с приложением 1С на сервере.
В моём списке это были следующие ip-адреса:
npchk.nalog.ru
oasis-open.org
schemas.xmlsoap.org
api.orgregister.1c.ru
api.taxregister.1c.ru
api.orgaddress.1c.ru
Возможно, я что-то упустил, может просто где то не срабатывает правило на шлюзе. Нюансов может быть много.
Проблема была решена, указав настройки авторизации на прокси-сервере для передачи отчетности.
Что бы это сделать в конфигурации 1С БП 2.0 (да и 3.0 думаю тоже) необходимо зайти в меню:
Отчёты --> Регламентированные отчёт. Далее нажать кнопку "Настройки", после чего в открывшемся окне в поле "Документооборот с контролирующими органами" нажать на ссылку "здесь". Далее указать настройки авторизации на прокси сервере.
Всем спасибо.
Руслан Федосеев @martin74ua Куратор тега Системное администрирование
а что мешает открыть серверу с 1с полный доступ в инет на шлюзе?
Во первых, не виду смысла давать серверам полный доступ. Каждый должен ходить только туда куда ему позволено администратором. Во вторых в приведённом мной пример 1С сервер не причём, так как запрос идёт со стороны клиента, т.е. пк и 1С бухгалтера!
Руслан Федосеев @martin74ua Куратор тега Системное администрирование
Ну вам виднее.
Вы сначала уточните - 1с про слово прокси сервер в курсе? Если нет - придется отслеживать все нужные адреса и открывать доступ через нат. Еще учтите вариант - сегодня работает, завтра какой нить нужный клиент банк сменит ип адрес, но при этом останется на прежнем домене. И вы получите жалобу "вчера работало, сегодня нет". И опять заново отслеживать.
Так что вы подумайте, может проще открыть все? )
Если ну совсем не хотите открывать, то хотя бы логи включите на прокси и ловите там все реджекты. Ну и прокси - это зло, больше проблем.
При первом включении компьютера интернет не работает (получает стандартные виндовские 169. ниже скрин). Надо перезапускать интерфейс Ethernet, только тогда он получает IP и выходит в сеть. А если задать вручную IP и маску, и DNS, тогда он может пинговать в локальной сети, но на внешнюю не выходит, пока опять не перезагружу интерфейс Ethernet`а. Пробовал давать статику (привязку IP и Mac) через роутер и на самом компьютере, без результата. В таком случае при первом включении он видит локалку и работает с ней, но на внешку не выходит. Опять надо перезапускать интерфейс Ethernet. Из за чего может быть причина?
Сеть внутри идет так:
ОНТ модем (Alcatel) -> Archer C80 -> ПК. До этого все работало, после установки и лабораторки в EVE-NG начались такие проблемы. Снес, все равно не помогает.
Скрин при недоступном инете по DHCP
P.S. Win 10 Pro
Думаю из за гипервизора. Потому что все VMware интерфейсы отключил. Позже поколдую с ним, а пока придется потерпеть, т.к. он сейчас нужен.
Вкладка сетевые адаптеры. Если стоит значок вопроса,значит драйвер не установлен. Правой копкой мыши наведите,и обновите драйвер.
пилите bat скрипт, при необходимости добавьте паузы с помощью ping -n секунд localhost , прописываете его в шедулере, условие запуск компьютера, права администратора
Обнулите настройки сети через ком строку.
Удалите интерфейс в диспетчере устройств(без удаления драйвера), и лишние другие интерфейсы, если есть
Перезагрузитесь, проверьте
Посмотрите какие компоненты установлены в свойствах адаптера, удалите / отключите явно не нужные
Читайте также: