1C 웹 클라이언트 정보

1C:Enterprise 기술의 좋은 기능 중 하나는 관리형 양식 기술을 사용하여 개발된 애플리케이션 솔루션이 Windows, Linux, MacOS X용 씬(실행 가능) 클라이언트와 5개 브라우저용 웹 클라이언트 모두에서 실행될 수 있다는 것입니다. Chrome, Internet Explorer, Firefox, Safari, Edge 등 애플리케이션 소스 코드를 변경하지 않고도 이 모든 기능을 사용할 수 있습니다. 또한 외부적으로 씬 클라이언트와 브라우저의 애플리케이션은 기능과 모양이 거의 동일합니다.
10가지 차이점 찾기(컷 아래 사진 2장):

Linux의 씬 클라이언트 창:

웹 클라이언트의 동일한 창(Chrome 브라우저):

우리는 왜 웹 클라이언트를 만들었나요? 다소 한심하게 말하면 시간이 우리에게 그러한 과제를 설정했습니다. 인터넷을 통한 작업은 오랫동안 비즈니스 애플리케이션의 전제 조건이었습니다. 첫째, 우리는 씬 클라이언트에 인터넷을 통해 작업할 수 있는 기능을 추가했습니다(그런데 경쟁사 중 일부는 거기서 멈췄고, 반대로 다른 일부는 씬 클라이언트를 포기하고 웹 클라이언트 구현으로 제한했습니다). 우리는 사용자에게 가장 적합한 클라이언트 옵션을 선택할 수 있는 기회를 제공하기로 결정했습니다.

씬 클라이언트에 웹 기반 기능을 추가하는 것은 클라이언트-서버 아키텍처가 완전히 변경된 대규모 프로젝트였습니다. 웹 클라이언트를 만드는 것은 처음부터 시작하는 완전히 새로운 프로젝트입니다.

문제 성명

따라서 프로젝트 요구 사항: 웹 클라이언트는 씬 클라이언트와 동일하게 수행해야 합니다. 즉,

1. 사용자 인터페이스 표시
2. 1C 언어로 작성된 클라이언트 코드 실행

1C의 사용자 인터페이스는 시각적 편집기에서 설명되지만 선언적으로는 요소의 픽셀 단위 배열이 없습니다. 버튼, 입력 필드(텍스트, 숫자, 날짜/시간), 목록, 표, 그래프 등 약 XNUMX가지 유형의 인터페이스 요소가 사용됩니다.

1C 언어의 클라이언트 코드에는 서버 호출, 로컬 리소스(파일 등) 작업, 인쇄 등이 포함될 수 있습니다.

씬 클라이언트(웹을 통해 작업할 때)와 웹 클라이언트는 모두 동일한 웹 서비스 세트를 사용하여 1C 애플리케이션 서버와 통신합니다. 물론 클라이언트 구현은 다릅니다. 씬 클라이언트는 C++로 작성되고 웹 클라이언트는 JavaScript로 작성됩니다.

역사의 비트

웹 클라이언트 프로젝트는 2006년 평균 5명의 팀으로 시작되었습니다. 프로젝트의 특정 단계에서는 특정 기능(스프레드시트 문서, 다이어그램 등)을 구현하기 위해 개발자가 참여했습니다. 일반적으로 이들은 씬 클라이언트에서 이 기능을 수행한 개발자와 동일했습니다. 저것들. 개발자는 이전에 C++로 만든 구성 요소를 JavaScript로 다시 작성했습니다.

처음부터 우리는 두 언어 간의 강력한 개념적 차이로 인해 C++ 씬 클라이언트 코드를 JavaScript 웹 클라이언트로 자동(부분적이라도) ​​변환한다는 아이디어를 거부했습니다. 웹 클라이언트는 처음부터 JavaScript로 작성되었습니다.

프로젝트의 첫 번째 반복에서 웹 클라이언트는 내장된 1C 언어의 클라이언트 코드를 JavaScript로 직접 변환했습니다. 씬 클라이언트는 다르게 작동합니다. 내장된 1C 언어의 코드가 바이트코드로 컴파일된 다음 이 바이트코드가 클라이언트에서 해석됩니다. 그 후 웹 클라이언트도 동일한 작업을 수행하기 시작했습니다. 첫째, 성능이 향상되었고, 둘째, 씬 클라이언트와 웹 클라이언트의 아키텍처를 통합할 수 있게 되었습니다.

웹 클라이언트를 지원하는 1C:Enterprise 플랫폼의 첫 번째 버전은 2009년에 출시되었습니다. 당시 웹 클라이언트는 Internet Explorer와 Firefox라는 두 가지 브라우저를 지원했습니다. 원래 계획에는 Opera에 대한 지원이 포함되어 있었지만 당시 Opera의 애플리케이션 종료 처리기와 관련된 극복할 수 없는 문제로 인해(애플리케이션이 종료되고 있다는 것을 2% 확실하게 추적하는 것은 불가능했으며 그 순간에 연결 해제 절차를 수행했습니다. 100C 애플리케이션 서버)는 이러한 계획에서 폐기되어야 했습니다.

프로젝트 구조

전체적으로 1C:Enterprise 플랫폼에는 JavaScript로 작성된 4개의 프로젝트가 있습니다.

1. WebTools – 다른 프로젝트에서 사용되는 공유 라이브러리(또한 다음을 포함합니다) Google 클로저 라이브러리).
2. 제어 요소 서식이 지정된 문서 (씬 클라이언트와 웹 클라이언트 모두에서 JavaScript로 구현됨)
3. 제어 요소 스케줄러 (씬 클라이언트와 웹 클라이언트 모두에서 JavaScript로 구현됨)
4. 웹 클라이언트

각 프로젝트의 구조는 Java 프로젝트(또는 .NET 프로젝트 중 더 가까운 프로젝트)의 구조와 유사합니다. 네임스페이스가 있고 각 네임스페이스는 별도의 폴더에 있습니다. 폴더 안에는 파일과 네임스페이스 클래스가 있습니다. 웹 클라이언트 프로젝트에는 약 1000개의 파일이 있습니다.

구조적으로 웹 클라이언트는 크게 다음 하위 시스템으로 나뉩니다.

• 관리형 클라이언트 애플리케이션 인터페이스
  • 일반 애플리케이션 인터페이스(시스템 메뉴, 패널)
  • 약 30개의 컨트롤(버튼, 다양한 유형의 입력 필드 - 텍스트, 숫자, 날짜/시간 등, 테이블, 목록, 그래프 등)을 포함한 관리되는 양식의 인터페이스

• 클라이언트에서 개발자가 사용할 수 있는 개체 모델(총 400개 이상의 유형: 관리형 인터페이스 개체 모델, 데이터 레이아웃 설정, 조건부 스타일 지정 등)
• 내장 1C 언어 통역사
• 브라우저 확장(JavaScript에서 지원되지 않는 기능에 사용됨)
  • 암호화 작업
  • 파일 작업
  • 씬 클라이언트와 웹 클라이언트 모두에서 사용할 수 있는 외부 구성 요소 기술

개발 기능

위의 모든 것을 JavaScript로 구현하는 것은 쉽지 않습니다. 아마도 1C 웹 클라이언트는 약 450.000줄에 달하는 JavaScript로 작성된 가장 큰 클라이언트 측 애플리케이션 중 하나일 것입니다. 우리는 웹 클라이언트 코드에서 객체 지향 접근 방식을 적극적으로 사용하여 이러한 대규모 프로젝트 작업을 단순화합니다.

클라이언트 코드의 크기를 최소화하기 위해 먼저 자체 Obfuscator를 사용했으며, 플랫폼 버전 8.3.6(2014년 XNUMX월)부터 사용하기 시작했습니다. Google 클로저 컴파일러. 숫자로 표현된 사용 효과 – 난독화 후 웹 클라이언트 프레임워크의 크기:

• 자체 난독 처리기 – 1556kb
• Google 클로저 컴파일러 – 1073kb

Google Closure Compiler를 사용하면 자체 난독처리기에 비해 웹 클라이언트 성능이 30% 향상되는 데 도움이 되었습니다. 또한, 애플리케이션이 소비하는 메모리 양이 15~25% 감소했습니다(브라우저에 따라 다름).

Google Closure Compiler는 객체 지향 코드와 매우 잘 작동하므로 웹 클라이언트의 효율성이 최대한 높습니다. 클로저 컴파일러는 우리에게 몇 가지 좋은 일을 해 줍니다:

• 프로젝트 빌드 단계에서 정적 유형 검사(JSDoc 주석으로 코드를 포함하는지 확인) 그 결과 정적 타이핑이 이루어지며 C++의 타이핑 수준과 매우 유사합니다. 이는 프로젝트 컴파일 단계에서 상당히 많은 비율의 오류를 잡는 데 도움이 됩니다.
• 난독화를 통해 코드 크기 줄이기
• 예를 들어 다음과 같이 실행된 코드의 다양한 최적화가 이루어졌습니다.
  • 인라인 함수 대체. JavaScript에서 함수를 호출하는 것은 상당히 비용이 많이 드는 작업이며 자주 사용되는 작은 메서드를 인라인으로 대체하면 코드 속도가 크게 향상됩니다.
  • 컴파일 타임에 상수를 계산합니다. 표현식이 상수에 의존하는 경우 상수의 실제 값이 해당 표현식으로 대체됩니다.

우리는 웹 클라이언트 개발 환경으로 WebStorm을 사용합니다.

코드 분석을 위해 우리는 소나큐브, 정적 코드 분석기를 통합합니다. 분석기를 사용하여 JavaScript 소스 코드의 품질 저하를 모니터링하고 이를 방지하려고 노력합니다.

우리는 어떤 문제를 해결했거나 해결하고 있나요?

프로젝트를 실행하는 동안 우리는 해결해야 할 여러 가지 흥미로운 문제에 직면했습니다.

서버와 창간 데이터 교환

소스 코드의 난독화가 시스템 작동을 방해할 수 있는 상황이 있습니다. 난독화로 인해 웹 클라이언트 실행 코드 외부의 코드에는 실행 코드에서 예상하는 것과 다른 함수 및 매개변수 이름이 있을 수 있습니다. 우리의 외부 코드는 다음과 같습니다.

• 데이터 구조 형태로 서버에서 오는 코드
• 다른 응용 프로그램 창에 대한 코드

서버와 상호작용할 때 난독화를 방지하기 위해 @expose 태그를 사용합니다.

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

그리고 다른 창과 상호 작용할 때 난독화를 피하기 위해 소위 내보낸 인터페이스(모든 메서드를 내보내는 인터페이스)를 사용합니다.

/**
 * Экспортируемый интерфейс контрола DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 * Перемещает выделение на 1 вперед или назад
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 * Перемещает выделение в начало или конец
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

우리는 Virtual DOM이 주류가 되기 전에 사용했습니다)

복잡한 웹 UI를 다루는 모든 개발자와 마찬가지로 우리는 DOM이 동적 사용자 인터페이스 작업에 적합하지 않다는 것을 빨리 깨달았습니다. 거의 즉시 UI 작업을 최적화하기 위해 Virtual DOM의 아날로그가 구현되었습니다. 이벤트 처리 중에 모든 DOM 변경 사항은 메모리에 저장되며, 모든 작업이 완료되어야 누적된 변경 사항이 DOM 트리에 적용됩니다.

웹 클라이언트 최적화

웹 클라이언트가 더 빠르게 작동하도록 하기 위해 표준 브라우저 기능(CSS 등)을 최대한 사용하려고 노력합니다. 따라서 양식 명령 패널(응용 프로그램의 거의 모든 양식에 위치)은 CSS 기반의 동적 레이아웃을 사용하여 브라우저 도구를 통해서만 렌더링됩니다.

테스트

기능 및 성능 테스트를 위해 우리는 독점 도구(Java 및 C++로 작성)와 이를 기반으로 구축된 테스트 제품군을 사용합니다. 셀레니움.

우리의 도구는 보편적입니다. 거의 모든 창 프로그램을 테스트할 수 있으므로 씬 클라이언트와 웹 클라이언트를 모두 테스트하는 데 적합합니다. 이 도구는 1C 애플리케이션 솔루션을 시작한 사용자의 작업을 스크립트 파일에 기록합니다. 동시에 화면 작업 영역의 이미지(표준)가 기록됩니다. 새 버전의 웹 클라이언트를 모니터링할 때 사용자 참여 없이 스크립트가 재생됩니다. 어떤 단계에서든 스크린샷이 참조 항목과 일치하지 않는 경우 테스트는 실패한 것으로 간주되며, 그 후 품질 전문가가 조사를 수행하여 이것이 오류인지 아니면 시스템 동작의 계획된 변경인지 확인합니다. 계획된 동작의 경우 표준이 자동으로 새로운 표준으로 대체됩니다.

또한 이 도구는 최대 25밀리초의 정확도로 애플리케이션 성능을 측정합니다. 어떤 경우에는 스크립트의 일부를 반복하여(예: 주문 입력을 여러 번 반복) 시간에 따른 실행 시간 저하를 분석합니다. 모든 측정 결과는 분석을 위해 로그에 기록됩니다.

테스트 중인 테스트 도구 및 애플리케이션

우리 도구와 Selenium은 서로를 보완합니다. 예를 들어, 화면 중 하나에 있는 일부 버튼의 위치가 변경된 경우 Selenium은 이를 추적하지 못할 수 있지만 우리 도구는 이를 알아차릴 것입니다. 스크린샷과 표준을 픽셀별로 비교합니다. 이 도구는 키보드나 마우스의 입력 처리와 관련된 문제도 추적할 수 있습니다. 이것이 정확히 재현되는 것이기 때문입니다.

두 도구(당사 및 Selenium)에 대한 테스트는 당사 애플리케이션 솔루션의 일반적인 작업 시나리오를 실행합니다. 테스트는 1C:Enterprise 플랫폼의 일일 빌드 후 자동으로 시작됩니다. 이전 빌드와 비교하여 스크립트가 느린 경우 속도 저하의 원인을 조사하고 해결합니다. 우리의 기준은 간단합니다. 새 빌드는 이전 빌드보다 느리게 작동해서는 안 됩니다.

개발자는 속도 저하 사고를 조사하기 위해 다양한 도구를 사용합니다. 주로 사용 다이나트레이스 AJAX 에디션 제조업 회사 DynaTrace. 이전 빌드와 새 빌드에서 문제가 있는 작업을 실행한 로그가 기록된 후 로그가 분석됩니다. 동시에 단일 작업의 실행 시간(밀리초 단위)은 결정적인 요소가 아닐 수 있습니다. 가비지 수집과 같은 서비스 프로세스는 브라우저에서 주기적으로 시작되며 기능 실행 시간과 겹쳐서 그림을 왜곡할 수 있습니다. 이 경우 더 관련성이 높은 매개변수는 실행된 JavaScript 명령어 수, DOM의 원자적 작업 수 등입니다. 새 버전에서 동일한 스크립트의 명령/작업 수가 증가한 경우 이는 거의 항상 수정이 필요한 성능 저하를 의미합니다.

또한 성능 저하의 원인 중 하나는 Google Closure Compiler가 어떤 이유로 함수의 인라인 대체를 수행할 수 없기 때문일 수 있습니다(예: 함수가 재귀적이거나 가상이기 때문에). 이런 경우에는 소스 코드를 다시 작성하여 상황을 수정하려고 합니다.

브라우저 확장

애플리케이션 솔루션에 JavaScript에서 사용할 수 없는 기능이 필요한 경우 브라우저 확장을 사용합니다.

• 파일 작업
• 암호화 작업을 위해
• 작업 외부 구성요소

우리의 확장은 두 부분으로 구성됩니다. 첫 번째 부분은 브라우저 확장(일반적으로 JavaScript로 작성된 Chrome 및 Firefox용 확장)으로, 두 번째 부분(필요한 기능을 구현하는 바이너리 확장)과 상호 작용합니다. 우리는 Windows, Linux 및 MacOS용 3가지 버전의 바이너리 확장을 작성한다는 점을 언급해야 합니다. 바이너리 확장은 1C:Enterprise 플랫폼의 일부로 제공되며 1C 애플리케이션 서버에 있습니다. 웹 클라이언트에서 처음 호출되면 클라이언트 컴퓨터로 다운로드되어 브라우저에 설치됩니다.

Safari에서 실행될 때 확장 기능은 NPAPI를 사용하고, Internet Explorer에서 실행될 때 ActiveX 기술을 사용합니다. 마이크로 소프트 에지 아직 확장 기능을 지원하지 않으므로 해당 기능의 웹 클라이언트는 제한적으로 작동합니다.

추가 개발

웹 클라이언트 개발팀의 업무 중 하나는 기능을 추가로 개발하는 것입니다. 웹 클라이언트의 기능은 씬 클라이언트의 기능과 동일해야 하며 모든 새로운 기능은 씬 클라이언트와 웹 클라이언트 모두에서 동시에 구현됩니다.

다른 작업에는 아키텍처 개발, 리팩토링, 성능 및 안정성 향상이 포함됩니다. 예를 들어, 방향 중 하나는 비동기식 작업 모델을 향한 추가 이동입니다. 웹 클라이언트의 일부 기능은 현재 서버와의 동기식 상호 작용 모델을 기반으로 구축되었습니다. 비동기 모델은 이제 브라우저(브라우저뿐만 아니라)에서 더욱 관련성이 높아지고 있으며 이로 인해 동기 호출을 비동기 호출로 대체하고 이에 따라 코드를 리팩터링하여 웹 클라이언트를 수정해야 합니다. 비동기식 모델로의 점진적인 전환은 출시된 솔루션과 점진적인 적응을 지원해야 하는 필요성으로 설명됩니다.

출처 : habr.com