"before New Mail Arrives" Or "after"

[wowa]

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

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

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

 

[ToxaRat]

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

 

[wowa]

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

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

 

[hosm]

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

Добавлено:

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

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

 

[oshmianski]

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

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

 

[wowa]

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

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

Ошибка?


Добавлено:

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

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

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

 

[wowa]

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

Ошибка?

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

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

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

 

[oshmianski]

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

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

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

 

[wowa]

хм, такой триггер отрабатывает до того, как документ сохраняется в бд (на сколько я понимаю).
и поэтому получать его через 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:

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

 

[wowa]

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

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

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

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

 

[hosm]

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

 

[wowa]

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

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

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

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

Для "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>

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

 

[hosm]

Я бы подумала, что надо использовать триггер "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 выполняются перед тем, как новое письмо записано в почтовый ящик пользователя. Это означает, что как автор агента, вы можете не найти этот новый документ в любой коллекции, полученной из почтовой базы пользователя (ведь он может быть уже удалён). Новый документ доступен только через контекст документа.

 

[wowa]

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

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

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

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

 

[nvyush]

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

 

[wowa]

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ы пошли нормальные). В общем, будьте бдительны, как грицца...

 

[garrick]

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

 

[Мыш]

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

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

 

[garrick]

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

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