🏢 🗼 👩‍🌾 1Cとの統合の方法 👦🏼 🗿 🏝️

ビジネスアプリケーションの最も重要な要件は何ですか？最も重要なものの1つは、次のタスクです。

変化するビジネスタスクに対するアプリケーションロジックの変更/適応の容易さ。
他のアプリケーションとの簡単な統合。

1Cで最初のタスクを解決する方法については、この記事の「カスタマイズとサポート」セクションで簡単に説明しました。今後の記事でこの興味深いトピックに戻ります。今日は、2番目のタスクである統合に焦点を当てます。

統合タスク

統合タスクは異なる場合があります。いくつかを解決するには、単純なインタラクティブなデータ交換で十分です。たとえば、給与のプラスチックカードを発行する従業員のリストを銀行に転送する場合です。より複雑なタスクの場合は、完全に自動化されたデータ交換が必要になる場合があり、外部システムのビジネスロジックにアピールする場合があります。外部機器（小売用機器、モバイルスキャナーなど）との統合や、レガシーシステムや高度に専門化されたシステム（RFIDタグ認識システムなど）との統合など、本質的に特化したタスクがあります。各タスクが最も適切な統合メカニズムを選択することが不可欠です。

1Cとの統合の可能性

1Cアプリケーションとの統合を実装するためのさまざまなアプローチがありますが、どのアプローチを選択するかは、タスクの要件によって異なります。

プラットフォームが提供する統合メカニズムに基づいた、 1Cアプリケーション側の独自の専用APIの実装（たとえば、サードパーティアプリケーションが1Cアプリケーションとデータを交換するために呼び出すWebまたはHTTPサービスのセット）。このアプローチの利点は、1Cアプリケーション側の実装の変更に対するAPIの耐性です。このアプローチの特徴は、典型的な1Cソリューションのソースコードを変更する必要があることです。これは、構成の新しいバージョンに切り替えるときにソースコードをマージするときに労力を必要とする可能性があります。この場合、レスキュー構成の拡張機能に新しいプログレッシブ機能が追加される場合があります。実際、拡張機能は、アプリケーションソリューション自体を変更せずにアプリケーションソリューションへの追加を作成できるプラグインメカニズムです。統合APIを構成拡張機能から削除すると、標準ソリューションの新しいバージョンに切り替えるときに構成をマージする際の問題を回避できます。
アプリケーションオブジェクトモデルへの外部アクセスを提供し、アプリケーションの改良や拡張機能の作成を必要としないプラットフォーム統合メカニズムの使用。このアプローチの利点は、1Cアプリケーションを変更する必要がないことです。マイナス-アプリケーション1Cが完成した場合、統合アプリケーションの改善が必要になる場合があります。このアプローチの例としては、統合のためのODataプロトコルの使用があります。これは、1C：Enterpriseプラットフォームの側面に実装されています（詳細については後述）。
標準1Cソリューションに実装された既製のアプリケーションプロトコルの使用。 1Cおよびパートナーの多くの標準ソリューションは、プラットフォームが提供する統合メカニズムに基づいて、特定のタスクに焦点を当てた独自のアプリケーションプロトコルを実装しています。これらのメカニズムを使用する場合、1Cアプリケーションの側でコードを記述する必要はありません。アプリケーションソリューションのフルタイム機能を利用します。 1Cアプリケーションの側では、特定の設定を行うだけです。

1Cの統合メカニズム：エンタープライズプラットフォーム

ファイルのインポート/エクスポート

1Cアプリケーションと任意のアプリケーション間の双方向データ交換のタスクに直面しているとします。たとえば、1Cアプリケーションと任意のアプリケーションの間で商品のリスト（命名法の参考書）を同期する必要があります。

この問題を解決するには、Nomenclatureディレクトリを特定の形式（テキスト、XML、JSONなど）のファイルにアンロードする拡張機能を記述し、この形式を読み取ることができます。

プラットフォームは、XMLでアプリケーションオブジェクトをシリアル化するためのメカニズムを実装します。これは、グローバルコンテキストWrite XML / Read XMLのメソッドを通じて、および補助オブジェクトXDTO（XMLデータ転送オブジェクト）を使用して直接行われます。

1C：EnterpriseシステムのオブジェクトはすべてXML表現にシリアル化でき、その逆も可能です。

この関数は、オブジェクトの表現をXMLとして返します。

 __XML() XML =  XML(); XML.(); XML(XML, );  XML.();

これは、XDTOを使用して命名規則参照をXMLにエクスポートする方法です。

 &  XML() XDTO = XDTO; XML =  XML(); XML.("C:\Data\.xml", "UTF-8"); XML.XML(); XML.("");  = ..();  .()   = .(); XDTO.XML(XML, , XML.); ; XML.(); XML.();

コードを簡単に変更することで、ディレクトリをJSONにエクスポートします。アイテムは配列に書き込まれます。変更のために、ここに構文の英語版があります：

 &AtServer Procedure ExportJSONOnServer() NewXDTOSerializer = XDTOSerializer; NewJSONWriter = New JSONWriter(); NewJSONWriter.OpenFile("C:\Data\.json", "UTF-8"); NewJSONWriter.WriteStartObject(); NewJSONWriter.WritePropertyName(""); NewJSONWriter.WriteStartArray(); Selection = Catalogs..Select(); While Selection.Next() Do NomenclatureObject = Selection.GetObject(); NewJSONWriter.WriteStartObject(); NewJSONWriter.WritePropertyName(""); NewXDTOSerializer.WriteJSON(NewJSONWriter, NomenclatureObject, XMLTypeAssignment.Implicit); NewJSONWriter.WriteEndObject(); EndDo; NewJSONWriter.WriteEndArray(); NewJSONWriter.WriteEndObject(); NewJSONWriter.Close(); EndProcedure

その後、最終消費者にデータを転送するためだけに残ります。 1C：エンタープライズプラットフォームは、安全なバージョンを含む、HTTP、FTP、POP3、SMTP、IMAPの基本的なインターネットプロトコルをサポートしています。 HTTPやWebサービスを使用してデータを転送することもできます。

HTTPおよびWebサービス

1Cアプリケーションは、HTTPおよびWebサービスを実装できるだけでなく、サードパーティアプリケーションによって実装されたHTTPおよびWebサービスを呼び出すことができます。

RESTインターフェイスとODataプロトコル

バージョン8.3.5以降、1C：Enterpriseプラットフォームは、アプリケーションソリューション全体のRESTインターフェイスを自動的に作成できます。構成オブジェクト（ディレクトリ、ドキュメント、情報レジスタなど）は、RESTインターフェイスを介してデータを受信および変更するために使用可能にできます。アクセスプロトコルとして、プラットフォームはODataプロトコルバージョン3.0を使用します。 ODataサービスの公開は、[設定]メニューの[管理-> Webサーバーへの公開]で実行されます。[OData標準インターフェイスの公開]チェックボックスをオンにする必要があります。サポートされている形式は、atom / XMLおよびJSONです。アプリケーションソリューションがWebサーバーに公開されると、サードパーティシステムは、HTTP要求を使用してRESTインターフェイスを介してそれにアクセスできます。 ODataプロトコルを介して1Cアプリケーションを操作するには、1C側でのプログラミングは不要です。

したがって、 http：// <server> / <configuration> /odata/standard.odata/Catalog_Nomenclatureという形式のURLは、XML形式のカタログNomenclatureのコンテンツを返します-エントリ要素のコレクション（簡潔にするためにメッセージヘッダーは省略されます）：

 <entry> <id>http://server/Config/odata/standard.odata/Catalog_(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')</id> <category term="StandardODATA.Catalog_" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/> <title type="text"/> <updated>2016-06-06T16:42:17</updated> <author/> <summary/> <link rel="edit" href="Catalog_(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')" title="edit-link"/> <content type="application/xml"> <m:properties xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"> <d:Ref_Key>35d1f6e4-289b-11e6-8ba4-e03f49b16074</d:Ref_Key> <d:DataVersion>AAAAAgAAAAA=</d:DataVersion> <d:DeletionMark>false</d:DeletionMark> <d:Code>000000001</d:Code> <d:Description> Mitsubishi</d:Description> <d:> 2,5 ,  : /</d:> </m:properties> </content> </entry> <entry> <id>http://server/Config/odata/standard.odata/Catalog_(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')</id> <category term="StandardODATA.Catalog_" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/> ...

URLに文字列「？ / json ）：

 { "odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_", "value": [{ "Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074", "DataVersion": "AAAAAgAAAAA=", "DeletionMark": false, "Code": "000000001", "Description": " Mitsubishi", "": " 2,5 ,  : /" },{ "Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074", "DataVersion": "AAAAAwAAAAA=", "DeletionMark": false, "Code": "000000002", "Description": " Daikin", "": " 3 ,  : /" }, …

外部データソース

場合によっては、外部データソースを介してデータを交換することが最適なソリューションである場合があります。外部データソースは1C構成のアプリケーションオブジェクトであり、ODBC準拠のデータベースと読み取りおよび書き込みの両方を操作できます。外部データソースは、WindowsとLinuxの両方で使用できます。

データ交換メカニズム

データ交換メカニズムは、1C：Enterpriseに基づく地理的に分散したシステムの作成と、1C：Enterpriseに基づかない他の情報システムとのデータ交換の整理の両方を目的としています。

このメカニズムは1Cの実装で積極的に使用されており、その助けによって解決されるタスクの範囲は非常に広いです。これは、組織の支店にインストールされている1Cアプリケーション間のデータ交換、1CアプリケーションとオンラインストアWebサイト間の交換、1Cサーバーアプリケーションとモバイルクライアント（1C：エンタープライズモバイルプラットフォームを使用して作成）間のデータ交換などです。

データ交換メカニズムの重要な概念の1つは、交換計画です。交換計画は、特に交換に関係するデータの構成（ディレクトリ、ドキュメント、レジスタなど）を決定する1Cアプリケーションプラットフォームのオブジェクトの特別なタイプです。交換計画には、交換の参加者（いわゆる交換ノード）に関する情報も含まれています。

データ交換メカニズムの2番目のコンポーネントは、変更登録メカニズムです。このメカニズムは、交換計画の一部として最終消費者に転送する必要があるデータ変更をシステムで自動的に監視します。このメカニズムを使用して、プラットフォームは最後の同期以降に発生した変更を監視し、次の同期セッションで転送されるデータの量を最小限に抑えることができます。

データは、特定の構造のXMLメッセージを使用して交換されます。メッセージには、ノードとの最後の同期以降に変更されたデータ、およびいくつかのオーバーヘッド情報が含まれています。メッセージ構造は、メッセージの番号付けをサポートし、受信ノードからメッセージの受信に関する確認を受け取ることができます。そのような確認は、最後に受信したメッセージの番号の形式で受信ノードから到着する各メッセージに含まれています。メッセージの番号付けにより、プラットフォームは受信ノードに正常に送信されたデータを理解し、再送信を回避し、受信ノードが最後のメッセージを受信してから変更されたデータのみを送信します。この動作方式により、信頼性の低い伝送チャネルとメッセージ損失があっても、保証された配信が保証されます。

外付け部品

場合によっては、統合の問題を解決するときに、1C：Enterpriseプラットフォームでは提供されていない相互作用プロトコル、データ形式などの特定の要件に対処する必要があります。この範囲のタスクに対して、プラットフォームは外部コンポーネントのテクノロジーを提供します。これにより、1C：Enterpriseの機能を拡張する動的に接続されたモジュールを作成できます。

同様の要件を持つタスクの典型的な例は、スケールからレジやバーコードスキャナーまで、取引機器と1Cアプリケーションソリューションの統合です。外部コンポーネントは、1C：Enterpriseのサーバー側とクライアント側（Webクライアント、および1Cの次のバージョン：Enterprise モバイルプラットフォームを含むがこれらに限定されない）の両方で接続できます。外部コンポーネントのテクノロジーは、開発者が実装する必要がある1C：Enterpriseプラットフォームとコンポーネントとの相互作用のために、非常にシンプルで理解しやすいプログラム（C ++）インターフェイスを提供します。

外部コンポーネントを使用するときに生じる可能性は非常に広いです。外部デバイスやシステムとデータを交換するための特定のプロトコルで相互作用を実装したり、データやデータ形式を処理するための特定のアルゴリズムを埋め込んだりできます。

古い統合メカニズム

プラットフォームには、新しいソリューションでの使用が推奨されない統合メカニズムがあります。それらは、後方互換性の理由、および反対側がより新しいプロトコルで動作できない場合のために残されています。それらの1つは、DBFファイル（XBaseオブジェクトを使用して埋め込み言語でサポートされています）で作業しています。

もう1つの古い統合メカニズムは、COMテクノロジの使用です（Windowsプラットフォームでのみ使用可能）。 1C：エンタープライズプラットフォームは、COMテクノロジーを使用するWindows用に、オートメーションサーバーと外部接続の2つの統合方法を提供します。これらは非常に似ていますが、基本的な違いの1つは、オートメーションサーバーの場合、本格的なクライアントアプリケーション1C：Enterprise 8が起動され、外部接続の場合、比較的小さなインプロセスCOMサーバーが起動されることです。つまり、オートメーションサーバーを介して作業する場合、クライアントアプリケーションの機能を使用して、インタラクティブなユーザーアクションに類似したアクションを実行できます。外部接続を使用する場合は、ビジネスロジック関数のみを使用できます。これらは、アウトプロセスCOMサーバーが作成される接続のクライアント側で実行でき、サーバー側1C：Enterpriseでビジネスロジックを呼び出すことができます。

また、COMテクノロジーを使用して、1C：Enterpriseプラットフォーム上のアプリケーションコードから外部システムにアクセスできます。この場合、アプリケーション1CはCOMクライアントとして機能します。ただし、これらのメカニズムは、1CサーバーがWindows環境で実行されている場合にのみ機能することを思い出してください。

標準構成で実装された統合メカニズム

エンタープライズデータ形式

上記のプラットフォームデータ交換メカニズムに基づく多くの1C構成（以下のリスト）では、構成のソースコードを変更する必要のない外部アプリケーションとの既製のデータ交換メカニズムが実装されています（データ交換の準備は、アプリケーションソリューションの設定で行われます）：

「1C：ERP Enterprise Management 2.0」
統合オートメーション2
「エンタープライズアカウンティング」、リビジョン3.0
「企業KORPの会計」エディション3.0
Retail、バージョン2.0
基本貿易管理、エディション11
貿易管理、エディション11
「給与および人事管理CORP」第3版

データ交換には、XMLベースのEnterpriseData形式が使用されます。この形式はビジネス指向です-ここに記述されているデータ構造は、1Cプログラムで提示されるビジネスエンティティ（ドキュメントおよび参照要素）に対応します。たとえば、実行された作業行為、現金受領、取引相手、命名法などです。

1Cアプリケーションとサードパーティアプリケーションの間でデータ交換が発生する可能性があります。

専用のファイルディレクトリを介して
FTPディレクトリ経由
1Cアプリケーションの側にデプロイされたWebサービスを通じて。データファイルはパラメーターとしてWebメソッドに渡されます
メールで

Webサービスを介した交換の場合、サードパーティアプリケーションは、対応する1CアプリケーションのWebメソッドを呼び出すことにより、データ交換セッションを開始します。その他の場合、交換セッションの開始者は1Cアプリケーションになります（データファイルを適切なディレクトリに配置するか、構成されたメールアドレスにデータファイルを送信します）。

また、1C側では、同期が発生する頻度を構成できます（ディレクトリと電子メールを介したファイル交換のオプションの場合）。

スケジュール済み（特定の頻度で）
手動で; ユーザーは必要なたびに手動で同期を開始する必要があります

メッセージの確認

1Cアプリケーションは、送受信された同期メッセージを追跡し、サードパーティアプリケーションから同じことを期待します。これにより、上記の「データ交換メカニズム」で説明したメッセージ番号付けメカニズムを使用できます。

同期中の1Cアプリケーションは、最後の同期以降にビジネスエンティティに発生した変更に関する情報のみを送信します（転送される情報の量を最小限に抑えるため）。最初の同期時に、1Cアプリケーションはすべてのビジネスエンティティ（たとえば、命名ディレクトリのアイテム）をEnterpriseData形式でXMLファイルにアップロードします（これらはすべて外部アプリケーションにとって「新しい」ため）。サードパーティのアプリケーションは、1CからのXMLファイルからの情報を処理し、次の同期セッションで、1Cに送信されたファイルに、特別なXMLセクションで、特定の番号の1Cからのメッセージが正常に受信されたという情報を入れる必要があります。受信メッセージは、すべてのビジネスエンティティが外部アプリケーションによって正常に処理され、それらに関する情報を送信する必要がなくなったことを示す1Cアプリケーションのシグナルです。領収書に加えて、サードパーティアプリケーションからのXMLファイルには、アプリケーションによる同期用のデータ（商品やサービスの販売に関するドキュメントなど）も含まれている場合があります。

受信メッセージを受信した後、1Cアプリケーションは、前のメッセージで送信されたすべての変更を正常に同期したものとしてマークします。ビジネスエンティティの非同期の変更（新しいエンティティの作成、既存のエンティティの変更と削除）のみが、次の同期セッション中に外部アプリケーションに送信されます。

外部アプリケーションから1Cアプリケーションにデータを転送すると、画像が反対に変わります。外部アプリケーションは、それに応じてXMLファイルの受信セクションに記入し、EnterpriseData形式でその部分に同期用のビジネスデータを配置する必要があります。

確認なしの簡素化されたデータ交換

簡単な統合の場合、サードパーティアプリケーションから1Cアプリケーションに情報を転送するだけで、1Cアプリケーションからサードパーティアプリケーションにデータを転送する必要がない場合（たとえば、販売情報を1Cに送信するオンラインストアの統合：アカウンティング）、 1Cアプリケーションの側で設定を必要としない、Webサービスを介して作業するオプション（確認なし）。

専用の統合ソリューション

標準ソリューション「1C：Data Conversion」があります。これは、プラットフォームメカニズムを使用して標準1C構成間でデータを変換および交換しますが、サードパーティアプリケーションとの統合にも使用できます。

銀行ソリューションとの統合

10年以上前に1Cの専門家によって開発されたクライアントバンク標準は、実際にはロシアの業界標準になりました。この方向の次のステップは、 DirectBankテクノロジーです。これにより、支払い文書を銀行に送信し、1Cプログラムのボタンをクリックするだけでエンタープライズシステムプログラムから銀行の明細書を直接受け取ることができます。クライアントコンピューターに追加プログラムをインストールして起動する必要はありません。

給与プロジェクトでのデータ交換の標準もあります。

その他

1C：エンタープライズシステムとサイト間の通信プロトコル、商用情報の交換のためのCommerceML標準（Microsoft、Intel、Price.ruおよび他の企業と共同開発）、取得操作に関するデータ交換の標準は言及に値します。

1Cとの統合の方法