Пароль админа на УКМ4 : УКМ-4

намана намана :) мне как раз очень приятно, что-то кто-то полазил и извлёк пользу от того, что текст открыт. вот если бы ещё кто-нить отчётов нарисовал или ещё какую полезность, мы бы репозиторий пользовательских страниц сформировали. эх, красота была бы :)

Идея очень правильная.
По поводу дополнительных отчетов клиенты у нас уже начинают интересоваться, правда пока никто еще не изложил это в виде нормального тех. задания.

Так, что пока, в целях собственного развития пытаюсь, что-то вывести на экран (например динамику чеков в виде графиков - пользы наверное мало - зато красиво :), или например количество логинов и логаутов в течение рабочего дня по кассе - можно сделать некоторые предположения, а правильно ли кассир выключила кассу)

Если бы база была вменяемая, описание и структура :( А то вот перейдете на 5 мускул, часть не будет работать на новом...

Разрешать пользоваться внутренними механизмами для нештатных разработчиков в не opensource продукте путь либо сразу же тупиковый либо очень тернистый для желающих там копаться. Структура БД однозначно является именно внутренним знанием. И даже когда мы пишем стандартный конвертер, мы всегда делаем прослойку в виде ещё одной базы для обмена. Платим этой базой за возможность менять внутреннюю структуру без оглядки на последствия. Конечно чудес тут нет, и в случае изменения внутренней структуры приходится затрагивать все конвертеры, но зато это происходит подконтрольно.

И когда я говорю про написание своего отчёта (например) я прежде всего имею ввиду следующую последовательность:

- IT отдел на какой-то версии УКМ построил свой отчёт
- Передал отчёт нам
- С этого момента поддержание отчёта в работающем состоянии от версии к версии наша головная боль.

что получаем мы - практичный отчёт, прошедший проверку "боем", чем платим - необходимость тащить "отчёт" вс. оставшуюся жизнь

что получает клиент - нужный ему отчёт, плюс гарантию поддержки этого отчёта силами СП в будущих версиях. чем платит - IT ресурсом, которому пришлось копаться в наших внутренностях, писать и отлаживать отчёт.

таким образом, версия мускула, структура и прочий инструментарий не мешают использовать
внешний код.

В этом случае есть рамки вашего нежелания поддерживать какие-то отчеты и костыли и время на их апгрейд, а так же нежелание разработчика передавать вам код по каким-то причинам (например, чтобы не становиться заложником того же апгрейда). В эти рамки уложится очень многое. Я думаю даже бОльшая часть. Например, есть у меня какой-то свой отчет, я, естественно, хочу, чтобы он работал сейчас и три версии спустя. Итак, чтобы его передать вам, я должен его вам объяснить, потратив личное или рабочее время, теряю возможность его менять по собственному усмотрению даже незначительно (доступа к вашему репозиторию у меня нет), далеко не факт, что он вам нужен и вы будете его поддерживать, далеко не факт, что кто-то не попросит его изменить и эти изменения не будут противоречить моим целям, неизвестно, как разрешится ситуация, если вы проапгрейдив его один раз не откажетесь от функционала в следующей версии, заставив меня пройти две версии и копаться в том, что я забыл. Так что лучше тернистый путь самостоятельной поддержки и именно поэтому я для УКМ4 ничего не пишу. А вот заняться редизайном и оптимизацией структуры базы надо по любому, самим проще будет да и при текущем подходе коллапс все равно когда-нибудь наступит. Кому надо - справятся и с этой структурой, а вот добровольную стороннюю разработку, на которую вы и расчитываете, нынешнее положение вещей сильно тормозит.

Если говорить объективно, то написание пользовательского кода в УКМ мероприятие маловероятное совсем по другим причинам. Во-первых, это малоинтересно. И объясняется это положением системы о общей инфраструктуре. Система находится на самом нижнем уровне иерархии и если и нуждается в пользовательском коде, то только в части соединения УКМ и какой-то другой системы. Однако, если пользователь всё-таки преодолев все сложности был вынужден самостоятельно писать код для УКМ, значит мы как разработчики что-то прощёлкали и нам важно понять что. Во-вторых, использовать код который написан не нами для работы с деньгами людей очень опасно. Ведь с одной стороны в случае проблем ответственность ляжет на нас, а с другой стороны максимум что мы можем сделать это посетовать на чужой код.

Что касается структуры БД, сейчас построили механизм дизайнера отчётов, это даёт возможность создавать самостоятельно отчёты базируясь на наших данных. Важно отметить, не на наших структурах, и именно на данных. То есть для получения списка документов пользователь не пишет

select id, name from tram_tam_tam.trun_tun_tun

а так и пишет - get_document_list()

таким образом мы получаем прослойку, которая даст нам возможность сохранив такую сущность как id документа и его название, тем не менее сохранить себе свободу в выборе способа его хранения. А чтобы писать код на внутренней структуре, нужно чтобы разработчик её опубликовал, то есть таким образом пообещал, что структура не будет меняться.

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

Примеров тому даже сейчас существует несколько - есть интерфейс взаимодействия с платёжной системой, любой кто хочет использовать свои карты, со своими счетами может этим воспользоваться. Импорт экпорт данных - описано, можно пользоваться, от внутренней структуры не зависит! Система видеонаблюдения (а по факту просто нотификатор событий), подключайся, все данные описаны и фактически распрастраняются.

Я ещё раз хочу подчеркнуть, что желание писать со стороны важно по двум причинам - первое, это может означать нехватку чего-то важного, что можно вставить в продукт и второе, на основании этого можно сформировать интерфейс и опубликовать его.

Нет никакого желания в качестве такого интерфейса отдавать например БД. Во-первых для решения пользовательских задач структура данных может показаться слишком громоздка (кстати когда данные проходят через импорт экспорт для пользователя они представляются в сильно упрощённом виде)
. Во-вторых, за две ближайшие версии нам нужно решить две задачи, которые кардинально повлияют на структуру - отказаться от серверной схемы и перейти на распределённую и вторая разделить понятие документа в работе и документа в БД, там образом мы хотим сильно сократить количество таблиц и связей между ними. Если бы мы публиковали БД, этот путь был бы либо закрытым либо мы бы здорово подставили тех, кто что-то написал.

То, что желание писать есть - однозначно. Причем некоторые вещи имеют сугубо личный, частный характер. Для полного отвлечения пользователя от структуры БД придется писать неимоверно широкий интерфейс плагинов, что не представляется разумным. Более того, при открытости и логичности структуры БД можно ловить глюки общими усилиями и привлекать все новых разработчиков без длительного вникания в суть дела, да и охватывать одним разработчиком более широкий круг задач. Насчет подстав со сменой структуры, думаю, если задумка удастся, то подстава оправдается упрощением решения кучи других задач. В нормальных условиях не требуется кардинальной смены структуры и разработчики со стороны нормально адаптируются к ее смене.

Спрашивал специально, но никто не ответил - зачем? Поэтому пока я вижу только беспредметное желание. А это очень зыбкая основа для каких либо действий со стороны разработчиков УКМ для привлечения внешних разработчиков. Я думаю мы сделаем так, у нас уже сформировалось несколько интерфейсов готовых к публикации, сейчас разберёмся со стандартом и быть может официально откроем их. Пока рассматриваются SOAP и D-BUS, пока перевес на стороне SOAP. Откроем и при возникновении подходящих задач постараемся их решить снаружи, если это удасться, будем считать неплохим началом и в дальнейшем развивать эту тему.

На данный момент статус интереса к внешнему коду выглядит так - "было бы здорово, но, в принципе, по барабану" :)

Никто не может тебе назвать что-то монументальное, но запросы к базе пишутся, думаю, большинством вменяемых людей, работающих с УКМ4. Что касается SOAP, то мне, если честно, не хочется сидеть и разгребать эти XML-навороты и изучать вашу спецификацию к ним. Есть база и желание быстро добыть из нее информацию, имея минимальную квалификацию и уже существующие инструменты.
Люди не сидят и бездельем не маются, тут все на бегу... Все это шашечки, а нужно ехать, причем как правило сроки - "вчера". Куча внедряемых технологий не нужна, среднестатический админ, имея зоопарк софта и запаренный вопросами юзеров не будет сидеть и листать талмуд с трилогию Толстого. А вот из вменяемой структуры базы выдернуть запросом то, что ему отдел маркетинга напилил - запросто. Прикинь, как ты увеличиваешь стоимость штатной единицы, способной обслуживать магазин на УКМ? Зачем такой человек пойдет в магаз, если он может идти в ЦУП работать с такими знаниями?

Мне известно только два примера, и то это наши саппортеры написали - дамп чека из БД и разрушение последнего чека.

А это и не требуется, ведь никого не пугает подключение через клиента Oracle к его серверу БД? А там протокол похлеще, одна авторизация чего стоит. SOAP это просто инструмент, даже я бы сказал просто транспорт. Пользователю нужно знать название функции и параметры, проще мне кажется уже некуда :) SOAP хорош тем, что только что из-под DOS тебе не удасться обратиться к нужному коду, во всех остальных случаях всё готово, написано и шарит без проблем. А вот из-под DOS действительно нужно покопаться и в TCP/IP, и в HTTP, и в XML и наконец в SOAP.

Я уже говорил, что само положение УКМ в структуре магазина не даёт оснований полагать, что в его БД, есть что-то уникальное и очень интересное, это может для бэкофисов справедливо, а в кассе делать в этом море чеков совершенно нечего. Ведь все справочники пришли из бэка, а все чеки ушли в бэк обратно. Фронт по сути своей получается петлёй, которая начинается в бэке, проходит через покупателя и возвращается обратно в бэк. В этом его смысл.

И потом быстро добыть информацию это вовсе не то, что я называю разработкой. Меня гораздо больше интересуют вещи, которые по объективным причинам проще сделать ИТ ресурсами клиента. Банальная скидка любой заковыристости от самой сложной до самой простой нуждается в экспорте своих правил в УКМ и чёткой алгоритмизации поведения на кассе. А ведь всё это в принципе на стороне клиента давно известно. Например, SAP сводобно умеет обращаться к веб сервисам. Уже содержит средства программирования. Позволяет создавать свои сущности и описывать структуру хранения. Так зачем имея такую мощь пытаться экспортировать скидки и заказывать у С+ новый алгоритм расчёта скидки? Ведь мы можем организовать запрос из УКМ в САП, передать всё, что у нас на данный момент известно о текущем чеке - позиции, платежи, существующие скидки, дисконтные карты и так далее, а нам просто сообщат какую скидку дать. И всё! Никакого лазанья по БД (САП по своей, мы по своей), а тем не менее скидка работает на стороне САП и без всякого усилия с нашей стороны оказывается в УКМ.