системы оповещения (по почте)

Доброго всем времени суток.
-----------------------------
Задумал написать систему оповещения пользователей корпоративной системы (БОСС-Корпорация)
Хочется например следующее: экономист исполнил документ, и по бизнесс-процессу следующее действие в системе должно быть: генерация и исполнение проводок на документе: но бухгалтер еще некоторое время (сутки, двое) не будет в курсе того что документ необходимо обработать.
На флне этого у меня появилась идея что если повешать триггер на таблицу с первичными документами и отлавливать исполнение документа, то можно посылать пользователю-бухгалтеру письмо с текстом о том, что документ исполнен и можно генерить проводки....

я первоначально составил требования к данной системе оповещения:
1) настраивать систему оповещения может любой (в моём случае это ИВЦ которое сопровождает приложение), те не обязательно программист
2) система оповещения по своей сути будет являться конструктором: например наполнение будет производиться по следующему пути: определение события, направление события, генерация текста, время выполнения (отложить сообщение на какой то срок или выполнить немедленно), назначение сообщения(кому доставить)
пока что смутно в голове всё прорисовывается - но идея по-моему хорошая и самое главное направленна на уменьшение времени между операциями разных пользователей, что в свою очередь ведёт к уменьшению времени простоя системы.

хотелось бы поинтересоваться есть ли у кого нить наработки в данном направлении?

C-Strelok

Доброго всем времени суток. ----------------------------- Задумал написать систему оповещения пользователей корпоративной системы (БОСС-Корпорация) Хочется например следующее: экономист исполнил документ, и по бизнесс-процессу следующее действие в системе должно быть: генерация и исполнение проводок на документе: но бухгалтер еще некоторое время (сутки, двое) не будет в курсе того что документ необходимо обработать. На флне этого у меня появилась идея что если повешать триггер на таблицу с первичными документами и отлавливать исполнение документа, то можно посылать пользователю-бухгалтеру письмо с текстом о том, что документ исполнен и можно генерить проводки.... я первоначально составил требования к данной системе оповещения: 1) настраивать систему оповещения может любой (в моём случае это ИВЦ которое сопровождает приложение), те не обязательно программист 2) система оповещения по своей сути будет являться конструктором: например наполнение будет производиться по следующему пути: определение события, направление события, генерация текста, время выполнения (отложить сообщение на какой то срок или выполнить немедленно), назначение сообщения(кому доставить) пока что смутно в голове всё прорисовывается - но идея по-моему хорошая и самое главное направленна на уменьшение времени между операциями разных пользователей, что в свою очередь ведёт к уменьшению времени простоя системы. хотелось бы поинтересоваться есть ли у кого нить наработки в данном направлении?

ДА полно такого, utl_smtp в зубы и вперед. Если надежность е-почты не устраивает, то можно сообщения писать в отдельную таблицу (где-то) и мониторить их прикладом. Есть другие варианты.

Наработки есть и это нормально работает.
Согласен с предыдущим оратором - ОЧЕНЬ нужна таблица, в которой фиксируются все отправленные сообщения, с указанием даты и времени попадания в таблицу и даты м времени отправления письма.

Без этого учета очень тяжко бороться с получателями, которые порой страдают склерозом и говорят что никакого письма они не получали. А в таблице "все ходы записаны", и вся борьба сводится к тыканью носом склеротика в соответсвующую строчку этой таблицы :)

Мне уже трудно писать, но пара замечаний:
Не дело БД отправлять письма, просто представь себе, что SMTP сервер не отвечает -- этот триггер тебя убъет
Варианты:
-- Вставлять в таблицу и сразу запускать джоб (нарвешься на много джобов)
-- Вставлять и джоб постоянно крутится (пытается отправить) -- можешь нарваться на то-же самое (16 попыток)
-- Вставлять и пусть внешняя приблуда занимается рассылкой почты
У нас сделано последним вариантом (после того, как я программистам высказал)

Зачем много джобов, если можно сделать одного демона и он будет крутиться и пытаться отправить неотосланные неотосланные сообщения? А триггером просто заполнять таблицу данными, откуда демон (процедура в джобе) будет брать все, что ей надо.

Эт точно. Такого счастья полно.

У нас на предприятии самописное счастье такое используется.

Я накатал демон + клиентскую часть.

120 клиентов стабильно юзают эту "аську". Все висит на одном коннекте к БД. Все 120 человек.

Другой коннект используется для сканирования таблички с сообщениями и их рассылки клиентам по TCP. Причем эта хрень пашет и по интернету, не только по локалке.

Так там вроде есть уже система сообщений типа открываеш ьы свой юлс а там сообщения лезут сразу

Arbeit macht frei