INFOSTART EVENT 2018 EDUCATION

Второй тур голосования за доклады.
Окончание 5 сентября.

Коробов Алексей | Генеральный директор | ООО "Корус Баланс"

«Управление бизнес-процессами предприятия и организация работы сотрудников»

Общие вопросы * Проблемы при автоматизации бизнес-процессов. * Проблемы при эксплуатации бизнес-процессов. * Человеческий фактор или может ли лень стать стимулом для внедрения и развития системы управления. * Как охватить весь спектр проблем предприятия и не захлебнуться. Взгляд на проблему со стороны разработчиков * Проблемы разработчиков при эксплуатации сложных гибко настраиваемых систем. Разработка в режиме предприятия? Возможно? Зачем? * Коллективная разработка ключ к развитию. * Проблемы оптимизации и скорости работы при универсальном подходе разработки. Программа автоматизации как живой организм. Сколько сил нужно чтобы вдохнуть в него жизнь? * Общее описание получившейся системы и взаимодействия ее подсистем. Описание потенциала подобных систем. Будут озвучены проблемы и вопросы автоматизации бизнес-процессов предприятия по каждому из тезисов, с которыми пришлось столкнуться на личном опыте. Описаны удачные способы решения или обходы проблем, примененные у клиентов.

1. Ukubaeva 07.11.16 10:03 Сейчас в теме

Обмен мобильного приложения с центральной базой через план обмена

Мобильное приложение платформа 8.3.9.74
Обмен с центральной базой через web-сервис, регистрация изменений через план обмена - Центральный узел и множество узлов для каждого мобильного устройства. Моб. приложение установлено на 100 устройствах, каждое из них обращается к плану обмена для выгрузки и загрузки данных примерно каждые 5-10 минут. В результате на каждом втором устройстве обмен заканчивается ошибкой "Конфликт блокировок при выполнении транзакции", обмен не производится. Подскажите, пожалуйста, как можно более оптимально организовать обмен в данном случае? Просто изначально не предполагалось использование такого большого количества устройств, думали, их будет около десятка, и при тестировании таких проблем не было, сейчас же, спустя год работы приложения, надо эту сложность устранить малой кровью. Спасибо
Ответы
Сортировка: Древо
2. ipoloskov 63 07.11.16 11:57 Сейчас в теме
Очевидно, блокировка происходит при выгрузке изменений из ЦУ в МУ (при чтении изменений из плана обмена). При записи изменений МУ - ЦУ блокируется только текущий записываемый объект, при чтении - все таблицы изменений.
Таким образом, нужно минимизировать время блокировки при чтении изменений в ЦУ. Прочитать изменения в переменную (например, хранилище значений) - снять блокировку - начать выгрузку данных из хранилища в МУ (длительный процесс).

Порядок действий в ЦУ должен быть такой (так приводится в демо-примерах):
1. Получение данных из МУ.
2. Выгрузка данных в МУ.
Посмотрите, не поменяли ли вы их местами. Нет ли в начале процедуры чтения данных из плана обмена, вызывающего блокировки, которые сохраняются до конца транзакции.
3. Ukubaeva 07.11.16 12:26 Сейчас в теме
(2) Порядок проверила - там все верно. Судя по наблюдению за процессом обмена - одновременно обменяться пытаются около 5-10 устройств, они неизбежно вызывают блокировки... Пока я вижу только два выхода - 1) Переписывать все в обход плана обмена, 2) Переводить все в фоновый режим без вывода ошибок - когда-нибудь да обменяется, а ошибки не будут нервировать пользователей
4. ipoloskov 63 07.11.16 12:36 Сейчас в теме
(3) Можно попробовать сделать так:
В ЦУ запустить фоновое задание, которое раз в 10 минут формирует пакет выгрузки для всех узлов. Чтобы исключить "мертвые" узлы, можно анализировать дату/время последнего получения данных от них. Фоновое задание формирует пакет выгрузки и помещает его в регистр сведений с измерением "УзелОбмена".
МУ при обращении к ЦУ, берет данные для выгрузки из этого регистра сведений, не читая данные из плана обмена.

Тут может быть опасность, что фоновое задание будет без перерыва выгружать данные и, соответственно, постоянно блокировать план обмена, так что никто не сможет в него ничего записать.
5. Ukubaeva 07.11.16 13:02 Сейчас в теме
(4) ну можно в принципе, чтобы и МУ писало свои изменения в регистр, а фоновое задание в ЦУ читало их оттуда? Правильно? или я что то не так поняла?
6. DitriX 2764 08.11.16 10:39 Сейчас в теме
Вот за такие посты реально обидно :( Ты тут всем по 100500 раз рассказываешь, на курсах, в статьях, на конференциях, и все-равно одно и тоже :)

Все просто. НЕ НАДО ДЕЛАТЬ ХОЛОСТЫЕ ВЫЗОВЫ!!! ЗАБУДЬТЕ!!! АУ!!! Мобильная, это не стационарная. У вас есть ID мобильного устрйоства, по нему вы можете послать уведомление.

Итого, весь процес выглядит так:
1. План обмена с фиксированными изменениями, у каждого узла есть реквизит ID пуш сообщения
2. Регламент, который получает факт наличия изменения и высылает приглашение на обновление 2-3 клиентам.
3. Мобильники получив пуш или сразу обновляются, или позже, если сейчас не в 1с.
4. Радуемся жизни.

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

З.Ы. Накипело, стабильно раз в неделю получаю такого рода вопросы :)
dj_serega; Ukubaeva; +2 Ответить
7. Ukubaeva 11.11.16 15:46 Сейчас в теме
(6) Спасибо!
Но у меня МУ инициируют обмен в тот момент, когда на них появляются данные для передачи. И заодно забирают зарегистрированные для них измененные данные. С большим количеством МУ неизбежны блокировки при использовании плана обмена. Или я Вас неправильно понимаю...
8. spezc 484 21.11.16 11:54 Сейчас в теме
Проблема в том, обмен может происходить только с одним узлом за раз, так как при обмене блокируется вся таблица изменений. Тут несколько вариантов:

1. Отправлять изменения чаще и маленькими порциями в рамках одного плана обмена.
2. Добавить несколько планов обмена - например один для справочников, другой для документов и регистров.

И конечно, перепишите на http сервис, говорят он работает быстрее чем web-сервис.

А вообще следует провести замеры времени при загрузке обычного пакета от МУ. Обычно размер данных от МУ довольно небольшой, объем измененных данных тоже, соответственно скорость загрузки их должна быть высокой. Как вариант - при загрузке из МУ отключить все возможные проверки и отключить проведение по регистрам (все то, что требует времени при записи).
9. Ukubaeva 28.11.16 17:03 Сейчас в теме
В продолжение темы. Прошу не ругать, потому что приложение уже второй год работает, сотня одновременно работающих и обменивающихся планшетов. И при этом нельзя кардинально ничего менять, потому что при обновлении необходимо обеспечить возможность одновременной работы как старой, так и новой версии.
Я сделала следующим образом:
1) убрала ручной обмен - перевела все в фоновый режим
2) убрала авторегистрацию объектов, записываю измененные объекты в регистр
3) фоновым заданием из этого регистра регистрирую изменения в плане обмена, данные регистра удаляю. Следом инициирую обмен с центральной базой.
При этом пользователи продолжают работать на планшетах - делают документы и записи регистра с фотографиями.
По большей части приложение в целом и обмен работают корректно. До тех пор, пока в процессе обмена приложение не в центральной базе не столкнется с тем, что план обмена занят другим узлом. При этом фоновое задание завершается аварийно и по какой то причине блокирует таблицу config, потому что при попытке сделать что либо в этот момент в приложении выдается ошибка: конфликт блокировок при выполнении транзакции - не удалось заблокировать таблицу config. Помогите, пожалуйста, вторую неделю сижу с этой проблемой уже... Спасибо!
10. spezc 484 29.11.16 10:17 Сейчас в теме
(9) если честно, сомнительный вариант. на мой взгляд путь тут единственный - сокращение времени одного обмена, увеличена интервала между обменами.
11. Ukubaeva 29.11.16 11:13 Сейчас в теме
(10)Спасибо за ответ. Как показала практика, вылет программы и ошибки про конфликт блокировок и таблицу cinfig возникают в том случае, когда фоновое задание завершено аварийно. В моем случае фоновое задание - это обмен через веб-сервис. Если произошла ошибка при выполнении операции веб-сервиса. Я исключила возможные ошибки при выполнении операций веб-сервиса, но я не могу исключить ошибку, когда превышено время ожидания подключения к веб-сервису. Например, когда планшет отправляет запрос на подключение на сервер, а там уже висят в ожидании 10 пользователей. В таком случае ошибка все равно возникает. Как результат - приложение вылетает с ошибкой снова, хоть это и произошло в фоне. На стационарной платформе, конечно же, вылета не происходит в таких случаях. И как бы я не старалась свести к минимуму ошибки операций веб-сервиса, в некоторых случаях они неизбежны, и поэтому неизбежен вылет приложения. Поэтому на мой взгляд тут либо закрывать глаза на эту ошибку и просто перезапускать приложение, что совсем не комильфо... Либо переводить пользователей на ручной обмен, и придумать механизм, как заставить их производить обмен как можно чаще, чтобы избежать большого размера пакета при обмене
12. ipoloskov 63 29.11.16 11:16 Сейчас в теме
16. spezc 484 29.11.16 12:49 Сейчас в теме
13. TODD22 17 29.11.16 11:18 Сейчас в теме
Либо переводить пользователей на ручной обмен, и придумать механизм, как заставить их производить обмен как можно чаще, чтобы избежать большого размера пакета при обмене

А пакеты анализировали? В них точно ничего лишнего? Может там какие нибудь объекты регистрируются которые регистрироваться не должны.

Например один талантливый парень написал загрузку Номенклатуры из одной базы в базу с РИБ на очень много узлов. И ничего лучше не придумал как обновлять все 10000 номенклатурных позиций при загрузке. А из них изменялись за весь период может всего 100-150 номенклатурных позиций. Но каждый раз в обмен регистрировались все 10 тыс. Которые потом расходились по узлам. И обмен между узлами из за этого шёл по 10-20 минут.
14. Ukubaeva 29.11.16 11:21 Сейчас в теме
(13)нет, там все очень аскетично - только все самое необходимое. Конечно же, в первую очередь оптимизировался именно обмен - но это не помогло. Вся загвоздка именно в большом количестве одновременно работающих пользователей
15. TODD22 17 29.11.16 11:24 Сейчас в теме
Тогда разносите пользователей по времени.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии


Программист 1С
Москва
зарплата от 100 000 руб. до 200 000 руб.
Полный день

Преподаватель 1С
Санкт-Петербург
Полный день

Удаленный ИТ-журналист
Санкт-Петербург
По совместительству

Удаленный бизнес-аналитик 1С
Санкт-Петербург
Временный (на проект)