Доброго времени суток, являюсь java разработчиком, переводим интеграцию между java приложением с odata на ws.
Вебсервисы начали писать через web-сервисы расширений (по утверждению 1с разраба - по необходимости).
Столкнулись с проблемой при генерации wsdl следующего характера:
в 1с конфигурации есть кастомная модель данных, в которой есть поле типа Enum (также кастомное) находящееся в стандартном общем пакете 'перечисления', при создании пакета XDTO требуется произвести импорт (что логично) пространства имен всех используемых пакетов в веб-сервисе. Наш Enum находится в, как я понял, самом глобальном и общем пакете 'http://v8.1c.ru/8.1/data/enterprise/current-config';.
Делаем импорт, публикуем web-сервисы расширений, и при обращении к wsdl в описании типов 1с нам вываливает полностью импортированный пакет 'http://v8.1c.ru/8.1/data/enterprise/current-config'; с сотнями внутренних моделей данных естественно клиентскому приложению не нужных, плюс к этому также тянет за собой еще два вложенных пакет внутри 'current-config' - это 'http://v8.1c.ru/8.1/data/core'; и 'http://v8.1c.ru/8.1/data/enterprise';. Какое может быть решение чтобы в итоге мы получили в импортe wsdl только нужные нам типы данных для клиента?

Я не асс, то чувствую что нужно смотреть в 1с) Там создать свой пакет XDTO и переопределить его в качестве пакета XDTO

(1) + в веб сервисе

(0) всё правильно. Current-config – это, как следует из названия, пакет _всей_ конфигурации. Core и enterprise – это пакеты встроенных типов платформы. И если у вас конфа типа ERP, то там тысячи типов.
Если вы хотите ограничить число типов в пакетах, нужно делать свой пакет XDTO, который не наследует системные пакеты. Но всю сериализацию придется писать вручную в обработчиках веб-сервиса.

(3) Однако правильно определил направление)

Найдите на Инфостарте серию статей "XDTO – это просто". Там подробно разобрано что к чему.

(3) т.е. это нормальное явление и все так делают? при условии что для клиента нужно какое то кастомное поле определенное в общей конфе? в каких случаях этого не нужно делать? разве нельзя просто сделать какой то импорт отдельной xsd схемы в wsdl?

(5) хорошо, попробую посмотреть, спасибо

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

Использование current-config имеет смысл только когда мы хотим обмениваться с базой с идентичной конфигурацией (см. РИБ). Либо для какой-то цели сериализуем объект, чтобы потом восстановить его в той же базе (например, в случае хранения настроек или какого-то хитрого внешнего версионирования).

(9) да, в основном гугл про это и говорил, о таком назначении. в сухом остатке для нормальных и гибких в инфраструктуре 1с ws нужно писать сериализаторы под каждый объект верно?

(8) ну вообще у нас как бы и создается свой пакет XDTO, и в него добавляются типы данных из конфы, и вот у какого то типа данных есть пресловутое поле типа Enum находящееся в current-config, и как бы нам при создании своего пакета XDTO нужно и указать все эти типы, а при переобновлении конфы при отсутствии нужного импорта 'current-config' конфигурация и создание пакета XDTO не обновляется. что нужно сделать в таком случае?

(11) в каком то типе объекта указан в базовом типе пакет XDTO 'http://v8.1c.ru/8.1/data/enterprise/current-config';

(12) нет, нет ссылок как на базовый тип на пакет 'http://v8.1c.ru/8.1/data/enterprise/current-config'; есть свойство у одного из типов в виде Enuma который описан в пакете 'http://v8.1c.ru/8.1/data/enterprise/current-config'.

(10) обычно немного наоборот: ты делаешь XDTO, описывая только то, что надо отдать сторонней системе, а в обработчике метода веб-сервиса "накачиваешь" его данными на основании чего-нибудь в базе.

(11) "создается свой пакет XDTO, и в него добавляются типы данных из конфы" - вот тут у вас ошибка. Не надо тащить типы из конфы.
Описывайте свои типы прямо в пакете. Желательно, чтобы они зависели только от простых типов http://www.w3.org/2001/XMLSchema.

а потом как-то так:

        Результат = СписокЗаказовПокупателей(ДатаНачала, ДатаОкончания, Параметры, Ошибка, ТекстОшибки);
        
        XDTO_TypeOrder = ФабрикаXDTO.Тип(XDTO_URI, "Order");
        XDTO_TypeOrderList = ФабрикаXDTO.Тип(XDTO_URI, "OrderList");
        
        OrderListXDTO = ФабрикаXDTO.Создать(XDTO_TypeOrderList);
        
        Для каждого элРезультат Из Результат Цикл
            OrderXDTO = ФабрикаXDTO.Создать(XDTO_TypeOrder);
            OrderXDTO.number = элРезультат.Номер;
            OrderXDTO.date = элРезультат.Дата;
            OrderXDTO.customer = элРезультат.Контрагент;
            OrderXDTO.summa = элРезультат.Сумма;
            OrderXDTO.organization = элРезультат.Организация;
            OrderXDTO.manager = элРезультат.Ответственный;
            OrderXDTO.department = элРезультат.Подразделение;
            OrderXDTO.comment = элРезультат.Комментарий;
            
            OrderListXDTO.Order.Добавить(OrderXDTO);
        КонецЦикла; // Результат

(13) значение типа Перечисление через XMLСтрока() превращается в строку, содержащую идентификатор значения, как оно описано в конфигурации.

(16) спасибо за ответы, стало понятнее, на инфостарте тоже нашёл статьи, но по enam'у тогда возникает вопрос, если клиентский код будет видеть поле в виде строки тогда возникают проблемы с возможным контентом в этом поле. как можно сделать чтобы был enam для клиента? ведь при строке я могу любое значение поместить в поле, а хотелось бы только enum варианты