Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Ну, а чего тут объяснять-то? Всё просто. Пишите Web-service, который по обращению к нему лезет в реляционную базу, находит там что-то и возвращает в качестве ответа, скорее всего в виде XML, ну или JSON (как вам удобнее). На клиенте вызываете этот web-service, который работает на вашем же сервере, возможно даже в той же самой базе, и разбираете полученный от него ответ.
С DECS как-то не сложилось, в вот LEI у нас на старой работе использовалось очень активно, всех устраивало. Техподдержка могла самостоятельно без программистов организовать выгрузку данных в реляционную базу для последующей обработки какой-либо аналитической системой, также загрузку справочников в Lotus Notes. Самое сложное было снабдить их информацией об именах полей в Lotus Notes. К тому же расписание и продолжительность выгрузок LEI никоим образом не зависит от прихотей менеджера агентов Domino, иногда это очень важно.
если напишите
, хотя "проще" использовать
Да, за выходные уже немного изучил эту тему. Нашел стандартный элемент дизайна webservice consumer. Но он, насколько я разобрался, дружит только с SOAP-сервисами.
Полностью согласен с @garrick . DAS совсем из другой оперы и не подходит для первоначально озвученной задачи. Т.е. человеку нужно работать с внешними данными по отношению к Domino, а DAS - для доступа внешних систем через rest-сервисы к данным в домине.
если задача интеграции данных, между доминой и SQL, допускает создание сторонней проги...
и как это претит использованию REST?
т.е. можно и на сервере, в домине, монтырить агент или чё там, а можно развернуть (там же) сервис, кот. будет интегрить домину с SQL
Ну относительно DECS не соглашусь - это "базовый" функционал Domino, сервис "из коробки", не требующий покупки и кодинга - просто галочка при инсталляции. Да, он ограничен по своим возможностям, но там где его хватает - он намного изящнее самописки работающей с домино через rest.
сама домина не реал-тайм
, а уж все остальное...Изначально речь шла о том, что лотус - это фронтэнд. При чем тут скуль-триггеры, если для их отработки требуется изменить данные в скуле? Под реал-таймом, естественно, понималась не работа ПЛК в системе АСУ электростанции, а то, что к моменту, когда лотус сохранит документ данные в сторонней системе уже точно будут обновлены. С внешним синхронизатором (по какой бы технологии он ни работал), если он не использует hook на событиях домины - такой уверенности нет и быть не может. к сожалению...сама домина не реал-тайм
а промежуточный синхронизатор может работать - как напишут
хоть из тригеров на РСУБД
Можно и на Lotus Sctipt, даже без LS2J. Только там могут быть проблемы с приведением типов данных, но со "своим" сервисом это легко решаемо, с чужими может быть всё плохо. Java конечно предпочтительнее, для неё это всё (web-service) родное, всё решается гораздо проще, чем в Lotus Script.
не было такого условия, цитата выше
см. цитату - "данные поступали на клиента" , т.е. опять - не факт
не стоит придумывать процесс, кот. ТС не описывал и реалтайм - это не то что у вас "подразумевается"
хук используется для перехвата событий в домине и никак не связан с СКЛ, а ускорение в процессе, кот. не нужно ускорять - это лишний повод задуматься об оптимальности "вклада"
1 для всех "конвертаций" достаточно использовать тока 1 поле
1. Как? Формула вычисляется однократно, затем производится маппинг полей. Т.е. На момент маппинга в одном поле одно значение
ТС четко отписал, что запрос идет от клиента лотуса и далее по маршруту домино-скуль. Неуж то не очевидно где здесь фронтенд? Да он не уточнял, что запрос должен идти при открытии документа, возможно в процессе работы с документом потребуется запрос в скуль и тогда это может быть уже не decs... но и не DAS, тем болеене было такого условия, цитата вышесм. цитату - "данные поступали на клиента" , т.е. опять - не факт
Realtime activity - термин, применяемый ибм в документации по LEI и на мой взгляд очень точно отражающий суть работы DECS. А что по-вашему реалтайм?
Фишка decs'а - запросить свежие данные из скуля на событии open, т.е. в тот момент, когда пользователь непосредственно открывает док. пропихнуть их в скуль на событии update, т.е. непосредственно в момент сохранения в домино (вопрос обновления данных скуль ТС не поднимался, это так, к слову)
)почему бы нет, если это практически ничего не стОит? у меня нет опыта использования decs в продакшн, но в тестовой среде он показал себя молниеносным - сохранение дока занимает по времени примерно одинаково, что с включенным дексом, что без, потребляемые ресурсы - копеейки.
DECS несет ограничения, достаточно примитивная схема маппинга без изысканной трансформации и валидации данных, особенно критично если обе базы (домино и скуль) писаны не вами и нет возможности (желания, времени) менять схему данных в одной из них.при этом DECS несет кучу кастылей и ограничений, лишний экстеншн менеджер - это повод для глюков
типа данных... ну вы сами уже вопрос задавали
Это конечно субъективно.не вижу смысла в DECS и за 17 лет знакомства не испытывал в нем необходимость
за ссылку спасибо, не @ (а decs понимает только их), но полезно
Обучение наступательной кибербезопасности в игровой форме. Начать игру!
