Сергей, конечно можно и без Sentinel EMS обойтись, но вы должны понимать, что при таком раскладе, вам придётся писать свой инструмент для генерации лицензий, а также, при необходимости, этот инструмент должен уметь сохранять историю сгенерированных лицензий, прошитые ключи, ваши конфигурации лицензий, ваших клиентов и т.д. и т.п.. Для создания такого инструмента у нас есть в составе нашего SDK LDK специальное API - License Generation API: https://docs.sentinel.gemalto.com/ldk/LDKdocs/API-licgen/
Сергей, на самом деле если нужно работать со своей CRM, то гораздо правильнее (и проще) было бы интегрировать свою CRM с нашим EMS, в SDK LDK есть для этого своё отдельное API - EMS Web Services: https://docs.sentinel.gemalto.com/ldk/LDKdocs/WebHelpWS/ При этом вы оставляете себе весь уже готовый функционал EMS, просто управляете им из своей CRM. Это идеологически более правильный путь, дающий множество преимуществ по сравнению с разработкой своего решения на базе LicGen API. Пример преимуществ: 1. Лёгкость обновлений нашего решения и получение всех нововведений без необходимости производить какие-либо доработки в своей связке CRM-LicGen; 2. Наличие готового сервера активации; 3. Наличие БД в которой хранится история прошивок всех ключей; 4. Готовый механизм для e-mail уведомлений о произведённых лицензий для клиентов; 5. Готовая система логирования в Sentinel EMS; 6. Список можно продолжать ещё долго...
но при этом EMS - это бегемот, построенный на базе нескольких технологий - каждая из которых огромная и сложная, и при сбое в любой из этих технологий ВСЯ работа сразу полностью встаёт. Если только у клиента нет специалиста по КАЖДОЙ из этих технологий
да, я пуганная ворона сильно укушенная EMS 6.4
При этом разврнуть с нуля EMS на чистой машине гораздо дольше и сложнее, чем установить на чистой машине Sentinel Runtime. Не говоря про то, что "нулёвая" установка убивает часть преимуществ типа "БД с историей" и сквозное "логирование".
Справедливости ради, в LicGen есть свои глюки, от реализации до ошибок в документации.
И особенно в последние месяцы. Вероятно, Мaster Update что-то хитрое зашил в мастер-ключ. Либо просто чёрная полоса, статистики у нас не много, конечно.
при создании v2c файла обязательно сохраняйте также Resultant State XML и СРАЗУ ЖЕ прогоняйте его через Decode License и смотрите, что у вас получилось, то что надо - или что-то не вполне совпадающее
иногда получается вовсе не то, что заказывали, причём ответ от Гемальто будет один и тот же: вы пользуетесь API не так, как это делает EMS, а потому сами виноваты
Добрый день. Пытаюсь работать с ключом SENTIEL HL через API для DotNet. C логином/логаутом и чтением/записью в ключ через класс Aladdin.HASP.Hasp разобрался. Теперь стоит вопрос как через API записать список из Feature в ключ (и, видимо, предварительно удалить все уже имеющиеся в ключе Features).
Я правильно понял, что это надо делать через класс Sentinel.Ldk.LicGen.LicGenAPIHelper? В документации по этому классу всё как то путанно (кроме интуитивно понятных stnl_lg_initialize и stnl_lg_cleanup). Может быть вы подскажете пример добавления/удаления Feature в ключе?
Вы должны понимать, что в общем виде процесс состоит из трёх шагов.
1. Клиент - где-то у чёрта на куличках - создаёт "слепок" ключа, "образ". А терминах API - это "текущее состояние", Current State. Клиент пересылает его вам. Если это файл - то дял "железных" ключей - это *.c2v Но вообще говоря - это XML-текст с шифрованным base64 внутри.
2. Получив "слепок" - вы формируете программу для перепрошивки ключа. Вот этот шаг делается в LicGen API Программа для перепрошивки ключа обычно сохраняется в *.v2c файл (как всегда - это XML текс тс шифрованным base64 внутри). Его вы пересылаете клиенту.
3. Клиент применяет эту программу на компьютере с ключом.
Если вы сами шьёте ключ - вы просто выступаете по очереди в этих двух лицах, но в любой случае, вы проходится те же самые три шага.
~~~~~~~~~~~~~
1. Для снятия слепка используется обычный Licensing API он же с недавнего времени Runtime API
В режиме Toolbox "C API" - это функция hasp_get_info либо hasp_get_sessioninfo Создание C2V возможно только локально, по сети не работает. Где находится USB-порт с ключом - на том комьпютере и запускаем.
В принципе, можно не писать свою программу, а отправить пользвоателя в браузер в Admin Control Center - http://localhost:1947/ - там есть кнопка c2v начиная с, кажется, 6.60
Но мы сделали свою утилитку - "во-первых, это красиво", а во вторых мы не можем закодировать все функции лицензии в терминах LicGen API (ограничения по времени, на hardware platform 6.x), и часть лицензии пишем в свою память, т.е. ACC просто не сможет показать всю нашу лицензию.
3. Для применения V2C программы к ключу - тоже используется Runtime API, тоже исключительно локально, функция hasp_update. Ну или снова internet explorer
В C# по умолчанию строки - UCS2 (16/32 bits на символ), насколько помню. Поэтому, если будете самописничать и будете не свой формат делать, а читать-пистаь стандартные c2v/v2c - не забываете конвертировать в/из Ansi-строку или UTF-8-строку
Самописка может и работать в обход файлов, например просто вставляя в себя V2C-текст из clipboard, или самостоятельно обмениваться с вашим самописным сервером (по e-mail например)
По последовательности вызовов LicGen API для создания V2C-программы - да, там "надо вкурить".
С "птичьего полёта" создание V2C - это функция, с 5 (3) параметрами на входе и 2 на выходе. Соответственно, надо входные параметры подготовить (хотя бы на уровне "знать как сформировать") до начала работы.
Код
( V2C-программа, XML-новый-расчётный-слепок "Resultant State") = LicGen
(
C2V-старый слепок "Current State",
физический MASTER-ключ (правильного batch-кода), парный Мастеру HVC-файл (Vendor Code),
XML с License Definition, правильный для неё License Type
)
USB порт с Мастер-ключом тоже должен быть подключён локально. Лично мы, намучавшись с "кто последний брал Мастер с батчем XXXXX? Как в отпуске???" воткнули все мастера в серверной и купили USB Redirector for Windows. В Linux такая функция должны быть встроена, если сможете сделать самописку под DotGNU/Mono.
Общая логика такая:
1. Сначала вы "заказываете" новую V2C-программу, в каком-то абстрактном смысле "создаёте новый объект-контейнер-очередь, временный файл". 2. Потом вы это очередь наполняете описаниями. 3. Потом вы по этой очереди копилируете V2C программу. 4. Потом вы контролируете результат, де-компилируя Resultant State и сравнивая с нужным. Если совпадает - V2C файл можно отправлять клиенту (даже если он - это вы сами)
1-й шаг - это sntl_lg_start, при этом старая очередь, если была, уничтожаете и создаётся новая 2-й шаг - это сначала всё та же sntl_lg_start, потом по необходимости сколько хотите дополнительных вызовов sntl_lg_apply_template 3-й шаг - sntl_lg_generate_license 4-й шаг - sntl_lg_decode_current_state
Это первоисточник документации и при любых сомнениях - сверяйтесь с ним. Именно из LDK\API\*.h копипастят в CHM и PDF и на сайт Gemalto - увы, порой с ошибками. А уже из документации, вероятно, копипастят в интерфейсные файлы на других языках, те же ошибки