Проблема в трансляции с почты


#1

Добрый день!

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

Тут и начались проблемы, объем трансляции около 400 писем в день + почтовый клиент на базе Lotus Notus.

Суть проблемы в том, что при включении трансляции огромная часть писем выпадала с ошибкой т.е. тикет не заводился. Начал исследовать проблему.
Включил отладку в модуле, включил отладку в конфигах, включил развернутую отладку в файле конфигурации крона. В итоге обнаружил, что большая часть тикетов не транслировалась именно из-за отладки у него были проблемы с записью “неизвестного симвовла” в строку debug_trace. Выключил отладку большая часть тикетов обработалась, но осталось несколько. Вот тут я попал в тупик взял 2 письма одно, которое обработалось, другое с ошибкой. Содержимое писем шаблонизировано т.к отправляется внутренним сервисом и в целом ни чем не различаются, но одно обработалось, а другое нет. Если вырезаю исходную тему и вставляю ее дубль, который содержится в теле письма то тикет транслируется нормально и казалось бы вот оно! проблема в кодировке ибо даже на почту изредка приходят сообщения об ошибке :
The following eMail (see attachment) was not decoded properly and therefore was not processed at all.
Такого вида, но это изредка 2 сообщения на 100 заявок.
Но тогда почему некоторые сообщения он обрабатывает сразу а некоторые отсеивает до сих пор остается тайной.

Дальше обнаружил, что во встроенном в модуль отладчике что то происходит не правильно. Пример:

2018-10-08 11:34:00 - Processing new eMail (index = 0)
2018-10-08 11:34:00 - The message ‘Файл согласившихся на ИЦ ООО “НСВ”’ is NOT considered as undesired.
2018-10-08 11:34:00 - Creating a new Ticket from eMail 'Файл согласившихся на ИЦ ООО “НСВ”'
2018-10-08 11:34:00 - Target format for ‘description’: text/html
2018-10-08 11:34:00 - Email body format: text/html
2018-10-08 11:34:00 - Managing inline images…
2018-10-08 11:34:00 - Inline image cid:image001.png@01D45EED.45A55430 stored as InlineImage::2136
2018-10-08 11:34:01 - Ticket R-006054 created.
2018-10-09 09:19:57 - Processing new eMail (index = 1)
2018-10-09 09:19:57 - The message 'тема сообщения’is NOT considered as undesired.
2018-10-09 09:19:57 - Creating a new Ticket from eMail 'тема сообщения’
2018-10-09 09:19:58 - Target format for ‘description’: text/html
2018-10-09 09:19:58 - Email body format: text/html
2018-10-09 09:19:58 - Managing inline images…
2018-10-09 09:19:58 - Inline image cid:2__=CCBB09B3DFA60D608f9e8a93df938@rosbank.ru stored as InlineImage::2207
2018-10-09 09:19:59 - Ticket R-006146 created.

Это лог отладки с корректной обработкой сообщений 1 индекс 1 процесс создания тикета.

2018-10-15 12:12:51 - Processing new eMail (index = 512)
2018-10-15 12:12:51 - Processing new eMail (index = 514)
2018-10-15 12:12:51 - Processing new eMail (index = 515)
2018-10-15 12:12:51 - The message ‘тема сообщения’ is NOT considered as undesired.
2018-10-15 12:13:22 - Processing new eMail (index = 512)
2018-10-15 12:13:22 - The message ‘тема сообщения’ is NOT considered as undesired.
2018-10-15 12:13:22 - Processing new eMail (index = 514)
2018-10-15 12:13:22 - The message ‘тема сообщения’ is NOT considered as undesired.
2018-10-15 12:13:22 - Creating a new Ticket from eMail ‘тема сообщения’
2018-10-15 12:13:22 - Target format for ‘description’: text/html
2018-10-15 12:13:22 - Processing new eMail (index = 516)
2018-10-15 12:13:22 - The message’тема сообщения’ is NOT considered as undesired.
2018-10-15 12:13:22 - Creating a new Ticket from eMail 'тема сообщения’
2018-10-15 12:13:22 - Target format for ‘description’: text/html
2018-10-15 12:13:22 - Email body format: text/html
2018-10-15 12:13:22 - Managing inline images…
2018-10-15 12:13:22 - Ticket DRPZ-007998 created.

Это лог ящика с ошибками. По итогу из 100 обращений 80 создаются 20 падают с ошибкой.

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


#2

Все разобрался, добавил регулярку в модуль трансляции и все заработало


#3

Может кому нибудь когда нибудь пригодится.

       Для решения проблемы нужно перейти в extensions\combodo-mail-to-ticket-automation\itop-standard-email-synchro найти там datamodel.itop-standard-email-synchro.xml в нем есть метод CreateTicketFromEmail ищем там кусок кода который вставляет тему тикета, а именно

		$oTicketTitleAttDef = MetaModel::GetAttributeDef(get_class($oTicket), 'title');
		$iTitleMaxSize = $oTicketTitleAttDef->GetMaxSize();
		$oTicket->Set('title', substr($oEmail->sSubject, 0, $iTitleMaxSize));

и заменяем на

        $oTicketTitleAttDef = MetaModel::GetAttributeDef(get_class($oTicket), 'title');
		$iTitleMaxSize = $oTicketTitleAttDef->GetMaxSize();
		$MyRegExp = "/[^а-яёА-ЯЁA-Z0-9_\-:\/\\()* \.#?№@\"\',]/u";
		$aString = $oEmail->sSubject;
		preg_match_all($MyRegExp , $aString, $matches, PREG_SET_ORDER, 0);
			foreach($matches as $arrExceptions){
			    foreach($arrExceptions as $exceptions){
			        $iElem[]=$exceptions;
			    }
			}		
		$aClear = str_replace($iElem," ",$aString);
                $oTicket->Set('title', substr($aClear, 0, $iTitleMaxSize));

обновляем и все работает


#4

Так в чем причина-то была?
Почитайте про венгерскую нотацию, в айтопе она используется.


#5

Про нотацию почитаю, спасибо. а проблема была в том, что Lotus Notus за место пробелов в некоторые места вставляет другие символы image вот так выглядит в юникоде %A0 и айтоп на это ругался


#6

И еще, в моем случае функция substr, не знаю почему, так же возвращала в конце строки неизвестный символ image по этому пришлось заменить ее на iconv_substr, но на этом преображения не закончились т.к функция iconv_substr отрезает не по весу, а по кол-ву символов по этому стандартное определение размера строки:

  $oTicketTitleAttDef = MetaModel::GetAttributeDef(get_class($oTicket), 'title');
  $iTitleMaxSize = $oTicketTitleAttDef->GetMaxSize();

не подошло. Пришлось определить в конфигах новую переменную:
module.itop-standard-email-synchro -> добавил в ‘settings’ =>‘subject_length’ => ‘125’,
в модуле заменил стандартный способ определения размера на:

 $iLength = utils::GetConfig()->GetModuleSetting('itop-standard-email-synchro', 'subject_length');

В итоге получилось так:

$iLength = utils::GetConfig()->GetModuleSetting('itop-standard-email-synchro', 'subject_length');
$sRegExp = "/[^а-яёА-ЯЁA-Za-z0-9_\-:\/\\()*\.#?№@\"\',]/u";
$sString = $oEmail->sSubject;
$aExceptions = array();
preg_match_all($sRegExp , $sString, $matches);
    foreach($matches as $arr){
        foreach($arr as $a){
            $aExceptions[]=$a;
        }
    }
$sCString = str_replace($aExceptions," ",$sString);
$sCleanSubject = iconv_substr($sCString, 0, $iLength);
$oTicket->Set('title', $sCleanSubject);

Не оптимальное решение ибо вес символа может быть больше 2б и тогда итоп не пропустит по весу, но пока другого решения найти не смог.


#7

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

UPD: возможно, лишние символы получится убрать через filter_var с каким-то очищающим фильтром.