> Синтегрировать все в одной системе.Эдакий монстр.
Мне что-то подсказывает - такого напрямую стоит избегать. Обработка заявок клиентов отдельно, информация о клиентах отдельно и т.д. с минимальным пересечением систем. С одной стороны интеграция сложней и не такая гибкая как порой хочется, зато сопровождать в итоге получается проще. Ну и заодно безопаснее. Т.к. системы пересекаются на минимально необходимом уровне. 17 августа 2012 г., 12:18 пользователь Naim Shafiev <[email protected]> написал: > 17 августа 2012 г., 13:16 пользователь Sergey Malochinskiy > <[email protected]> написал: >> Мне не совсем понятно из вашего описания, что вы ждете от тикет >> системы. С упомянутыми вами продуктами не знаком и оценить возникшие > Синтегрировать все в одной системе.Эдакий монстр. > >> сложности по такому описанию не могу. >> Создавать тикеты(заявки через API) а работать сотрудникам через >> Web-интерфейс. Это основной путь интеграции. > > Я покамесь тоже только такой путь и вижу. > >> Т.е. какие-то разные системы создают заявки, сотрудники работают с >> заявками через web-интерфейс OTRS. Логины и пароли сотрудников вполне >> можно "синхронизировать" между системами. В OTRS это настроить можно и >> не сложно. Также информация по клиентам тоже может браться из >> сторонней БД. >> >> >> 15 августа 2012 г., 15:00 пользователь Naim Shafiev <[email protected]> >> написал: >>> 14 августа 2012 г., 10:08 пользователь Sergey Malochinskiy >>> <[email protected]> написал: >>>> Здравствуйте. >>>> >>>> Что-то мне подсказывает, что готового решения для встраивания не >>>> найдете. Либо писать свое либо использовать и интегрировать OTRS/RT. >>> >>> Ок. Именно вопрос с интеграцией меня сподвигнул на это . В данный >>> момент у нас сложилась такая ситуация - есть наша система с который >>> происходит и управление и хранение различнейшей инфы(данные по >>> клиентам, их потребление и тд) и система обработки заявок Sysaid . >>> При этом sysaid не связан с обьектами ironleg ( к примеру нельзя >>> выбрать абонента у которого траблы, нет инфа об трафике с его порта ) >>> и приходиться все обьекты дублировать , постоянно. >>> Также нету нормальной базы знаний. >>> Sysaid с трудом позволяет(щас работаю над этим) интегрироваться, но >>> там все довольно бажно, как и в любом глубоко проприетарном софте. >>> Причем при интеграции он переносит(перетягивает если кто понял) все >>> на себя. >>> Интересно RT/OTRS при интеграции как себе ведет и можно ли его >>> синтегрировать по моему сценарию. >>> >>> >>>> За последние три года немало поковырялся с OTRS - пишу модули, >>>> сопровождаю для компании в которой работа. локализованную внутреннюю >>>> ветку. >>>> Нравится чистота кода и логичность структуры. Кстати в последних >>>> версиях есть нормальный RPC для приложения айфоновского. Думаю для >>>> интеграции вам подойдет. >>>> Там насколько помню реализован основной функционал которого вам на >>>> первом этапе хватит вполне, а потом можно и расширять своими силами. >>>> Плюс для вас думаю будет полезным настройка авторизации по учетным >>>> данным в другой БД или даже LDAP, что упростит связь приложений. >>>> >>>> >>>> 14 августа 2012 г., 9:00 пользователь Naim Shafiev <[email protected]> >>>> написал: >>>>> 13 августа 2012 г., 23:38 пользователь Nick Knutov <[email protected]> >>>>> написал: >>>>>> Вопрос то в чем? Вы ищите существующее решение, или человека, который >>>>>> такое >>>>>> напишет? >>>>> >>>>> Безусловно решение. >>>>> Делать то все равно моей командой. >>>>> >>>>>> >>>>>> 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 >>>>>> [email protected] | http://moscow.pm.org >>>>> -- >>>>> Moscow.pm mailing list >>>>> [email protected] | http://moscow.pm.org >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Sergey Malochinskiy >>>> -- >>>> Moscow.pm mailing list >>>> [email protected] | http://moscow.pm.org >>> -- >>> Moscow.pm mailing list >>> [email protected] | http://moscow.pm.org >> >> >> >> -- >> Best regards, >> Sergey Malochinskiy >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Best regards, Sergey Malochinskiy -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
