› › Bitrix24의 박스형 버전에 대한 설명서입니다. 설치 마법사 완료

Bitrix24의 박스형 버전에 대한 설명서입니다. 설치 마법사 완료

Bitrix 프레임워크 - 프로젝트(웹사이트 및 기업 포털) 생성 및 관리를 위한 기술 핵심(플랫폼)입니다. 플랫폼을 사용하면 제품의 하나의 복사본(라이센스)을 사용하여 무제한의 프로젝트를 생성하고 시스템의 코어와 데이터베이스를 서버의 단일 복사본에 배치할 수 있습니다.

~에 이 순간이전 커널의 모든 기능이 D7에 중복되는 것은 아닙니다. 하지만 새로운 D7 코어 Bitrix 프레임워크점차적으로 오래된 것을 교체하십시오. 이전 커널을 사용하면 IDE에서 경고: Method/class is deprecated 가 표시되는 경우 메서드를 사용해야 합니다.

여러 가지 이유로 인해 API 문서에서 모든 메서드를 다루지 못할 수 있습니다. 작동 방식을 이해하려면 실제 프로그램 코드를 살펴보는 것이 더 나을 때도 있습니다. 이를 위해 다음을 사용할 수 있습니다. 무료 모듈마켓플레이스에서: .

메모: 페이지 주소에 #examples를 추가하면 해당 예제로 빠르게 이동할 수 있습니다. (CHM 형식의 문서 파일에서는 작동하지 않습니다.)


엔터티 버전

Bitrix 프레임워크끊임없이 진화하고 있습니다. 새로운 기능이 나타나고 일부는 더 이상 사용되지 않으며 새로운 매개변수가 기능에 나타납니다. 그러나 상당히 많은 수의 프로젝트가 업데이트되지 않습니다. 프로그래밍 작업을 더 쉽게 하기 위해 문서에는 클래스, 메소드, 매개변수, 이벤트가 존재하는 제품 버전이 표시되어 있습니다.

버전은 제목과 표 두 곳에 나열됩니다. 방법이 유효한 경우 제목에는 제품에 표시된 버전 번호만 포함됩니다. 방법이 오래된 경우 해당 방법이 유효한 버전 범위도 표시됩니다.

표에는 엔터티의 모양이 클래스가 나타나는 순간, 메서드 자체 등과 일치하지 않는 경우에만 제품에 엔터티가 나타나는 버전이 표시됩니다. 아래 그림에서 COURSE_ID 매개변수는 메소드(즉, 5.1.0부터)와 함께 표시되었으며 CHAPTER_ID 매개변수는 버전 9.5.4에서만 나타났습니다.

제품 개발로 인해 매개변수(일반적으로 매개변수를 나타냄)가 변경된 경우 해당 설명에 해당 참고 사항이 표시됩니다. (예: x.x.x 버전 이전에는 매개변수를 *****라고 했습니다).

예

노트:

  • 표시 시대에 뒤쳐진메서드, 매개변수 또는 키의 경우 확장이나 수정 사항이 없으므로 사용하지 않는 것이 좋습니다.
  • 버전 설치가 완전히 완료되지 않았으며 현재 이 방향의 작업이 진행 중입니다.

"비트릭스", 2001-2019, "1C-비트릭스", 2019

1C-Bitrix의 온라인 상점을 시스템과 통합하려면 Bitrix.Marketplace의 시스템 모듈을 사용하면 됩니다.

설치하는 동안 모듈은 기존 주문을 시스템에 업로드하는 데 도움을 줍니다.

설치 후 모듈은 다음을 수행합니다.

  • 1C-Bitrix에서 시스템으로 새 주문을 업로드합니다.
  • 1C-Bitrix의 변경 사항을 고려하여 기존 주문에 대한 데이터를 업데이트합니다.
  • 시스템에서 1C-Bitrix로 새로운 주문과 클라이언트를 업로드합니다.
  • 시스템 변경 사항을 고려하여 기존 주문에 대한 데이터를 업데이트합니다(예: 시스템에서 변경된 주문 상태, 주문 상품 수 등, 이러한 변경 사항은 1C-Bitrix에도 반영됩니다). ;
  • 사용자의 온라인 주문 결제에 대한 정보를 시스템으로 보냅니다.

업데이트 시 수정된 코드를 잃지 않고 플러그인 클래스를 사용자 정의하는 것도 가능합니다. 수정된 코드를 구현하려면 필요한 클래스가 포함된 파일의 복사본을 bitrix/php_interface/retailcrm 디렉터리에 배치해야 합니다.

플러그인에는 다음 파일을 사용자 정의할 수 있는 기능이 있습니다.

RestNormalizer.php
로거.php
클라이언트.php
RCrmActions.php
RetailCrmUser.php
소매CrmICML.php
RetailCrmInventories.php
RetailCrmPrices.php
RetailCrmCollector.php
RetailCrmUa.php
RetailCrmEvent.php
RetailCrmHistory_v4.php
RetailCrmHistory_v5.php
RetailCrmOrder_v4.php
RetailCrmOrder_v5.php
APIClient_v4.php
APIClient_v5.php

사용된 API 버전이 이름에 포함된 파일을 사용자 정의하려면 버전을 지정하지 않고 이름을 사용하여 파일이 생성됩니다(예: RetailCrmHistory.php).

bitrix/php_interface/retailcrm 디렉토리에 있는 클래스를 사용하여 파일의 복사본을 생성한 후 모듈은 사용자 정의 클래스를 사용합니다. 해당 메서드를 변경할 수 있습니다.

시스템에 온라인 상점 등록

설치하기 전에 시스템 인스턴스에 온라인 상점을 등록하십시오(예를 들어 데모 버전에서는 관리 > 상점 섹션).

1C-Bitrix에 솔루션 설치

  • Marketplace의 솔루션 페이지에서 "설치"를 클릭하고 온라인 상점 주소를 입력하세요.

  • 1C-Bitrix 업데이트 시스템을 통해 모듈을 다운로드하십시오.

  • 모듈 설치를 시작합니다.

설치 마법사가 시작됩니다.

설치 마법사. 1 단계

1.1단계에서는 시스템 주소(예: https://test.retailcrm.ru)와 시스템에서 이전에 생성한 API 키를 표시해야 합니다.

중요한! Bitrix에 매장이 하나만 있는 경우 1단계. 사이트를 건너뜁니다.

설치 마법사. 1단계. 웹사이트

1.Sites 단계에서는 1C-Bitrix의 매장과 시스템 간의 통신을 설정해야 합니다.

중요한! 시스템의 모든 상점에는 공통 API 키가 있어야 합니다.

설치 마법사. 2 단계

두 번째 단계에서는 온라인 상점 값과 시스템 디렉토리 값 간의 일치성을 표시해야 합니다. 모듈 자체는 일반적인 상태에 대한 대응을 설정하려고 시도합니다. 모듈이 이 작업을 수행하지 못한 경우 일치 항목을 직접 지정해야 합니다.

시스템에 온라인 상점 디렉토리에 해당하는 필수 디렉토리 값이 있는지 확인하십시오. 충분하지 않은 경우 설치 마법사 페이지를 닫지 않고 관리 섹션에 추가하십시오.

그런 다음 마법사 페이지를 새로 고치십시오. 새 디렉토리 값이 로드되어야 합니다.

설치 마법사. 3단계

세 번째 단계에서 모듈을 사용하면 1C-Bitrix 필드와 시스템 간의 대응 관계를 설정할 수 있습니다.

중요한! "라는 형식이 있는 경우 피드백"또는 "1번의 클릭으로" 주문하며 이 데이터는 표준 Bitrix 주문에 속하지 않으며 시스템으로 가져오지 않습니다.

또한, 당신이 함께 일하고 있다면 법인, 아래 스크린샷에 표시된 대로 모든 필드를 작성해야 합니다.

설치 마법사. 4단계

네 번째 단계에서는 모듈을 사용하여 이전에 주문한 주문을 시스템에 업로드할 수 있습니다. 언로드에는 다소 시간이 걸릴 수 있습니다(약 5분 안에 1000개의 주문이 언로드됩니다). 업로드 프로세스의 진행 상황은 진행률 표시줄로 표시됩니다.

필요한 경우 다운로드를 일시 중지하고 잠시 후에 다시 시작할 수 있습니다.

이전에 접수한 주문을 업로드한 후 KPI 패널에서 분석 보고서를 볼 수 있습니다. 이 단계를 수행하는 것이 좋습니다.

설치 마법사. 5단계

다섯 번째 단계에서는 제품 카탈로그 업로드를 구성합니다. 이렇게 하려면 다음 사항을 완료해야 합니다.

1. 정보 블록 및 속성 선택

선택한 정보 블록이 시스템에 업로드됩니다. 귀하는 제품을 포함하거나 거래 제안과 연결된 정보 블록이 있는 정보 블록 중에서만 선택할 수 있습니다. 정보 블록 선택과 병행하여 품목, 제조업체, 색상, 무게, 크기 등의 속성을 선택할 수 있습니다. 이를 위해서는 해당 속성을 저장하는 정보 블록 속성을 지정해야 합니다. 속성 선택은 선택 사항입니다.

2. 파일 경로

해당 형식의 파일은 디렉토리 구조를 포함하는 지정된 경로에 생성됩니다. 기본 경로는 - "/bitrix/catalog_export/retailcrm.xml". 경로를 변경하는 경우 시스템에서 유사한 설정을 수행해야 합니다.

3. 수출 제안 수 설정

카탈로그 내보내기 설정에는 "제품에 대한 최대 거래 제안 수" 필드가 있으며, 여기에는 한 제품이 보유할 수 있는 최대 거래 제안 수(50개가 넘는 경우)를 입력해야 합니다. 기본적으로 모듈은 제품에 대해 최대 50개의 거래 제안을 계산합니다. 매장에 상품당 거래 제안이 50개 미만인 경우 이 설정을 무시할 수 있습니다. 더 많은 거래 제안이 있고 설정이 지정된 경우 히트에 작동하면 에이전트를 크라운으로 전송하는 것이 좋습니다.

4. 하역 빈도 선택

선택할 수 있는 옵션은 세 가지가 있습니다.

1. 아니요- 이 항목을 선택하면 카탈로그의 주기적 업로드가 자동으로 구성되지 않으며, 매번 카탈로그를 직접 업로드해야 합니다.

이 옵션은 온라인 상점의 제품 카탈로그가 거의 변경되지 않거나 나중에 업로드 매개변수를 구성하려는 경우에 유용할 수 있습니다.

2. 크론- 이 항목을 선택하면 온라인 상점 웹사이트가 운영되는 서버의 Cron 서비스에 연결되는 특수 프로필이 자동으로 생성됩니다.

cron 유틸리티는 다음에서 실행됩니다. 배경그리고 지정된 시간에 지정된 작업을 수행합니다.

카탈로그에 매우 큰 항목( 10,000개 이상의 제품). 이 항목의 경우 특수 내보내기 프로필의 이름을 지정해야 합니다.

3. 대리인. 이 경우 1C-Bitrix의 "에이전트" 기술에 연결되는 특수 프로필도 생성되고 업로드가 이루어집니다. 하루에 한 번씩 자동으로.

에이전트는 특정 빈도로 실행되는 PHP 함수입니다. 각 페이지 로드가 시작될 때 시스템은 시작해야 할 에이전트가 있는지 자동으로 확인하고 필요한 경우 이를 실행합니다. 시간이 많이 걸리는 업로드를 위해 에이전트를 생성하는 것은 권장되지 않습니다. cron을 사용하는 것이 좋습니다.

이 옵션은 디렉토리에 다음이 포함된 경우 가장 바람직합니다. 10,000개 미만의 제품, 업로드가 매우 빠르게 이루어지며 이는 온라인 상점 웹 사이트의 속도에 어떤 영향도 미치지 않습니다.

범위가 큰 경우( 10,000개 이상의 제품), 필수적이다 추가 사용자 정의 Cron의 에이전트. 이 항목의 경우 특수 내보내기 프로필의 이름도 지정해야 합니다.

4. 즉시 하역 표시

"지금 언로드" 플래그를 설정하면 모듈 설치 직후 디렉터리 구조가 위 파일로 언로드됩니다.

시스템의 파일에 카탈로그를 업로드한 후 관리 -> 매장 -> 매장 이름 -> "카탈로그" 탭으로 이동하여 "지금 ICML에서 카탈로그 다운로드" 상자를 선택해야 합니다. 이 경우 파일 다운로드 및 처리가 거의 즉시 시작됩니다.

5. 프로필 이름 지정

제품 카탈로그 업로드를 올바르게 설정하면 스토어 > 설정 > 데이터 내보내기 섹션에 새로운 유형의 시스템 내보내기가 표시되며, 설치 중에 주기적인 업로드를 지정하면 내보내기 프로필도 표시됩니다.

메모:
을 위한 자체 구성업로드하면 자신만의 내보내기 프로필을 만들 수 있습니다.

설치 마법사 완료

설치가 끝나면 2개의 에이전트가 생성됩니다. 한 에이전트는 Bitrix의 주문 내역을 시스템에 업로드하고 두 번째 에이전트는 카탈로그를 생성합니다. 상담원에 대해 주문 업로드가 구성된 경우 내역이 호출될 때 주문이 시스템에 업로드됩니다. 다른 경우에는 이벤트에 따라 주문이 언로드됩니다.

1C-Bitrix 교환 중 배송 서비스 언로드 - 시스템

Russian Post, EMS, DHL 등 많은 프로필이 있는 eDost와 같이 1C-Bitrix에 연결된 자동 배송 서비스가 있는 경우 시스템에서 이러한 종류의 배송 서비스를 업로드하는 기능을 활용할 수 있습니다.

전달 방법은 시스템 측에서 구성되어야 합니다. 배송 서비스를 Bitrix에 연결하기 전에 시스템 모듈을 설치한 경우 누락된 배송 방법을 시스템에 수동으로 입력해야 합니다. 배송 서비스 연결 후 모듈을 설치한 경우, 배송 방법도 자동으로 설치되고, 서비스 언로드도 자동으로 실행됩니다. 즉, 각 주문에 대해 배송비가 다운로드됩니다.

1C-Bitrix 측에서 배송 서비스를 1C-Bitrix 시스템에 연결한 후 시스템 모듈을 설치한 경우 다음 설정을 지정해야 합니다.

이동 관리 > 설정, "디렉터리 설정" 탭으로 이동합니다.

전달 방법의 대응을 구성합니다(시스템 측에서 미리 구성). 다음으로 '배송 서비스 업로드' 버튼을 클릭하세요.

1C-Bitrix 업로드 빈도 설정-시스템

제품 카탈로그를 업데이트할 때 다음 두 가지 사항을 강조할 수 있습니다.

클라이언트측에서 카탈로그 생성(yml/icml 형식) 및

시스템은 3시간마다 한 번씩 카탈로그를 다운로드합니다. 업로드해야 하는 파일의 경로는 스토어 설정에서 설정됩니다. 섹션으로 이동해야 합니다. 관리 > 매장 > 매장 선택 > 카탈로그 탭.

1C-Bitrix에 시스템 모듈을 설치하면 업로드용 프로필이 생성됩니다. 보려면 다음으로 가야 합니다. 데스크탑 > 스토어 > 설정 > 데이터 내보내기. 스크린샷에는 두 가지 옵션이 표시됩니다.

기본,

시스템 디렉터리를 업로드하는 중입니다.

두 번째 옵션을 선택한 경우 해당 옵션을 클릭하면 업로드 옵션이 열립니다.

빈도 옵션으로 에이전트를 선택한 경우 에이전트 목록을 보려면 다음으로 이동해야 합니다. 데스크톱 > 설정 > 제품 설정 > 에이전트.

"변경" 또는 "새로 추가"를 클릭하면 생성 작업 실행 빈도를 할당하거나 변경할 수 있습니다.

교환 중 데이터 동기화 빈도 1C-Bitrix - 시스템

시스템 모듈을 사용하면 시스템에 제품 카탈로그를 업로드할 수 있을 뿐만 아니라 주문과 고객의 정기적인 양방향 교환을 수행할 수 있습니다.

카탈로그에서 적시에 데이터를 업로드하면 시스템 관리자가 제품 가용성에 대한 최신 정보를 얻을 수 있습니다. 상품을 주문하고 시간이 지나면 품절이 되는 상황은 발생하지 않습니다.

주문 교환은 주문이 양방향으로 업로드될 때 데이터를 동기화하는 프로세스입니다.

1C-Bitrix에서 시스템으로:

  • 이벤트별 업로드가 활성화된 경우 1C-Bitrix 시스템에서 주문을 생성하거나 변경할 때 즉시 시스템에 업로드됩니다. 하역 대리인이 선택되면 주문은 15분 이내에 시스템에 업로드됩니다. (이 경우 주문이 지연되어 도착하고 해당 주문에 대한 업데이트가 전송되지 않으므로 부득이한 이유 없이 이 메커니즘을 사용하지 않는 것이 좋습니다. 시스템에).
  • 사용자가 변경되면 마스터 데이터도 즉시 시스템에 업로드됩니다.

시스템에서 1C-Bitrix로:

  • 신규 사용자를 위해 시스템에서 주문을 생성하면 주문이 1C-Bitrix에 업로드되어 생성됩니다. 새로운 사용자 1~15분 범위에서.
  • 주문 페이지의 시스템에서 주소, 배송 비용 또는 상태를 변경하면 이러한 모든 변경 사항이 15분 이내에 1C-Bitrix에 업로드됩니다.
  • 시스템에서 제품 할인을 변경하고 제품 수량을 변경하면 1C-Bitrix에서 1~15분 간격으로 변경됩니다.

통합 모듈의 변경 사항

버전 2.0

  • 통합 모듈 버전 V2.0은 1C-Bitrix를 "온라인 상점(판매)" 모듈 버전 > 16과 통합하도록 설계되었습니다.
  • 이제 모듈은 API V4를 통해 작동합니다.
  • 통합 모듈은 이제 새로운 1C-Bitrix D7 코어를 사용합니다.
  • 이제 클라이언트 관련 변경 사항(성명, 이메일, 전화번호)도 시스템에서 웹사이트로 전송됩니다.
  • "기타 설정"섹션의 통합 모듈 설정에서 시스템의 주문 번호를 1C-Bitrix로 변환하는 것이 가능해졌습니다. 즉, 시스템에서 12345R과 같은 번호로 주문을 수동으로 생성하면 1C-Bitrix에서 동일한 번호의 주문이 생성됩니다.
  • "온라인 상점(판매)" 모듈 버전 > 16에서 Bitrix 개발자는 전체 주문에 할인을 적용하는 것에서 벗어나 제품에 대해서만 할인을 남겼으므로 시스템은 현재로서는 할인을 사용할 수 없습니다. 전체 주문. 특정 주문 품목에 대해서만 할인을 설정할 수 있습니다.

버전 2.1

  • 카탈로그 내보내기에 측정 단위가 추가되었습니다.

버전 2.2

  • 이제 모듈은 선택하여 여러 API 버전을 지원합니다.
  • API V5 지원.
  • 창고별 잔액을 언로드하는 기능이 추가되었습니다.
  • 가격 유형을 다운로드하는 기능이 추가되었습니다.
  • 기본 데몬 수집기 통합이 추가되었습니다.
  • Universal Analytics와의 통합이 추가되었습니다.
  • 데이터 수정을 위한 내장 기능의 로직이 개선되었습니다.
  • 내장 함수인 RetailCrmApiResult가 추가되었습니다.
  • 변경 기록의 트리거 버전이 추가되었습니다.

버전 2.4

  • 새로운 주문에 대한 결제를 저장하기 위해 프로세서에 수표를 추가했습니다.
  • 수출 시 거래 제안 수에 대한 설정이 추가되었습니다.
  • 구매 가격 변환이 추가되었습니다.
  • 번역 파일 변경.
  • 주문 속성에 대한 시스템에서 변경 사항을 언로드할 때 확인을 추가했습니다.
  • VAT 업로드가 추가되었습니다.
  • 업로드할 가격 유형 목록을 가져오는 문제가 수정되었습니다. Bitrix에서 사용 가능한 모든 유형을 선택할 수 있습니다.

다른 설정

주문 설정

중앙처리센터에서 생성된 주문번호를 매장으로 전송

시스템에서 주문이 생성되면 지정된 규칙에 따라 고유한 번호가 생성됩니다. 모듈에서 이 설정을 설정하면 역동기화 중에 해당 주문 건수가 매장으로 전송됩니다.

주문 하역

  • 이벤트별- 주문을 저장하면 데이터가 시스템에 입력됩니다.
  • 대리인- 시스템에서 변경 내역을 요청하기 전에 새로운 주문이 전송됩니다.

클라이언트 API 버전

이제 모듈이 작동할 API 버전을 선택할 수 있습니다. 선택은 시스템 버전에 따라 다릅니다. 최신 버전을 선택하는 것이 좋습니다.

창고별 잔액 하역 활성화(창고가 있는 경우 사용 가능)

이제 사이트 창고에서 시스템 창고로 잔액을 주기적으로 언로드할 수 있습니다. 이렇게 하려면 다음이 필요합니다.

  • 사이트 웨어하우스와 시스템 웨어하우스를 비교합니다.
  • 잔액이 로드될 시스템 저장소를 나타냅니다.
  • 잔고 로드에 필요한 상품이 포함된 정보 블록을 선택합니다(시스템의 카탈로그 내보내기에 표시된 상품을 선택해야 함).

업로드는 1시간 간격(기본값)으로 에이전트에 의해 수행됩니다.

시스템에 로드 밸런싱을 수행하려면 옵션을 활성화해야 합니다.

상품 가격 유형 업로드 활성화(가격 유형이 여러 개인 경우에만 사용 가능)

이제 스토어에서 시스템으로 추가 가격 유형을 주기적으로 업로드할 수 있습니다. 이렇게 하려면 다음이 필요합니다.

  • 사이트 가격 유형을 시스템 가격 유형과 비교합니다.
  • 추가 가격 유형이 로드될 시스템 상점을 나타냅니다.
  • 추가 가격 유형을 로드해야 하는 제품이 포함된 정보 블록을 선택합니다(시스템에 대한 카탈로그 내보내기에 지정된 항목을 선택해야 함).

업로드는 에이전트에 의해 24시간마다(기본적으로) 수행됩니다.

악마 수집가 활성화

이제 설정 인터페이스에서 웹사이트에 Collector Daemon을 추가할 수 있습니다. 이렇게 하려면 원하는 사이트에 적합한 키를 지정해야 합니다. 열쇠는 시스템에서 찾을 수 있습니다.

UA 통합 활성화

이제 설정 인터페이스에서 Universal Analytics와의 통합을 활성화할 수 있습니다(표준 주문 구성요소와 올바르게 작동). 추적을 추가하려는 각 사이트에 대해 추적 ID와 맞춤 매개변수 색인을 입력해야 합니다.

여기서 $order는 시스템으로 전송될 생성된 주문 데이터 배열이고 $arFields는 웹사이트의 주문 필드 배열입니다. function RetailCrmBeforeOrderSave($order) ( //변경 사항은 $order를 반환합니다. //또는 false를 반환합니다. 그런 다음 이 주문에 대한 시스템의 변경 사항은 무시됩니다.)

여기서 $order는 시스템에서 수신된 수정된 주문 데이터가 포함된 배열입니다.

함수 소매CrmAfterOrderSave

RetailCrmAfterOrderSave - 시스템 내역에서 수신된 주문 데이터의 변경 사항이 웹사이트에 저장된 후 즉시 실행되는 기능입니다.

함수 RetailCrmAfterOrderSave($order) ( //변경 사항이 반환됩니다. )

여기서 $order는 시스템에서 수신된 수정된 주문 데이터가 포함된 배열입니다.

함수 소매CrmApiResult

RetailCrmApiResult - 시스템 API로부터 응답을 받은 후 즉시 실행되는 함수입니다.

function RetailCrmApiResult($methodApi, $res, $code) ( //변경 사항이 반환됩니다. )

여기서 $methodApi는 API 메서드의 이름이고, $res는 true/false 요청(요청 성공 또는 실패)의 결과이며, $code는 API 응답 상태 코드입니다.

이 기능을 사용할 때 코드에 오류가 있으면 사이트와 시스템의 동기화가 중단될 수 있습니다.

위에 나열된 도구가 어떤 이유로 충분하지 않은 경우 모듈을 업데이트할 때 이러한 변경 사항을 잃을 위험 없이 모듈 코드에 직접 필요한 변경 사항을 적용할 수 있습니다. 이렇게 하려면 필요한 클래스가 포함된 파일을 /bitrix/php_interface/retailcrm/ 디렉터리에 복사하고 수정해야 합니다. 이 메커니즘은 클라이언트, 주문, 이벤트, 카탈로그 내보내기 및 기타 보조 메커니즘과 함께 작동하도록 클래스 변경을 지원합니다.


서표 사용자 정의 작업제품을 직접 사용하여 작업하는 사람, 즉 당사 소프트웨어 제품을 사용하는 회사의 직원을 위한 것입니다.

관리 작업 탭은 박스형 버전을 관리할 사용자를 위한 것입니다. "비트릭스24".

서표 선적 서류 비치박스형 버전을 기반으로 하는 프로젝트 개발자를 위한 것입니다. "비트릭스24".

사용자 정의 작업

관리 업무

개발자용

개발자 문서는 시스템 API에 대한 설명입니다. 사용자 문서는 시스템 구성 요소 및 설정에 대한 설명입니다.

설명서는 온라인과 chm 형식의 파일로 모두 제공됩니다. 최신 버전인 온라인 버전을 사용하는 것이 좋습니다. chm 파일은 주기적으로 업데이트되며 최신 버전에 대한 정보가 포함되어 있지 않을 수 있습니다.

주목! 서식 파일의 내용이 보이지 않는 경우 .chm, 그 이유는 보안 설정 때문입니다. 운영 체제. 파일 속성에서 파일 보기 차단을 해제해야 합니다. 자세히 알아보기자주하는 질문

문서는 참조 정보입니다. 초보 개발자가 시스템을 사용하는 것만으로는 충분하지 않습니다. 프로그래밍의 원리를 익히는 과정에서 Bitrix 프레임워크특별 과정이 도움이 될 것입니다:

얼마 전 우리 회사는 유지 관리 및 수정을 위해 1C-Bitrix에서 상당히 큰 온라인 상점을 받았습니다. 이 프로젝트는 몇 달 전에 상업 운영에 들어갔지만 동시에 여러 가지 심각한 문제도 안고 있었습니다. 또한 고객은 새로운 기능을 마무리하는 작업을 최대한 빨리 완료할 계획이었습니다. 정리하는 일을 맡게 됐어요 효율적인 작업사이트 가동 중지 시간을 최소화하고 고객 요구 사항을 최대로 만족시키는 프로젝트에 따라.

초기 데이터:

  • 1C-Bitrix에는 온라인 상점이 있습니다.
  • 이 프로젝트는 몇 년이 지났지만 불과 몇 달 전에 사이트가 1C-Bitrix로 이전되었습니다.
  • 하루 10~15만명 출석
  • 매장 카탈로그에는 약 12,000개의 제품 항목이 포함되어 있습니다.
  • 가동 중지 시간 및 사이트 중단은 허용되지 않습니다.
  • 이 프로젝트는 6개월 이내에 다른 회사에 의해 개발되었습니다.
    1. 완료된 작업의 약 40%에 해당하는 약 100장에 대한 기술 사양이 있습니다.
    2. 프로젝트 문서 없음
    3. 이전 개발자가 특정 아키텍처 솔루션을 사용한 이유에 대한 이해가 부족합니다.

개발 소프트웨어일반적으로, 특히 웹 프로젝트에서는 약 8년 동안 웹 프로젝트 작업을 해왔습니다. 이 기간 동안 나는 다양한 복잡성의 프로젝트를 접했고 언뜻보기에 작업이 너무 어려워 보이지 않았습니다. 우리 회사에서는 프로젝트를 구현할 때 원칙적으로 SCRUM 방법론을 사용합니다. 나는 그녀에게서 멀어지기 시작했습니다.

우선 접근권을 얻었습니다 소스 코드프로젝트. 표면적으로 분석되었습니다. 우선순위 작업 목록에 대해 고객과 합의했습니다. 개발자 3명을 위한 개발 계획을 세웠고 가가린 말대로 가자!

문제 #1 - 개발자가 모든 것에 대해 책임을 져야 합니다.

일반적으로 그렇듯이 고객을 제외한 모든 사람이 책임을 져야 합니다. 디자이너는 너무 무거운 레이아웃을 만들었고, 호스팅 업체는 느리게 작동하는 서버를 제공했고, 개발자는 항상 버그가 많고 망가지는 웹사이트를 만들었고, 관리자는 전환 후 우리가 수행하도록 요청하지 않은 일부 작업을 완료했습니다. 구 버전 1C-Bitrix 사이트에서 검색 트래픽 등이 급격히 감소했습니다. 상황은 명확하지 않습니다. 물론 주된 책임은 개발사에 있어야 합니다. 사이트에서 수행한 모든 작업의 ​​결과를 고객에게 전달하고 결과를 준비하는 것이 필요했습니다. 업무 수행 시 전체적인 아키텍처를 제안 미래 시스템그리고 이정표가 완료될 때까지 따라야 할 개발 계획입니다. 기능에 대한 철저한 테스트를 실시하고 작품을 제출합니다. 반면에 나는 고객의 어머니가 한때 그림을 그렸기 때문에 고객이 모든 것을 더 잘 아는 상황을 자주 접합니다. 최고의 디자이너, 그의 7살 아들은 GTA를 플레이하며 컴퓨터에서 모든 시간을 보내기 때문에 SEO 최적화에 정통합니다.

누가 유죄이고 누가 옳은지를 판단하는 것은 우리의 몫이 아닙니다. 이 경우 이전 계약자는 상당히 유명하고 신뢰할 수 있는 회사였으며 개발에 대해 나쁘다고 말할 수 없습니다. 그리고 고객은 객관적으로 자신의 제품에 관심을 갖고 개선하려고 노력합니다. 어떻게 된 일인지는 모르겠지만, 계약자가 고객에게 제공한 분석량이 충분하지 않다는 설명을 직접 찾았습니다.

결과적으로:

  • 프로젝트는 논리적인 결론에 이르지 못했습니다. 많은 작업이 중간에 포기됩니다
  • 프로젝트가 문서화되어 있지 않습니다. 일부 기능의 작동은 명확하지 않습니다. 새로운 기능을 개발할 때, 예전에 작동하던 기능과 새로운 개발자가 그 존재를 의심하지 않았던 기능이 작동을 멈춘 것으로 밝혀졌습니다.
  • 이전 수행자가 작성한 코드 중 일부를 처음부터 다시 작성해야 함
  • 프로젝트의 의도된 아키텍처는 작업 첫 주/몇 달 동안 새 계약자에게 명확하지 않습니다. 한 모듈의 기능이 향상되면 해당 모듈과 전혀 관련이 없는 모듈의 기능이 손실됩니다.
  • 손님이 불안하다, 출연자가 불안하다, 방문객이 기분이 좋지 않다, 출석률이 감소하다, 매출이 감소하다

문제에 대한 해결책은 단 하나뿐입니다. 모든 사이트 모듈을 하나씩 체계적으로 정리하여 제품을 필요한 상태로 만드는 것입니다. 일부 오류는 별도의 작업에 포함되어 즉시 완료되었으며, 일부 오류는 새로운 기능 개발과 병행하여 수정되었습니다. 그 결과, 업데이트할 때마다 버그를 즉시 제거한 후 사이트가 더 좋아지고 안정적이게 되었습니다.

문제 #2 - 병렬 개발.

1C-Bitrix 라이센스 정책에 따라 각 웹사이트 라이센스를 통해 시스템 사본 2개를 사용할 수 있습니다. 하나는 생산 사이트로, 두 번째는 개발용으로 사용됩니다. 문제는 개발이 여러 명의 개발자(나의 경우에는 3명)에 의해 지속적으로 진행된다는 점이다. 클래식 개발의 경우 모든 것이 간단합니다. 각 개발자는 자신의 모듈에서 작업합니다. 그런 다음 각 모듈의 기능 테스트가 수행되고 모든 개선 사항이 일부 버전 제어 시스템의 저장소에 병합된 다음 모두 함께 테스트됩니다(통합 테스트). 결과가 정상이면 테스트 버전을 고객에게 제시합니다. 테스트 버전이 승인되면 프로덕션 서버가 업데이트됩니다. SCRUM 방법론에 따라 일주일에 한 번씩 프로덕션 사이트에 새 버전을 업로드하기로 결정했습니다. 따라서 기본 개발에는 3~4일이 소요됩니다. 테스트 및 버그 수정에 1일, 프로덕션 서버 업데이트에 반나절이 소요됩니다. 물론 마감일은 유동적이지만 '매주 목요일 공개'라는 규칙을 엄격하게 지키려고 노력했습니다.

내가 처음 접한 것은 1C-Bitrix에서는 동일한 파일이 사이트의 다른 끝에서 다른 기능으로 동시에 사용되는 상황이 있다는 것입니다. 가장 간단하고 확실한 해결책은 버전 제어 시스템을 사용하는 것입니다. 제 경우에는 다른 모든 프로젝트에서 사용하는 SVN입니다. 그러나 버전 제어를 사용하려면 각 개발자가 자신만의 코드 버전을 갖고 이를 편집한 다음 공통 저장소에 병합해야 합니다.

라이센스는 어떻습니까? 연락함 기술적 지원 1C-비트릭스. 추가 구매 제안을 받았습니다. 개발 라이센스. 좋게 말하면 기분이 좋지는 않았지만 다른 제안을 받은 적은 없었다. 나는 충분히 빨리 해결책을 찾았습니다. NFR 키를 사용하기로 결정했습니다. 다행히도 파트너 상태에서는 이를 허용합니다. 결과적으로 저는 5개의 온라인 상점 설치물을 만들었습니다.

  • 프로덕션 서버
  • 테스트 서버
  • 개발 서버 3개(개발자당 1개)

시간이 지남에 따라 나는 더욱 발전했습니다. 테스터를 위한 별도의 설치도 있습니다. 운 좋게도 고객은 항상 테스트 서버에서 무언가가 업데이트되는 순간에 로그인하는 것으로 나타났습니다. 버그 트랙에는 이미 완료된 불필요한 작업이 많이 포함되어 있으며 고객은 우리가 업무를 제대로 수행하지 못하고 있다는 인상을 받습니다.

현재 나는 다음 구성표를 사용하고 있습니다.

  • 각 개발자는 자신의 로컬 복사본만 업무에 사용합니다.
  • 합의된 시간에 완료된 모든 개선 사항은 저장소의 공통 분기로 병합됩니다.
  • QA에서는 테스트를 위해 병합된 버전을 사용합니다.
  • 오류를 테스트하고 수정한 후 고객을 위해 데모 서버가 업데이트됩니다.
  • 고객이 확인하고 승인한 후 개선 사항이 프로덕션 서버로 전송됩니다.

이 접근 방식의 명백한 단점 중 하나는 개발에 대한 고객 참여 수준이 낮다는 점을 강조하고 싶습니다. 결과는 최종 단계에서만 고객에게 표시됩니다. 이 접근 방식은 실수를 거의 하지 않고 고객과 지속적으로 접촉하는 훌륭한 분석가가 있는 경우에 적용 가능합니다. 그렇지 않으면 많은 작업을 처음부터 다시 수행해야 합니다.

회로를 구축하면서 또 다른 문제에 직면했습니다. 이 프로젝트는 약 80GB의 디스크 공간을 차지합니다. 캐시 및 임시 파일 없음 - 약 60개. 처음에는 버전 관리에서 사진과 비디오를 제거하려고 했지만 작동하지 않았습니다. 사이트의 정보는 지속적으로 변경됩니다. 현재 데이터를 사용하여 테스트해야 합니다. 저장소에 대한 첫 번째 사이트 커밋에는 청크로 2일 이상이 걸렸습니다. 개발 폴더에 대한 첫 번째 체크아웃에는 몇 시간이 걸립니다(SVN 서버는 지역 네트워크개발). 실수로 프로젝트 폴더를 완전히 업데이트한 경우에는 담배를 피우거나, 점심을 먹거나, 탁구를 치거나 컬링을 할 수 있습니다. 선택한 파일이나 폴더만 커밋하는 것은 매우 빠릅니다. 해결책: 변경된 파일 12개를 한 번에 다운로드하는 작업을 완료했습니다.

문제 3번 – 프로덕션 서버 업데이트 및 고객과의 협업

문제는 가장 중요하고 복잡하며 완전히 해결되지 않았습니다. 결국 다른 문제가 프로젝트 내부 작업과 관련된 경우 고객의 평판과 수입, 결과적으로 내 수입은 사이트 작업에 따라 달라집니다.

머피의 법칙은 여기서 훌륭하게 작동합니다.

  • 테스트 서버에서 제대로 작동하지 않으면 프로덕션 서버에서는 반드시 문제가 발생합니다.
  • 테스트 서버에서 완벽하게 작동하더라도 프로덕션 서버에서는 여전히 작동하지 않습니다.
  • 사이트에 버그가 5초 동안만 존재한다면 방문자 중 한 명이 분명히 이를 발견하고 리뷰나 피드백 양식에 이에 대해 글을 쓸 것입니다.
  • 업데이트 중에 사이트가 1분 동안 작동하지 않으면 회사 소유자가 친구나 경쟁자에게 사이트를 표시하는 것은 이 순간입니다(업데이트 시간 및 절차에 대한 합의에도 불구하고).
물론 과장하고 있지만 모든 농담에는 유머가 담겨 있습니다. 사이트의 최소 로드는 오전 4시부터 6시까지입니다. 물론 이때 업데이트 하면 더 좋겠지만 별로 그러고 싶지 않네요.

대부분의 웹 애플리케이션의 경우 애플리케이션을 레이어로 나누는 명확한 구조가 있으며 사이트 업데이트는 두 부분으로 나눌 수 있습니다.

  • 코드 업데이트
  • SQL 스크립트를 사용하여 데이터베이스 업데이트

1C-Bitrix의 경우 모든 것이 조금 더 복잡합니다. 첫째, 파일이 너무 많습니다. 내 프로젝트에는 백만 개가 넘는 항목이 있습니다. 저장소에서 일반적인 업데이트는 20~30분 이상 소요됩니다. 물론 변경된 파일만 업데이트할 수 있지만 그러면 저장소의 전체 내용이 손실됩니다. 둘째, 이는 훨씬 더 슬픈 일입니다. 업데이트할 때 관리자 패널을 통해 수동으로 변경하고 설정해야 하는 경우가 많습니다. 그리고 이것은 항상 느립니다. 필요한 모든 변경 사항을 기억해야 하며 실수로 실수할 가능성이 높습니다. 물론 데이터베이스에 필요한 모든 변경을 수행하는 SQL 스크립트를 작성할 수도 있습니다. 물론 가장 간단한 경우에는 그렇게 합니다. 그러나 대부분의 경우 이러한 스크립트를 작성하고 디버깅하는 데는 개발 자체보다 시간이 더 많이 걸리고 후속 테스트에서 모든 작업을 수동으로 수행하는 것보다 훨씬 더 많은 시간이 걸립니다.

아직 문제에 대한 좋은 해결책을 찾지 못했습니다. 이제 데이터베이스의 설정을 수동으로 업데이트합니다. 오류를 최소화하기 위해 업데이트 중에 수행해야 할 작업 목록과 함께 체크리스트가 작성됩니다. 우리는 가능한 한 신중하고 정확하게 업데이트를 수행하려고 노력합니다. 업데이트 후에는 팀 전체가 프로덕션 서버의 주요 기능을 확인하고 추가 테스트를 실시합니다. 오류 수는 최소화되었으나 아직까지 업데이트 중 발생하는 버그와 다운타임을 완전히 없애는 것은 불가능했습니다.

두 번째로 제가 접한 것은 협동고객과 함께. 왜냐하면 이 프로젝트는 규모가 커서 약 30명이 지속적으로 작업하고 있습니다. 콘텐츠 관리자, 영업 관리자, SEO 최적화 담당자, 마케팅 담당자 등이 있습니다. 당연히 모든 사람이 사이트 페이지와 모듈 설정을 일부 변경합니다. 첫 번째 결정은 고객으로부터 사이트의 프로그램 코드를 변경할 수 있는 권리를 박탈하는 것이었습니다. 그 결정은 절대적으로 옳았지만 상황은 더욱 악화되었습니다. 이전에 고객이 현장에 가서 실수로 무언가를 깨뜨릴 수 있다고 가정했다면 이제 모든 문제는 우리에게만 떨어지기 시작했습니다. 그것이 그것과 무슨 관련이 있습니까? 콘텐츠 관리자가 페이지의 텍스트를 비뚤게 편집하고 일부 태그를 닫지 않았더라도 여전히 개발자의 책임입니다. 해결책은 매우 간단한 것으로 나타났습니다. 마켓플레이스에는 페이지 버전 제어를 위한 무료 모듈이 있습니다. 그래도 문제가 해결되지는 않았습니다. 누군가는 때때로 뭔가를 엉망으로 만들 것입니다. 그러나 이제는 누가 변경한 내용을 변경했는지, 왜 모든 것이 중단되었는지 언제든지 확인할 수 있습니다. 물론 결과는 얼음이 아니지만 많은 신경을 절약 해줍니다.

또한 테스트 서버를 업데이트할 때마다 프로덕션 서버에서 복사본을 가져오기로 결정했습니다. 이것도 시간이 많이 걸립니다. 프로젝트를 보관하고 다른 서버로 전송한 후 압축을 풉니다. 이 모든 작업에는 몇 시간이 걸립니다. 그러나 새로운 개선 사항은 전투 상황에서 실제로 테스트되었습니다. 테스트 서버와 프로덕션 서버의 설정이 동일하면 작동 차이가 최소화되고 오류 수도 크게 줄어듭니다. 경험에 따르면 일주일 안에 프로덕션 서버가 너무 많이 변경되어 일주일 전 복사본에서는 문제 없이 작동했던 새로운 기능 중 일부가 새 복사본에서는 전혀 작동하지 않을 수 있습니다.

문제 #4 – “급하게 해주세요. 5분이면 됩니다.”

문제는 1C-Bitrix가 아니라 작업 프로젝트의 개선 및 지원과 관련이 있습니다. 종종 고객은 작은 일을 하고 싶어하지만 생산 현장에서는 긴급하고 즉각적으로 작업을 수행하고 싶어합니다. 결과는 항상 동일합니다. 좋은 결과가 나오지 않습니다. 최선의 경우 이 수정 사항은 다음 릴리스에서 잊어버리게 되며, 최악의 경우에는 서버가 단순히 충돌하여 몇 시간 동안 백업에서 복원해야 합니다.

나는 단 하나의 해결책을 찾았습니다. 신뢰성과 안전을 희생하면서 고객의 지시를 따르지 마십시오. 고객이 어떻게 질문하든 개발자의 책임은 항상 있습니다. 내 전 상사가 나에게 이렇게 말했습니다. “나는 당신에게 나쁜 일을 하라고 요구하지 않았습니다.”

그리고 백업 주제를 다루었으므로 주목하고 싶습니다. 1C-Bitrick을 사용한 백업은 물론 훌륭하고 편리하지만 매우 느립니다. 1~2개의 파일이나 데이터베이스의 여러 값을 긴급하게 복원해야 하는 경우 60GB가 모두 압축이 풀릴 때까지 기다려야 합니다. 다음 계획이 가장 효과적인 것 같습니다.

  • 아카이브 형식으로 파일과 데이터베이스를 매일 백업해야 합니다. 외부 소스데이터.
  • 우리는 항상 다음 두 가지 옵션 중 하나로 업데이트하기 직전에 백업을 만듭니다.
    1. 옵션 표시등 – 전체 프로젝트 폴더를 서버의 인접한 폴더에 복사합니다. 데이터베이스를 별도의 파일에 덤프로 저장합니다. 우리는 아무것도 보관하지 않습니다. 데이터베이스나 파일 중 하나의 일부 값을 복원해야 하는 경우 모든 것이 가까이 있고 쉽게 액세스할 수 있습니다.
    2. 강력한 옵션 - 이전 옵션과 유사하지만 데이터베이스를 다른 데이터베이스에 복사만 합니다. MySQL 데이터. 이렇게 하면 전체 충돌이 발생하는 경우 호스트 파일에 있는 사이트의 루트 폴더를 1~2분 안에 수정할 수 있으며 프로젝트는 데이터베이스 복사본이 있는 인접 폴더에서 작업을 시작합니다.

결론

끝까지 읽어주신 모든 분들께 감사드립니다. 내 경험이 당신에게 도움이 되기를 바랍니다. 댓글이나 개인 메시지를 통해 제기된 문제를 해결할 수 있는 더 나은 방법에 대한 제안을 받게 되어 기쁘게 생각합니다. 이제 저는 이미 시작된 프로젝트를 높은 신뢰성 요구 사항으로 마무리하고 지원하는 데 따른 주요 문제를 표명하려고 노력했습니다. 자료가 흥미로운 것으로 판명되면 Bitrix 사이트 개발과 다른 웹 프로젝트 개발을 구별하는 1C-Bitrix 아키텍처의 기능에 대해 계속해서 작성할 계획입니다.

협력에 대한 정보 튜토리얼과 문서에서 찾을 수 있습니다. 교육 과정은 작업 방법을 마스터하도록 설계되었습니다. 소프트웨어 제품및 문서 - CMS 사용자 정의 원칙을 익히기 위한 것입니다.

함께 일할 때 "1C-Bitrix: 사이트 관리"문제는 구체적인 실제 문제의 형태로 발생합니다. 전문적인 주제로 모아봤습니다 다른 페이지질문에 대한 답변을 더 쉽게 찾을 수 있도록 교육 과정을 제공합니다.
훈련 센터 질문하기 법정



서표 콘텐츠 관리자제품을 직접 사용하여 작업하는 사람, 즉 당사 소프트웨어 제품에서 생성된 프로젝트를 주도하는 콘텐츠 관리자를 위한 것입니다.

서표 관리자관리할 사람을 대상으로 함 "1C-Bitrix: 사이트 관리".

서표 개발자용다음을 기반으로 하는 프로젝트 개발자를 위해 설계되었습니다. "1C-Bitrix: 사이트 관리".

콘텐츠 관리자

강좌를 웹사이트로 가져올 수 있습니다. 콘텐츠 관리자이 아카이브에서. 시험문제 없는 강좌입니다.
2015년 6월 5일자 과정 버전입니다.

관리자

개발자용

개발자 문서는 시스템 API에 대한 설명입니다. 사용자 문서는 시스템 구성 요소 및 설정에 대한 설명입니다.

설명서는 온라인과 chm 형식의 파일로 모두 제공됩니다. 최신 버전인 온라인 버전을 사용하는 것이 좋습니다. chm 형식 파일은 주기적으로 업데이트되며 다음에 대한 정보가 포함되지 않을 수 있습니다. 최신 변경 사항도움말 시스템에서.

주목! 서식 파일의 내용이 보이지 않는 경우 .chm, 그 이유는 운영 체제의 보안 설정 때문입니다. 파일 속성에서 파일 보기 차단을 해제해야 합니다. 자세히 알아보기자주하는 질문

문서는 참조 정보입니다. 초보 개발자가 시스템을 사용하는 것만으로는 충분하지 않습니다. 프로그래밍의 원리를 익히는 과정에서 Bitrix 프레임워크특별 과정이 도움이 될 것입니다:

해당 카테고리의 인기 항목:
컴퓨터에서 노래방 ​​클립을 만드는 방법은 무엇입니까?
컴퓨터에서 노래방 ​​클립을 만드는 방법은 무엇입니까?
읽다
게임을 이용하려면 Origin 앱이 필요하지만 설치되어 있지 않습니다.FIFA 16에는 Origin이 필요합니다.
플레이하려면 Origin 앱이 필요하지만 FIFA가 설치되어 있지 않습니다...
읽다
소셜 네트워크 Facebook에 개인 페이지 등록
소셜 네트워크 Facebook에 개인 페이지 등록
읽다
간단한 Nmap Nmap 스캔을 실행하는 방법
간단한 Nmap Nmap 스캔을 실행하는 방법
읽다

최신 기사
이미지를 몇도 회전시키는 방법...
읽다
Yandex 브라우저에서 광고를 비활성화하는 방법...
읽다
Wi-Fi 연결 문제 해결...
읽다
Windows 10 프로필의 비밀번호 변경
읽다
무선 라우터 설정 지침...
읽다
하드 드라이브를 선택하는 방법과 어떤 드라이브를 구입하는 것이 더 좋은가요?
읽다
인형을 위한 메이주. 전화와 주소록....
읽다
PDFMaster 프로그램 다운로드
읽다
맨 위