Есть MS Project server, опубликован web сервис.
Мы хотим из web сервиса получить список проектов на стороне 1С:8.3.
Делаем пустую файловую базу, в которой создаем обработку, создаем управляемую форму с кнопкой "Тест" и в модуле формы пишем:
&НаКлиенте
Процедура Тест(Команда)
ТестНаСервере();
КонецПроцедуры
&НаСервере
Процедура КнопкаВыполнитьНажатие(Кнопка)
Определение = Новый WSОпределения("http://adrseservera/pwa1/_vti_bin/psi/Project.asmx?wsdl","domain\user","password!",,,);
Прокси = Новый WSПрокси(Определение,"http://schemas.microsoft.com/office/project/server/webservices/Project/","Project","ProjectSoap",,,);
Прокси.Пользователь = "domain\user";
Прокси.Пароль = "password!";
//Подготовка и заполнение параметра для передачи в метод ReadProject
ТипПараметр = Прокси.ФабрикаXDTO.Пакеты.Получить("http://schemas.microsoft.com/office/project/server/webservices/Project/").Получить("ReadProject");
Парам = Прокси.ФабрикаXDTO.Создать(ТипПараметр);
Парам.projectUid = "00000000-0000-0000-0000-000000000000";
Парам.dataStore = "PublishedStore";
//Если передать пустой идентификатор проекта, то метод работает. Возвращает пустой объект XDTO "Ответ.ReadProjectResult = Неопределено"
Ответ = Прокси.ReadProject(Парам);
//Теперь заполним параметр существующим значением идентификатора проекта
Парам.projectUid = "75FC7297-3F9D-E311-BEF0-00155D000801";
Парам.dataStore = "PublishedStore";
//В следующей строке при выполнении метода возникает ошибка
Ответ = Прокси.ReadProject(Парам);
КонецПроцедуры
Показать
Когда мы хотим получить проект по пустому айдишнику - ответ получаем корректный.
Но когда мы хотим получить проект по определенному айдишнику получаем ошибку:
Для того чтобы удостоверится что проблема точно на стороне 1С, чтобы не наводить зря напраслину :)
Предлагаю проверить полученный ответ от веб-сервиса на валидность - строгое соответствие схеме.
Например с помощью SOAP UI. Кстати тем всем кто занимается отладкой взаимодействия из 1С с сторонними веб сервисами обязательный must have, так как
в платформе нет возможности перехватить сообщение до валидатора и его изменить.
Как проверить вот: http://www.soapui.org/soap-and-wsdl/validating-soap-services.html С помощью же SOAP UI можно привести сообщение к такому виду, который будет устраивать валидатор 1С.
Для этого в SOAP UI поднять веб-сервис эммулирующий сервис проджекта и запросы из 1С слать на него.
Потом как было сказано в 14 берем готовый WS-SOAP прокси (к слову это одна из функций сервисной шины ESB) или если есть возможность и средства пишем свой, который умеет преобразовать входящие сообщения в удобоворимый вид для валидатора 1С, с помощью XSLT преобразований например.
В свое время подобным образом решал задачу интеграции 1с-ных веб сервисов с саповской шиной PI.
Если возможно, опубликуйте судя WSDL(поинты можно обезличить) и сообщение полученное от MS Project-а.Посмотрю на досуге.
(4) HitGroove, спасибо за ссылки. Обе ссылки скорее "учебные".
Хотелось получить комментарии специалистов конкретно по интеграции 1С:8.3.5.1383 с MS Project, так как есть мнение, что платформа работает не корректно.
(5) RailMen, Да ссылки учебные, это в основном для понимая как работать 1С и web-сервису, для 1С вообще пофиг это что это MS Project, или какой другой сервис. Вы когда передаете пустой параметр, то сервер Вам выдает пустой ответ следовательно при получении не пустого ответа, 1С пытается сопоставить объекты которые получает, а не может "Ошибка преобразования данных XDTO:" ибо не знает что это за объекты.
И попробуйте поработать с самим сервисом, если подобные ошибки будут появляться, возможно сервер отправляет в ответе типы объектов которые 1С понимать не хочет... И что то придется менять в настройках сервера.
(8) RailMen, Отлично выяснили что с сервером ни чего сделать нельзя. Добавив ws ссылку мы НАГЛЯДНО сможем посмотреть какие свойства, типы объектов и типы значений используются в данном сервисе! Чтобы указать те которые устроят 1С. Потому как приведенные ошибки указывают что одинэс не может сопоставить типы.
(9) HitGroove, делали через ссылку. Да удобно, все видно. Но эффект тот же. Ошибка возникает при разборе любого не пустого значения, полученного из MS Project. Через ссылку или через код не имеет значения.
Вот-вот, "платформа 1С не может сопоставить типы".
(1) Есть несколько путей интеграции, которые можно разделить на две условные группы:
К первой относятся виды, где обмен происходит онлайн, т.е. об изменениях сразу сообщается целевому получателю.
Ко второй относится обмен, когда изменения происходят сами собой и об этом целевой получатель узнает, только когда сам "пошевелится".
Первый вариант:
Изменение порождает событие, которое ставится в очередь на отправку получателю. Можно писать в таблицу с учетом времени и на ее основе дергать вебсервис, к примеру.
Второй вариант:
Получатель сам периодически копается в источнике в поисках измененных данных. Этот вариант разумеется возможен в рамках только локальной сети.
Конечно это две крайности, часто бывает решение где-то в середине - не онлайн и без поиска изменений.
(1) Сниффером посмотреть, что уходит из 1С и что возвращает веб-сервис в обоих случаях, не пробовали? И сравнить в проверочным на C#
Я не уверен, что ответ, содержащий что-то вроде
является корректным ответом сервера.
Возможно, происходит сбой на стороне сервиса из-за неверно переданных параметров (или при их обработке происходит ошибка), и сервер возвращает обычную html страницу.
(27) Я также пользовал снифер в начале. А потом выяснилось, что проще писать на шарпе и логировать обмен. Но если надо логировать имеющийся, то прокси, т.к. дров ставить не надо для сетевой карты.
(1) RailMen, А есть ли смысл загружать все данные которые выдает Projects, может свойства с типом anyType вообще не нужны для дальнейшей обработки в 1С?
Мы сделали обращение в техническую поддержку 1С (зарегистрирована 25.12.2014 под номером SW893155 код ошибки 30016652). Предоставив дополнительную информацию по запросам специалистов 1С мы получили ответ 02.04.2015 о том, что «это не ошибка платформы». Однако, есть сомнения.
Мы делали интеграцию 1С с Web сервисами на JBoss (Java EE сервер), так вот проблема в том, что 1С очень требовательна к типам возвращаемых значений. Т.е. в описании SOAP методов на JBoss было все сделано корректно и они вызывались другими системами нормально. Но 1С выдавала ошибку несовпадения типов при разборе XDTO. Нам было проще, т.к. методы мы писали сами, то добавили аннотации:
Было: @WebMethod()
public String getTaskStateByNumber(
@WebParam(name = "number") long number,
@WebParam(name = "projectId") long projectId) {
TaskDTOfor1C task = findTaskByTaskNumber(new BigDecimal(number),
projectId);
return task != null ? task.getState() : null;
}
Стало: @XmlAccessorType(javax.xml.bind.annotation.XmlAccessType.FIELD)
public class TaskDTOfor1C implements Serializable {
private static final long serialVersionUID = 1L;
@XmlElement(namespace = "http://web.msp.inagro.ua/")
private long id;
@XmlElement(namespace = "http://web.msp.inagro.ua/")
private long currentStatusId;
...
Думаю у вас похожая проблема.
Если это так то есть несколько путей:
1. Вручную парсить строки - жуть, если честно.
2. Написать прокси сервер, который будет транслировать запросы и ответы. Чисто техническая задача - брать и делать, ничего сверх сложного - просто время и деньги.
3. В 8.3.6 в описании написано, что они чего-то переделали с форматом обращения с SOAP... Я не проверял, хуже точно не стало, но стало ли лучше - не знаю. Но проверить стоит.
(17) Я специально 15 под задачи с вэб сервисами изначально и решал. Где куча классов итд, что муторно решать через свою оболочку COM. А так ты получаешь доступ к классам Net как к ком объектам и написание обращения к Вэб сервису через эту оболочку во многих случаях даже проще и понятнее чем родными 1Скими
(17) Я решил задачу интеграции с Project Server-ом составляя пакета запроса (soap:Envelope и RequestHeaders) и отсылая его через Msxml2.ServerXMLHTTP. Потом делаю парсинг ответа при помощи MSXML2.DOMDocument. Таким образом получаю и список всех проектов и параметры одного определенного проекта.
Для того чтобы удостоверится что проблема точно на стороне 1С, чтобы не наводить зря напраслину :)
Предлагаю проверить полученный ответ от веб-сервиса на валидность - строгое соответствие схеме.
Например с помощью SOAP UI. Кстати тем всем кто занимается отладкой взаимодействия из 1С с сторонними веб сервисами обязательный must have, так как
в платформе нет возможности перехватить сообщение до валидатора и его изменить.
Как проверить вот: http://www.soapui.org/soap-and-wsdl/validating-soap-services.html С помощью же SOAP UI можно привести сообщение к такому виду, который будет устраивать валидатор 1С.
Для этого в SOAP UI поднять веб-сервис эммулирующий сервис проджекта и запросы из 1С слать на него.
Потом как было сказано в 14 берем готовый WS-SOAP прокси (к слову это одна из функций сервисной шины ESB) или если есть возможность и средства пишем свой, который умеет преобразовать входящие сообщения в удобоворимый вид для валидатора 1С, с помощью XSLT преобразований например.
В свое время подобным образом решал задачу интеграции 1с-ных веб сервисов с саповской шиной PI.
Если возможно, опубликуйте судя WSDL(поинты можно обезличить) и сообщение полученное от MS Project-а.Посмотрю на досуге.
О! Здорово, спасибо, не знал что есть такие готовые, интересные решения )
Не знаю как автор этой темы, но я точно себе попробую - давно хотел с MS Exchange пообщаться, да только там похожая проблема... а задача не настолько критична, чтобы выделять сколько нибудь значимые ресурсы... А если через готовый прокси заработает - то будет здорово!
По сути имея современные ресурсы в виде бесплатных VDS которые можно расковырять и настроить на какую угодно задачу, логирования превращается в творческую задачу: миллион способов и все сводится к предпочтениям. Как по мне то прокся поднятая на VDS идеально подходит под это дело