1Cでのカスタマイズ

一般的なカスタマイズについて

ソフトウェアのカスタマイズの必要性、つまり 特定のユーザーのニーズへの変更は、おそらくソフトウェア自体と同時に現れました。 すべての人を満足させるプログラムを作成することは困難であるため、プログラムの製造元を関与させずに変更の可能性を置くことは良い考えです。 特に、ビジネスアプリケーションに関しては、 同じ領域であっても、ビジネスプロセスは組織によって異なる場合があります。

ソースコードの変更

さまざまなカスタマイズ戦略があります。 アプリケーションがソースコードで提供される場合、最も明白なアプローチは、ニーズに合わせてソースコードを書き直すことです。 そして、この場合の最も明らかな問題は、アプリケーションの新しいバージョンへの移行です。 クライアント側のバージョンのソースコードとプロバイダーの新しいバージョンをマージする必要があります。 また、特にクライアント側のコードが高度にカスタマイズされている場合、これは重要なタスクです。

プラグイン

この点でより安全な戦略はプラグインです。 ソースアプリケーションは、プラグインにインターフェイスの固定セットを提供し、アプリケーションに自身を登録する機能も提供します。 アプリケーションの新しいバージョンのリリースに伴い、以前のバージョン用に作成されたプラグインは、新しいバージョンでも引き続き機能します（インターフェイスが変更されていない場合）。 ソフトウェアプロバイダーがアプリケーションの動作を変更した場合、新しいバージョンのプラグインの動作は前のバージョンの動作と異なる場合があります。 プラグインの概念は、オフィスおよびビジネスソフトウェア、開発環境（Visual Studio、Eclipseなど）、グラフィックおよびサウンドエディターなど、さまざまなソフトウェアクラスで使用されます。

サブスクリプション

別のカスタマイズテクノロジは、アプリケーション内のイベントをサブスクライブし、これらのイベント中に既知の言語または独自の言語でカスタムコードを実行する機能です。 イベントには、ウィンドウを開く、画像を読み込む（グラフィックエディターの場合）、注文処理（ビジネスシステムの場合）など、さまざまな種類があります。

このアプローチの種類の1つは、Visual Basic for Application（ VBA ）などの言語でユーザースクリプトを実行する機能をメインプログラムに埋め込むことです。 カスタムコードは、特に、アプリケーションイベントに応じて実行される場合があります。 同じVBAが非常に強力で柔軟なカスタマイズ手段であることが証明されました。 Microsoft Office、AutoCAD、SolidWorks、CorelDRAW、WordPerfect、ESRI ArcGIS、その他の製品に組み込まれています。

1Cソリューションのカスタマイズ：開始

1C：エンタープライズプラットフォームは、さまざまなカスタマイズ戦略を実装しています。 1Cアプリケーションソリューションはソースコードで提供されるため、当然、最も明らかなシナリオの1つはソースコードの変更です。

1Cアプリケーションのソースコードの変更

クライアントが1Cソリューションのソースコードをニーズに合わせて変更する場合、アプリケーションプロバイダーもアイドル状態ではなく、新しいバージョンをリリースし、機能を追加してバグを修正することを覚えておく必要があります。 新しいバージョンのアプリケーションをインストールするときに、クライアントのニーズに加えられた変更が失われないように、変更された前のバージョンのアプリケーションと新しいバージョンを何らかの方法でマージする必要があります。

当然、1Cでこの問題に大きな注意を払い、その解決を促進するための配信およびサポートメカニズムを開発しました 。 仕組みを説明する前に、1Cソリューションの内部構造に関するいくつかの詳細を説明します。

1Cアプリケーションソリューション（構成）のソースコードとメタデータは、アプリケーション自体のデータ（投稿、ディレクトリとドキュメントのデータなど）を含む同じデータベースに保存されます。 プログラムはデータとともに保存されます。 1Cの用語で構成されたデータベース（およびアプリケーションデータ）は、情報データベース（略して情報ベース）と呼ばれます。

開発プロセス中に、構成プロバイダーは、クライアントが変更できる構成オブジェクト（ディレクトリ、ドキュメントなど）と変更できない構成オブジェクトを決定します。



サプライヤ固有の配信設定

クライアントは、このメカニズムを使用して、ベンダーの組み込み構成のオブジェクトをサポートするためのルールを決定することもできます。たとえば、このオブジェクトのさらなる変更を担当する場合、特定のオブジェクトのサプライヤーのサポートを拒否できます。 または、逆に、偶発的な変更を防ぐために、（サプライヤが許可している場合でも）独自の構成のオブジェクトの編集を禁止できます。



クライアント側のサポートを構成する

クライアントが一般的な構成で何かを変更し始めると、情報ベースに2つの構成が作成されます。

1. 元のベンダー構成。
2. クライアント側で現在の構成が変更されました。

そして今、サプライヤーは新しいバージョンをリリースしています。 完全なアプリケーションとして配信することも、オブジェクトを変更したサービスパックとして提供することもできます。 新しいバージョンに切り替えると、クライアント側に3つの構成があり、これに基づいて、いわゆる3方向構成のマージが実行されます。

1. サプライヤーからの古い構成。
2. クライアントの現在の構成（サプライヤーからの古い構成に加えて、クライアントがクライアントに行った変更）。
3. サプライヤーからの新しい構成。

場合によっては、サプライヤによって変更されたオブジェクトを自動的に更新できることは明らかです。

• クライアントによって変更されていないオブジェクト。
• クライアント側のオブジェクトへの簡単な変更（たとえば、オブジェクトに追加の詳細を追加）。

クライアント側とサプライヤからの新しいバージョンの両方でオブジェクトが変更された場合、手動による介入が必要です。 コードモジュールだけでなく、モデル（メタデータ、フォーム、レポートなど）に対しても比較および結合するための強力なメカニズムがありますが、このメカニズムを使用しても、構成の結合は簡単な作業ではありません。

外部報告および処理

新しいバージョンへの切り替えの観点から比較的安全な別のカスタマイズメカニズムは、 外部レポートおよび処理のメカニズムです。 名前が示すように、外部レポートと外部処理の両方のタイプのオブジェクトは、アプリケーションソリューションの外部にあり、別々のファイルに保存され、実行時にアプリケーションソリューションにロードされます。 したがって、新しいバージョンに切り替えるプロセスは、それらにまったく影響しません。 ただし、新しいバージョンでオブジェクトの詳細が削除または名前変更され、処理またはレポートがそれらを参照する場合、新しいバージョンではレポートまたは処理は変更なしでは機能しません。

外部のレポートと処理は基本的にプラグインです。 これらは、「カスタム」レポートおよびデータに対する特定の操作（他のシステムからの情報のインポートなど）に適していますが、もちろん、すべてのカスタマイズシナリオがカバーされているわけではありません。 クライアントがドキュメントの処理中に実行する必要がある特定のコードを追加する必要がある場合、ここでは外部処理が不可欠です。ドキュメントモジュールのソースコードを編集する必要があります。

クラウドでのカスタマイズ

1cFreshクラウドテクノロジーの出現により、カスタマイズのタスクは新しいレベルに達しました。 実際、さまざまな組織のアプリケーションソリューションの「クラウド」ユーザーは、1つの情報ベース（つまり、アプリケーションの1つのインスタンス）で物理的に作業できますが、同時に、データ分離メカニズムのおかげで、組織のデータのみが表示されます。 ここでソースコードを変更することによるカスタマイズは受け入れられなくなります。各組織には独自のカスタマイズが必要であり、情報ベースの「隣人」をカスタマイズする必要はまったくありません。

カスタマイズ用の「クラウド」では、外部レポートと処理の使用のみが適用されますが、前述のように、外部レポートと処理はユーザーが必要とするすべてのシナリオをカバーするわけではありません。

構成拡張

そのため、次の要件を満たすカスタマイズメカニズムを考案する必要がありました。

1. カスタマイズされたソリューションを新しいバージョンに簡単に更新し、構成を結合する手作業を回避できます。
2. 特定の条件（たとえば、特定の組織のコンテキストで作業する場合）でカスタマイズを含めることができます。
3. 元の構成の新しいバージョンに切り替えるときに、カスタマイズのパフォーマンスが失われる可能性を減らしました。
4. 問題が発生した場合に、アプリケーションの正常性を維持するためにカスタマイズを無効にする機能がありました。

このようなメカニズムは、クラウドソリューションで使用されることに加えて、カスタマイズが必要な一般的な構成の導入時に新しいバージョンに切り替えると、非常に便利になります。
私たちはそのようなメカニズムを思いつき、その拡張を呼び出しました。 ある意味で、このメカニズムは、プラグインのイデオロギーとサブスクリプションメカニズムという2つのカスタマイズアプローチを組み合わせています。

拡張機能は、構成の変更を構成自体とは別に保持する方法です。 実際、拡張機能自体は、変更されたオブジェクトを含む個別の構成です。 構成と同様に、オブジェクトのツリーとして表されます。 拡張機能を使用するには、通常の構成と同じ作業方法が使用されます。



拡張機能のメイン構成からオブジェクトを使用する場合（たとえば、メイン構成に存在するドキュメントに新しいフォームを追加する場合）、最初に「拡張機能に追加」コマンドを使用して拡張機能にオブジェクトを借用する必要があります。 オブジェクトを拡張機能に追加した直後は、拡張機能オブジェクトのツリーで「空」になっています。メイン構成にあるプロパティのみがあります。 メイン構成から既存のフォームを借用して、たとえば、特定のアクションを実行する新しいボタンをフォームに追加することもできます。 拡張機能のオブジェクトに新しい詳細を追加することはまだできませんが、現在取り組んでいます。



借用文書の請求書発行による基本構成および拡張

この拡張機能には、イベントのサブスクライブに似たものもあります。たとえば、記録処理など、拡張可能な構成のオブジェクトのイベントを処理する機能です。 拡張機能でコードを呼び出す方法を指定できます。



ドキュメントを記録する標準手順の前にコードを呼び出すことができます。たとえば、ドキュメントを担当するフィールドが入力されているかどうかを確認し、入力されていない場合は、このフィールドに現在のユーザーを書き込みます。

&("")  _(, , )  (. = ..())  . = .(); ;  

構成の新しいバージョンでは、ドキュメントレコードの実装が変更される可能性がありますが、拡張機能のコードは、ドキュメントの記録およびジョブの標準コードの前に実行されます。

実行時に、一般的な構成と拡張機能（複数の場合があります）が「追加」され、新しいカスタマイズされた構成が作成され、エンドユーザーが操作します。

拡張順序

拡張機能を開発するとき、複数の拡張機能を構成に追加するときにプラットフォームが拡張機能の実行の同じ順序を保証しないことを覚えておく必要があります。 拡張機能が実行された順序を明示的に指定することを意図的に拒否しました。 これは、私たちの意見では、セットアップを複雑にし、最終的には解決するよりも多くの問題をもたらします。

構成にいくつかの拡張機能を追加し、それぞれが「＆After」ディレクティブを使用して同じドキュメントを処理すると、すべてのハンドラーが実行されますが、プラットフォームは実行順序が常に同じであることを保証しません。 これは、拡張機能を開発するときに考慮する必要があります。

同じイベントの複数の拡張機能に「＆代わり」ディレクティブを使用したハンドラーがある場合、実行されるハンドラーは1つだけであり、事前に指定することはできません。 これは、最大1つの拡張機能が同じオブジェクト/イベントの「＆代わり」ハンドラーを持つように、記憶および監視する必要があります。

拡張機能でのフォームのカスタマイズ

拡張機能の設定（たとえば、ドキュメントフォーム）からオブジェクトフォームを借用できます。 同時に、拡張機能のビジュアルフォームエディターでは、フォームがメイン構成と同じであることがわかります。 また、フォームコードエディターでは、拡張子は空になります。これまでのフォームのすべてのコードはメイン構成にのみ含まれています。

新しいボタンをフォーム（または複数）に追加できます。 複数の拡張機能が同じフォームにボタンを追加した場合、それらはすべて実行時に最終フォームに表示されます。

ただし、フォームから標準要素を削除することはお勧めしません。これにより、元の構成に存在するコードが破損する可能性があります（フォーム要素を参照している場合）。 そのようなニーズがある場合は、「可視性」プロパティを使用して要素を非表示にすることをお勧めします。

1C：Enterprise上のアプリケーションは、単なるプログラミング言語のコードではないことに注意してください。 アプリケーションのほとんどは、宣言型モデルとして説明されています。 さらに、さまざまなタイプのモデルがさまざまなタスク（フォーム、レポート、権利など）に使用されます。 モデルのタイプごとに、拡張機能で独自のカスタマイズ方法を選択します。これにより、典型的なケースに最も便利な変更が提供されます。

拡張機能の利点

拡張機能には、配信およびサポートメカニズムとのイデオロギー的な違いがあります。 配信とサポートのメカニズムでは、開発者はサプライヤの構成を必要に応じて修正します。まるで自分の構成を微調整するだけで、（更新時に）競合する変更を同期する方法を理解します。 拡張機能では、開発者は追加された機能に関して拡張機能をすぐに最初に開発します。 拡張機能はシステムによって追加として正確に保存され、システムは最も安全な更新を処理します。

新しいバージョンの構成への簡単な移行

サプライヤが標準構成の新しいバージョンをリリースすると、標準構成のサポートモードが変更されなかったため、自動更新が実行されます。サプライヤの完全なサポートのままでした。 更新されたアプリケーションソリューションを開始すると、プラットフォームは自動的に変更された標準構成と拡張機能を自動的に組み合わせます。 また、クライアントは、自分のニーズに合わせて修正された標準ソリューションを引き続き使用します。

典型的な構成のバージョンを更新した後、たとえば、拡張に含まれるオブジェクトまたはオブジェクトの詳細が新しいバージョンで名前が変更された場合など、拡張を新しいバージョンに適合させる必要がある場合があります。 これについては、「エラーの早期警告」セクションで詳しく説明します。

変更は別です

拡張機能の最初の明白な利点は、クライアントに対して行われたすべてのカスタマイズが通常の構成とは別個であり、変更された構成を標準の構成と比較して、変更内容を正確に理解する必要がないことです。

拡張機能のメイン構成からオブジェクトを使用するには、メイン構成から拡張機能にオブジェクトを借用する必要があることは既に述べました。 したがって、拡張機能では、メイン構成からのオブジェクトへの参照のようなものが表示されます。

構成内のどの借用オブジェクトが実際に変更され、読み取り専用モードで借用されているのか（たとえば、レポートで使用するため）を理解する方法があります。 拡張オブジェクトのツリーには、「拡張機能に変更および追加」フィルターボタン用のボタンがあり、クリックすると、この拡張機能で変更された借用オブジェクトと、この拡張機能で作成された新しいオブジェクトのみがツリーに残ります。

エラーの早期警告

レポートで使用するために、拡張機能のメイン構成からContractsディレクトリを借用したとします。 一方、標準構成の新しいバージョンがリリースされ、Contractsディレクトリの名前がContractsに変更されました。 当然、新しいバージョンへの移行後、拡張機能のレポートは機能しません。 古いカスタマイズテクノロジー（外部レポート）を使用した場合、エラーはレポートの実行時にのみ発生します。 拡張機能の場合、標準構成のバージョンを更新した後、設計時に拡張機能の正確性を検証し、ユーザーが作業を開始する前にすべての問題を修正する機会があります。

これは、多くの拡張機能が同じ情報ベースで使用され、構成バージョンが中央で更新される実装に特に当てはまります（たとえば、同じ構成を使用しているが異なるデータ領域で作業する異なる組織が異なるセットを使用できるクラウド実装など）拡張機能）。 管理者は、テストベースで標準構成バージョンを更新し、新しいバージョンに関するすべてのユーザー拡張機能の正確性を検証できます。 問題が発生した場合、彼は拡張機能の所有者にそれらについて通知し、すべての拡張機能が新しいバージョンの構成に合わせられた場合にのみ、作業ベースの新しいバージョンの標準構成への移行が行われます。

次は？

拡張機能の開発は、1C：エンタープライズプラットフォームのカスタマイズツール開発の主要な分野の1つであると考えています。 もともとクラウドサービスのカスタマイズを容易にするために考案された拡張機能は、カスタマイズと非クラウド展開の状況を容易にするように設計されました。

これまでのところ、拡張機能では、必要なものをすべてカスタマイズすることはできません。 たとえば、新しいアプリケーションオブジェクト（リファレンスブック、ドキュメントなど）を作成することはまだ不可能であり、既存のアプリケーションオブジェクトに新しい詳細を追加することはできません。 私たちはこれに取り組んでおり（および他の機能も）、1C：Enterpriseプラットフォームのほぼすべての新しいバージョンで、拡張機能に新しい機能を追加しています。

• 拡張機能のWebおよびHTTPサービス （バージョン8.3.7）。
• 拡張機能に独自のオブジェクトを追加する-一般的なコマンド、レイアウト、画像、および借用したアプリケーションオブジェクトの形式、それらのコマンドとレイアウト（バージョン8.3.8、 リンク ）。
• 拡張機能のメカニズムの開発 （拡張機能にロールを追加する-バージョン8.3.9）。
• 拡張モジュール （バージョン8.3.9）。