Информация из защищённого лог-файла

[Остапченко]

Можно ли как-нибудь получить доступ к информации из защищённого лог-файла, кроме как через экспорт в лог-файл? Может быть можно из своего приложения на VB или VBA для Excel/Access через API как нибудь обратиться? Запись в него не нужна. Только чтение.
И ещё, можно ли как-нибудь ограничить доступ к настройкам пользователю?

[Даниленко Сергей]

Можно ли как-нибудь получить доступ к информации из защищённого лог-файла, кроме как через экспорт в лог-файл? Может быть можно из своего приложения на VB или VBA для Excel/Access через API как нибудь обратиться? Запись в него не нужна. Только чтение.

Открытого API по этому поводу у нас нет и не будет - иначе лог-файл перестанет быть закрытым . Можем добавить в SLLogViewer опцию для запуска из командной строки, которая будет декодировать указанный SLLog-файл и генерить из него текстовый файл. А вы из своего приложения дернете SLLogViewer, он раскодирует указанный файл, а дальше вы делаете с ним что хотите.
Устраивает?

И ещё, можно ли как-нибудь ограничить доступ к настройкам пользователю?

А можете сказать какие ограничивать, а какие нет?

[Остапченко]

1. да, запуск по ком.строке устраивает. Но только тогда уже сделайте, чтобы SLLogViewer запускался в фоновом режиме, без окна, и отработав запрошенный день сам же закрывался после экспорта. Просто нужно будет перебирать все 30 файлов для того, чтобы составить отчёт за прошедший месяц.
2. Вообще запретить нажатие кнопки "Установки". Они настраиваются Администратором и нечего в них лазить выпускающему.
PS, кстати, не понимаю, чем плохо подключение к своей программе SLLogViewer как объекта и обращение к нему, напрмер:

Set SLLog = CreateObject("SLLogViewer.Application")
ReportPlay = SLLog.Document.Playback("D:\OnAirLog\2008_07_03.sllog")
ReportLogbook = SLLog.Document.Logbook("D:\OnAirLog\2008_07_03.sllog")
ReportAll = SLLog.Document.All("D:\OnAirLog\2008_07_03.sllog")

В Report осядет нужная информация, и изменить её в исходном файле всё равно будет нельзя.

[Даниленко Сергей]

1. да, запуск по ком.строке устраивает. Но только тогда уже сделайте, чтобы SLLogViewer запускался в фоновом режиме, без окна, и отработав запрошенный день сам же закрывался после экспорта.

Естественно так и будет.

Просто нужно будет перебирать все 30 файлов для того, чтобы составить отчёт за прошедший месяц.

Можно сделать так, что вы будете указывать стартовую дату и конечную дату для лог-файла. А там уже в автоматическом режиме будет сделан перебор.
А что включается в отчет? Информация о выходе рекламных роликов? В LogViewer'е уже сделана поддержка составления отчета о проигранных видеофайлах. Поэтому хотелось бы уточнить что именно вам нужно - может достаточно будет уже сделанного.

2. Вообще запретить нажатие кнопки "Установки". Они настраиваются Администратором и нечего в них лазить выпускающему.

А не слишком ли это сурово? Может достаточно сделать систему логинов? Ваш выпускающий перед работой должен ввести свое имя и пароль. И если он трогал какие-то настройки, то это будет видно в лог-файле.

PS, кстати, не понимаю, чем плохо подключение к своей программе SLLogViewer как объекта и обращение к нему, напрмер:
Set SLLog = CreateObject("SLLogViewer.Application")
ReportPlay = SLLog.Document.Playback("D:\OnAirLog\2008_07_03.sllog")
ReportLogbook = SLLog.Document.Logbook("D:\OnAirLog\2008_07_03.sllog")
ReportAll = SLLog.Document.All("D:\OnAirLog\2008_07_03.sllog")
В Report осядет нужная информация, и изменить её в исходном файле всё равно будет нельзя.

В принципе так сделать можно - получается некоторая простая оболочка для работы с защищенным лог-файлом.

[Остапченко]

В отчёте нужно название файла, дата и время начала выхода в эфир. Собственно, из открытых логов тоже можно было бы тянуть, но информация в них легко меняется не только физически в файле через стандартный "Блокнот", но даже через просмотрщик Журнала в самом OnAir! Это уж вообще...
Кстати, не плохо бы иметь возможность скидывать лог проигрывания в MySQL, например. Там и права, и отчётность любую можно дёргать, и бэкап, и удаление старого...
Что касается запретов установок, то можно, конечно, потом лазить и смотреть кто что нажимал, можно наказывать, ругать, штрафовать, увольнять и т.д. Только всё это будет уже ПОСЛЕ того, как выпускающий накосячит. А т.к. он сидит один в другом конце города, то прийдётся сначала по телефону пытаться узнать какие он кнопки нажимал (при том сначала вообще нужно будет догадаться, что это ОН накосячил, т.к. обычно звонят с паническим крикрм "Я запускаю, а он не показывает!" и добиться вразумительного ответа ЧТО ИМЕННО ПРОИСХОДИТ бывает очень трудно), затем приехать лично и искать тот заветный грыжик, который он нажал. На всё это уйдёт минимум 3 часа. По 4 двухминутных рекламных блока в каждом. А каждая минута у нас 30 000 рублей стоит. Выпускающиму пирийдётся 2 года без зарплаты работать? Всётаки лучше не допустить, чем потом стучать кулоком по столу в очередной раз.

[fedor]

Поддерживаю наличие админских/не админских прав на изменение настроек OnAir, а заодно и FD300 Sound Control

[ACCA]

День добрый.
Авторизация выпускающих крайне интересна.
права доступа на настройки тоже вещ хорошая.
Я уже писал на эту тему.
А вот поддержка експорта из защищённых лог файлов в MySQL это вообще конфетка была бы

[Остапченко]

А вот поддержка експорта из защищённых лог файлов в MySQL это вообще конфетка была бы

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

[Даниленко Сергей]

По вопросу о чтении защищенного лог-файла.
Мы готовы сделать оболочку, которая позволит программно читать защищенный лог-файл. А дальше вы можете делать с ним все, что захотите: писать свое собственное приложение для составления эфирной стправки, делать импорт в базу данных,...
Делать импорт в базу данных из OnAir'а мы не планируем - слишком много головной боли предвидится.
По вопросу о правах доступа.
Речь шла о запрете нажимать кнопку установки. Можем предложить для обсуждения достаточно простое и значит быстрое в реализации решение.
Если запустить regedt32 (системная утилита), то над любой веткой в реестре в меню по правой кнопке мышипоявляется дополнительный пункт Permissions (см. картинку).

По этой команде появляется стандартный диалог, в котором можно выбрать какого-либо пользователя и установить запрещение (Deny) на чтение/запись данной ветки в реестре.
Естественно, это можно сделать и для пользователя, который создавался в системе как администратор.
В OnAir добавляется чтение определенной ветки из реестра. Если FDOnAir не может прочитать эту ветку при запуске, то он устанавливает переменную, которая означает "настройки менять нельзя" (кнопка Установки недоступна).
Администратору эфирного сервера останется только создать пользователя под каждого выпускающего оператора эфира и запретить ему права в реестре на нужную ветку. Естественно, этому пользователю потом еще надо запретить вызов regedt32. И/или запретить изменять права той же ветки в реестре (запретить право Control).
Реализовать такую штуку в OnAir'е можно очень быстро. Написать нам инструкцию, как этим вам пользоваться - дело 10 минут. Проделать все настройки - и того быстрее.
По нашему мнению, это проще, чем городить права доступа в самом OnAir.

[Остапченко]

Ну, хоть так...
Хотя, не понятно в чём головная боль при записи логов в базу.

[ACCA]

По вопросу о чтении защищенного лог-файла.
Мы готовы сделать оболочку, которая позволит программно читать защищенный лог-файл. А дальше вы можете делать с ним все, что захотите: писать свое собственное приложение для составления эфирной стправки, делать импорт в базу данных,...
Делать импорт в базу данных из OnAir'а мы не планируем - слишком много головной боли предвидится.

можно по подробнее?

[Даниленко Сергей]

Хотелось бы ответить чуть позже из-за того, что мы вернулись к проработке вопроса о прямой записи в базу данных.
Нужно немного времени для обсуждения и потом расскажем о предполагаемом механизме реализации.

[stealth]

Так какое все-таки решение для доступа к защищенному логу есть ? Какие ключи у LogViewer для экспорта ?

[Даниленко Сергей]

1)Можно написать свой плагин, который будет "цепляться" к нашему SLLogServer'у и получать из него информацию в текстовом виде в режиме реального времени.
У нас есть пример реализации такого плагина, который выводит текст в DBGOutput
2)Другие возможности работы описаны здесь:
http://www.softlab-nsk.com/rus/forward/qna.html#a4_11

[AntonChik]

Сергей, а все-таки как сделать экспорт в ткстовый файл из командной строки? какие ключики?
есть что-нибудь в таком духе:

SLLogViewer.exe 2012_04_26.SLLog /output=2012_04_26.txt

?
колдования с info файлом результата не дали