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:
-
Custom module (
/local/modules/yourcompany.parser/) — full structure withinstall/,admin/,lib/, system registration, menu items in left panel. Right path for long-lived projects. -
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 |







