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

Пт Авг 17 01:27:54 PDT 2012

> Синтегрировать все в одной системе.Эдакий монстр.

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

17 августа 2012 г., 12:18 пользователь Naim Shafiev <shafiev на gmail.com> написал:
> 17 августа 2012 г., 13:16 пользователь Sergey Malochinskiy
> <sergey.malochinskiy на gmail.com> написал:
>> Мне не совсем понятно из вашего описания, что вы ждете от тикет
>> системы. С упомянутыми вами продуктами не знаком и оценить возникшие
> Синтегрировать все в одной системе.Эдакий монстр.
>
>> сложности по такому описанию не могу.
>> Создавать тикеты(заявки через API) а работать сотрудникам через
>> Web-интерфейс. Это основной путь интеграции.
>
> Я покамесь тоже только такой путь и вижу.
>
>> Т.е. какие-то разные системы создают заявки, сотрудники работают с
>> заявками через web-интерфейс OTRS. Логины и пароли сотрудников вполне
>> можно "синхронизировать" между системами. В OTRS это настроить можно и
>> не сложно. Также информация по клиентам тоже может браться из
>> сторонней БД.
>>
>>
>> 15 августа 2012 г., 15:00 пользователь Naim Shafiev <shafiev на gmail.com> написал:
>>> 14 августа 2012 г., 10:08 пользователь Sergey Malochinskiy
>>> <sergey.malochinskiy на gmail.com> написал:
>>>> Здравствуйте.
>>>>
>>>> Что-то мне подсказывает, что готового решения для встраивания не
>>>> найдете. Либо писать свое либо использовать и интегрировать OTRS/RT.
>>>
>>> Ок. Именно вопрос с интеграцией меня сподвигнул на это . В данный
>>> момент у нас сложилась такая ситуация - есть наша  система с который
>>> происходит и управление и хранение различнейшей инфы(данные по
>>> клиентам, их потребление и тд) и система обработки заявок Sysaid .
>>> При этом sysaid не связан с обьектами ironleg ( к примеру нельзя
>>> выбрать абонента у которого траблы, нет инфа об трафике с его порта )
>>> и приходиться все обьекты дублировать  , постоянно.
>>> Также нету нормальной базы знаний.
>>> Sysaid с трудом позволяет(щас работаю над этим) интегрироваться, но
>>> там все довольно бажно, как и в любом глубоко проприетарном софте.
>>> Причем при интеграции он переносит(перетягивает если кто понял)  все
>>> на себя.
>>> Интересно RT/OTRS при интеграции как себе ведет и можно ли его
>>> синтегрировать по моему сценарию.
>>>
>>>
>>>> За последние три года немало поковырялся с OTRS - пишу модули,
>>>> сопровождаю для компании в которой работа. локализованную внутреннюю
>>>> ветку.
>>>> Нравится чистота кода и логичность структуры. Кстати в последних
>>>> версиях есть нормальный RPC для приложения айфоновского. Думаю для
>>>> интеграции вам подойдет.
>>>> Там насколько помню реализован основной функционал которого вам на
>>>> первом этапе хватит вполне, а потом можно и расширять своими силами.
>>>> Плюс для вас думаю будет полезным настройка авторизации по учетным
>>>> данным в другой БД или даже LDAP, что упростит связь приложений.
>>>>
>>>>
>>>> 14 августа 2012 г., 9:00 пользователь Naim Shafiev <shafiev на gmail.com> написал:
>>>>> 13 августа 2012 г., 23:38 пользователь Nick Knutov <mail на knutov.com> написал:
>>>>>> Вопрос то в чем? Вы ищите существующее решение, или человека, который такое
>>>>>> напишет?
>>>>>
>>>>> Безусловно решение.
>>>>> Делать то все равно моей командой.
>>>>>
>>>>>>
>>>>>> 13.08.2012 17:44, Naim Shafiev пишет:
>>>>>>
>>>>>>> Доброго времени суток господа.
>>>>>>> Встала задача организации системы заявок и их обработки в нашей
>>>>>>> системе управления ironleg ( я в киеве показывал, может кто и видел
>>>>>>> ).
>>>>>>> Так вот в виду того,что держать много систем рук нету  и люди ими не
>>>>>>> хотят пользоваться, то надо поднять легковесный(именно по функциям)
>>>>>>> аналог RT/OTRS , который можно спокойно встроить в наш perlовый код
>>>>>>> ironlegа.
>>>>>>>
>>>>>>> От системы хочется покамест следующего:
>>>>>>> 0) Заявки создаются как вручную так и посредством данных
>>>>>>> мониторинга(это часть уже написана)
>>>>>>> 1) Создание заявки с привязкой к нашему объекту(школу/частный
>>>>>>> пользователь)
>>>>>>> 2) Состояние заявки - неопределенный статус, решено, в процессе
>>>>>>> решения, не может быть решено по причине(тут как бы строгий список из
>>>>>>> АТС/ремонт/административная проблема)
>>>>>>> 3) История всего этого
>>>>>>>
>>>>>>> P.S Предчувствую , в виду того что аппетит растет во время еды,
>>>>>>> накрутки требований для  всего этого со стороны вышестоящих товарищей,
>>>>>>>   и превращения этого во внеочередной велосипед с квадратными колесами
>>>>>>> , нерациональность подхода.Однако пока рассматриваю верхний вариант.
>>>>>>> P.P.S Привязка посредством API с  RT/OTRS тоже параллельно
>>>>>>> рассматривается.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards,
>>>>>> Nick Knutov
>>>>>> http://knutov.com
>>>>>> ICQ: 272873706
>>>>>> Voice: +7-904-84-23-130
>>>>>> --
>>>>>> Moscow.pm mailing list
>>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>> --
>>>>> Moscow.pm mailing list
>>>>> moscow-pm на pm.org | http://moscow.pm.org
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Sergey Malochinskiy
>>>> --
>>>> Moscow.pm mailing list
>>>> moscow-pm на pm.org | http://moscow.pm.org
>>> --
>>> Moscow.pm mailing list
>>> moscow-pm на pm.org | http://moscow.pm.org
>>
>>
>>
>> --
>> Best regards,
>> Sergey Malochinskiy
>> --
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

-- 
Best regards,
Sergey Malochinskiy