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

Bitrix24의 박스형 버전에 대한 문서. 설치 마법사 완료

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

에 이 순간이전 커널의 모든 기능이 D7에서 복제되는 것은 아닙니다. 그러나 새로운 D7 코어 비트릭스 프레임워크점차 오래된 것을 대체합니다. 이전 커널을 사용하면 IDE: Method/class is deprecated 경고가 표시되면 .

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

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


엔티티 버전

비트릭스 프레임워크끊임없이 진화합니다. 새로운 기능이 나타나고 일부는 더 이상 사용되지 않으며 새로운 매개변수가 기능에 나타납니다. 그러나 상당히 많은 수의 프로젝트가 업데이트되지 않습니다. 프로그래머의 작업을 용이하게 하기 위해 문서는 클래스, 메소드, 매개변수, 이벤트가 존재하는(존재하는) 제품의 어떤 버전에서 어떤 버전에 대한 것인지를 나타냅니다.

버전은 제목과 표의 두 위치에 첨부됩니다. 방법이 유효한 경우 제목에는 제품에 표시된 버전 번호만 포함됩니다. 방법이 오래된 경우 유효한 버전 범위가 거기에 표시됩니다.

테이블은 엔티티가 클래스 자체의 출현 순간, 메소드 등과 일치하지 않는 경우에만 엔티티가 제품에 나타난 버전을 나타냅니다. 아래 그림에서 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
logger.php
클라이언트.php
RCrmActions.php
RetailCrmUser.php
RetailCrmICML.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단계. 사이트에서 1C-Bitrix의 상점과 시스템 간의 통신을 설정해야 합니다.

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

설치 마법사. 2 단계

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

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

그런 다음 마법사 페이지를 새로 고칩니다. 새 참조 값을 로드해야 합니다.

설치 마법사. 3단계

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

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

또한 함께 작업하는 경우 법인, 아래 스크린샷에 표시된 대로 모든 필드를 채워야 합니다.

설치 마법사. 4단계

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

필요한 경우 업로드를 일시 중지하고 잠시 후 다시 재개할 수 있습니다.

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

설치 마법사. 5단계

다섯 번째 단계에서는 제품 카탈로그 언로드가 구성됩니다. 이렇게 하려면 아래 단계를 따르십시오.

1. 인포블록 및 속성 선택

선택한 정보 블록이 시스템에 업로드됩니다. 상품을 포함하거나 정보 블록을 거래 제안과 연결한 정보 블록만 선택할 수 있습니다. infoblock 선택과 동시에 기사, 제조업체, 색상, 무게, 크기 속성을 선택할 수 있습니다. 이렇게 하려면 해당 속성 저장을 담당하는 infoblock 속성을 지정해야 합니다. 속성 선택은 선택 사항입니다.

2. 파일 경로

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

3. 내보내기에서 오퍼 수 설정

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

4. 언로드 빈도 선택

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

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

이 옵션은 온라인 상점 제품 카탈로그가 매우 드물게 변경되거나 나중에 업로드 설정을 조정하려는 경우에 유용할 수 있습니다.

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

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

이 항목의 선택은 카탈로그에 매우 큰 명명법이 포함된 경우 유용할 수 있습니다( 10,000개 이상의 제품). 이 항목의 경우 사용자 지정 내보내기 프로필의 이름을 지정해야 합니다.

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

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

이 옵션은 디렉토리에 다음이 포함된 경우 가장 선호됩니다. 10,000개 미만의 항목, 업로드가 매우 빠르며 이는 온라인 상점 웹 사이트의 속도에 영향을 미치지 않습니다.

큰 명명법의 경우( 10,000개 이상의 제품), Cron에 Agent 추가 설정이 필요합니다. 이 항목의 경우 사용자 지정 내보내기 프로필의 이름도 지정해야 합니다.

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 지원.
  • 창고와 관련하여 잔여물을 내리는 기능을 추가했습니다.
  • 가격 유형을 다운로드하는 기능을 추가했습니다.
  • 기본 Daemon Collector 통합이 추가되었습니다.
  • 유니버설 애널리틱스와의 통합이 추가되었습니다.
  • 데이터 수정을 위한 기본 제공 함수의 논리가 개선되었습니다.
  • 기본 제공 retailCrmApiResult 기능이 추가되었습니다.
  • 변경 내역의 트리거 버전을 추가했습니다.

버전 2.4

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

다른 설정

주문 설정

CRM에서 생성된 주문 수를 매장에 브로드캐스트

시스템에서 주문을 생성할 때 지정된 규칙에 따라 고유 번호가 있습니다. 모듈에서 이 설정을 설정하면 역동기화 중에 이러한 주문 번호가 상점으로 전송됩니다.

주문 내리기

  • 이벤트별- 주문을 저장하면 데이터가 시스템으로 들어갑니다.
  • 에이전트- 시스템에서 변경 내역을 요청하기 전에 새 주문이 전송됩니다.

클라이언트 API 버전

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

창고 맥락에서 잔고 하역 활성화(창고가 있는 경우 사용 가능)

이제 사이트 창고에서 시스템 창고로 잔여물을 주기적으로 언로드할 수 있습니다. 이를 위해서는 다음이 필요합니다.

  • 사이트의 창고와 시스템의 창고를 비교합니다.
  • 저울이 로드될 시스템의 저장소를 지정합니다.
  • 남은 음식을 로드하는 데 필요한 상품이 있는 정보 블록을 선택합니다(시스템의 카탈로그 내보내기에 지정된 상품을 선택해야 함).

언로드는 에이전트가 1시간 간격(기본값)으로 수행합니다.

남은 음식을 시스템에 업로드하려면 옵션을 활성화해야 합니다.

제품에 대한 가격 유형 업로드 활성화(여러 가격 유형이 있는 경우에만 사용 가능)

이제 상점에서 시스템으로 추가 유형의 가격을 주기적으로 업로드할 수 있습니다. 이를 위해서는 다음이 필요합니다.

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

언로드는 24시간(기본값)의 빈도로 에이전트에 의해 수행됩니다.

데몬 수집기 활성화

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

UA 통합 활성화

이제 설정 인터페이스에서 유니버설 애널리틱스와의 통합을 활성화할 수 있습니다(표준 체크아웃 구성 요소와 올바르게 작동). 추적을 추가하려는 각 사이트에 대해 추적 ID와 맞춤 측정기준 색인을 입력해야 합니다.

여기서 $order는 시스템에 보낼 주문 데이터의 배열이고 $arFields는 사이트의 주문 필드 배열입니다. function retailCrmBeforeOrderSave($order) ( //귀하의 변경 사항은 $order를 반환합니다. //또는 false를 반환합니다. 그러면 이 주문에 대한 시스템의 변경 사항이 무시됩니다. )

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

retailCrmAfterOrderSave 기능

retailCrmAfterOrderSave - 시스템 기록에서 가져온 주문 데이터의 사이트 변경 사항을 저장한 후 즉시 실행되는 기능입니다.

function retailCrmAfterOrderSave($order) ( //귀하의 변경 사항이 반환됩니다. )

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

retailCrmApiResult 함수

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

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

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

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

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


서표 사용자 지정 작업제품을 직접 사용하는 사람, 즉 당사 소프트웨어 제품을 사용하는 회사의 직원을 대상으로 합니다.

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

서표 선적 서류 비치박스형 버전을 기반으로 하는 프로젝트 개발자를 위해 설계됨 비트릭스24.

사용자 지정 작업

관리자 작업

개발자

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

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

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

설명서는 참조 정보입니다. 초보 개발자가 시스템으로 작업하는 것만으로는 충분하지 않습니다. 프로그래밍의 원리를 마스터하는 데 있어 비트릭스 프레임워크특별 과정이 도움이 될 것입니다:

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

초기 데이터:

  • 1C-Bitrix에 온라인 상점이 있습니다.
  • 이 프로젝트는 몇 년 전이지만 불과 몇 달 전에 사이트가 1C-Bitrix로 이전되었습니다.
  • 하루에 10-15,000명 참석
  • 매장 카탈로그에는 약 12,000개의 상품이 포함되어 있습니다.
  • 사이트 다운타임 및 정전은 용납할 수 없습니다.
  • 이 프로젝트는 다른 회사에서 6개월 동안 개발했습니다.
    1. 약 40%가 수행한 작업에 해당하는 100장 정도의 TOR이 있습니다.
    2. 프로젝트 문서 없음
    3. 이전 개발자가 이러한 아키텍처 솔루션을 사용한 이유에 대한 이해 부족.

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

우선 접근권을 받았습니다 소스 코드프로젝트. 피상적으로 분석했습니다. 고객과 우선 순위 작업 목록에 동의했습니다. 3명의 개발자를 위한 개발 계획을 세웠고 가가린이 말했듯이 가자!

문제 번호 1 - 개발자 책임

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

누가 잘못이고 누가 옳다는 것은 우리가 판단할 일이 아닙니다. 이 경우 이전 계약자는 상당히 잘 알려진 신뢰할 수있는 회사였으며 그들의 개발에 대해 나쁜 말을 할 수 없습니다. 그리고 고객은 객관적으로 자신의 제품에 대해 걱정하고 개선하려고 노력합니다. 어땠는지 모르겠지만 계약자가 고객에게 제공하는 분석 양이 충분하지 않다는 설명을 찾았습니다.

결과적으로:

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

문제에 대한 해결책은 하나뿐입니다. 사이트의 모든 모듈을 차례로 체계적으로 정리하여 제품을 필요한 상태로 만듭니다. 일부 오류는 별도의 작업으로 이동되어 즉시 실행되었으며, 새로운 기능 개발과 동시에 수정되었습니다. 그 결과, 업데이트가 있을 때마다 발생한 버그를 효과적으로 제거한 후 사이트가 더 좋아지고 더 안정적으로 변하고 있습니다.

문제 #2는 병렬 개발입니다.

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

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

라이센스는 어떻습니까? 1C-Bitrix 기술 지원에 연락했습니다. 추가 구매 제안을 받았습니다. 개발 라이센스. 가볍게 말하면 행복하지 않았지만 다른 제안을받지 못했습니다. 나는 탈출구를 꽤 빨리 찾았습니다. NFR 키를 사용하기로 결정했습니다. 다행히 파트너 상태가 허용됩니다. 결과적으로 온라인 상점 설치를 5개 만들었습니다.

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

시간이 지남에 따라 그는 더 나아갔습니다. 테스터를 위한 별도의 설치도 있었습니다. 운 좋게도 고객은 항상 무언가가 업데이트되는 순간에 테스트 서버에 들어갑니다. 버그 트랙에는 이미 완료된 불필요한 작업이 많고 고객은 우리가 일을 잘하고 있지 않다는 인상을 받습니다.

현재 다음 스키마를 사용하고 있습니다.

  • 각 개발자는 업무용으로 로컬 사본만 사용합니다.
  • 합의된 시간에 완료된 모든 개선 사항은 리포지토리의 공통 분기로 병합됩니다.
  • QA는 테스트를 위해 "번짐" 버전을 선택합니다.
  • 테스트 및 버그 수정 후 고객을 위해 데모 서버가 업데이트됩니다.
  • 고객의 확인 및 수락 후 개선 사항은 전투 서버로 전송됩니다.

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

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

문제 #3 – 프로덕션 서버 업그레이드 및 고객과의 협업

문제는 가장 중요하고 복잡하며 결국 해결되지 않습니다. 결국 나머지 문제가 프로젝트의 내부 주방과 관련이 있다면 고객의 명성과 수입, 결과적으로 내 수입은 사이트 작업에 달려 있습니다.

여기서 머피의 법칙이 작용합니다.

  • 테스트 서버에서 뭔가 잘 안되면 프로덕션 서버에서는 반드시 망가집니다.
  • 어떤 것이 테스트 서버에서 잘 작동한다면 어쨌든 프로덕션 서버에서는 확실히 중단될 것입니다.
  • 사이트에 버그가 5초만 존재하면 방문자 중 한 명이 반드시 버그를 찾아 리뷰나 피드백 형식으로 작성합니다.
  • 업데이트 중 사이트가 1분 동안 작동하지 않으면 이 순간 회사 소유자가 친구나 경쟁자에게 사이트를 보여줄 것입니다(업데이트 시간 및 절차 조정에도 불구하고).
물론 과장이지만 모든 농담에는 농담이 있습니다. 사이트의 최소 부하는 아침 4시에서 6시입니다. 물론 이때 업데이트하면 더 좋겠지만 별로 하고 싶지는 않다.

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

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

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

아직 좋은 해결책을 찾지 못했습니다. 이제 데이터베이스의 설정을 수동으로 업데이트합니다. 오류를 최소화하기 위해 업데이트 중에 수행해야 할 작업 목록이 포함된 체크리스트가 컴파일됩니다. 최대한 신중하고 정확하게 업데이트하려고 노력합니다. 업데이트 후 전체 팀은 프로덕션 서버의 주요 기능을 확인하고 추가 테스트를 수행합니다. 오류의 수는 최소화되었지만 업데이트 중 버그 및 중단 시간은 아직 완전히 제거되지 않았습니다.

두 번째로 만난 것은 팀워크고객과 함께. 왜냐하면 프로젝트 규모가 크고 약 30명이 지속적으로 작업하고 있습니다. 콘텐츠 관리자, 영업 관리자, SEO 최적화 도구, 마케터 등. 당연히 모든 사람이 사이트 페이지와 모듈 설정을 약간 변경합니다. 첫 번째 결정은 사이트의 프로그램 코드를 변경할 수 있는 고객의 권리를 박탈하는 것이었습니다. 결정은 절대적으로 옳았지만 상황은 더욱 악화되었습니다. 이전에 고객이 사이트에 가서 실수로 무언가를 깨뜨릴 수 있다고 가정했다면 이제 모든 충돌이 우리에게만 떨어지기 시작했습니다. 무엇에. 콘텐츠 관리자가 페이지의 텍스트를 비뚤게 편집하고 일부 태그를 닫지 않았더라도 개발자는 여전히 책임이 있습니다. 해결책은 매우 간단하다는 것이 밝혀졌습니다. 마켓플레이스에는 무료 페이지 버전 제어 모듈이 있습니다. 이것은 문제를 제거하지 못했습니다. 모두 똑같이 누군가가 때때로 무언가를 할 것이지만 이제 누가 변경했는지, 무엇이 변경되었는지, 왜 모든 것이 고장 났는지 언제든지 볼 수 있습니다. 물론 결과는 얼음이 아니지만 많은 신경을 구해줍니다.

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

문제 번호 4 - "급하게 해주세요. 5분 동안 할 일입니다."

문제는 1C-Bitrix와 그다지 관련이 없지만 기존 프로젝트의 개선 및 지원과 관련이 있습니다. 종종 고객은 작은 것을 만들고 싶어하지만 긴급하고 즉시 전투 현장에 있습니다. 결과는 항상 동일합니다. 좋은 결과는 없습니다. 최선의 경우 이 개선 사항은 다음 릴리스에서 잊어버리고 최악의 경우 서버가 다운되어 백업에서 복원하는 데 몇 시간이 걸립니다.

나는 단 하나의 해결책을 찾았습니다. 신뢰성과 안전을 해치는 고객의 리드를 절대 따르지 마십시오. 고객이 어떻게 요청하든 항상 책임은 개발자에게 있습니다. 이전 상사가 나에게 말했듯이 "나는 당신에게 나쁜 일을 요구하지 않았습니다."

백업 주제를 다루었으므로 주목하고 싶습니다. 1C-Bitrik을 사용한 백업은 확실히 훌륭하고 편리하지만 매우 느립니다. 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, 그 이유는 운영 체제의 보안 설정 때문입니다. 파일 속성에서 파일 보기 차단을 해제해야 합니다. 더 읽어보기자주하는 질문.

설명서는 참조 정보입니다. 초보 개발자가 시스템으로 작업하는 것만으로는 충분하지 않습니다. 프로그래밍의 원리를 마스터하는 데 있어 비트릭스 프레임워크특별 과정이 도움이 될 것입니다:

인기 카테고리:
생성기로서의 사운드 카드
생성기로서의 사운드 카드
읽다
해야 할 일
"개체 필드를 찾을 수 없음"인 경우 수행할 작업
읽다
Windows 7 Ultimate 시스템 요구 사항
Windows 7 Ultimate 시스템 요구 사항
읽다
Samsung Galaxy Grand Prime: 리뷰, 사양 및 리뷰
Samsung Galaxy Grand Prime: 검토, 사양 및...
읽다

최신 기사
Huawei HiSuite는 동기화를 위한 프로그램입니다...
읽다
다음과 같은 경우 애플리케이션을 자동으로 실행하는 방법...
읽다
쓰레기에서 디스크를 청소하는 방법
읽다
AMD Radeon 드라이버 설치/업데이트 -...
읽다
클라우드 제너레이터 렌탈, 플라잉 로고...
읽다
메모리 카드에서 데이터를 복구하는 절차
읽다
재설치 후 활성화
읽다
체스 프로그램 분쇄기
읽다
맨 위