Есть сильно доработанная ут 10. Встал вопрос в мобильном приложении, теперь на распутье: делать ли клон частей ут и делать обмены или пилить оригинальную конфу. Кто что скажет по опыту?

(0)
Пили мобильный клиент и да будет тебе счастье без обменов и прочих конвертаций

(1) В смысле в своей УТ все модули прошерстить на предмет будет он там в мобильном клиенте или нет и соответственно препроцессоры вставить?

Я бы запилил отдельную конфу с минимальным функционалом + план обмена.

(3) А если там очень много чего обменивать?

(4) Насколько много?

Если для мобильного приложения достаточно онлайн-клиента (т.е. нет нужды, например, при отлупе связи чего-то все равно сохранять локально на МУ и отправлять потом), то смотреть в сторону мобильного клиента.
Если нужна оффлайн-работа на МУ, то смысл в отдельной базе? Пилить обмен в оригинальной конфе. Если делать стандартизованно, то обвязка с универсальным обменом по правилам конвертации заходит на ура. Но можно, конечно, и "по-дедовски" - передавать в хттп-сервисы массивы или ТЗ, в которых структуры с реквизитами объектов из МП

Ну и посмотреть на какие-нибудь "Заказы" или "Мобильную кассу" - вдруг там половина нужного уже есть

Нету там половины, много очень нестандартного и связанного с основной конфой, к сожалению.

(6)
Правила конвертации если я не ошибаюсь в обмене с мобильными приложениями не работают же ж... Или это не так?

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

(0)
Мы разрабатывали мобильное приложение для своих удаленных точек (их больше 170)
Одно из требований было Офф-лайн.
В итоге ведущий разраб устав от постоянного геморроя с обменами плюнул и сделал мобильный клиент (мобильное приложение на хттп-сервисах). Это было тогда, когда мобильного клиенте у 1С еще не было. В итоге оказалось что офф-лайн не очень-то и нужно было бизнесу...

Сейчас это можно было бы сделать из коробки на мобильных клиентах в разы быстрее и дешевле, чем тогда...

(0)Ну что за подкидывание монетки на мисте...Тут все просто. Или ты МОЖЕШЬ сам или НЕТ

Плюнул всё переводить в управляемый режим. Во всех модулях прописать, кучу галочек проставить. Ну его на..
Буду сервисами пользоваться )
Тот еще конечно гемор но блин всю конфу на упр перевести это дорого стоит )

(0) Пили приложение. Только не на 1С

(13)
Тогда я бы сделал так:
Параллельная база на 8.3 с реализованным мобильным клиентом.
Содержит только данные, которые нужны на мобильном клиенте, не более.
И обмен основная база <-> база мобильного клиента на конвертации данных.
Это будет работать хорошо и в реализации не затратно.

(9) В каком обмене?
Правила конвертации - это обработка + xml-строка файла обмена, отправляемая в приемник и там разбираемая. Все конечно же работает.

(16) Между сервером и базёнке на мобилке.

(16)
Я про Конвертацию данных писал

Хз о чем ты

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

(20) "причем,можно даже разные версии платформы использовать"
Вот вам большой пролетарский болт! Дорогой товарисчЪ. Версии клиента и ком-коннектора должны совпадать до последней бубочки.

(21) Но версия ком-коннектора может не совпадать с релизом платформы той инфобазы, в которой этот ком-коннектор создается

Так всё таки можно com или нельзя и какая скорость? Я пока пытаюсь через обмены запилить и пока только грабли (

Какая еще скорость?

Скорость соединения по com

Меньше чем за 0.5 секунд вряд ли соединение будет устанавливаться

Ну т.е. получаем тормоза, жжжжжжаль.

СОМ явно лишнее тут.
Храните нужные данные в самой базе.
Или на крайний случай делайте http-сервисы. Они отрабатывают в разы быстрее чем СОМ.

Какие тормоза-то?

(28) Ну вот и думаю по поводу сервисов, но мне как раз нужно что бы данные из ЦБ брались побыстрее и обрабатывались на клиенте и возвращались на ЦБ. Поэтому думаю про сервисы, но чёт пока затык. Позже может тему создам если сам совсем встряну.

(30) Вы на мобильном клиенте псевдо онлайн что ли делаете? Делайте оффлайн.

(31) Мне надо онлайн (
За 5 секунд может всё поменяться раз 20

(32) делай на метадате js

тут и онлайн и если и оффлайн одновременно

(33) А его можно прикрутить к WinCE?

(35) если там браузер запускается, то все будет работать

(33)
К чему такие усложнения?)
Чем механизмы 1С не подходят?)

(36)
Боюсь там и к браузеру некоторые требования существуют

(38) js тралируется в ес5, но вот по произовдительности конечно запас должен быть.
Но на тормозе и 1с особо не запустишь

А WinCE тут причем? Ведроид и Джобос

(39) ты вообще в курсе, что такое windows ce?

(0) а мобильное приложение для клиентов или для сотрудников?
Если для сотрудников, то однозначно Своё + обмены.
Т.е. как в (20), но без ком. Просто отдельная база, где есть то, что нужно и обмены между ней и основной. Один фиг в мобильном приложении не нужен весь функционал и все объекты из ут.

А если для клиентов, то тут только сторонний сервис, к которому будешь обращаться ты через АПИ для выгрузки/загрузки нужных данных.

(42)
Почему для клиентов вариант "Своё + обмены" не подходит?

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

(44) + не хотелось бы пускать в сетку кого-то стороннего...

Приложение будет и для своих и для чужих. Общаться через com думаю не стоит, буду мутить сервисы.

(41) А что на вин це браузер не запускается?

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

(48) Ты сам делал что-нибудь на метадате?

ну кроме хеллоуворлд

метадатчики как бэ сами говорят "не надо использовать метадату там где можно обойтись без неё"

Я за уменьшение геммороя при построении системы. Если для системы уведомлений дизайнеров (2-3 пуша раз в день на человека) о заказе нужно купить шаттл то ну его на эту задачу.

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

Я вообще про wce не понял, Андрюша и АйОйОсь актуальны, а это реликт и мертворожденный пережиток прошлого.

"для системы уведомлений дизайнеров (2-3 пуша раз в день на человека) о заказе" // Это вообще решается одним ХТТП-сервисом (с парой операций в нем) в основной инфобазе

Какие переводы форм на УФ или СОМ-соединения ты придумал, Я хз

(46) ну если так, то хорошенько подумай про безопасность...
ИМХО, не стоить светить в инет свою базу, лучше какую-нибудь ограниченную прослойку вставить(тут надо будет хорошенько продумать варианты взаимодействия этой прослойки с основной базой, ИМХО, веб/хттп-сервисы в основной тут не лучший вариант, лучше бы эта прослойка была пассивна в этом взаимодействии)...
Так же желательно, чтобы прослойка работала на отдельном канале, чтобы основной не лег, когда его будут ддосить...ну и админ нужен хороший, который грамотно настроит оборудование...