Общая информация

Механизм работы модуля

В общих чертах жизненный цикл модуля регистратора в BILLmanager выглядит следующим образом:

1. Установка модуля
2. Добавление подключения к регистратору
3. Настройка тарифного плана
4. Заказ и оплата услуги
5. Обработка открытия услуги
6. Включение/выключение/удаление услуги, а так же выполнение дополнительных операций

Установка модуля выполняется либо вручную, если он представлен набором файлов, либо из стандартного репозитория при помощи пакетного менеджера. После установки модуль становится доступен для выбора при добавлении подключения к регистратору в BILLmanager.

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

Структура модуля

Модуль регистратора состоит из двух файлов:

• etc/xml/billmgr_mod_pmXXX.xml — XML-описание модуля. Формат наименования файла строго регламентирован
• processing/pmXXX — основной скрипт модуля. Формат наименования файла строго регламентирован

Где pmXXX название вашего модуля, указываемое латиницей. Кроме того, для модулей обработки (processing modules) необходимо указание pm перед именем файла. Если название основного скрипта модуля содержит расширение файла, оно так же включается в имя модуля. Например, если ваш скрипт называется pmregistrar.php, то именем модуля будет являться pmregistrar.php, а не pmregistrar.

Описание XML

Наименование файла должно иметь вид billmgr_mod_pmXXX.xml, где pmXXX — имя модуля. Файл копируется в каталог etc/xml относительно пути установки BILLmanager. Файл содержит описание самого модуля (описывается как плагин), а также описание дополнительных форм и сообщений.

Примерный вид XML-файла модуля:

<?xml version="1.0" encoding="UTF-8"?>
<mgrdata>
  <plugin name="pmXXX">
    <group>processing_module</group>
    <params>
      <type name="domain"/>
    </params>
    <msg name="desc_short" lang="ru">XXX модуль</msg>
    <msg name="desc_short" lang="en">XXX module</msg>
    <msg name="desc_full" lang="ru">XXX модуль</msg>
    <msg name="desc_full" lang="en">XXX module</msg>
  </plugin>

<metadata name="processing.edit.pmXXX" type="form">
    <form>
      <page name="connect">
        <field name="prop1">
          <input name="prop1" required="yes" type="text" />
        </field>
        <field name="prop2">
          <input name="prop2" required="yes" type="text" />
        </field>
      </page>
    </form>
  </metadata>

<lang name="en">
    <messages name="label_processing_modules">
      <msg name="pmXXX">XXX module</msg>
      <msg name="module_pmXXX">XXX module</msg>
    </messages>

<messages name="processing.edit.pmXXX">
      <msg name="prop1">Prop 1</msg>
      <msg name="hint_prop1">Hint for prop 1</msg>
      <msg name="prop2">Prop 2</msg>
      <msg name="hint_prop2">Hint for prop 2</msg>
    </messages>
  </lang>

<lang name="ru">
     <messages name="label_processing_modules">
      <msg name="pmXXX">XXX модуль</msg>
      <msg name="module_pmXXX">XXX модуль</msg>
    </messages>

<messages name="processing.edit.pmXXX">
      <msg name="prop1">Свойство 1</msg>
      <msg name="hint_prop1">Подсказка для свойства 1</msg>
      <msg name="prop2">Свойствоop 2</msg>
      <msg name="hint_prop2">Подсказка для свойства 2</msg>
    </messages>
  </lang>
</mgrdata>

Здесь секция <plugin> отвечает за описание самого модуля. Свойство name совпадает с именем модуля регистратора. Внутри секции может быть:

• один элемент group со значением processing_module, который указывает на то, что данный модуль используется для обработчиков услуг,
• несколько элементов msg
• и секция params с поднодой <type name="domain"/>, указывающей на то, что обработчик относится к регистраторам, т.е. умеет обрабатывать услуги с типом, имеющем внутреннее имя domain.

Свойство lang у элемента msg указывает, к какому языку относится сообщение, атрибут name может иметь следующие значения:

• desc_short — краткое описание модуля. Отображается при выборе модуля в BILLmanager
• desc_full — полное описание модуля. Отображается при построении списка установленных модулей в COREmanager

Секция metadata с именем processing.edit.pmXXX отвечает за дополнительные поля модуля при добавлении и настройке обработчика. Формируется согласно стандартному описанию [ XML|/index.php/%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_%D1%84%D0%BE%D1%80%D0%BC] формы, с учетом необходимости расположения полей в секции <page name="connect"></page> для корректного размещения полей на формах в BILLmanager.

Секция lang содержит переводы наименований полей на форме согласно стандартной схеме описания переводов. Раздел <messages name="label_processing_modules"> отвечает за подпись наименования модуля в списке обработчиков.

Основной скрипт модуля

Основной скрипт модуля отвечает за передачу BILLmanager информации о поддерживаемых модулем функциях, а так же обработку этих функций. При работе с модулем BILLmanager исполняет файл скрипта со следующими параметрами:

processing/pmxxx --command command [--item item] [--module module] [--itemtype itemtype] [--param param --value value] 
[--runningoperation runningoperation] [--tld tld] [--searchstring searchstring]

Где

• command — управляющая команда. Указывает на действие, которое необходимо выполнить модулю
• item — код услуги, для которой выполняется действие
• module — код обработчика, для которого выполняется действие
• itemtype — внутреннее наименование типа продукта, для которого выполняется действие
• param — наименование параметра
• value — значение параметра
• runningoperation — код текущей операции для выполняемого действия. Требуется для изменения параметров текущей операции, а так же для создания задач
• tld — наименование зоны, для которой выполняется действие
• searchstring — строка поиска, используемая при импорте

Параметр runningoperation передается, если модуль запущен BILLmanager после создания текущей операции. В этом случае, по завершению работы модуля нужно либо выполнить одну из функций BILLmanager (описаны далее в статье), которая удалит текущую операцию из очереди, либо выполнить одно или несколько из следующих действия:

• сохранить текст ошибки в свойствах текущей операции с помощью функции runningoperation.edit
• выставить текущей операции ручной запуск, для предотвращения автоматического перезапуска данной операции с помощью функции runningoperation.setmanual
• создать задачу на ответственный отдел с помощью функции task.edit

Параметр command может принимать одно из следующих значений:

• features — запрос списка поддерживаемых возможностей. В ответ на вызов данной команды модуль должен вернуть XML-документ следующего вида:

  <?xml version="1.0" encoding="UTF-8"?>
  <doc>
    <itemtypes>
      <itemtype name="domain" />                   <!-- поддерживаемый тип продукта. Для модуля регистратора как минимум domain, но могут содержаться и дополнительные типы -->
    </itemtypes>
    <params>                                       <!-- список параметров модуля -->
      <param name="param" />                       <!-- параметр подключения к регистратору. Требуется указание в списке поддерживаемых возможностей для корректного сохранения и обработки панелью -->
      <param name="crypted_param" crypted="yes" /> <!-- зашифрованный параметр подключения к регистратору. Признаком необходимости шифрования является crypted="yes" -->
    </params>
    <features>
      <feature name="check_connection" />          <!-- поддержка модулем функции проверки введенных параметров при добавлении обработчика услуг -->
      <feature name="tune_connection" />           <!-- поддержка модулем изменения формы добавления обработчика услуг -->
      <feature name="import" />                    <!-- поддержка импорта услуг от регистратора. Подробнее механизм импорта описан далее в документации -->
      <feature name="open" />                      <!-- поддержка обработки открытия услуг, в случае с регистратором — регистрации доменов -->
      <feature name="suspend" />                   <!-- поддержка обработки выключения услуг -->
      <feature name="resume" />                    <!-- поддержка обработки включения услуг -->
      <feature name="close" />                     <!-- поддержка обработки удаления услуг -->
      <feature name="setparam" />                  <!-- поддержка изменения параметров и дополнений к услугам -->
      <feature name="prolong" />                   <!-- поддержка продления услуг на стороне регистратора -->
      <feature name="transfer" />                  <!-- поддержка переноса услуг -->
      <feature name="sync_item" />                 <!-- поддержка получения информации о домене от регистратора -->
      <feature name="tune_service" />              <!-- поддержка изменения формы редактирования услуги -->
      <feature name="get_contact_type" />          <!-- поддержка получения списка необходимых для регистрации домена в определенной зоне типов контактов -->
      <feature name="tune_service_profile" />      <!-- поддержка изменения формы контакта доменов -->
      <feature name="validate_service_profile" />  <!-- поддержка проверки свойств контактов доменов -->
      <feature name="update_ns" />                 <!-- поддержка изменения списка серверов имен -->
      <feature name="whois" />                     <!-- поддержка реализации команды whois модулем регистратора -->
      <feature name="uploaddocs" />                <!-- поддержка загрузки документов -->
      <feature name="contactverify" />             <!-- поддержка верификации контактов домена (нельзя использовать совместно с "domainverify") -->
      <feature name="domainverify" />              <!-- поддержка верификации домена (нельзя использовать совместно с "contactverify") -->
      <feature name="uploadext" />                 <!-- поддержка возврата списка поддерживаемых форматов файлов для загрузки документов доменов -->
    </features>
  </doc>
  

Ваш модуль может не поддерживать некоторые из описанных функций. В этом случае не сообщайте о поддержке отсутствующих функций при обработке команды features, в противном случае могут возникать ошибки обработки услуг

• check_connection — на вход модулю подается XML с параметрами подключения к регистратору. Формат входного документа выглядит следующим образом:

  <?xml version="1.0" encoding="UTF-8"?>
  <doc>
    <param>value</param>
    ...
    <param>value</param>
  </doc>
  

Не зависимо от требований модуля, параметры представлены в незашифрованном виде.

Используя данные параметры, модуль должен проверить возможность использования их для подключения к регистратору, и в случае ошибки вернуть ее XML-описание. В случае успеха необходимо вернуть XML-документ вида

<?xml version="1.0" encoding="UTF-8"?>
<doc/>

• tune_connection — на вход обработчику передается XML-документ текущего описания формы подключения к регистратору, на выход нужно передать XML-документ с необходимыми изменениями
• import — обработка импорта услуг. Помимо параметра command, обработчику в этом случае передаются параметры:
  • module — код обработчика услуг
  • itemtype — внутреннее имя типа услуг
  • searchstring — строка поиска услуг

Подробное описание импорта услуг приведено далее в статье

• open — команда открытия услуги. Модулю так же передаются параметры item и runningoperation (при запуске задания BILLmanager). По завершению обработки открытия услуг необходимо вызвать функцию domain.open для завершения обработки услуги и удаления задания из текущих операций.
• suspend — команда выключения услуги. Модулю так же передаются параметры item и runningoperation (при запуске задания BILLmanager). По завершению выключения услуги необходимо вызвать функцию service.postsuspend для перевода услуги в статус Остановлена и удаления задания из текущих операций.
• resume — команда включения услуги. Модулю так же передаются параметры item и runningoperation (при запуске задания BILLmanager). По завершению включения услуги необходимо вызвать функцию service.postresume для перевода услуги в статус Активна и удаления задания из текущих операций.
• close — команда удаления услуги. Модулю так же передаются параметры item и runningoperation (при запуске задания BILLmanager). По завершению удаления услуги необходимо вызвать функцию service.postclose для перевода услуги в статус Удалена и удаления задания из текущих операций.
• setparam — команда изменения параметров или тарифа услуги. Модулю так же передаются параметры item и runningoperation (при запуске задания BILLmanager). По завершению изменения параметров услуги необходимо вызвать функцию service.postsetparam для сохранения нового тарифного плана, обновления стоимости услуги для отображения в списке и удаления задания из текущих операций.
• prolong — команда продления срока действия услуги. Модулю так же передаются параметры item и runningoperation (при запуске задания BILLmanager). По завершению продления услуги необходимо вызвать функцию service.postprolong для удаления задания из текущих операций.
• transfer — обрабатывается аналогично open, за исключением специфики операции.
• sync_item — команда получения информации об услуге от регистратора. Модулю так же передается параметр item. Сохранение параметров выполняется с помощью функций, описанных ниже
• tune_service — команда изменения формы редактирования домена. Модулю так же передается параметр param, содержащий наименование доменной зоны. На вход модуль получает текущее XML-описание формы редактирования домена, на выход необходимо вернуть измененную форму

• get_contact_type — команда получения списка необходимых типов контактов для регистрации домена в определенной зоне, а так же дополнительной информации о поддержке данной зоны регистратором. Модулю так же передается параметр tld содержащий наименование доменной зоны. На выход модуль должен вернуть XML-документ следующего вида:

  <?xml version="1.0" encoding="UTF-8"?>
  <doc ns="require" auth_code="require">
    <contact_type>customer</contact_type>
    <contact_type>owner</contact_type>
    <contact_type>admin</contact_type>
    <contact_type>bill</contact_type>
    <contact_type>tech</contact_type>
  </doc>
  

Набор нод contact_type может быть полным, или содержать только одно или несколько значений. Все зависит от требований конкретного регистратора к регистрации доменов в конкретной зоне. Типы customer, owner, admin, bill и tech являются встроенными. При желании можно вернуть свое наименование типа, но в этом случае к XML-описанию плагина нужно будет добавить секцию описания сообщений для label_service_profile:

<messages name="label_service_profile">
  <msg name="contact_type_name">Имя типа контакта</msg>
</messages>

где contact_type_name — имя вашего типа.

Атрибут ns="require" означает, что для переданной доменной зоны регистратор требует указание серверов имен. Атрибут может отсутствовать. Атрибут auth_code="require" означает, что для переданной доменной зоны регистратор требует при трансфере указание пароля домена. Атрибут может отсутствовать. Атрибут *cancel_prolong_before="xxx"*срок в днях, за который до окончание срока действия домена необходимо вызвать функцию отмены автоматического продления. Атрибут может отсутствовать.

• tune_service_profile — команда изменения формы параметров контакта доменов. Модулю так же передаются параметры param, содержащий наименование доменной зоны, и value, содержащий наименование типа контакта. На вход модулю передается XML-форма контакта доменов, на выход модуль должен вернуть измененный XML.
• validate_service_profile — команда проверки указанных в свойствах контакта данных. Модулю так же передается параметр param, содержащий наименование доменной зоны. На вход модулю подается XML-документ, содержащий все параметры текущей сессии пользователя. На выход модуль должен либо вернуть XML-описание ошибки проверки данных, либо пустой XML-документ.
• update_ns — команда изменения списка серверов имен домена. Модулю так же передаются параметры module, содержащий код обработчика, и item, содержащий код услуги.
• cancel_prolong — команда отмены автоматического продления домена на стороне регистратора. Модулю так же передается параметр item, содержащий код услуги.
• whois — получение данных whois из модуля обработчика.

Ответ обработчика должен состоять из XML с нодой whois, содержащей whois информацию по домену. Пример:

<doc>
   <whois>NOT FOUND </whois>
</doc>

• contactverify, domainverify — команды верификации. В случае contactverify верифицируются все услуги, принадлежащие контакту домена (контакт домена создается на стороне регистратора и имеет внешний ID), а domainverify верифцирует только домен (обычно у таких регистраторов данные о контакте домена передаются вместе с данными о самом домене, и контакт не имеет внешнего ID). На вход подается XML, содержащая внешний идентификатор контакта домена (если имеется), и все параметры услуги. На выход модуль в случае ошибки должен вернуть пустую XML, либо XML в формате:

  <doc>
    <response>
      <file id="идентификатор файла из BILLmanager">ok</file> <!-- ok — в случае успешной отправки файла, err — в случае ошибки -->
      ...
    </response>
  </doc>
  

• uploadext — вызов данной команды возвращает список поддерживаемых обработчиком форматов файлов в формате:

  <doc>
    <ext>jpg</ext>
    <ext>png</ext>
    ...
  </doc>
  

• checkdomaindoc — данная команда проверяет статус верификации доменов/контактов доменов, ответ на неё должен быть возвращен в следующем формате:

   <doc>
     <response>
       <item id="идентификатор услуги из BILLmananger">ok</item> <!-- ok — в случае успешной проверки, err — в случае ошибки -->
       ...
     </response>
   </doc>
  

Пример реализации скрипта можно найти в конце статьи

Структура связанных таблиц

• таблица item — содержит основную информацию об услугах,
  • поле id — код услуги,
  • поле processingmodule — код обработчика
• таблица processingmodule — содержит основную информацию об обработчике услуг,
  • поле id — код обработчика
• таблица processingparam — содержит параметры модуля обработчика,
  • поле processingmodule — код обработчика,
  • поле intname — имя параметра,
  • поле value — значение
• таблица processingcryptedparam — содержит зашифрованные параметры модуля обработчика,
  • поле processingmodule — код обработчика,
  • поле intname — имя параметра,
  • поле value — зашифрованное значение
• таблица service_profile — содержит основную информацию о контактах доменов,
  • поле id — код контакта домена
• таблица service_profileparam — содержит параметры контактов доменов,
  • поле service_profile — код контакта домена,
  • поле intname — имя параметра,
  • поле value — значение параметра
• таблица service_profile2item — содержит привязки доменов к контактам,
  • поле item — код услуги,
  • поле service_profile — код контакта домена,
  • поле type — тип контакта
• таблица service_profile2processingmodule — содержит привязки контактов к обработчикам,
  • поле service_profile — код контакта домена,
  • поле processingmodule — код обработчика,
  • поле type — тип контакта,
  • поле externalid — код контакта на стороне регистратора,
  • поле externalpassword — пароль контакта на стороне регистратора

Импорт услуг

Импорт услуг в BILLmanager осуществляется в два этапа:

• получение от регистратора списка услуг по переданному условию
• назначение услуг клиентам

Для получения списка услуг в модуль передается управляющая команда import, при исполнении которой модуль должен:

• средствами API получить от регистратора список подходящих под условие доменов
• по доменам получить информацию о контактах и сгруппировать их по id у регистратора
• зарегистрировать в BILLmanager контакты функцией processing.import.profile (для разных типов контактов можно использовать один созданный контакт, но зарегистрировав его привязку к обработчику функцией service_profile2processingmodule.edit)
• зарегистрировать в BILLmanager домены функцией processing.import.service
• привязать контакты к доменам функцией service_profile2item.edit

Работа с текущими операциями

Перед передачей большинства запросов модули BILLmanager создает операцию, которая будет перезапущена, в случае, если предыдущая попытка закончилась неудачей, и если включен автоматический перезапуск. Код операции передается в модуль параметром runningoperation, и может отсутствовать.

Если модулем получен код текущей операции, то в случае ошибки обработки команды можно сохранить информацию о ней в параметрах текущей операции для отображения в BILLmanager с помощью функции runningoperation.edit, а так же перевести ее запуск в ручной режим с помощью функции runningoperation.setmanual.

В случае, если вы так же хотите создать задачу на основе текущей операции, для ее решения администратором BILLmanager вам необходимо:

1. Получить тип задачи с помощью функции task.gettype, передав в нее параметром operation полученную модулем команду
2. Зарегистрировать задачу с помощью функции task.edit

После этого задача появится в списке у сотрудников, входящих в отдел, выбранный в качестве ответственного в настройках обработчика.

Дополнительные поля доменов и контактов

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

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

• service_profile.tld — влияет на контакты при использовании любого модуля регистрации
• service_profile.type — влияет на контакты при использовании любого модуля регистрации
• service_profile.type.tld — влияет на контакты при использовании любого модуля регистрации
• service_profile.xxx
• service_profile.xxx.tld
• service_profile.xxx.type
• service_profile.xxx.type.tld

где

• xxx — имя модуля
• tld — имя доменной зоны
• type — имя типа контакта

К примеру, для добавления поля возраст (age), для владельца домена (owner) при регистрации в зоне .teen (абстрактный пример), нужно добавить к имеющемуся описанию плагина следующие XML

<?xml version="1.0" encoding="UTF-8"?>
<mgrdata>
  <metadata name="service_profile.xxx.owner.teen" type="form">
    <form title="name">
      <field name="age">
        <input name="age" required="yes" type="text" check="int" checkargs="1,"/>
      </field>
    </form>
  </metadata>
  <lang name="en">
    <messages name="service_profile.xxx.owner.teen">
      <msg name="age">Age</msg>
      <msg name="hint_age">Age of owner</msg>
    </messages>
  </lang>
  <lang name="ru">
    <messages name="service_profile.xxx.owner.teen">
      <msg name="age">Возраст</msg>
      <msg name="hint_age">Возраст владельца</msg>
    </messages>
  </lang>
</mgrdata>

Для тех же целей и также для заполнения списков выбора можно использовать обработку tune_service_profile

Функции BILLmanager

• paramlist — не требует параметров. Отдает список параметров конфигурации панели
• processing.import.profile — сохранить в BILLmanager импортированный контакт домена. Параметры:
  • module — код обработчика
  • type — тип контакта
  • sok=ok — признак сохранения параметров
  • externalid — код контакта на стороне регистратора
  • список стандартных параметров контактов доменов
  • любые дополнительные параметры, которые нужно сохранить в свойства контакта домена

Возвращает profile_id — код созданного контакта

• processing.import.service — сохранить в BILLmanager импортированный домен. Параметры:
  • module — код обработчика
  • import_pricelist_intname — код зоны домена из BILLmanager
  • import_service_name — имя домена
  • status — статус услуги
  • expiredate — срок действия домена
  • domain — полное имя домена
  • service_status — дополнительный статус услуги. Возможные значения указаны ниже в документации
  • period — период заказа в месяцах
  • sok=ok — признак сохранения параметров
  • любые дополнительные параметры, которые нужно сохранить в свойства домена

Возвращает service_id — код созданного домена

• service_profile2item.edit — привязать контакты к доменному имени по типу
  • service_profile — код контакта в BILLmanager
  • item — код домена в BILLmanager
  • type — тип контакта (рекомендуется использовать стандартные типы customer, owner, admin, tech, bill)
• runningoperation.delete — удаление текущей операции
  • elid — код текущей операции
• runningoperation.edit — изменение параметров текущей операции
  • elid — код текущей операции
  • sok=ok — признак сохранения параметров
  • errorxml — XML произошедшей ошибки
• runningoperation.setmanual — перевести текущую операцию в режим ручного запуска
  • elid — код текущей операции
• service.postclose — операция завершения удаления услуги. Меняет статус услуги и удаляет операцию на удаление
  • elid — код услуги
  • sok=ok — признак сохранения параметров
• service.postopen — операция завершения открытия услуги. Только удаляет операцию на открытие услуги
  • elid — код услуги
  • sok=ok — признак сохранения параметров
• service.postprolong — операция завершения продления услуги. Только удаляет операцию на продление услуги
  • elid — код услуги
  • sok=ok — признак сохранения параметров
• service.postresume — операция завершения включения услуги. Меняет статус услуги и удаляет операцию на включение
  • elid — код услуги
  • sok=ok — признак сохранения параметров
• service.postsetparam — операция завершения изменения параметров услуги. Сбрасывает ссылку на предыдущий тарифный план, удаляет текущую операцию и обновляет стоимость услуги для отображения в списке
  • elid — код услуги
  • sok=ok — признак сохранения параметров
• service.postsuspend — операция завершения выключения услуги. Меняет статус услуги и удаляет операцию на выключение
  • elid — код услуги
  • sok=ok — признак сохранения параметров
• service.saveparam — сохраняет произвольный параметр услуги
  • elid — код услуги
  • name — внутреннее имя параметры
  • value — значение параметра
• service.setexpiredate — изменяет срок действия услуги
  • elid — код услуги
  • expiredate — новый срок действия услуги
• service.setstatus — меняет дополнительный статус услуги
  • elid — код услуги
  • service_status — новый статус услуги
• service_profile2processingmodule.edit — сохраняет параметры привязки контакта домена к регистратору
  • service_profile — код контакта домена
  • sok=ok — признак сохранения параметров
  • processingmodule — код обработчика
  • type — тип контакта
  • externalid — код контакта на стороне регистратора
  • externalpassword — пароль контакта на стороне регистратора (необязательно)

Статусы услуги

Дополнительный статус услуги может принимать следующие значения

• 1 — домен не оплачен
• 2 — домен зарегистрирован и делегирован
• 3 — домен зарегистрирован, но не делегирован
• 4 — домен удален
• 5 — домен проходит процедуру регистрации
• 6 — домен проходит процедуру смены регистратора
• 7 — домен на продлении
• 8 — делегирование домена окончено

Стандартные параметры контактов доменов

По умолчанию в BILLmanager контакт домена может иметь следующие свойства:

• profiletype — юридический статус контакта.
  • 1 — физ. лицо,
  • 2 — юр. лицо,
  • 3 — ИП
• firstname_locale — имя контактного лица в символах национального алфавита
• middlename_locale — отчество контактного лица в символах национального алфавита
• lastname_locale — фамилия контактного лица в символах национального алфавита
• firstname — имя латиницей
• middlename — отчество латиницей
• lastname — фамилия латиницей
• email — email адрес
• phone — номер телефона
• mobile — номер мобильного телефона
• fax — номер факса
• passport — номер паспорта с серией
• passport_org — организация выдавшая паспорт
• passport_date — дата выдачи паспорта в формате YYY-MM-DD
• birthdate — дата рождения в формате YYY-MM-DD
• location_country — код страны места нахождения из справочника стран BILLmanager
• location_state — штат, регион и т.п. места нахождения контакта
• location_postcode — почтовый индекс места нахождения контакта
• location_city — город места нахождения контакта
• location_address — адрес (улица, дом, квартира/офис и т.д.) места нахождения контакта
• postal_country — код страны почтового адреса контакта из справочника стран BILLmanager
• postal_state — штат, регион и т.п. почтового адреса контакта
• postal_postcode — почтовый индекс почтового адреса контакта
• postal_city — город почтового адреса контакта
• postal_address — адрес (улица, дом, квартира/офис и т.д.) почтового адреса контакта
• postal_addressee — ФИО получателя почты
• company_locale — наименование организации в символах национального алфавита
• company — наименование организации латиницей
• inn — налоговый учетный номер организации
• kpp — код постановки на учет организации

• ogrn — государственный регистрационный номер организации

Пример модуля

C++ (с использованием библиотек BILLmanager)

Использование заголовочных файлов BILLmanager для разработки собственных модулей обработчиков доступно с версии BILLmanager 5.58.0. Кроме приведенного упрощенного примера, можно изучить примеры представленные в пакете разработчика BILLmanager — billmanager-Редакция BILLmanager-devel, например:

 yum install billmanager-standard-devel

После этого примеры можно найти в директории:

/usr/local/mgr5/src/examples

Если у Вас возникла ошибка при попытке make

Building for <ваша операционная система>
Compiling pmregru.cpp
pmregru.cpp:12:23: фатальная ошибка: json/json.h: Нет такого файла или каталога
#include <json/json.h>
                      ^
компиляция прервана.
make: *** [.build/.obj/pmregru.o] Ошибка 1

Выполните установку пакета

make centos-prepare

или

make debian-prepare

PHP

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

Модуль состоит из трех основных файлов:

• etc/xml/billmgr_mod_pmregistrar.php.xml — XML описание
• processing/pmregistrar.php — основной скрипт модуля
• dist/pmregistrar.php/domains.sql — дамп тестовой базы данных

А так же вспомогательного файла с полезными функциями:

• include/php/bill_util.php

Пример можно просмотреть онлайн — https://github.com/ISPsystemLLC/billmanager/ Обратите внимание, что для верной работы обработчика также нужно установить непосредственно интерпретатор PHP и расширение для связи с СУБД — mysqli

Функции bill_util.php

!!! Перед включением в свой скрипт файла bill_util.php необходимо определить макрос _MODULE_, для формирования имени файла лога. Выглядит это примерно так:

set_include_path(get_include_path() . PATH_SEPARATOR . "/usr/local/mgr5/include/php"); 
define('__MODULE__', "pmXXX"); 
require_once 'bill_util.php';

Файл bill_util.php предоставляет следующие функции:

• Debug($str) — для вывода $str в качестве дополнительной информации в лог
• Error($str) — для вывода $str в качестве сообщения об ошибке в лог
• LocalQuery($function, $param, $auth = NULL) — выполняет в BILLmanager функцию $function, передав ей параметры из массива $param и код сессии из $auth
• HttpQuery($url, $param, $requesttype = "POST", $username = "", $password = "", $header = array("Accept: application/xml")) — выполняет к $url запрос, с параметрами из $param, используя тип запроса $requesttype и данные авторизации из $username и $password. Так же можно передать дополнительные заголовки в $header
• CgiInput($skip_auth = false) — получает массив параметров, полученных из скриптов в строке запроса или POST данных. $skip_auth отвечает за получение параметра auth из cookie, если он отсутствует в полученных данных
• ClientIp() — получить IP-адрес, с которого вызван скрипт
• class Error — класс ошибки, имитирующей поведение, схожее с ошибками в COREmanager