Система обработки заявок, Стыковка со сторонним/своим ПО |
Здравствуйте, гость ( Вход | Регистрация )
Система обработки заявок, Стыковка со сторонним/своим ПО |
Pro100A1ex |
4.7.2018, 21:02
Сообщение
#21
|
Активный участник Группа: Пользователи Сообщений: 287 Регистрация: 18.8.2015 Пользователь №: 7 019 |
|
kurilka |
18.7.2018, 10:18
Сообщение
#22
|
Участник Группа: Пользователи Сообщений: 85 Регистрация: 22.8.2008 Пользователь №: 3 136 |
Я полностью поддерживаю это
отделить SPult от самой системы обработки заявок, так как может использоваться уже готовая система... А так как большинство систем учета заявок имеют встроенный почтовый парсер, то достаточно сформировать и отправить письмо с необходимой информацией из SPult, чтобы было так Вся дальнейшая работа с введённой заявкой производится уже в системе обработки заявок... |
revit |
18.7.2018, 11:22
Сообщение
#23
|
Активист Группа: Пользователи Сообщений: 6 658 Регистрация: 7.2.2006 Из: г. Ростов-на-Дону Пользователь №: 3 |
А так как большинство систем учета заявок имеют встроенный почтовый парсер, .... Это откуда такая статистика?-------------------- Я не понял Вашего вопроса, но я Вам на него отвечу.....
Лень-психоматический признак исправности выработанного за годы эволюции механизма интуитивного распознавания безсмысленности выполняемой задачи. |
sergey57949 |
18.7.2018, 13:20
Сообщение
#24
|
Активный участник Группа: Пользователи Сообщений: 293 Регистрация: 22.12.2013 Из: Волгоград Пользователь №: 6 847 |
У меня такая система учета
Поэтому и жду систему от разработчиков Эскизы прикрепленных изображений |
kurilka |
19.7.2018, 10:58
Сообщение
#25
|
Участник Группа: Пользователи Сообщений: 85 Регистрация: 22.8.2008 Пользователь №: 3 136 |
|
sergey57949 |
19.7.2018, 12:22
Сообщение
#26
|
Активный участник Группа: Пользователи Сообщений: 293 Регистрация: 22.12.2013 Из: Волгоград Пользователь №: 6 847 |
Скиньте ссылочку на готовый проект, если не трудно
|
kurilka |
19.7.2018, 15:43
Сообщение
#27
|
Участник Группа: Пользователи Сообщений: 85 Регистрация: 22.8.2008 Пользователь №: 3 136 |
sergey57949 из того, что помню:
trellis desk, freehelpdesk, osTicket, Reguest Tracker, hesk, itop, redmine, otrs, glpi. Поиск по словам help desk, service desk, тикет система. |
sergey57949 |
19.7.2018, 17:30
Сообщение
#28
|
Активный участник Группа: Пользователи Сообщений: 293 Регистрация: 22.12.2013 Из: Волгоград Пользователь №: 6 847 |
Благодарствую.
Побуду назойливым. А какой из них вы пользуетесь? Я так понимаю, вы выбрали приемлемую для себя. Мне чтоб не перебирать все подряд. |
kurilka |
19.7.2018, 20:45
Сообщение
#29
|
Участник Группа: Пользователи Сообщений: 85 Регистрация: 22.8.2008 Пользователь №: 3 136 |
osTicket - чем он мне не понравился уже не помню, но посмотреть стоит.
hesk - не плох, легкий интерфейс, база знаний, настраиваемые поля... Для меня был кандидатом №1. otrs - монстр в плане интерфейса, для меня слишком перегружен. Не пошел, хоть и очень гибко настраиваемый. redmine - очень круто, но из коробки пользоваться сложно. Если с программированием дружба, есть свободное время и не лень этим заниматься, то рекомендую, может получиться очень мощная система. Мне лень, у меня не прижился. glpi - определяющим фактором, помимо активности проекта, для меня стала встроенная система инвентаризации. Внес туда все оборудование, контакты, поставщиков, договора, настроил автоматические уведомления. В общем с ней и живу 2+ года. НО! К интерфейсу надо привыкнуть, как то французы немного не логичны, что ли. В общем, проект должен быть активным. Это главное. Если последнее обновление было год назад и форум в спячке, то смотреть на такие проекты не стоит. Если нужна просто тикет-система - hesk, osTicket и им подобные. Выбор по дружелюбности интерфейса. Кстати, у некоторых проектов есть demo-сайты. Можно без установки посмотреть и "пощупать" интерфейс. Точно есть у trellis desk, itop, otrs, glpi, hesk. |
ВячеславK |
21.11.2018, 12:12
Сообщение
#30
|
Участник Группа: Пользователи Сообщений: 15 Регистрация: 31.10.2013 Пользователь №: 6 825 |
Хотелось бы получить мнения по такому подходу, а так же уточнить перечень информации, которую должна содержать заявка, формируемая в SPult. Вставлю свои пять копеек... Возможность связи SPult по инициативе диспетчера с сторонними программами очень даже нужна и интересна! Лично я за локальную обработку данных по нескольким причинам: 1) Не всегда есть возможность "тонко" настроить логику сторонней программы (очевидно, что заявки на освобождение застрявшего пассажира, ремонт двигателя, проверку/восстановление связи и мытье в лифте обрабатываются по совершенно разной логике)! 2) В случае необходимости получить дополнительную (обновленную) информацию из БД SPult придется опять же городить костыли на "чужой" площадке + необходимо будет дать доступ к БД третьей стороне, что не лучшим образом скажется на безопасности... 3) Если организация в силах создать и/или подключить систему обработки заявок, то я думаю создать локальный демон для промежуточной обработки не должно составить труда, а вот вернуться с удаленного сервиса в локальную систему уже может быть очень сложно. Имею в виду в том числе и то, что есть ведь еще и MPult, а у него все лежит локально... По поводу состава информации, то, в случае самостоятельной обработки считаю, что полностью достаточно будет адреса на локальной шине и логина диспетчера. Все остальное легко берется из БД и конфигов. Против XML ни чего не имею, но лично мне будет достаточно и плоского файла и даже пустого файла в названии которого будет "зашито" имя пользователя и адрес на локальной шине (типа kudryavtsev.0.4.6.21.lft). Я буду раз в секунду проверять наличие таких файлов и дальше уже делать с ними ВСЕ что придумает мое больное воображение, не дожидаясь пока LKDS, osTicket или glpi че-то там специально для меня допилят... ))) UPD: Вспомнил еще вот что - практически во всех онлайн системах обработки запросов (хоть тикет системах, хоть CRM) в теле запроса присутствует секретный ключ безопасности, дискредитация которого может дорого обойтись... А в большинстве случаев придется формировать и хранить эти ключи на КАЖДОГО пользователя (каждого диспетчера как минимум)... Готов ЛифтКомплексДС плодить сущности? |
Андрей Ефименко |
22.11.2018, 8:21
Сообщение
#31
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
Вставлю свои пять копеек... Возможность связи SPult по инициативе диспетчера с сторонними программами очень даже нужна и интересна! Лично я за локальную обработку данных по нескольким причинам: 1) Не всегда есть возможность "тонко" настроить логику сторонней программы (очевидно, что заявки на освобождение застрявшего пассажира, ремонт двигателя, проверку/восстановление связи и мытье в лифте обрабатываются по совершенно разной логике)! 2) В случае необходимости получить дополнительную (обновленную) информацию из БД SPult придется опять же городить костыли на "чужой" площадке + необходимо будет дать доступ к БД третьей стороне, что не лучшим образом скажется на безопасности... 3) Если организация в силах создать и/или подключить систему обработки заявок, то я думаю создать локальный демон для промежуточной обработки не должно составить труда, а вот вернуться с удаленного сервиса в локальную систему уже может быть очень сложно. Имею в виду в том числе и то, что есть ведь еще и MPult, а у него все лежит локально... По поводу состава информации, то, в случае самостоятельной обработки считаю, что полностью достаточно будет адреса на локальной шине и логина диспетчера. Все остальное легко берется из БД и конфигов. Против XML ни чего не имею, но лично мне будет достаточно и плоского файла и даже пустого файла в названии которого будет "зашито" имя пользователя и адрес на локальной шине (типа kudryavtsev.0.4.6.21.lft). Я буду раз в секунду проверять наличие таких файлов и дальше уже делать с ними ВСЕ что придумает мое больное воображение, не дожидаясь пока LKDS, osTicket или glpi че-то там специально для меня допилят... ))) UPD: Вспомнил еще вот что - практически во всех онлайн системах обработки запросов (хоть тикет системах, хоть CRM) в теле запроса присутствует секретный ключ безопасности, дискредитация которого может дорого обойтись... А в большинстве случаев придется формировать и хранить эти ключи на КАЖДОГО пользователя (каждого диспетчера как минимум)... Готов ЛифтКомплексДС плодить сущности? Именно, что бы не плодить сущности и было предложено передавать заявку в виде http(s) запроса post с телом в виде XML строк. Использование протокола http позволяет обработать заявку как на том же компьютере, на котором запущен SPult, так и на другом компьютере (компьютере-сервере), доступном по сети. Использование https позволяет защитить передаваемую информацию, если информация критична. Запустить http(s) сервер сейчас не представляет трудностей. В принципе, этот сервер может сформировать предложенный файл после разбора полученного http запроса, хотя логичнее было бы все-таки сразу его и обработать. Замечания конкретно по предложенному подходу: 1. Сейчас, для однозначной идентификации ЛБ, используется не только адрес на локальной шине (адрес в сети «Обь», т.е. в LKDSDrv), но и индекс ЛБPro в службе поддержки ЛБPro (LKDSPro), а так же идентификатор (ID) ЛБPro в «облаке» (LKDSCloud) и LKDSDomain. 2. SPult – это клиент сервера, соответственно одновременно может работать несколько SPult (диспетчеров) на разных компьютерах. Не ясно как можно в данном случае обойтись без единого сервера обработки заявок. 3. ASPult ограниченно, но все-таки используется для реальной работы, поэтому и ASPult должен иметь возможность сформировать заявку. При использовании http это возможно. Опять же, что бы не плодить сущности, как альтернатива формированию предложенного файла, можно использовать возможность вывода оператором в журнал специальной записи , которую оператор может сформировать по своей инициативе. Приложение, которое должно было обрабатывать файл, может читать записи журнала в базе данных, извлекать сообщения оператора и обрабатывать записи оператора, так же, как обрабатывало бы файлы. |
Андрей Ефименко |
13.12.2018, 14:56
Сообщение
#32
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
Именно, что бы не плодить сущности и было предложено передавать заявку в виде http(s) запроса post с телом в виде XML строк. Использование протокола http позволяет обработать заявку как на том же компьютере, на котором запущен SPult, так и на другом компьютере (компьютере-сервере), доступном по сети. Использование https позволяет защитить передаваемую информацию, если информация критична. Запустить http(s) сервер сейчас не представляет трудностей. В принципе, этот сервер может сформировать предложенный файл после разбора полученного http запроса, хотя логичнее было бы все-таки сразу его и обработать. Замечания конкретно по предложенному подходу: 1. Сейчас, для однозначной идентификации ЛБ, используется не только адрес на локальной шине (адрес в сети «Обь», т.е. в LKDSDrv), но и индекс ЛБPro в службе поддержки ЛБPro (LKDSPro), а так же идентификатор (ID) ЛБPro в «облаке» (LKDSCloud) и LKDSDomain. 2. SPult – это клиент сервера, соответственно одновременно может работать несколько SPult (диспетчеров) на разных компьютерах. Не ясно как можно в данном случае обойтись без единого сервера обработки заявок. 3. ASPult ограниченно, но все-таки используется для реальной работы, поэтому и ASPult должен иметь возможность сформировать заявку. При использовании http это возможно. Опять же, что бы не плодить сущности, как альтернатива формированию предложенного файла, можно использовать возможность вывода оператором в журнал специальной записи , которую оператор может сформировать по своей инициативе. Приложение, которое должно было обрабатывать файл, может читать записи журнала в базе данных, извлекать сообщения оператора и обрабатывать записи оператора, так же, как обрабатывало бы файлы. Описание доработок в Документе Это начальный вариант формата взаимодействия SPult с внешней системой обработки заявок. Конечно, наполнение информацией можно менять, например, можно добавить состояние контрольных точек, выдержку из журнала событий по этому лифту, состояние кабины и т.п. Так же панель формирования заявки можно существенно доработать, добавив автоматизацию описания события в виде выбора из описаний из каких-то наборов. Главное все-таки, что бы эти внешние системы обработки заявок были адаптированы к приёму заявок от SPult, либо разработаны самостоятельно, сейчас это не представляет особых проблем. |
sergey57949 |
13.12.2018, 17:27
Сообщение
#33
|
Активный участник Группа: Пользователи Сообщений: 293 Регистрация: 22.12.2013 Из: Волгоград Пользователь №: 6 847 |
У меня не запускается
Эскизы прикрепленных изображений |
Андрей Ефименко |
14.12.2018, 8:15
Сообщение
#34
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
|
ВячеславK |
19.12.2018, 10:39
Сообщение
#35
|
Участник Группа: Пользователи Сообщений: 15 Регистрация: 31.10.2013 Пользователь №: 6 825 |
В файле c:\LKDSDrv\SPult\LogSpultBad\B0000001.Bad по этому поводу имеется только одна строчка: "19.12.2018 10:54:22 RequestPort connect(): 10061 (0x274d) - Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение."
В настройках подключения указала https://localhost/spz Фактически сервер на localhost не запущен (симулировал ситуацию). Сразу хочу сказать - я категорически против формулировок в журнал типа "Запись на обслуживание успешно послана..." Это мы, технари, будем читать, что да, мол, диспетчер нажал кнопочку, а те, для кого этот журнал собственно и нужен будут читать, что вот же заявка успешно послана и ПРИНЯТА!!! Успешно же! Эскизы прикрепленных изображений |
Андрей Ефименко |
19.12.2018, 15:13
Сообщение
#36
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
В файле c:\LKDSDrv\SPult\LogSpultBad\B0000001.Bad по этому поводу имеется только одна строчка: "19.12.2018 10:54:22 RequestPort connect(): 10061 (0x274d) - Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение." В настройках подключения указала https://localhost/spz Фактически сервер на localhost не запущен (симулировал ситуацию). Сразу хочу сказать - я категорически против формулировок в журнал типа "Запись на обслуживание успешно послана..." Это мы, технари, будем читать, что да, мол, диспетчер нажал кнопочку, а те, для кого этот журнал собственно и нужен будут читать, что вот же заявка успешно послана и ПРИНЯТА!!! Успешно же! В данном случае в журнале будет запись о том, что заявка НЕ принята. SPult считает, что заявка принята: |
Андрей Ефименко |
20.12.2018, 7:52
Сообщение
#37
|
Активист Группа: Администраторы Сообщений: 2 718 Регистрация: 8.2.2006 Пользователь №: 4 |
В файле c:\LKDSDrv\SPult\LogSpultBad\B0000001.Bad по этому поводу имеется только одна строчка: "19.12.2018 10:54:22 RequestPort connect(): 10061 (0x274d) - Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение." Фактически сервер на localhost не запущен (симулировал ситуацию). Доработан SPult, что бы и при ошибках подключения к серверу обработки заявок в лог SPult записывался POST запрос. Текст заявки и текст ответа выводится в лог в кодировке utf-8 SPult выложен в штатное обновление ПО |
sergey57949 |
27.1.2019, 14:43
Сообщение
#38
|
Активный участник Группа: Пользователи Сообщений: 293 Регистрация: 22.12.2013 Из: Волгоград Пользователь №: 6 847 |
Наткнулся вот на такое- https://play.google.com/store/apps/details?...nisoft.lmonitor
Правда за неделю так ни кто и не откликнулся, чтоб попробовать этот продукт. Но идея не плоха. |
sergey57949 |
1.2.2019, 11:17
Сообщение
#39
|
Активный участник Группа: Пользователи Сообщений: 293 Регистрация: 22.12.2013 Из: Волгоград Пользователь №: 6 847 |
Попробовал все таки пробничек.
Мне понравилось. Надо ЛКДС что то подобное замутить. Прикололо, что нельзя заявку выполнить не находясь возле дома, отслеживает местоположение Эскизы прикрепленных изображений |
oleg |
1.3.2019, 8:24
Сообщение
#40
|
Активист Группа: LKDS_Team Сообщений: 1 534 Регистрация: 10.2.2006 Пользователь №: 6 |
Добрый день, коллеги. Хотим познакомить вас с новой программой мониторинга техобслуживания лифтов "Лифт Мониторинг 2.0." Состав продукта: Диспетчерская с web-интерфейсом Мобильное приложение электромеханика . . . . . Обсуждение стороннего коммерческого продукта "Лифт Мониторинг 2.0." перенесено в раздел "Куплю-Продам". Лифт Мониторинг 2.0. |
Текстовая версия | Сейчас: 29.3.2024, 10:45 |