Всем доброго времени суток, собсно, сабж.

Вводные данные:
Клиенты и сервер 8.5.3 с последними фикспаками, сервер под виндой. Клиентам LN в реальном времени нужны данные, лежащие в справочнике 1с. Напрямую обратиться нельзя, видимость сервера 1с для клиентской машины не гарантируется. Клиенты LN работают под разными операционками -> нужно решение штатными средствами. Данные из 1с нужно получить в лотусскрипте либо яве -> DECS+DCR отпадает.

Предложенное решение - на лотусовом сервере лежит кэш справочника, который обновляет сама 1с по мере изменения своего справочника - был забракован.

Пока придуман такой вариант: на доминошном сервере поднимается веб-сервис, к которому обращаются клиенты, а уже веб-сервис лезет на сервер 1с и возвращает клиенту данные. Но ввиду некошерной реализации в LN штатного soap-клиента этот вариант рассматривается как крайний.

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

Garrick, спасибо за ответ,

GarrickОчевидно, 1-с-ники не хотят связываться с Лотусом. Надо что бы Лотус сам по рассписанию обновлял эти справочники из 1С.
По расписанию никак, заказчик уперся рогом в реальное время. Даже о полуминутной задержке слышать не хочет. Не спрашивайте почему, я не специалист по фобиям.

GarrickА что такого некошерного в Лотусовом soap-клиенте? Web Service Consumer в Domino Designer видели?Да, видели и пользовали, потому и не хочется - при добавлении в сервис новых функций нужно перекомпилировать consumer, например. При переезде сервиса на новый адрес та же беда.
Была написана своя либа на базе mssoap, которая и трудится на серверах. На клиентах на неё завязаться не получается, клиенты не только под win, так что в крайнем случае конечно будет использован штатный Web Service Consumer. Но хотелось бы без него.

GarrickХороший вариант.
Спасибо. Но никак не могу донести до заказчика, что в случае реалтайма правильное и очевидное решение это когда источник данных (1с) сам обновляет данные у получателя (лотус).

GarrickА вы поставьте расписание раз в 10 минут - скажите "это в реальном времени".Если обман вылезет будет большой скандал. Разговор идет именно о реалтайме - в 1с поменяли значение, через секунду юзер создает документ в лотусе и видит новое значение из справочника 1с. Зачем это нужно не представляю, но заказчик упирается и ради этого готов мириться с возможными проблемами реализации реалтайма. Так что деваться некуда.


GarrickЗачем? Разве он перестанет работать?Да, при изменении wsdl штатный лотусовый consumer вместо работы кричит о несоответствии wsdl начально заданному.


GarrickЕсли же вы хотите использовать эти новые функции, то вам в любом случае переписывать код и на MS SOAP тоже.Типовой сценарий: лотусовая база использует функцию А из 1с-ного сервиса. Другой базе требуется очень похожая функция, 1с-ные разрабы пишут функцию Б и включают её в тот же веб-сервис, который теперь предоставляет две функции. На штатном консьюмере потребуется перекомпиливать консьюмер в первой базе, при использовании mssoap никаких действий в первой базе делать ненужно. Вторая база просто использует функцию Б без дополнительных телодвижений.


GarrickА MS SOAP будет продолжать работать по старому адресу или он сам узнает новый и подставит себе в код?Хех, помимо либы на mssoap я поднял единый справочник веб-сервисов (тоже в виде веб-сервиса, чтобы был доступен не только лотусовым клиентам).

Допустим, мне надо по коду выбранного в лотусовом документе проекта получить его бюджет из 1с. Я знаю, что веб-сервис 1с, отвечающий за бюджеты проектов, имеет справочный идентификатор ProjectBudgetingFrom1s, и мне от веб-сервиса нужна функция GetProjectBudget. Пишу в коде:

doc.ReplaceItemValue "ProjectBudjet", WebServices_GetClientObject("ProjectBudgetingFrom1s").GetProjectBudget("ID проекта")

Либа найдет адрес сервера 1с, отвечающего за ProjectBudgetingFrom1s, если в справочнике указано что сервис нестандартный то с помощью msxml скачает с него wsdl и преобразует в понятный для mssoap формат, проинициализирует COM-объект mssoap и вернет проинициализированный объект mssoap. Вот такой цирк, зато переезды сервисов на другие сервера требуют всего лишь минимальной правки справочника.

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