[Moscow.pm] Легковесный аналог RT/OTRS для встраивания в стороннее приложение.

[Ruslan Zakirov]

2012/8/19 Naim Shafiev <shafiev на gmail.com>:
> 17 августа 2012 г., 23:31 пользователь Ruslan Zakirov
> <ruz на bestpractical.com> написал:
>> 2012/8/17 Naim Shafiev <shafiev на gmail.com>:
>>> 17 августа 2012 г., 13:16 пользователь Sergey Malochinskiy
>>> <sergey.malochinskiy на gmail.com> написал:
>>>> Мне не совсем понятно из вашего описания, что вы ждете от тикет
>>>> системы. С упомянутыми вами продуктами не знаком и оценить возникшие
>>> Синтегрировать все в одной системе.Эдакий монстр.
>>>
>>>> сложности по такому описанию не могу.
>>>> Создавать тикеты(заявки через API) а работать сотрудникам через
>>>> Web-интерфейс. Это основной путь интеграции.
>>>
>>> Я покамесь тоже только такой путь и вижу.
>>
>> Для интеграции все равно придется опрашивать стороннюю систему или
>> тянуть данные. Так как везде perl, то RPC/REST можно не использовать,
>> а использовать API.
>
> +1. Я из-за этого и выбираю между OTRS/RT.
>
>>
>>> к примеру нельзя выбрать абонента у которого траблы,
>>
>> Вот для этого вам придется либо писать SQL, который говорит с
>> несколькими БД, хранить все в одной БД и общаться с частью OTRS/RT на
>> чистом SQL. Другой вариант написать скрипт, который в вашу БД заливает
>> выжимки. Последнее считаю предпочтительней. Во первых, не нужно
>> общаться с другой системой в реальном времени. Во вторых, систему
>> легче заменить.
>
> Ок,логически я так себе все представлю.
> Попробую реализовать оба варианта(  и их по очереди запустить на части
> абонентов в продакшене)
>
>>
>> Самый простое - это флаг в таблице абонентов, который синкается с
>> трекером. Можно соответственно делать простые запросы типа "найти
>> абонента с проблемами". На странице абонента ссылка на трекер, которая
>> ведет сразу на поиск активных заявок этого абонента.
>>
>
> Ок.
>
>> Усложняется процедура поддержки и внесения нового функционала.
> Где усложняется и почему?
> Если ironleg то там усложнение будет минимально возможным .

Если тянуть данные в ironleg, то возникает вопрос сколько тянуть.
Каждое изменение приведет к изменению в схеме, в скриптах, которые
тянут и так далее.

Если брать в реальном времени через API, то самые большие трудности с
кросс выборками. Несколько способов:

1) Вы можете делать их через программный nested loop - для каждого
найденого объекта одной БД делаем проверку в другой БД. Медленно и не
эффективно. Можно ускорить проверкой сразу нескольких найденных
записей. Хорош вариант завязкой только на API.

2) Как я уже говорил, можно в одну из систем внести знания о схеме БД
другой системы. Тогда можно делать выборки из двух БД сразу используя
API одной системы. Недостаток в привязке к схеме БД, а также в
необходимости понимать ее. Схема БД редко описывается. Изменения между
мажорными версиями, если они есть, то они часто радикальные.

> P.S
> Я щас немного не сразу вьезжаю наверное из-за воздуха Лерика ;)

-- 
Best regards, Ruslan.