Всегда приятно получать обратную связь, особенно такую положительную)) Да уж, видео получилось не маленьким, но надеюсь, не нудным, и будет многим полезно:)
@@polite5802 Раздобудь Систему стандартов и методик разработки конфигураций. Там все что касается лучших практик по 1С. Ну и почитай что-нибудь общепрограммистское, того же МакКонелла "Совершенный код", например. и больше практики))
Благодарю за подписку!)) Тема обширная, и потому видео получилось объемное. Подписчики попросили про XDTO, вот и постарался :) P.S.: если есть пожелания по темам новых видео - пишите, обязательно рассмотрю!
Подскажите пожалуйста, как правильно определить какого типа нужно передавать параметр в SOAP запрос (то есть, иногда в определенных веб сервисах мы передаем сразу примитивы, в других мы допустим сериализуем структуру 1С в объект XDTO, в третьих мы получаем сам тип сервиса на основании его создаем объект XDTO заполняем параметры а потом этот объект передаем как параметр), как этот момент точно определять какой тип нужен в том или ином случае?
Спасибо за интересный вопрос. Преимущество SOAP сервисов в том, что они имеют схему WSDL. Собственно, все что внутри SOAP сервиса - какие методы есть, какие у этих методов параметры, какие у этих параметров типы, и т.д. - все это описывается в схеме WSDL. Следовательно, чтобы узнать, какой тип параметра нужно указать при вызове того или иного SOAP сервиса, нужно смотреть его схему. На помощь могут придти специализированные программы для тестирования и выполнения веб-сервисов, например SOAP UI или Postman.
Здравствуйте. Спасибо за ролик. А можно ли как-то проверить xml - файл на соответствие xsd- схеме (отдельный xsd-файл) и получить ошибки при расхождении?
xml-валидация средствами 1С достаточно ограниченная. Есть метод Проверить() у объекта XDTO, и по сути все. Т.е. волшебной кнопки нет, придется писать много кода. И нужно иметь в виду, что файл, валидный по стандартам xml может не читаться 1С. А так используют внешние способы проверки (msxml, в частности), и из 1С их только вызывают.
В целом еще долго будут актуальны, т.к. есть масса корпоративных приложений, сервисов, и прочего, использующие SOAP сервисы и/или xml. Крупный бизнес и госсектор достаточно неповоротливы, и не будут торопиться менять устоявшиеся надежные технологии. JSON же, мне кажется, больше востребован в веб-приложениях, микросервисах и т.п. У нас в организации используются и те и те механизмы. Постепенно отказываемся от SOAP в сторону http-сервисов, т.к. их проще поддерживать и разрабатывать. но за счет формализации WSDL схем есть кодогенерация - так что все равно выбор не очевиден )))
Xdto умеет работать и с json форматом. Правда тянет туда лишний мусор. Для себя сдедал вьівод что читать json удобно по модели xdto, а вот формировать гораздо удобнее из структурьі.
Единственное видео в котором многое не понял. Если будет видео в котором будет подробно создаваться пакет, в котором будет описано почему тут указываем то, а в другом иное и дальше применение его в веб сервисе, тогда будет намного понятнее. Например как создавали пакет WS_goods. Если как сделали "ЕдиницуИзмерения" вроде разобрался (Проставил типы децимал и стринг) и далее прицепил к номенклатуре, а вот Со статьей затрат непонятно. что там? Статья затрат это Перечисление или нет, какой тип должен быть там у элементов не ясно.
В XDTO прямая аналогия со структурой метаданных - есть примитивные типы, а есть ссылочные. И единица измерения и статья затрат - это ссылочные типы, это можно определить по одинаковым значкам. Самый лучший вариант поразбираться - выгрузить CurrentConfig и начать его копать, одновременно сопоставляя с метаданными в конфигурации. Ну и читать спецификацию этого формата - про оффсеты, типы данных, и т.п.
@@alexcode_1c Более менее понятно. А как быть если будет содержаться составной ссылочный тип ( док. Приходная и возврат)? Или это не поддерживается? и как быть потом с сериализацией?
Снова же самый простой способ разобраться - выгрузить current-config и посмотреть :) По идее там может быть тип anyType или anyRef. Ну а сериализацию / десериализацию можно проверить экспериментально. Для каких-нибудь планов видов характеристик, например, может записываться тип значения - атрибутом xsi:Type.
Спасибо вам за четкую подачу материала.
Рад, если видео оказалось полезным! Сам у себя иногда подглядываю, если что-то подзабыл :)
Спасибо за твой труд. Ты один из лучших лектора По 1С на просторах ютуба. Без лишней воды, без слов паразитов и междометий. Слушать одно удовольствие
Спасибо за высокую оценку! Сам терпеть не могу, когда лектор мямля или половину вебинара "ээээммннуу" :) Стараюсь не уподобляться)))
Спасибо автору канала за ценную информацию, изложенную подробно и с примерами. Всем кто прочитал комментарий удачи)
Всегда приятно получать обратную связь, особенно такую положительную)) Да уж, видео получилось не маленьким, но надеюсь, не нудным, и будет многим полезно:)
Ты прям профессор (если по разговорному стилю, и знаниям разумеется) ... Я ещё больше полюбил 1с ... И тебя ))) ... Замечательно , ещё пожалуйста !!!
Неожиданное признание!😁 не профессор, конечно, но в одной из онлайн школ преподаю☺ Вот так и вербуем людей в 1С разработчики😁😉
мне бы красивый код делать научится...Мож совет дашь? или я просто бездарен?
@@polite5802 Раздобудь Систему стандартов и методик разработки конфигураций. Там все что касается лучших практик по 1С. Ну и почитай что-нибудь общепрограммистское, того же МакКонелла "Совершенный код", например. и больше практики))
Спасибо за работу.
На здоровье!😇
Спасибо за материал!
Крутое изложение, все подробно!! Прям очень понравилось, спасибо за труд!!
Подписался)
Благодарю за подписку!)) Тема обширная, и потому видео получилось объемное. Подписчики попросили про XDTO, вот и постарался :)
P.S.: если есть пожелания по темам новых видео - пишите, обязательно рассмотрю!
Спасибо!
Подскажите пожалуйста, как правильно определить какого типа нужно передавать параметр в SOAP запрос (то есть, иногда в определенных веб сервисах мы передаем сразу примитивы, в других мы допустим сериализуем структуру 1С в объект XDTO, в третьих мы получаем сам тип сервиса на основании его создаем объект XDTO заполняем параметры а потом этот объект передаем как параметр), как этот момент точно определять какой тип нужен в том или ином случае?
Спасибо за интересный вопрос. Преимущество SOAP сервисов в том, что они имеют схему WSDL. Собственно, все что внутри SOAP сервиса - какие методы есть, какие у этих методов параметры, какие у этих параметров типы, и т.д. - все это описывается в схеме WSDL. Следовательно, чтобы узнать, какой тип параметра нужно указать при вызове того или иного SOAP сервиса, нужно смотреть его схему.
На помощь могут придти специализированные программы для тестирования и выполнения веб-сервисов, например SOAP UI или Postman.
Здравствуйте. Спасибо за ролик. А можно ли как-то проверить xml - файл на соответствие xsd- схеме (отдельный xsd-файл) и получить ошибки при расхождении?
xml-валидация средствами 1С достаточно ограниченная. Есть метод Проверить() у объекта XDTO, и по сути все. Т.е. волшебной кнопки нет, придется писать много кода. И нужно иметь в виду, что файл, валидный по стандартам xml может не читаться 1С. А так используют внешние способы проверки (msxml, в частности), и из 1С их только вызывают.
Спасибо за видео. Сейчас еще актуальны XDTO пакеты после появления JSON?
В целом еще долго будут актуальны, т.к. есть масса корпоративных приложений, сервисов, и прочего, использующие SOAP сервисы и/или xml. Крупный бизнес и госсектор достаточно неповоротливы, и не будут торопиться менять устоявшиеся надежные технологии. JSON же, мне кажется, больше востребован в веб-приложениях, микросервисах и т.п. У нас в организации используются и те и те механизмы. Постепенно отказываемся от SOAP в сторону http-сервисов, т.к. их проще поддерживать и разрабатывать. но за счет формализации WSDL схем есть кодогенерация - так что все равно выбор не очевиден )))
Xdto умеет работать и с json форматом. Правда тянет туда лишний мусор. Для себя сдедал вьівод что читать json удобно по модели xdto, а вот формировать гораздо удобнее из структурьі.
Единственное видео в котором многое не понял. Если будет видео в котором будет подробно создаваться пакет, в котором будет описано почему тут указываем то, а в другом иное и дальше применение его в веб сервисе, тогда будет намного понятнее. Например как создавали пакет WS_goods. Если как сделали "ЕдиницуИзмерения" вроде разобрался (Проставил типы децимал и стринг) и далее прицепил к номенклатуре, а вот Со статьей затрат непонятно. что там? Статья затрат это Перечисление или нет, какой тип должен быть там у элементов не ясно.
В XDTO прямая аналогия со структурой метаданных - есть примитивные типы, а есть ссылочные. И единица измерения и статья затрат - это ссылочные типы, это можно определить по одинаковым значкам. Самый лучший вариант поразбираться - выгрузить CurrentConfig и начать его копать, одновременно сопоставляя с метаданными в конфигурации. Ну и читать спецификацию этого формата - про оффсеты, типы данных, и т.п.
@@alexcode_1c Более менее понятно. А как быть если будет содержаться составной ссылочный тип ( док. Приходная и возврат)? Или это не поддерживается? и как быть потом с сериализацией?
Снова же самый простой способ разобраться - выгрузить current-config и посмотреть :)
По идее там может быть тип anyType или anyRef. Ну а сериализацию / десериализацию можно проверить экспериментально. Для каких-нибудь планов видов характеристик, например, может записываться тип значения - атрибутом xsi:Type.