1C Web クライアントについて

1C:Enterpriseテクノロジーの優れた機能の1つは、マネージドフォームテクノロジーを使用して開発されたアプリケーションソリューションを、シンクライアント（実行可能クライアント）でも実行できることです。 Windows, Linuxアプリケーションのソースコードを変更することなく、MacOS X、およびChrome、Internet Explorer、Firefox、Safari、Edgeの5つのブラウザに対応したWebクライアントとして動作させることができます。さらに、アプリケーションの機能と外観は、シンクライアントとブラウザの両方でほぼ同じです。
10 個の違いを見つけます (カットの下に 2 枚の写真):

シンクライアントウィンドウ Linux:

Web クライアント (Chrome ブラウザー) の同じウィンドウ:

なぜ Web クライアントを作成したのでしょうか? やや情けない言い方をすれば、時間が私たちにそのような課題を課したのです。 インターネット上での作業は、長い間、ビジネス アプリケーションの前提条件でした。 まず、シン クライアントにインターネット経由で動作する機能を追加しました (ちなみに、競合他社の一部はこれでやめましたが、他の競合他社は逆にシン クライアントを放棄し、Web クライアントの実装に限定しました)。 私たちは、ユーザーに最適なクライアント オプションを選択する機会を提供することにしました。

シン クライアントに Web ベースの機能を追加することは、クライアント/サーバー アーキテクチャを完全に変更する大規模なプロジェクトでした。 Web クライアントの作成は、ゼロから始めるまったく新しいプロジェクトです。

問題の定式化

したがって、プロジェクトの要件は次のとおりです。Web クライアントはシン クライアントと同じことを実行する必要があります。つまり、次のとおりです。

1. ユーザーインターフェースを表示する
2. 1C言語で書かれたクライアントコードを実行する

1C のユーザー インターフェイスはビジュアル エディターで記述されていますが、要素をピクセルごとに配置することなく宣言的に記述されています。 ボタン、入力フィールド (テキスト、数値、日付/時刻)、リスト、表、グラフなど、約 XNUMX 種類のインターフェイス要素が使用されます。

1C 言語のクライアント コードには、サーバー呼び出し、ローカル リソース (ファイルなど) の操作、印刷などを含めることができます。

シン クライアント (Web 経由で作業する場合) と Web クライアントは両方とも、同じ Web サービス セットを使用して 1C アプリケーション サーバーと通信します。 もちろん、クライアントの実装は異なります。シン クライアントは C++ で記述され、Web クライアントは JavaScript で記述されます。

歴史を少し

Web クライアント プロジェクトは 2006 年に (平均) 5 人のチームで始まりました。 プロジェクトの特定の段階では、開発者が特定の機能 (スプレッドシート ドキュメント、図など) の実装に関与しました。 原則として、これらはシン クライアントでこの機能を実行したのと同じ開発者でした。 それらの。 開発者は、以前に C++ で作成したコンポーネントを JavaScript で書き直しました。

XNUMX つの言語の間には概念的な大きな違いがあるため、私たちは最初から、C++ シン クライアント コードを JavaScript Web クライアントに自動的に (部分的であっても) 変換するという考えを拒否しました。 Web クライアントは JavaScript で最初から作成されました。

プロジェクトの最初の反復では、Web クライアントは組み込み 1C 言語のクライアント コードを JavaScript に直接変換しました。 シン クライアントの動作は異なります。組み込み 1C 言語のコードがバイトコードにコンパイルされ、このバイトコードがクライアントで解釈されます。 その後、Web クライアントも同様のことを行うようになりました。第一に、パフォーマンスが向上し、第二に、シン クライアントと Web クライアントのアーキテクチャを統合できるようになりました。

Web クライアントをサポートする 1C:Enterprise プラットフォームの最初のバージョンは 2009 年にリリースされました。 当時の Web クライアントは、Internet Explorer と Firefox の 2 つのブラウザをサポートしていました。 当初の計画には Opera のサポートが含まれていましたが、当時は Opera のアプリケーション終了ハンドラーに克服できない問題があったため (アプリケーションが終了していることを 100% 確実に追跡することができず、その時点でアプリケーションからの切断手順を実行することはできませんでした)。 1C アプリケーション サーバー) などの計画は断念する必要がありました。

プロジェクトの構造

合計で、1C:Enterprise プラットフォームには JavaScript で書かれた 4 つのプロジェクトがあります。

1. WebTools – 他のプロジェクトで使用される共有ライブラリ (これも含まれています) Google Closure ライブラリ).
2. 制御要素 フォーマットされたドキュメント (シンクライアントとWebクライアントの両方でJavaScriptで実装されます)
3. 制御要素 プラハ (シンクライアントとWebクライアントの両方でJavaScriptで実装されます)
4. ウェブクライアント

各プロジェクトの構造は、Java プロジェクト (または .NET プロジェクトのどちらか近い方) の構造に似ています。 名前空間があり、各名前空間は別のフォルダーにあります。 フォルダー内にはファイルと名前空間クラスがあります。 Web クライアント プロジェクトには約 1000 個のファイルがあります。

構造的に、Web クライアントは次のサブシステムに大別されます。

• マネージド クライアント アプリケーション インターフェイス
  • 一般的なアプリケーション インターフェイス (システム メニュー、パネル)
  • 管理フォームのインターフェイス。特に、約 30 個のコントロール (ボタン、テキスト、数値、日付/時刻などのさまざまなタイプの入力フィールド、表、リスト、グラフなど) が含まれます。

• 開発者がクライアントで利用できるオブジェクト モデル (マネージド インターフェイス オブジェクト モデル、データ レイアウト設定、条件付きスタイルなど、合計 400 種類以上)
• 内蔵 1C 言語のインタプリタ
• ブラウザ拡張機能 (JavaScript でサポートされていない機能に使用されます)
  • 暗号化の操作
  • ファイルの操作
  • シン クライアントと Web クライアントの両方で使用できる外部コンポーネントのテクノロジ

開発機能

上記のすべてを JavaScript で実装するのは簡単ではありません。 おそらく 1C Web クライアントは、JavaScript で書かれた最大のクライアント側アプリケーションの 450.000 つであり、その行数は約 XNUMX 行です。 私たちは、Web クライアント コードでオブジェクト指向のアプローチを積極的に使用しており、これにより、このような大規模なプロジェクトでの作業が簡素化されます。

クライアント コードのサイズを最小限に抑えるために、最初は独自の難読化ツールを使用し、プラットフォーム バージョン 8.3.6 (2014 年 XNUMX 月) からは、 Google Closure コンパイラ。 使用の効果を数字で示します – 難読化後の Web クライアント フレームワークのサイズ:

• 独自の難読化ツール – 1556 kb
• Google クロージャ コンパイラ – 1073 kb

Google Closure Compiler を使用すると、独自の難読化ツールと比較して Web クライアントのパフォーマンスが 30% 向上しました。 さらに、アプリケーションによって消費されるメモリ量が 15 ～ 25% 減少しました (ブラウザによって異なります)。

Google Closure Compiler はオブジェクト指向コードと非常にうまく連携するため、Web クライアントの効率が可能な限り高くなります。 Closure Compiler は、次のような良いことをしてくれます。

• プロジェクトのビルド段階での静的型チェック (コードが JSDoc アノテーションでカバーされていることを確認します)。 その結果、静的型付けが行われ、C++ での型付けに非常に近いレベルになります。 これは、プロジェクトのコンパイル段階でかなりの割合のエラーを検出するのに役立ちます。
• 難読化によるコードサイズの削減
• たとえば、次のような実行コードのさまざまな最適化。
  • インライン関数の置換。 JavaScript での関数の呼び出しはかなり負荷の高い操作であり、頻繁に使用される小さなメソッドをインラインで置換することで、コードが大幅に高速化されます。
  • コンパイル時に定数をカウントします。 式が定数に依存している場合、定数の実際の値が代入されます。

Webクライアント開発環境としてWebStormを使用しています。

コード分​​析には以下を使用します ソナーキューブ、静的コード アナライザーを統合します。 アナライザーを使用してJavaScriptソースコードの品質低下を監視し、その防止に努めます。

私たちはどのような問題を解決しましたか?

プロジェクトの実施中に、解決しなければならない興味深い問題が数多く発生しました。

サーバーとのデータ交換およびウィンドウ間でのデータ交換

ソース コードの難読化によりシステムの動作が妨げられる場合があります。 Web クライアントの実行可能コードの外部にあるコードは、難読化により、実行可能コードが予期するものとは異なる関数名やパラメーター名を持つ場合があります。 私たちの外部コードは次のとおりです。

• データ構造の形式でサーバーから取得されるコード
• 別のアプリケーションウィンドウのコード

サーバーと対話する際の難読化を避けるために、 @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 (){}

仮想 DOM が主流になる前に使用していました)

複雑な Web UI を扱うすべての開発者と同様に、私たちも DOM が動的なユーザー インターフェイスの操作にはあまり適していないことにすぐに気づきました。 ほぼすぐに、UI での作業を最適化するために Virtual DOM の類似物が実装されました。 イベント処理中、すべての DOM 変更はメモリに保存され、すべての操作が完了した場合にのみ、蓄積された変更が DOM ツリーに適用されます。

Webクライアントの最適化

Web クライアントの動作を高速化するために、ブラウザの標準機能 (CSS など) を最大限に活用するように努めています。 したがって、フォーム コマンド パネル (アプリケーションのほぼすべてのフォームに配置されています) は、CSS に基づく動的レイアウトを使用してブラウザ ツールのみを使用してレンダリングされます。

テスト

機能およびパフォーマンスのテストには、独自のツール (Java および C++ で書かれた) と、その上に構築された一連のテストを使用します。 Selenium .

私たちのツールは汎用性があり、ほぼすべてのウィンドウ プログラムをテストできるため、シン クライアントと Web クライアントの両方のテストに適しています。 このツールは、1C アプリケーション ソリューションを起動したユーザーのアクションをスクリプト ファイルに記録します。 同時に、画面の作業領域（標準）の画像が記録されます。 Web クライアントの新しいバージョンを監視する場合、スクリプトはユーザーの参加なしで再生されます。 どの段階でもスクリーンショットが基準のものと一致しない場合、テストは不合格とみなされ、その後、品質専門家が調査を実施して、これがエラーなのか、それともシステムの動作の計画された変更なのかを判断します。 計画された動作の場合、標準は自動的に新しいものに置き換えられます。

このツールは、アプリケーションのパフォーマンスも最大 25 ミリ秒の精度で測定します。 場合によっては、スクリプトの一部をループして (たとえば、注文入力を数回繰り返すなど)、時間の経過に伴う実行時間の低下を分析します。 すべての測定結果は分析のためにログに記録されます。

当社のテストツールとテスト対象のアプリケーション

私たちのツールと Selenium は相互に補完します。 たとえば、いずれかの画面上のボタンの位置が変更された場合、Selenium はこれを追跡しない可能性がありますが、ツールはそれを認識します。 スクリーンショットと標準のスクリーンショットをピクセルごとに比較します。 このツールは、キーボードまたはマウスからの入力の処理に関する問題を追跡することもできます。これは、まさにそれが再現されるためです。

両方のツール (私たちのツールと Selenium) のテストでは、アプリケーション ソリューションの典型的な作業シナリオが実行されます。 テストは、1C:Enterprise プラットフォームの毎日のビルド後に自動的に開始されます。 スクリプトが (以前のビルドと比較して) 遅い場合は、速度低下の原因を調査して解決します。 私たちの基準は単純です。新しいビルドは以前のビルドよりも遅く動作しないはずです。

開発者はさまざまなツールを使用して速度低下インシデントを調査します。 主に使用される Dynatrace AJAX エディション 製作会社 ダイナトレース。 以前のビルドと新しいビルドで問題のある操作の実行ログが記録され、ログが分析されます。 同時に、単一操作の実行時間 (ミリ秒単位) は決定的な要素ではない可能性があります。ガベージ コレクションなどのサービス プロセスはブラウザーで定期的に起動され、関数の実行時間と重なって画像が歪む可能性があります。 この場合、より関連性の高いパラメータは、実行された JavaScript 命令の数、DOM 上のアトミック操作の数などです。 新しいバージョンで同じスクリプト内の命令/操作の数が増加した場合、これはほとんどの場合、修正が必要なパフォーマンスの低下を意味します。

また、パフォーマンス低下の理由の XNUMX つは、Google Closure Compiler が何らかの理由で関数のインライン置換を実行できなかった可能性があります (たとえば、関数が再帰的または仮想であるため)。 この場合、ソースコードを書き直すことで状況を修正しようとします。

ブラウザ拡張機能

アプリケーション ソリューションに JavaScript では利用できない機能が必要な場合は、ブラウザ拡張機能を使用します。

• ファイルを操作するには
• 暗号化を扱うための
• と連携 外部コンポーネント

私たちの拡張機能は2つの部分から構成されています。1つ目はブラウザ拡張機能（通常はChromeとFirefox用のJavaScript拡張機能）で、2つ目は必要な機能を実装するバイナリ拡張機能です。なお、バイナリ拡張機能は3種類作成しており、それぞれ異なるブラウザ向けに開発しています。 Windows, Linux およびmacOSに対応しています。バイナリファイルは1C:Enterpriseプラットフォームに同梱されており、1Cアプリケーションサーバー上にあります。Webクライアントから初めてアクセスすると、クライアントコンピュータにダウンロードされ、ブラウザにインストールされます。

Safari で実行する場合、拡張機能は NPAPI を使用し、Internet Explorer で実行する場合は、ActiveX テクノロジを使用します。 Microsoft Edge はまだ拡張機能をサポートしていないため、その Web クライアントは制限付きで動作します。

さらなる発展

Web クライアント開発チームのタスクの XNUMX つは、機能のさらなる開発です。 Web クライアントの機能はシン クライアントの機能と同一である必要があり、すべての新しい機能はシン クライアントと Web クライアントの両方に同時に実装されます。

その他のタスクには、アーキテクチャの開発、リファクタリング、パフォーマンスと信頼性の向上が含まれます。 たとえば、方向性の XNUMX つは、非同期作業モデルへのさらなる移行です。 現在、Web クライアントの機能の一部は、サーバーとの対話の同期モデルに基づいて構築されています。 非同期モデルは現在、ブラウザー (ブラウザーに限らず) での関連性が高まっており、そのため、同期呼び出しを非同期呼び出しに置き換えること (およびそれに応じてコードをリファクタリングすること) によって、Web クライアントを変更する必要があります。 非同期モデルへの段階的な移行は、リリースされたソリューションとその段階的な適応をサポートする必要性によって説明されます。

出所： habr.com