Export two or more directories from Bitrix to 1C on request
Many were faced with the task of exporting a catalog from Bitrix to 1C.
But not everyone managed to find a suitable option. The built-in tools of Bitrix do not give freedom of action in this regard. Consider what options Bitrix offers:
1) at the address Shop - Settings - Export Catalog
')
But in the settings you can specify only one directory for export, and if you need to unload more, then it no longer fits.
2) Store - export of data - looked, saw that there is already where to roam.
You can configure the export to YML and CSV. And even in crowns place on schedule. And even make an unloading on request from 1C, albeit using castes. This functionality is already worthy of consideration, but due to the rake and the fact that we wanted “pure” XML, it is also dismissed.
And then the question arose - what to do? Take YML? Or CSV? Or maybe there are other options?
It was decided to sort through the standard exchange between 1C and Bitrix.
The request goes to the file /bitrix/admin/1c_exchange.php - this is a link to the file /bitrix/modules/sale/admin/1c_exchange.php - this file performs import and export operations in Bitrix.
The following types of requests and their settings were excavated: sale, crm, catalog, reference, get_catalog, listen.
The purpose was clear from the title. In this list, we are interested in get_catalog - it is he who creates the export file, this is what the piece of code that interests us looks like:
We can observe that export settings are taken from variant 1 already discussed above, which are stored in the database.
We will continue to work with this data. They decided to leave the standard functionality and create a duplicate, renaming the request type in get_catalog1 with the indication of the information block identifier:
Tested, everything works. But I did not want to create similar duplicates for each information block. We needed flexibility and scalability of the solution.
The output was found quite simple: pass the ID number from 1C in the query string. And intercept the value of a variable via GET.
The result was the following:
The query string from 1C contains the following segment ... & iblockid = 6 & ..., respectively, $ _GET ['blockid'] equates to 6 information block. To import another information block, it is enough to specify the ID of the required information block in the request.
PS: This solution may not correspond to the “True Way” Bitrix, and maybe even comply — I don't know.
But I know for sure - it is this option that satisfies all the needs of this project and solves all the problems associated with the integration of 1C and Bitrix.
Worked in tandem with the 1C programmer, therefore I cannot tell in detail about the difficulty of the work done on importing and processing the received data from 1C.
But not everyone managed to find a suitable option. The built-in tools of Bitrix do not give freedom of action in this regard. Consider what options Bitrix offers:
1) at the address Shop - Settings - Export Catalog
')
But in the settings you can specify only one directory for export, and if you need to unload more, then it no longer fits.
2) Store - export of data - looked, saw that there is already where to roam.
You can configure the export to YML and CSV. And even in crowns place on schedule. And even make an unloading on request from 1C, albeit using castes. This functionality is already worthy of consideration, but due to the rake and the fact that we wanted “pure” XML, it is also dismissed.
And then the question arose - what to do? Take YML? Or CSV? Or maybe there are other options?
It was decided to sort through the standard exchange between 1C and Bitrix.
The request goes to the file /bitrix/admin/1c_exchange.php - this is a link to the file /bitrix/modules/sale/admin/1c_exchange.php - this file performs import and export operations in Bitrix.
The following types of requests and their settings were excavated: sale, crm, catalog, reference, get_catalog, listen.
The purpose was clear from the title. In this list, we are interested in get_catalog - it is he who creates the export file, this is what the piece of code that interests us looks like:
elseif($type=="get_catalog") { $APPLICATION->IncludeComponent("bitrix:catalog.export.1c", "", Array( "IBLOCK_ID" => COption::GetOptionString("catalog", "1CE_IBLOCK_ID", ""), "INTERVAL" => COption::GetOptionString("catalog", "1CE_INTERVAL", "-"), "ELEMENTS_PER_STEP" => COption::GetOptionString("catalog", "1CE_ELEMENTS_PER_STEP", 100), "GROUP_PERMISSIONS" => explode(",", COption::GetOptionString("catalog", "1CE_GROUP_PERMISSIONS", "1")), "USE_ZIP" => COption::GetOptionString("catalog", "1CE_USE_ZIP", "Y"), ) ); } We can observe that export settings are taken from variant 1 already discussed above, which are stored in the database.
We will continue to work with this data. They decided to leave the standard functionality and create a duplicate, renaming the request type in get_catalog1 with the indication of the information block identifier:
elseif($type=="get_catalog1") { $APPLICATION->IncludeComponent("bitrix:catalog.export.1c", "", Array( "IBLOCK_ID" => "6", "INTERVAL" => COption::GetOptionString("catalog", "1CE_INTERVAL", "-"), "ELEMENTS_PER_STEP" => COption::GetOptionString("catalog", "1CE_ELEMENTS_PER_STEP", 100), "GROUP_PERMISSIONS" => explode(",", COption::GetOptionString("catalog", "1CE_GROUP_PERMISSIONS", "1")), "USE_ZIP" => COption::GetOptionString("catalog", "1CE_USE_ZIP", "Y"), ) ); } Tested, everything works. But I did not want to create similar duplicates for each information block. We needed flexibility and scalability of the solution.
The output was found quite simple: pass the ID number from 1C in the query string. And intercept the value of a variable via GET.
The result was the following:
elseif($type=="get_catalog1") { $APPLICATION->IncludeComponent("bitrix:catalog.export.1c", "", Array( "IBLOCK_ID" => $_GET['blockid'], "INTERVAL" => COption::GetOptionString("catalog", "1CE_INTERVAL", "-"), "ELEMENTS_PER_STEP" => COption::GetOptionString("catalog", "1CE_ELEMENTS_PER_STEP", 100), "GROUP_PERMISSIONS" => explode(",", COption::GetOptionString("catalog", "1CE_GROUP_PERMISSIONS", "1")), "USE_ZIP" => COption::GetOptionString("catalog", "1CE_USE_ZIP", "Y"), ) ); } The query string from 1C contains the following segment ... & iblockid = 6 & ..., respectively, $ _GET ['blockid'] equates to 6 information block. To import another information block, it is enough to specify the ID of the required information block in the request.
PS: This solution may not correspond to the “True Way” Bitrix, and maybe even comply — I don't know.
But I know for sure - it is this option that satisfies all the needs of this project and solves all the problems associated with the integration of 1C and Bitrix.
Worked in tandem with the 1C programmer, therefore I cannot tell in detail about the difficulty of the work done on importing and processing the received data from 1C.
Source: https://habr.com/ru/post/273129/
All Articles