Development of an administrative interface for managing the 1C-Bitrix parser

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1175
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    747
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

Development of administrative interface for parser management in 1С-Bitrix

A parser without an admin panel is a bash script on cron that only the developer who wrote it understands. When they go on vacation, nobody can stop the import, change the source, or figure out why the catalog is filling with garbage. A full-featured parser management interface is an investment in system manageability. Let's look at architecture, key screens, and integration with Bitrix mechanisms.

Architecture: module or admin page

In 1С-Bitrix there are two paths to create administrative interface:

  1. Custom module (/local/modules/yourcompany.parser/) — full structure with install/, admin/, lib/, system registration, menu items in left panel. Right path for long-lived projects.
  2. Admin pages (/local/admin/parser_*.php) — faster to implement but scales poorly. Suitable for MVP.

For parser management interface, recommend full module. Reason — parser usually grows entities: sources, mapping rules, schedules, logs. All grouped nicely in one module with ORM entities.

Module structure

/local/modules/yourcompany.parser/
├── install/
│   ├── db/          — SQL migrations
│   └── index.php    — install/uninstall
├── admin/
│   ├── parser_source_list.php
│   ├── parser_source_edit.php
│   ├── parser_task_list.php
│   ├── parser_log_list.php
│   └── menu.php
├── lib/
│   ├── Source.php         — ORM table of sources
│   ├── Task.php           — ORM table of tasks
│   ├── TaskLog.php        — ORM table of logs
│   ├── MappingRule.php    — field mapping rules
│   └── Engine/
│       ├── AbstractParser.php
│       ├── HttpClient.php
│       └── DomExtractor.php
└── lang/

Standard module registration — include.php in root, Module::register() on install, menu items via admin/menu.php using $aMenuLinks[].

Screen 1: Sources management

Main screen. List of parsing sources in standard CAdminList with columns:

Column Type Purpose
ID int Primary key
NAME string Human-readable source name
BASE_URL string Root URL
STATUS enum active / paused / error
LAST_RUN datetime Last run
LAST_RESULT string ok / error: description
ELEMENTS_COUNT int Elements processed in last run
SCHEDULE string Cron expression

Edit form (CAdminForm / CAdminTabControl) contains tabs:

  • Basic — name, URL, status, bind to catalog info block (IBLOCK_ID).
  • Parsing rules — CSS selectors or XPath for fields: name, price, SKU, description, images. Each rule — line with fields field_code, selector, type (text/html/attr/regex), transform (trim/number/replace).
  • Schedule — cron expression or preset selection (every hour, every 6 hours, daily). Stored in source table, agent reads and executes.
  • HTTP settings — User-Agent, timeout, proxy, request delay, page limit.

Screen 2: Parsing tasks

Each parser run creates record in parser_task table:

CREATE TABLE parser_task (
    id SERIAL PRIMARY KEY,
    source_id INT REFERENCES parser_source(id),
    status VARCHAR(20) DEFAULT 'pending',  -- pending, running, completed, failed
    started_at TIMESTAMP,
    finished_at TIMESTAMP,
    total_items INT DEFAULT 0,
    created_items INT DEFAULT 0,
    updated_items INT DEFAULT 0,
    skipped_items INT DEFAULT 0,
    error_items INT DEFAULT 0,
    error_message TEXT
);

Task list has filter by source and status, color indicator (green — completed, red — failed, yellow — running). Action buttons: Re-run, Stop (sets status=cancelling, parser checks flag before each iteration).

Screen 3: Error log

Built on parser_task_log ORM table. Columns: time, source, level (info/warning/error), element URL, message, context (JSON). Filtering by level and source is mandatory — without it log is unreadable.

For each ERROR-level record, add "Open element" link — direct URL to product page in info block admin (/bitrix/admin/iblock_element_edit.php?IBLOCK_ID=X&ID=Y).

Screen 4: Mapping rules

Separate page for visual editing of field mapping: source → info block property. Table:

Source field Selector Info block property Transform
Title h1.product-title NAME trim
Price .price-current span PROPERTY_PRICE extractNumber
SKU [data-sku] PROPERTY_ARTICLE
Picture .gallery img[0]@src DETAIL_PICTURE downloadImage

Mapping stored in source JSON field or separate parser_mapping table. Second option is better for versioning — can rollback to previous rules.

"Test parse" button

Critically important function. Button in source edit form runs parsing of one element by specified URL and shows result right in interface: which fields extracted, which values obtained, which errors. Lets manager check selectors without running full cycle.

Implementation — AJAX handler taking source_id and test_url, calling parser in dry_run=true mode (without write to info block) and returning JSON with results.

Security and rights

Access to parser interface — via $APPLICATION->GetGroupRight('yourcompany.parser') check. Assign rights via standard module mechanism: Settings → Users → Groups → Module access. Minimum two roles: view (logs, statuses) and manage (create/edit sources, run).

Timescale by component

Component Time
Module + ORM entities + migrations 2-3 days
Source list/edit 2 days
Task list + management 1-2 days
Error log 1 day
Mapping + test parse 2-3 days
Testing, debugging 1-2 days
Total 1-2 weeks