Api error 200 entry not found occurred

Hi All, please see the answer from wibu support below:
«CodeMeter does indeed support IPv6. The error only means, that they don’t have this entry on any of their CmContainer.
This can happen for example when your customer tries to use a module of your application, which requires an additional license, which the customer does not own.
In a CmDust.log you could see, that the customer does not have this license entry. (101074:63:134478911)

To generate a CmDust.log file, please follow the steps below:

1. Plug in your CmDongle
2. Start CmDust via “Start -> All Programs -> CodeMeter -> Tools -> CmDust”
3. A command prompt window will be opened automatically and also will be closed automatically after a few seconds
4. Now you will find the file «CmDust-Result.log» in your user directory which opens automatically in a new explorer window. If you like, you can open this file with a usual text editor (e.g. notepad) to see contents of the collected data»
If further questions remain, let us know! Best

Hello All,

I’m getting a CodeMeter error when I try to open SBPro the text of the error is:

“CodeMeter error: Please ensure your CM stick is securely in a USB port”

Everything was fine this afternoon but this evening this error appeared.

I did some research in this forum and found some post similar but not exactly the same. It looks like there is no license information on the CM stick.

Any help would be much appreciated since I can’t run SBPro.

Eric

Here’s some info from CodeMeter that might help diagnose this problem:

Events from CodeMeter Control Center:

2012-09-05 01:05:20: Logging activated.

2012-09-05 01:05:20: CodeMeter for Windows (B4.40.698.501.32.150)

2012-09-05 01:05:20: Running on Microsoft Windows 7 Business Edition, 64-bit Service Pack 1 (build 7601)

2012-09-05 01:05:20: Execution path: C:Program Files (x86)CodeMeterRuntimebin

2012-09-05 01:05:20: Found IPv4 address: 127.0.0.1 | 192.168.0.135

2012-09-05 01:05:20: Found IPv6 address: ::1 | fe80::4d34:3a62:ca8e:ef3%10

2012-09-05 01:05:20: Used Communication Mode: IPv6 IPv4 SharedMemory

2012-09-05 01:05:20: Used IP address: default address

2012-09-05 01:05:20: Used IP port: 22350

2012-09-05 01:05:20: Multicast server search: not available

2012-09-05 01:05:20: Run as network server: no

2012-09-05 01:05:20: Run as system service: yes

2012-09-05 01:05:20: Box Access: use direct access mode

2012-09-05 01:05:24: Detecting CmContainer with Serial Number 2-1638848

2012-09-05 01:05:24: Box Event HW59-507 (1638848) occurred.

2012-09-05 01:05:24: API Event HW0059 (RC) occurred.

2012-09-05 01:05:24: API Event WB0059 (MEMORY DAMAGED) occurred (returned to caller)

2012-09-05 01:05:24: Removable Device state has been changed!

2012-09-05 01:05:24: Removable Device state has been changed!

2012-09-05 01:05:42: Access from ::1 to SubSystem (Handle 16)

2012-09-05 01:05:42: Using security library version (US) 4.40.698.500

2012-09-05 01:05:42: Handle 16 released

2012-09-05 01:07:26: Executing Broadcast for CodeMeter License Servers

2012-09-05 01:07:27: Entry (100146:11081) not found — Event WB0200 (ENTRY NOT FOUND), Request IP-Address ::1

2012-09-05 01:07:27: API Error 200 (ENTRY NOT FOUND) occurred!

From the ‘Content’ page of ‘CodeMeter WebAdmin’:

“ERROR 201 The specified CmContainer () cannot be found.”

(Windows does recognize the CodeMeter.)

From the “Home” page of ‘CodeMeter WebAdmin’:

Host Name: My pc’s name

IP Address: 192.168.0.135

Operating System: Microsoft Windows 7 Business Edition, 64-bit Service Pack 1 (build 7601)

Server Startup: Sep/05/2012 01:05:20

Runtime Version: 4.40b

Server Version: Version 4.40a of Mar/15/2012 (Build 698)

WebAdmin Version: Version 4.40 of Mar/15/2012

From the ‘Server’ page of ‘CodeMeter WebAdmin’:

The name of my PC is shown and then there is no information other than the date of the last update (which is the time I rebooted)

From the ‘Configuration’ page of ‘CodeMeter WebAdmin’:

Bind AddressAll (Default)

Network Port: 22350

UDP Waiting Time: 1000ms

Server Search List: is empty

From the “Diagnosis” page:

2012-09-05 01:05:20: Logging activated.

2012-09-05 01:05:20: CodeMeter for Windows (B4.40.698.501.32.150)

2012-09-05 01:05:20: Running on Microsoft Windows 7 Business Edition, 64-bit Service Pack 1 (build 7601)

2012-09-05 01:05:20: Execution path: C:Program Files (x86)CodeMeterRuntimebin

2012-09-05 01:05:20: Found IPv4 address: 127.0.0.1 | 192.168.0.135

2012-09-05 01:05:20: Found IPv6 address: ::1 | fe80::4d34:3a62:ca8e:ef3%10

2012-09-05 01:05:20: Used Communication Mode: IPv6 IPv4 SharedMemory

2012-09-05 01:05:20: Used IP address: default address

2012-09-05 01:05:20: Used IP port: 22350

2012-09-05 01:05:20: Multicast server search: not available

2012-09-05 01:05:20: Run as network server: no

2012-09-05 01:05:20: Run as system service: yes

2012-09-05 01:05:20: Box Access: use direct access mode

2012-09-05 01:05:24: Detecting CmContainer with Serial Number 2-1638848

2012-09-05 01:05:24: Box Event HW59-507 (1638848) occurred.

2012-09-05 01:05:24: API Event HW0059 (RC) occurred.

2012-09-05 01:05:24: API Event WB0059 (MEMORY DAMAGED) occurred (returned to caller)

2012-09-05 01:05:24: Removable Device state has been changed!

2012-09-05 01:05:24: Removable Device state has been changed!

2012-09-05 01:05:42: Access from ::1 to SubSystem (Handle 16)

2012-09-05 01:05:42: Using security library version (US) 4.40.698.500

2012-09-05 01:05:42: Handle 16 released

2012-09-05 01:07:26: Executing Broadcast for CodeMeter License Servers

2012-09-05 01:07:27: Entry (100146:11081) not found — Event WB0200 (ENTRY NOT FOUND), Request IP-Address ::1

2012-09-05 01:07:27: API Error 200 (ENTRY NOT FOUND) occurred!

Время прочтения
6 мин

Просмотры 13K

Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры «дергают» бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.

За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.

№1: HTTP статусы

Если почитать апологетов REST, то для кодов ошибок надо использовать HTTP статусы, а текст ошибки отдавать в теле или в специальном заголовке. Например:

Success:

HTTP 200 GET /v1/user/1
Body: { name: 'Вася' }

Error:

HTTP 404 GET /v1/user/1
Body: 'Не найден пользователь'

Если у вас примитивная бизнес-логика или API из 5 url, то в принципе это нормальный подход. Однако как-только бизнес-логика станет сложнее, то начнется ряд проблем.

Http статусы предназначались для описания ошибок при передаче данных, а про логику вашего приложения никто не думал. Статусов явно не хватает для описания всего разнообразия ошибок в вашем проекте, да они и не были для этого предназначены. И тут начинается натягивание «совы на глобус»: все начинают спорить, какой статус ошибки дать в том или ином случае. Пример: Есть API для task manager. Какой статус надо вернуть в случае, если пользователь хочет взять задачу, а ее уже взял в работу другой пользователь? Ссылка на http статусы. И таких проблемных примеров можно придумать много.

REST скорее концепция, чем формат общения из чего следует неоднозначность использования статусов. Разработчики используют статусы как им заблагорассудится. Например, некоторые API при отсутствии сущности возвращают 404 и текст ошибки, а некоторые 200 и пустое тело.

Бэкенд разработчику в проекте непросто выбрать статус для ошибки, а клиентскому разработчику неочевидно какой статус предназначен для того или иного типа ошибок бизнес-логики. По-хорошему в проекте придется держать enum для того, чтобы описать какие ошибки относятся к тому или иному статусу.

Когда бизнес-логика приложения усложняется, начинают делать как-то так:

HTTP 400 PUT /v1/task/1 { status: 'doing' }
Body: { error_code: '12', error_message: 'Задача уже взята другим исполнителем' } 

Из-за ограниченности http статусов разработчики начинают вводить “свои” коды ошибок для каждого статуса и передавать их в теле ответа. Другими словами, пользователю API приходится писать нечто подобное:

if (status === 200) {
  // Success
} else if (status === 500) {
  // some code
} else if (status === 400) {
  if (body.error_code === 1) {
    // some code
  } else if (body.error_code === 2) {
    // some code
  } else {
    // some code
  }
} else if (status === 404) {
  // some code
} else {
  // some code
}

Из-за этого ветвление клиентского кода начинает стремительно расти: множество http статусов и множество кодов в самом сообщении. Для каждого ошибочного http статуса необходимо проверить наличие кодов ошибок в теле сообщения. От комбинаторного взрыва начинает конкретно пухнуть башка! А значит обработку ошибок скорее всего сведут к сообщению типа “Произошла ошибка” или к молчаливому некорректному поведению.

Многие системы мониторинга сервисов привязываются к http статусам, но это не помогает в мониторинге, если статусы используются для описания ошибок бизнес логики. Например, у нас резкий всплеск ошибок 429 на графике.  Это началась DDOS атака, или кто-то из разработчиков выбрал неудачный статус?

Итог:  Начать с таким подходом легко и просто и для простого API это вполне подойдет. Но если логика стала сложнее, то использование статусов для описания того, что не укладывается в заданные рамки протокола http приводит к неоднозначности использования и последующим костылям для работы с ошибками. Или что еще хуже к формализму, что ведет к неприятному пользовательскому опыту.

№2: На все 200

Есть другой подход, даже более старый, чем REST, а именно: на все ошибки связанные с бизнес-логикой возвращать 200, а уже в теле ответа есть информация об ошибке. Например:

Вариант 1:

Success:
HTTP 200 GET /v1/user/1
Body: { ok: true, data: { name: 'Вася' } }

Error:
HTTP 200 GET /v1/user/1
Body: { ok: false, error: { code: 1, msg: 'Не найден пользователь' } }

Вариант 2:

Success:
HTTP 200 GET /v1/user/1
Body: { data: { name: 'Вася' }, error: null }

Error:
HTTP 200 GET /v1/user/1
Body: { data: null, error: { code: 1, msg: 'Не найден пользователь' } }

На самом деле формат зависит от вас или от выбранной библиотеки для реализации коммуникации, например JSON-API.

Звучит здорово, мы теперь отвязались от http статусов и можем спокойно ввести свои коды ошибок. У нас больше нет проблемы “впихнуть невпихуемое”. Выбор нового типа ошибки не вызывает споров, а сводится просто к введению нового числового номера (например, последовательно) или строковой константы. Например:

module.exports = {
  NOT_FOUND: 1,
  VALIDATION: 2,
 // ….
}

module.exports = {
  NOT_FOUND: ‘NOT_AUTHORIZED’,
  VALIDATION: ‘VALIDATION’,
 // ….
}

Клиентские разработчики просто основываясь на кодах ошибок могут создать классы/типы ошибок и притом не бояться, что сервер вернет один и тот же код для разных типов ошибок (из-за бедности http статусов).

Обработка ошибок становится менее ветвящейся, множество http статусов превратились в два: 200 и все остальные (ошибки транспорта).

if (status === 200) {
  if (body.error) {
    var error = body.error;
    if (error.code === 1) {
      // some code
    } else if (error.code === 2) {
      // some code
    } else {
      // some code
    }
  } else {
    // Success
  }
} else {
  // transport erros
}

В некоторых случаях, если есть библиотека десериализации данных, она может взять часть работы на себя. Писать SDK вокруг такого подхода проще нежели вокруг той или иной имплементации REST, ведь реализация зависит от того, как это видел автор. Кроме того, теперь никто не вызовет случайное срабатывание alert в мониторинге из-за того, что выбрал неудачный код ошибки.

Но неудобства тоже есть:

• Избыточность полей при передаче данных, т.е. нужно всегда передавать 2 поля: для данных и для ошибки. Это усложняет чтение логов и написание документации.

• При использовании средств отладки (Chrome DevTools) или других подобных инструментов вы не сможете быстро найти ошибочные запросы бизнес логики, придется обязательно заглянуть в тело ответа (ведь всегда 200)

• Мониторинг теперь точно будет срабатывать только на ошибки транспорта, а не бизнес-логики, но для мониторинга логики надо будет дописывать парсинг тела сообщения.

В некоторых случаях данный подход вырождается в RPC, то есть по сути вообще отказываются от использования url и шлют все на один url методом POST, а в теле сообщения передают все параметры. Мне кажется это не правильным, ведь url это прекрасный именованный namespace, зачем от этого отказываться, не понятно?! Кроме того, RPC создает проблемы:

• нельзя кэшировать по http GET запросы, так как замешали чтение и запись в один метод POST

• нельзя делать повторы для неудавшихся GET запросов (на backend) на реверс-прокси (например, nginx) по указанной выше причине

• имеются проблемы с документированием – swagger и  ApiDoc не подходят, а удобных аналогов я не нашел

Итог: Для сложной бизнес-логики с большим количеством типов ошибок такой подход лучше, чем расплывчатый REST, не зря в проектах c “разухабистой” бизнес-логикой  часто именно такой подход и используют.

№3: Смешанный

Возьмем лучшее от двух миров. Мы выберем один http статус, например, 400 или 422 для всех ошибок бизнес-логики, а в теле ответа будем указывать код ошибки или строковую константу. Например:

Success:

HTTP 200 /v1/user/1
Body: { name: 'Вася' }

Error:

HTTP 400 /v1/user/1
Body: { error: { code: 1, msg: 'Не найден пользователь' } }

Коды:

• 200 – успех

• 400 – ошибка бизнес логики

• остальное ошибки в транспорте

Тело ответа для удачного запроса у нас имеет произвольную структуру, а вот для ошибки есть четкая  схема. Мы избавляемся от избыточности данных (поле ошибки/данных) благодаря использованию http статуса в сравнении со вторым вариантом. Клиентский код упрощается в плане обработки ошибки (в сравнении с первым вариантом). Также мы снижаем его вложенность за счет использования отдельного http статуса для ошибок бизнес логики (в сравнении со вторым вариантом).

if (status === 200) {
  // Success
} else if (status === 400) {
  if (body.error.code === 1) {
    // some code
  } else if (body.error.code === 2) {
    // some code
  } else {
    // some code
  }
} else {
  // transport erros
}

Мы можем расширять объект ошибки для детализации проблемы, если хотим. С мониторингом все как во втором варианте, дописывать парсинг придется, но и риска “стрельбы” некорректными alert нету. Для документирования можем спокойно использовать Swagger и ApiDoc. При этом сохраняется удобство использования инструментов разработчика, таких как Chrome DevTools, Postman, Talend API.

Итог:  Использую данный подход уже в нескольких проектах, где множество типов ошибок и все крайне довольны, как клиентские разработчики, так и бэкендеры. Внедрение новой ошибки не вызывает споров, проблем и противоречий. Данный подход объединяет преимущества первого и второго варианта, при этом код более читабельный и структурированный.

Самое главное какой бы формат ошибок вы бы не выбрали лучше обговорить его заранее и следовать ему. Если эту вещь пустить на “самотек”, то очень скоро обработка ошибок в проекте станет невыносимо сложной для всех.

P.S. Иногда ошибки любят передавать массивом

{ error: [{ code: 1, msg: 'Не найден пользователь' }] }

Но это актуально в основном в двух случаях:

• Когда наш API выступает в роли сервиса без фронтенда (нет сайта/приложения). Например, сервис платежей.

• Когда в API есть url для загрузки какого-нибудь длинного отчета в котором может быть ошибка в каждой строке/колонке. И тогда для пользователя удобнее, чтобы ошибки в приложении сразу показывались все, а не по одной.

В противном случае нет особого смысла закладываться сразу на массив ошибок, потому что базовая валидация данных должна происходить на клиенте, зато код упрощается как на сервере, так и на клиенте. А user-experience хакеров, лезущих напрямую  в наше API,  не должен нас волновать?HTTP