Добрый день.
В базу данных приходят письма. Мне желательно их сразу обрабатывать.
Найдя одну из тем, так указано что лучше всего для агента использовать "Before new mail arrives".

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

У кого есть какие мысли?

 

если никаких настроек на сервере не меняли то ПОСЛЕ будет аж через 15 минут
а если сервер не почтовый то вообще ничего не будет

 

если никаких настроек на сервере не меняли то ПОСЛЕ будет аж через 15 минут
а если сервер не почтовый то вообще ничего не будет

Сервер не почтовый.
Если письма допустим будут приходить раз в 1-2 недели(периодичность не известна), то лучшим вариантом будет вообще запуск агента раз в день? А не по приходу писем. Я прав?

 

вот 2 полезные темки по почтовым агентам:
link removed
link removed

Добавлено:

Если письма допустим будут приходить раз в 1-2 недели(периодичность не известна), то лучшим вариантом будет вообще запуск агента раз в день? А не по приходу писем. Я прав?

так зачем ежедневный агент, если письмо раз в 1-2 недели? %)

 

Когда я отсылаю письма по одному, то агент обрабатывает все письма кроме последнего, что в принципе логично.

эм, разве логично?
как получаете документы в агенте?
я использую DocumentContext.

 

эм, разве логично?
как получаете документы в агенте?
я использую DocumentContext.

хм, вот тут видимо моя и ошибка....
Я получаю вью, куда попадают письма..

Ошибка?


Добавлено:

вот 2 полезные темки по почтовым агентам:
Как часто отрабатывает агент "after New Mail Has Arrived"
прием писем в указанную папку вместо "входящие"

Добавлено:
так зачем ежедневный агент, если письмо раз в 1-2 недели? %)

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

 

хм, вот тут видимо моя и ошибка....
Я получаю вью, куда попадают письма..

Ошибка?

Хм... Использую DocumentContext. Агент получает какой-то документ, по логам нахожу UNID, и по униду я получаю, что документ был удален. А письмо имеет совсем другой унид.
+ на 3 строке ошибка "DXL exporter operation failed"

Set exporter = s.CreateDXLExporter(docMail)
Call exporter.SetOutput(tmpRichText)
Call exporter.process

Но это возможно следствие что документ неправильный получен

 

Использую DocumentContext. Агент получает какой-то документ, по логам нахожу UNID, и по униду я получаю, что документ был удален. А письмо имеет совсем другой унид.

хм, такой триггер отрабатывает до того, как документ сохраняется в бд (на сколько я понимаю).
и поэтому получать его через db.GetDocumentByUNID (если я правильно понял) не верно.

попробуйте ту же операцию с DXL провести на нормальных (уже сохраненных в бд) документах.
будет ругаться?

 

хм, такой триггер отрабатывает до того, как документ сохраняется в бд (на сколько я понимаю).
и поэтому получать его через db.GetDocumentByUNID (если я правильно понял) не верно.

попробуйте ту же операцию с DXL провести на нормальных (уже сохраненных в бд) документах.
будет ругаться?

Блин, какая-то проблема не понятная.
вот код:

Dim s	аs NotesSession
Set s = New NotesSession
Set mailDoc = s.DocumentContext
getHTMLLinkToDoc = {Notes:///} & mailDoc.ParentDatabase.ReplicaID & {/0/} & mailDoc.UniversalID & {/?EditDocument}

Всегда getHTMLLinkToDoc одинаков, всегда mailDoc имеет один и тот же UNID.= B5A0E9AE27B76A80C12576F200405B0C
Откуда берется этот UNId? С помощью ScanEz оно его не находит.

Далее ошибка в

Set exporter = s.CreateDXLExporter(docMail)
Call exporter.SetOutput(tmpRichText)
Call exporter.process

Добавлено:

Блин, какая-то проблема не понятная.
вот код:

Dim s	аs NotesSession
Set s = New NotesSession
Set mailDoc = s.DocumentContext
getHTMLLinkToDoc = {Notes:///} & mailDoc.ParentDatabase.ReplicaID & {/0/} & mailDoc.UniversalID & {/?EditDocument}

Всегда getHTMLLinkToDoc одинаков, всегда mailDoc имеет один и тот же UNID.= B5A0E9AE27B76A80C12576F200405B0C
Откуда берется этот UNId? С помощью ScanEz оно его не находит.

Далее ошибка в

Set exporter = s.CreateDXLExporter(docMail)
Call exporter.SetOutput(tmpRichText)
Call exporter.process

Хм. проверил, письмо получает верное, хоть и с каким-то не понятным UNID.
Вопрос остается в ошибке в строке
Call exporter.process
DXL exporter operation failed:

Может бы док надо сохранять или еще что-н?

 

Вопрос остается в ошибке в строке
Call exporter.process
DXL exporter operation failed:

Может бы док надо сохранять или еще что-н?

Методом научного тыка, обнаружил, что если в письме нет аттачментов, то все работает хорошо.
Как быть если есть аттачменты?

Может кто даст линк на хелп, что ну никак нельзя... Плз, очень срочно

 

ты напиши, что ты с аттачами делаешь - вроде не писал в теме - только экспорт?
И зачем брать документ по униду, если он уже получен из контекста агента?
Для "DXL exporter operation failed" детально лог exporter.Log что-то говорит?

 

ты напиши, что ты с аттачами делаешь - вроде не писал в теме - только экспорт?

Приходит письмо, В письме текст и аттачменты.
Разбираю этот текст, создаю документ базы и заполняю поля в соответствии с тем, что находится в письме.
В письме есть аттачменты. Их я должен запихнуть в РТФ поле с текстом так как оно находится в письме.
Вот я с помощью ДХЛ этот делаю, вырезаю нужный мне кусок и вставляю его импортом в док

И зачем брать документ по униду, если он уже получен из контекста агента?

Я не беру по УНИДУ, в случае ошибки я в лог выдаю этот Унид

Для "DXL exporter operation failed" детально лог exporter.Log что-то говорит?

<?xml version='1.0'?>
<DXLExporterLog>
<error>Error occurred during processing of note ID 0x80000001</error>
<error>Invalid or nonexistent document</error>
<error>DXL exporter operation failed</error>
</DXLExporterLog>

Никогда не пользовался этим, какие выводы можно сделать?

 

Я бы подумала, что надо использовать триггер "after" (post-delivery) либо сохранить документ - иначе унид невалиден, т.к. документ фактически еще не сохранен в БД.

Pre-delivery почтовые агенты обрабатывают почту прежде, чем она поступает в почтовую базу пользователя; для примера, перемещая входящую почту в папку.
Агенты запускаются почтовым роутером, это гарантирует, что он будет выполнен прежде, чем письмо будет доставлено пользователю. В противоположность, post-delivery почтовые агенты запускаются после того, как письмо придёт в почтовую базу пользователя. Таким образом вы можете использовать post-delivery агенты для операций, которые не зависят от выбора времени при доставке почты, например для ответов на почтовые сообщения.
Хотя вы можете использовать оба типа агентов в вашей почтовой базе, вы можете использовать только один pre-delivery агент за раз. Вы можете иметь неограниченное число выключенных pre-delivery агентов. В дополнение вы можете иметь неограниченное число post-delivery агентов, как разрешённых, так и запрещённых. Обратите внимание, что синяя стрелка ниже переключателя идентифицирует текущее состояние агента (разрешенно) для pre-delivery агентов:
Если вы разрешили оба, pre-delivery и post-delivery агентов в вашей почтовой базе, pre-delivery агент всегда выполняется первым (перед тем, как сообщение будет отправлено в почтовую базу). Затем выполняется post-delivery агент (после того, как сообщение было доставленно в почтовую базу). Рost-delivery агенты выполняют обработку новых сообщений, даже если pre-delivery агенты переместили их в другую папку. Если pre-delivery агент удалил почтовое сообщение, оно никогда не будет доставленно в почтовую базу. Это значит, что рost-delivery агенты не запускаются для обработки этого сообщения.

Запомните, что агенты pre-delivery выполняются перед тем, как новое письмо записано в почтовый ящик пользователя. Это означает, что как автор агента, вы можете не найти этот новый документ в любой коллекции, полученной из почтовой базы пользователя (ведь он может быть уже удалён). Новый документ доступен только через контекст документа.

 

Я бы подумала, что надо использовать триггер "after" (post-delivery) либо сохранить документ - иначе унид невалиден, т.к. документ фактически еще не сохранен в БД.

Пытаюсь сохранить док

If docMail.Save(True,True) Then
Call agentLog.LogAction( {True: })
Else
Call agentLog.LogAction( {false: })
End If

Идет в False, получается что не может сохранить его

 

wowa
Для данной задачи не стоит использовать агент before..., она для него слишком "тяжёлая" (см. ссылки OKEN). Лучше попробовать after... или по расписанию.

 

wowa
Для данной задачи не стоит использовать агент before..., она для него слишком "тяжёлая" (см. ссылки OKEN). Лучше попробовать after... или по расписанию.

ВОТ что-то я тоже к этому выводу прихожу насчет по расписанию

 

Я бы подумала, что надо использовать триггер "after" (post-delivery) либо сохранить документ - иначе унид невалиден, т.к. документ фактически еще не сохранен в БД.

Эхехе... Напоролся тут на днях.
Пишу свое журналирование, переписка с определенными адресатами должна складываться в отдельную базу.

Заметил, что исходящие письма дублируются, это косяк №1. Возникает, в частности, если у письма есть локальные (лотусовые) адресаты, и у них в АК разные значения "Format preference for incoming mail:". Дубликаты имеют одинаковый MessageID, но разные UNID.
Ну ок, сделал в базе агента "Before New mail...", рассчитывал, что он будет отслеживать и удалять дубли (по несовпадению MessageID и UNID).
Аха, как же - получил косяк №2. В агенте типа "Before..." эти письма имеют одинаковый UNID (!).
Переделал агента на "After..." - все заработало (UNIDы пошли нормальные). В общем, будьте бдительны, как грицца...

 

Когда "Before..." - e-mail ещё не сохранён в базе, соответственно, никакого UNID у не должно быть.

 

Когда "Before..." - e-mail ещё не сохранён в базе, соответственно, никакого UNID у не должно быть.

Дык. Чудо и состоит в том, что UNID есть - непустой, ненулевой и одинаковый у обоих писем. Это UNID исходного документа (с которого клонируется дубликат). Ну, по крайней мере, lotusscript так кажет

 

Дык. Чудо и состоит в том, что UNID есть - непустой, ненулевой и одинаковый у обоих писем.

Во-во, не UNID, а полная хрень. Странно что в данном случае вообще что-то возвращается этой функцией, думаю тут какой-то индусский косяк, не смогли сделать что бы возвращался NULL или пустая строка, вот и получается чёрти-что. Настоящего UNID'а у пришедшего документа (e-mail) в этот момент нету.