Бесплатный курс по Мобильной платформе 1C. Модуль 5
Модуль 5. Интеграция с типовой конфигурацией 1С
В ходе пятого модуля Вы изучите:
- Объект ПреобразованиеXSL
- Хранилище значений
Порядок обучения
Скачивайте теоретические материалы в PDF и видео-формате. Рекомендуем начинать именно с изучения теории.
Выполняйте практическое задание для закрепления полученных знаний.
Выполните самоконтроль, просмотрев видео-решение преподавателя.
Теоретические материалы
Итак, приступайте к изучению теоретического материала пятого модуля курса.
Пожалуйста, войдите на сайт (Войти), если Вы уже зарегистрированы или зарегистрируйтесь на сайте (Зарегистрироваться), чтобы получить доступ.
Регистрация занимает 1 минуту, но открывает доступ к материалам сайта.
Завершение тренинга
Подведем итоги. За эти несколько дней тренинга Вы многому научились и теперь можете разработать простое мобильное приложение.
Пора переходить к более сложным вопросам:
- Как разрабатывать коммерческие мобильные приложения?
- Какие есть подводные камни в мобильной платформе?
- Какие фишки в новых релизах мобильной платформы?
- Как вообще можно зарабатывать в этой нише?
Обо всем этом Вы узнаете из Полного курса по разработке Мобильных приложений на платформе «1С:Предприятие 8».
Отзывы по тренингу
Свои впечатления о пройденном курсе, предложения и пожелания Вы можете оставить на странице с отзывами бесплатного тренинга.
Финалистам предусмотрен бонус :)
Комментарии / обсуждение (101):
Комментарии закрыты
Скажите, а здесь уже можно выкладывать пример своей реализации XSL-преобразования для уточнения некоторых вопросов и правильно ли в принципе сделал?
А то я что-то решил что раз уж разбираться с этим монстром, то разбираться на сложных случаях – как и предлагали в задании, взял типовую конфигурацию “Управление торговлей 10.3” в качестве сервера, ну добавил туда наши план обмена и web-сервис.
В итоге получается что в номенклатуре 29 реквизитов всего, а нам нужна только ЕдиницаИзмерения, которой и нету в УТ.
В УТ документ называется ПоступлениеТоваровУслуг, а у меня ПоступлениеТоваровИУслуг… Ну и в УТ там 5 табличный частей, везде полно лишних реквизитов. И в регистре сведений Штрихкоды – Владелец имеет составной тип, куча левых измерений и ресурсов…
В итоге удалось сделать чтобы заработало, но это ужас если честно :)
Вот 5-ый модуль – это жесть!!! Еще в базовом-продвинутом курсе я спрашивал Евгения, как скрывать ненужные свойства у, скажем, товаров – т.к. все свойства не относятся к товару, но СКД их упрямо показывал все! Вручную я менял в XML-е и всё работало – одно было плохо, парсить и добавлять, то что не нужно показывать… а теперь можно намного проще всё это сделать! – это не знания, это супер-знания!
полностью поддерживаю – разница как между зажигалкой и паяльной станцией.
в связи с этим, один вопрос: в теории и практике описано как удалять “свойства” из определенного места XML, а есть ли метод обратный: добавлять в определенное место?
чуть ниже найдите shema.txt я кидал
Здравствуйте,
Такой вопрос.
Перед отправкой данных на клиент мы преобразовываем файл XML используя схему (происходит удаление лишних реквизитов).
А если я получаю данные с клиента, то я так понимаю мне нужно дополнить XML файл реквизитами? Если так, то нужно ли чтобы порядок реквизитов в XML файле соответствовал порядку реквизитов в объекте (например справочнике)?
в видео решения наглядно показано, что без этого никак. :(
Я видел удаление реквизитов.
А добавление в видео я не заметил :(
ну это да.. только если подумать, какая разница.
удаляем мы или добавляем, мы это делаем для того чтобы привести конструкции к идентичному виду. И если проблема с порядком есть в одном направлении, то она же будет и в обратном.
Порядок не важен – главное верный состав нужных полей
Тема очень интересна, но сама схема предложенная в теории слабовата. На практике гораздо чаще меняется реквизитный состав сервера нежели состав на мобильном устройстве. А это значит что после очередного обновления все агенты прекратят обмен с базой т.к. вы забыли обновить схему.
В идеале схема меняется только, тогда когда меняется реквизитный состав на новой версии мобильного приложения. т.о. в xsl нужно указывать список разрешенных полей, которые можно брать в теории из самого приложения и далее делать обмен.
Кстати, а кто нибудь задавался вопросом: Как, с помощью мобильного приложения, вывести документ на печать? Может кто-то уже реализовал эту функцию. Было бы очень интересно про это узнать
Сейчас стоит задача разработать рабочее место менеджера по продажам полностью на мобильной платформе, но без печати документов смысла будет не много…
печать на мобильных устройствах вещь весьма неопределенная. Как я понял у мобильной платформы собственных средств на это нет. Печать будет где, у менеджера? Если он использует мобильную платформу, то какой принтер он будет использовать?
Использоваться обычный принтер внутри сети.
одним из способов может быть отправка на почту, а потом на печать. Но это совсем не вариант…
вторым способом является
– создание табличного документа на сервере,
– сохранить его на диск,
– программно создать bat-файл с отправкой этого файла на принтер
Может есть еще способы?
если есть сеть, обычный принтер, то лучше добавить и обычный комп, взгромоздить на него 1С с веб-сервисом получающему задание на печать от мобильных и отсылающего его принтеру. Проще и надежней чем печать непосредственно с телефона.
Согласно СП печать с мобильного клиента (что клиент, что сервер) недоступна, поэтому только через стационарный компьютер… можно или скидывать куда-то и по регламенту (например раз в 2 мин) или вручную подтолкнуть или через веб-сервер “интерактивно” отправлять на печать.
А вообще конечно следим далее за развитием мобильной платформы, может что новое и появится
а у меня на телефоне – раздел Общие, там где “Спец. возможности”, “Дата и время”, “Подключение к ПК”, “О телефоне” есть и “Печать” – чтобы это значило?
может и сделают, может и нет – но телефоны уже поддерживают :)
так то не в мобильной платформе а в телефоне… андроид, думаю, не поймёт что такое табличный документ
это виртуальный принтер гугла.. печатает в пдф, или на заранее настроенный принтер подключенный к другому ПК.
Кроме, видел принтеры (кажется хюлет) использующие также технологию печати из облака без ПК посредника. И есть еще принтеры печатающие файлы с bluetooth но во всех трех случаях речь идет о применении софта 3ей стороны, который нужно подружить с 1С.
ну накидать самому софт который готовый отчёт оттуда заберёт и там-то его распечатает – не проблема
Тема 5 дня интересна и не знакома.
Однако использование шаблона сильно сужает область применения этих знаний, т.к. шаг влево, шаг вправо – здравствуй гугл, я снова с вопросом.
Есть ли какой-нибудь визуальный редактор схемы преобразования?
Есть ли внятный способ изучить весь спектр возможностей схемы преобразования (какие теги, инструкции и пр. за что отвечают) и как ими пользоваться на практике?
существование xsl-генератора, типа как получения из спец.конфигурации схем конвертации данных), или хотя бы редактора со справкой и списка готовых шаблонов на все случаи жизни, упрощало бы его применение.
общий смысл понятен, это интересно действительно при обмене с базой-интернет магазина, но ручное редактирование тегов и недостаток знаний по синтаксису, как-то настораживает трудоемкостью.
Настройку планов обмена и веб-сервисов преодолел успешно.
Застрял на схемах XSL преобразований.
Прояснение как всегда наступит с решением преподавателя.
так скучно
Скучно? Начало тренинг порядка 3500-4000 чел, по 4 заданию отчиталось менее 500… по 5 блоку отписалось пока менее 50… не все-же имеют возможность в рабочее время учёбу учить!
Решение выложили! :)
2 постами ниже schema.txt
так авторитетного решения по обратному преобразованию данных с клиента не будет? :(
Не думаю что это подсчитают грубой подсказкой. За полчаса ковыряний нашел-таки как красиво добавить реквизиты в объект
В исходной схеме после тега закрытия темплейта
Добавляем еще один темплейт.
Например в моем тесте он выглядил так
импорт
Смысл примерно такой – для каждой записи объекта номенклатуры,
копируем его содержимое и добавляем новую строку
Глупо конечно давать рекомендации в том чего сам непонимаешь :) но авось поможет. А может и меня кто-нибудь поправит еще более красивым способом.
блин.. все теги стираются
Вобщем в приложенном файле.. Думаю все просто
Я делал приблизительно так же. Мне показалось, что это вполне нормальный вариант решения.
Выглядит красиво!
Интегрируюсь с типовой УТ11.
Преобразование и в ту и в другую сторону делаю на сервере.
С сервера на клиент схему написал. (только в регистре штрихкодов сразу перетащил владельца в ресурсы, но теперь уже понимаю как там можно было сделать в схеме).
С клиента на сервер преобразование вроде бы проще, но ни в какую не хочет работать: я скопировал тэги, которых нет на клиенте из строки сериализованных объектов, которые сервер выгружает до обработки xslt. но не грузит. уже и сравнивал построчно – все тэги на месте, порядок даже одинаков. ошибку выдает посередине имени какого-нибудь тэга. С одной такой ошибкой справился – заново кусок из нескольких тэгов скопировал из эталонного xml, но со следующей ошибкой не помогает уже. Может быть, что при копировании какие-то символы не так перенеслись? уж не знаю что думать.
все получилось
Я тоже понял как удалять. А вот как изменить название поля, или не удалять по одному, а циклом к примеру перебрать и оставить только то что нужно. Но как я понимаю это не входит в рамки данного курса.
Коллеги, если честно рассчитывал что более продуктивное будет обсуждение в комментариях, а по большому счету все свелось к разбору одних и тех же ошибок без развития тем курса и обсуждения своих проблем/успехов при работе.
Вобщем решил поделиться своим опытом в создании приложения на мобильной платформе, думаю кому-то поможет. Жду конструктивной критики или вашего опыта в подобных разработках.
ну там большинство начало менее недели назад по этой теме… ошибки типовые, как-бы ожидаемо.
На самом деле – а решение преподавателя будет?
А то всю голову уже сломал. Для решения практического задания, считаю, что нужно при переносе с клиента на сервер добавлять недостающие реквизиты (атрибуты) в xml, а при синхронизации с сервера на клиент уже удалять их. Как удалять атрибуты в xml понятно (благодаря вебинару). А как добавить, не могу на скорую руку найти решение. Точно для себя определил, что нужно изучать XSL.
Поддерживаю коллег.
Не помешало бы пару рабочих примеров схем преобразования, в которых можно добавлять свои теги или переименовывать существующие,если вдруг, названия объектов на клиенте и сервере не совпадают.
Да, кстати, а решение тренера будет?
Конечно будет, сегодня выложим.
Здравствуйте,
Просмотрел вебинар, скачал базы клиента и сервера. По кнопке выполнить обмен данные с сервера по плану обмена выгружаются и преобразовываются по схеме преобразования XSL для корректной загрузки на клиент. В базе на сервере больше реквизитов чем на клиенте? Соответственно реквизиты в xml подрезаются. Если я на клиенте добавил например элемент справочника и выполняю обмен, значит я так понимаю снова нужно выполнять преобразование только в другую сторону. Т.е. добавлять реквизиты. Или я не верно думаю?
Если все так, то вопрос: не подскажете каким образом описать это действие в схеме преобразования XSL? Например вставить “Основание” после “Description”. Значки тегов убрал.
v8msg:Body”
CatalogObject.СтатьиРасхода
Ref 93596884-c008 /Ref
DeletionMark false /DeletionMark
Code 000000001 /Code
Description Проезд333 /Description
/CatalogObject.СтатьиРасхода
/v8msg:Body
Объединил конф Сервер с базой из Продвинутого курса после 2-го блока. Опубликовал базу. Поправил ссылку на web сервис в базе “Клиент”. Настроил узлы обмена.
Поправил схему преобразования, для удаления из выгрузки с сервера лишних реквизитов справочника Номенклатура
СхемаПреобразования = "<xsl:stylesheet version=""1.0"" xmlns:xsl=""http://www.w3.org/1999/XSL/Transform"" xmlns:v8msg=""http://v8.1c.ru/messages"">
| <xsl:output method=""xml"" encoding=""UTF-8""></xsl:output>
| <xsl:template match=""node() | @*"">
| <xsl:copy>
| <xsl:apply-templates select=""@* | node()""></xsl:apply>
| </xsl:copy>
| </xsl:template>
| <xsl:template match=""v8msg:Message/v8msg:Body/CatalogObject.Номенклатура/Поставщик"" ></xsl:template>
| <xsl:template match=""v8msg:Message/v8msg:Body/CatalogObject.Номенклатура/ПолноеНаименование"" ></xsl:template>
| <xsl:template match=""v8msg:Message/v8msg:Body/CatalogObject.Номенклатура/Артикул"" ></xsl:template>
| <xsl:template match=""v8msg:Message/v8msg:Body/CatalogObject.Номенклатура/Партия"" ></xsl:template>
| <xsl:template match=""v8msg:Message/v8msg:Body/CatalogObject.Номенклатура/Реквизит1"" ></xsl:template>
| <xsl:template match=""v8msg:Message/v8msg:Body/CatalogObject.Номенклатура/Реквизит2"" ></xsl:template>
|</xsl:stylesheet>";
Преобразование = Новый ПреобразованиеXSL;
Преобразование.ЗагрузитьИзСтроки(СхемаПреобразования);
Возврат Преобразование.ПреобразоватьИзСтроки(Начальный);
КонецФункции
Отправляю с клиента:
https://docs.google.com/document/d/1ViIXxi7bU4Dx9EyaXvnvzoOOuySp6GG7EZk12g5VapI/edit?usp=sharing
В отладчике на серверной базе происходит ошибка на строке “Данные = ПрочитатьXML(ЧтениеСообщения.ЧтениеXML);”
Собственно до преобразования дело не доходит.
Предполагаю что в “ЧтениеСообщения.ЧтениеXML” – не то что нужно для функции ПрочитатьXML
Пните где я ошибся.
Мне одному кажется что на реальных проектах очень сложно будет писать правила преобразования? мы же не один справочник выгружать будем а несколько десятков разнородных объектов, да и при изменении как клиента так и сервера переписивать правила преобразований. Помоэму образовалась необходимость в конфигурации типа “конвертации данных” но которая будет работать с мобильными конфигурациями.
может со временем появятся велосипеды. Но пока, создается впечатление что моб.приложения должны быть исключительно утилитарны, а значит и количество объектов должно быть минимизировано.
Да и КД порой не экономит время, а лишь портит нервы (или просто я “не умею его готовить”)
C вами согласен насчет сложности преобразования. По поводу “конвертации данных” для мобильного приложения может быть, но т.к. сейчас количество объектов в мобильном приложение ещё немного, т.е. даталогическую модель легко нарисовать на одном листе бумаге, то пока всё преобразование можно уложить в понятный и простой алгоритм формирования текстов сообщений непосредственно на сервере
На практике обычно по 4-6 систем в интеграции и далеко все они не 1С. Обычно под каждую системы пишем пакет XDTO для обеспечения соответствия схеме и предоставления точных требований к смежным системам – да это не просто, но помогают некоторые конструкторы, разрабатываемые в рамках внедряемой системы (например, такой присутствует в конфигурации Консолидация данных в механизме настройки импорта файла формата ФНС – там тоже используются схемы).
Ну и есть архитектурные решения – например использовать шину данных – при это все преобразования делать на ней а каждая система обменивается с шиной в своей структуре (естественно есть промышленные шины, но никто не мешает сделать шину на платформе 1С :) )
Ну первый раз даже обезъяне догадаться что банан можно сбить палкой было ой как не просто… второй раз всё уже в разы легче, а дальше ещё легче!
А где можно посмотреть решение 4 задания от преподавателя (для тех кто отчитался по заданию)?
Да вроде там же на странице
http://курсы-по-1с.рф/мобильная-платформа/флешмоб/модуль-4-часть-2-мультимедиа/
вопрос знатокам:
реально ли заставить одновременно работать 2 компоненты веб-сервисов: и 8.2 и 8.3 на одном апаче?
А что есть компоненты веб сервисов? Расширения платформы? С утра не въехал =)
Вы же публикуете конкретные базы, а не компоненты или платформы. По адресу ./base82 на сервере может жить база, работающая под 8.2, а по адресу ./base82 – база, работающая под 8.3
Опечатка: базу под 8.3 публикуем конечно в каталог ./base83
А как вы думаете происходит взаимодействие?
Для разных версий платформы разные длл для взаимодействия. Они не универсальны. Об этом и вопрос
если открыть конфиг апача, то там все очень просто – каждый алиас прописывает путь к конкретному каталогу публикации и врдшке, а указывает что это именно 1С строкой
SetHandler 1c-application
Сам же обработчик врдшки это компонента, которая в том же конфиге ранее прописана строкой вида
LoadModule _1cws_module “C:/Program Files/1cv8*/*.*.*.**/bin/wsap22.dll”
Так вот.. если я публикую базу из 8.2 – там прописывается 8.2, если из 8.3 – то она стирает 8.2 и ставит 8.3 и наоборот.
даже если я ручками пропишу обе компоненты, то, скорее всего, это приведет к неработоспособности конфига т.к. у компонент одинаковые имена.
Только поставить второй экземпляр апача – конфиги будут разные и каждый настроить на свою платформу. Если потом нужно смотреть на все публикации с одного сайта – то использовать, например, mod_proxy (с клиентами работает,с веб-сервисами не пробовал)
Спасибо, жаль и не утешительно.
на апаче не знаю, iis точно может, там привязки к нужным dll настраиваются достаточно просто, единственное на 6 iis были проблемы, с 5 и 7 проблем в настройке не встречал
а поподробней? В какую сторону копать?
На xp (iis 5) нужная версия библиотеки должна прописываться автоматом в зависимости от версии платформы из которой публикуете, просмотреть можно в свойствах по кнопке настройка.
На win7, winserver2008 (iis7) если не ошибаюсь при публикации обработчик прописывается для сайта целиком, для конкретного приложения можно переопределить обработчик, для этого кликаем на приложение, выбираем сопоставление обработчиков, добавляем новый обработчик вида “сопоставление сценария” и прописываем путь к нужной dll.
Смотрите скриншоты.
Воу. Спасибо. Пригодится :)
И прямо сразу же пригодилось =)
Это, собственно, та же задача если опубликовать несколько конфигурация на 8.2 и на 8.3. Изменил пути, все отлично ) Супер.
в общем-то апачу без особой разницы с той работать или с другой или с обоими
Реально, но придется ручками конфиг править, указав загрузку компонент разных платформ и настройку alias’ов по аналогии с типовой публикацией, но подключением обработчика нужной платформы.
Прлчитав 5й день не увидел практического применения xsl в обмене между основной базой и мобильным приложением. имхо, обычно перегружаются десяток реквизитов и всё :) может я мелко мыслю… незнаю незнаю =) но xls крутая штука однозначно Спасибо.
В этом есть смысл при использовании баз с разной структурой данных и использованием планов обмена.
Если честно пока тоже не могу найти применения в своей работе, но тема весьма интересная, наверняка скоро что-нибудь выстрелит.
стоит типовая база а вы к ней мобильного прикрутили… проходят годы, структура типовой меняется а ваш клиент продолжает работать с ней без вмешательства извне
Дмитрий, после 2-го дня я задавал вопрос, на который вы ответили “После просмотра 5 дня, все вопросы отпадут сами по себе.”
Так вот, 5 день просмотрел, обмен для разных конфигураций с помощью ПреобразованиеXSL сделал (кстати, а решение преподавателя будет?), а вопрос остался :)
Задачу 5-го дня можно решить без обработки XML, с помощью XDTO.
Кратко решение приблизительно такое:
1. Перед выгрузкой из конфигурации с меньшим к-вом реквизитов (клиент) создаем СериализаторXDTO на основании ФабрикиXDTO сервера (которая включает описание типов значений из http://v8.1c.ru/8.1/data/enterprise/current-config , ее можно получить из соединения с веб-сервисом )
2. Далее значение из клиентской базы записываем в XML не напрямую, а путем сериализации в объект XDTO созданным выше СериализаторомXDTO, установки методом объекта XDTO “Установить()” недостающих на клиенте реквизитов и последующей записи в XML полученного объекта XDTO.
3. При получении данных – обратная операция: из XML получаем ОбъектXDTO, методом объекта XDTO “Сбросить()” убираем лишние реквизиты, после чего преобразовываем объект XDTO в значение
Вопрос заключается в том, рассматривали ли вы такой путь решения задачи? Есть ли в нем какие-то нюансы, из-за которых его лучше не использовать?
Меня сомневаться заставляет то, что как внутри работает СереализаторXDTO я могу только догадываться и потому нет уверенности в том, что можно смело использовать преобразование значения из одной базы в объект XDTO по описанию Фабрики XDTO из другой базы (хотя это вроде бы работает на небольших примерах)
>>При получении данных – обратная операция: из XML получаем ОбъектXDTO, методом объекта XDTO “Сбросить()” убираем лишние реквизиты
Это действие выполняется на сервере до отправки?
Я пробовал все на клиенте уже после получения отправки:
из полученной строки XML создаем объект XDTO СериализаторомXDTO, который создан на основе фабрики XTDO из соединения с веб-сервисом (Объект XDTO будет создан такой же, как был на сервере при отправке), потом сбрасываем свойства, которых нет на клиенте и после этого ОбъектXDTO уже получиться преобразовать в значение на клиент.
Пока писал ответ подумал, что, наверное, это удобно при небольших отличиях в конфигурациях и нескольких разных “клиентских” базах (серверу не важно куда и в базу с какой конфигурацией отправлять, ему можно не знать структуру конфигурации принимающей строны), а вот если на “сервере” существенно больше данных, то будем много лишней информации передавать при обмене…
тащем-то, к тому я и спрашивал.
Сейчас сижу прикручиваю нашу маленьку конфу к УТ 10.3. И представить что все это в пустую передавать на клиент и заставлять телефон обрабатывать это – слишком жестоко.
__
Сижу с ошибкой: я правильно понимаю что при импорте данных с мобильной конфы в базу, 1С так же не сможет прочитать объект, пока не будут добавлены все свойства?
Угу вчера тоже с этим вопросом сидел :) С сервера в мобильный клиент в одну сторону забрать можно.. А назад? С клиента же придут убогие минимальные данные =)
Возвращаясь к одному из уроков, думаю лучше всего при больших различиях все-таки использовать промежуточную базу.
Т.е. имеем например:
1. УТ 10.3 или 11
2. Промежуточная база
3. Мобильное приложение.
метаданные 2 и 3 должны быть равны.
Тогда между 1 и 2 обмен делаем при помощи конвертации данных. А обмен между 2 и 3 при помощи УРБД.
stig, понятно что так проще технически, но актуализация данных становится в два раза большей проблемой.
Но тем не менее хотелось бы услышать ответ на вопрос
“можно ли смело использовать преобразование значения из одной базы в объект XDTO по описанию Фабрики XDTO из другой базы?”
Кажется, что все-таки есть ситуации, когда обмен по такой схеме оправдан (тем более, что обрабатывать-то XDTO-объекты можно и на сервере, просто тогда “сервер” должен знать конфигурацию “клиента”. Но в случае XSL-преобразования ситуация точно такая же).
—
Ну я тоже так понимаю. Для решения практического задания писал “Обратное” XSL-Преобразование.
интересен пример кода, где добавляются реквизиты и сбрасываются.
Набример у Сбросить(Параметр) есть 2 варианта по синтаксису:
– в параметр Выражение XPath, соответствующее свойству, у которого необходимо сбросить значение.
Как выражение XPath правильнее (и быстрее) сформировать? я достаточно интуитивно, может где и неправильно, поняла из видео что в приводимой схеме XSL было написано на каждом из трех языков: XSLT, XSL-FO и XPath. Пример строки с XPath – это когда удаляли тег Dedcription? Выражение, соответствующее свойству будет как-то так писаться?
– СвойствоXDTO – это, я так поняла, то что сами описывали в объекте XDTO в типах объектов (еще плаваю в понимании описания типов что и где)?
И еще в справке пишется, что “Сбрасывает значения указанного свойства”, т.е. значение, а не само свойство, свойство (реквизит) остается с пустым значением и при обмене будет вылетать ошибка? этот вариант теоретический, или его уже кто-то реализовал?
Этот вариант теоретический и проверенный на небольших примерах, которые опробовал пока делал практические задания.
Сброс значения, как показали эксперименты, приводит к тому, что в XML это значение вроде как не выгружается и при прямой передаче XDTO-объекта через веб-сервис тоже ошибок не возникает
У меня получалось установить/сбросить реквизиты если в качестве выражения XPath передавать просто имя реквизита. Можно еще через свойство как-то так:
Свойство = Серилизатор.Фабрика.Тип(“http://v8.1c.ru/8.1/data/enterprise/current-config”,”CatalogObject.Номенклатура”).Свойства.Получить(“ЕдиницаИзмерения”)
ОбъектДляВыгрузки.Установить(Свойство,”2″);
У меня вот Сбросить() на сервере тоже получилось. А как Установить() недостающие на клиенте поля, не сообразил.
У вас как получилось? Кусок кода можно глянуть (простите за наглость, не работал раньше с этими объектами).
ОбъектДляВыгрузки = Серилизатор.ЗаписатьXDTO(Выборка.ПолучитьОбъект());
ОбъектДляВыгрузки.Установить(“ЕдиницаИзмерения”,””);
Это в случае примитивных типов.
Для не примитивных не пробовал, но мне кажется, что должно сработать точно так же, только в качестве устанавливаемого значения, возможно, нужно будет использовать какой-то “пустой” XDTO-объект, который нужно будет создать из ФабрикиXDTO “сервера”
Идея интересная, никогда xslt не использовал, попробую. Есть реальные проекты, где это используется при обмене с мобильным приложением?
Но позвольте усомниться в использовании этой технологии в организации обмена между базами. Что смущает:
1.) Что делать, если объекты баз серверной и мобильного приложения очень сильно отличаются. Например, Контрагент в серверной базе адрес хранит в регистре сведений, а в мобильном приложении это реквизит Адрес в справочнике Контрагента. Это какую схему xslt придумывать придётся? ведь в стандартном плане обмен эти данные будут вообще в разных концах сообщения. Да и ещё нужно перед отправкой сложить адрес из регистра сведений в одну строку.
2.) В обмене главная надежность, стабильность. Например, серверная база перешла на платформу представит 8.5, у меня есть большие подозрения, что формат сообщения плана обмена останется тем же самим, т.е. нужно переделывать будет xslt изучая аналы документации от фирмы 1С. Поэтому вариант собственной сериализации, например, через массив структур и т.п. в этом смысле выглядит более стабильным.
3.) Если в основную базу добавили новый реквизит, я так понимаю обмен сразу прекратить работать, т.к. он не будет по умолчанию исключен из обмена. Т.е идея “убрать всё лишнее” мне нравится гораздо меньше, чем “выгружать только то что нужно”.
Теория красива и стойна… посмотрим что выйдет на практике.
Жаль что схема обрабатывает xml путем исключения: сейчас было бы удобно использовать перечисления только нужных полей.
//И что я раньше об xsl не слышал, как раз сейчас бы не помешала схема преобразования json в xml
Раскройте, пожалуйста, подробнее смысл задания: “Объедините серверную конфигурацию с Вашей информационной базой.”
Не совсем понял ДЗ 5 в плане объединения серверной конфигурации, нужно добиться чтобы справочник и документ был с разными составом реквизитов и сделать тогда уже обмен с МБ?
Пример. Берем в качестве примера типовую конфгурацию, в которой есть подобные нашим – поступление, ШК, номенклатура.
Накатываем на неё нашу серверную часть.
Состыковываем их разные по структуре объекты ( в реальной конфигурации, новом сервере объекты будут гораздо сложнее).
Составляем xls, преобразуем, отдаем клиенту. Получает. Празднуем! :)
Так все потерли, что даже теперь не ясно, есть ли смысл задавать вопросы здесь?.
А вопрос есть:
Web-сервисы и xsl преобразование возможно и в 8.2. Исходя из этого, можно ли разрабатывать серверную 1С хранящую данные и предоставляющую веб-сервисы под 8.2, а мобильную под 8.3?
Думаю что да. А что нам может помешать? Те же планы обмена должны успешно отрабатывать, вроде там с переходом на 8.3 ничего не менялось.
Однащначно да, у нас есть рабочий такой проект
спасибо. Чувствую у меня тоже скоро такой проект появится :)
Так с начала курса же объяснялось что веб-серивисы используются для интеграции разных информационных систем, на практике приходилось вызывать их из php и из powershella, тем более это будет работать на разных версиях одной платформы :) С планами обмена тоже все просто, когда-то при переходе с 8.0 на 8.1 на работе выполнялся стандартый обмен между базами на разных версиях платформы.
Где все вопросы? ))
Когда будем работать со штрихкодами? ^^
а что.. есть еще и надежда что мобильная 1С сможет распознавать штрихкоды? Или речь про сканеры штрихкода на андройде?
1С не умеет, но 1С может общаться с другими приложениями, которые могут помочь
Хотя и в мобильной платформе вроде обещали добавить что-то стандартное для распознавания. Но когда это будет… хтобызнал)
Возможно, как вариант, передавать скан – штрихкода на сервер, а обратно получать или штрих код или ошибку.
Это да, но хотелось бы автономии. Уж для считывания штрихкода обращаться к серверу это совсем ад(
Да, кстати, говорят на партнёрском семинаре в декабре 2013 в Москве было продемонстрировано сканирование инвернтаризационной ведомости мобильным устройством с очень быстрым (почти моментальным)и совершенно точным распознаванием!
платформу 8.3.5 (и соответственно соответсвующую ей мобильную платформу релизить обещат с декабря 2013, пока последний срок 30.04.2014)
есть сканеры штрихкодов(в т.ч. очень дешовые) которые можно подключить к мобильному устройству (через usb, например)
Возможно в бонусном модуле увидим. Ждем-с :)