🥇1C との統合方法 | プロホスター

ビジネスアプリケーションにとって最も重要な要件は何ですか? 最も重要なタスクには次のようなものがあります。

変化するビジネスタスクに合わせてアプリケーションロジックを簡単に変更/適応できます。
他のアプリケーションと簡単に統合できます。

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

統合タスク

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

1C との統合オプション

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

実装ベース統合メカニズムプラットフォームによって提供される、1C アプリケーション側の独自の特殊 API (たとえば、1C アプリケーションとデータを交換するためにサードパーティアプリケーションを呼び出す一連の Web サービスまたは HTTP サービス)。このアプローチの利点は、1C アプリケーション側の実装の変更に対する API の耐性です。このアプローチの特徴は、標準 1C ソリューションのソースコードを変更する必要があることであり、新しいバージョンの構成に移行するときにソースコードをマージする際に労力が必要になる可能性があります。この場合、新しい進歩的な機能が役に立ちます。構成拡張。拡張機能は本質的に、アプリケーションソリューション自体を変更せずにアプリケーションソリューションへの追加機能を作成できるようにするプラグインメカニズムです。統合 API を構成拡張機能に移動すると、標準ソリューションの新しいバージョンに移行するときに構成をマージする際の問題を回避できます。
アプリケーションオブジェクトモデルへの外部アクセスを提供し、アプリケーションの変更や拡張機能の作成を必要としないプラットフォーム統合メカニズムを使用します。このアプローチの利点は、1C アプリケーションを変更する必要がないことです。マイナス - 1C アプリケーションが改善された場合、統合アプリケーションでも改善が必要になる可能性があります。このアプローチの一例は、1C:Enterprise プラットフォーム側に実装される統合のための OData プロトコルの使用です (詳細は以下を参照)。
標準の 1C ソリューションに実装された既製のアプリケーションプロトコルの使用。 1C およびパートナーの多くの標準ソリューションは、プラットフォームによって提供される統合メカニズムに基づいて、特定のタスクに焦点を当てた独自のアプリケーションプロトコルを実装しています。これらのメカニズムを使用する場合、1C アプリケーション側でコードを記述する必要はありません。アプリケーションソリューションの標準機能を使用します。 1C アプリケーション側では、特定の設定を行うだけで済みます。

1C:Enterprise プラットフォームの統合メカニズム

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

1C アプリケーションと任意のアプリケーションの間で双方向のデータ交換を行うというタスクに直面しているとします。たとえば、1C アプリケーションと任意のアプリケーションの間で製品のリスト (命名ディレクトリ) を同期する必要があります。

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

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

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

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

Функция Объект_В_XML(Объект)
    ЗаписьXML = Новый ЗаписьXML();
    ЗаписьXML.УстановитьСтроку();
    ЗаписатьXML(ЗаписьXML, Объект);
    Возврат ЗаписьXML.Закрыть();
КонецФункции

XDTO を使用して Nomenclature ディレクトリを 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:Enterprise プラットフォームは、安全なバージョンを含む主要なインターネットプロトコル HTTP、FTP、POP3、SMTP、IMAP をサポートします。 HTTP サービスや Web サービスを使用してデータを転送することもできます。

HTTP および Web サービス

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

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

バージョン 8.3.5 以降、1C:Enterprise プラットフォームは自動的に RESTインターフェースを作成するアプリケーションソリューション全体に。任意の構成オブジェクト (ディレクトリ、ドキュメント、情報レジスタなど) を、REST インターフェイス経由でデータの受信および変更に使用できるようにすることができます。プラットフォームはアクセスプロトコルとしてプロトコルを使用します Oデータバージョン3.0。 OData サービスの公開は、Configurator メニューの「管理 -> Web サーバーでの公開」から実行します。「標準 OData インターフェイスを公開する」チェックボックスをオンにする必要があります。 Atom/XML および JSON 形式がサポートされています。アプリケーションソリューションが Web サーバー上で公開されると、サードパーティシステムは HTTP リクエストを使用して REST インターフェイス経由でアプリケーションソリューションにアクセスできるようになります。 OData プロトコル経由で 1C アプリケーションを操作するには、1C 側でのプログラミングは必要ありません。

したがって、次のような URL http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура XML 形式で命名カタログの内容 (エントリ要素のコレクション) が返されます (簡潔にするためにメッセージタイトルは省略されています)。

<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  >
			<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 に文字列「?$format=application/json」を追加すると、命名カタログの内容が JSON 形式で取得されます (フォームの URL http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура?$format=application/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 кВт, режимы работы: тепло/холод"
}, …

外部データソース

場合によっては、外部データソース最良の解決策かもしれません。外部データソースは、読み取りと書き込みの両方で ODBC 互換データベースと対話できるようにする 1C アプリケーション構成オブジェクトです。外部データソースは Windows と Linux の両方で利用できます。

データ交換メカニズム

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

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

データ交換メカニズムの重要な概念の 1 つは交換計画です。交換計画は、XNUMXC アプリケーションプラットフォームの特別な種類のオブジェクトであり、特に交換に参加するデータの構成 (どのディレクトリ、ドキュメント、レジスタなど) を決定します。交換計画には、交換参加者 (いわゆる交換ノード) に関する情報も含まれます。
データ交換メカニズムの XNUMX 番目のコンポーネントは、変更登録メカニズムです。このメカニズムは、交換計画の一環としてエンドユーザーに転送する必要があるデータの変更についてシステムを自動的に監視します。このメカニズムを使用すると、プラットフォームは最後の同期以降に発生した変更を追跡し、次の同期セッション中に転送されるデータの量を最小限に抑えることができます。

データ交換は、特定の構造の XML メッセージを使用して行われます。メッセージには、ノードとの最後の同期以降に変更されたデータと一部のサービス情報が含まれています。メッセージ構造はメッセージの番号付けをサポートしており、メッセージが受信されたことを受信者ノードから確認できるようになります。このような確認は、最後に受信したメッセージの番号の形式で、受信ノードから送信される各メッセージに含まれます。メッセージに番号を付けることで、プラットフォームはどのデータが受信ノードにすでに正常に送信されたかを把握でき、受信ノードが受信したデータの受信確認を含む最後のメッセージを送信ノードが受信してから変更されたデータのみを送信することで再送信を回避できます。この運用スキームにより、信頼性の低い伝送チャネルやメッセージ損失があっても確実に配信が保証されます。

外部コンポーネント

多くの場合、統合の問題を解決する際には、1C:Enterprise プラットフォームでは提供されていない対話プロトコルやデータ形式などの特定の要件に対処する必要があります。このような幅広いタスクに対して、プラットフォームは次の機能を提供します。外部コンポーネント技術を使用すると、1C:Enterprise の機能を拡張するプラグインモジュールを動的に作成できます。

同様の要件を持つタスクの典型的な例としては、1C アプリケーションソリューションと、秤からレジやバーコードスキャナに至るまでの小売機器との統合が挙げられます。外部コンポーネントは、1C:Enterprise サーバー側とクライアント側 (Web クライアント、モバイルプラットフォームの次期バージョン 1C:エンタープライズ)。外部コンポーネントのテクノロジは、コンポーネントと 1C:Enterprise プラットフォームとの対話のための非常にシンプルでわかりやすいソフトウェア (C++) インターフェイスを提供します。これは開発者が実装する必要があります。

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

時代遅れの統合メカニズム

このプラットフォームは、新しいソリューションでの使用が推奨されない統合メカニズムを提供します。これらは、下位互換性の理由と、相手がより新しいプロトコルを使用できない場合に備えて残されます。そのうちの XNUMX つは、DBF 形式ファイルの操作です (XBase オブジェクトを使用する組み込み言語でサポートされています)。

もう 1 つの従来の統合メカニズムは、COM テクノロジの使用です (Windows プラットフォームでのみ利用可能)。 1C:Enterprise プラットフォームは、COM テクノロジを使用した Windows の 8 つの統合方法 (オートメーションサーバーと外部接続) を提供します。これらは非常に似ていますが、根本的な違いの 1 つは、オートメーションサーバーの場合は本格的な XNUMXC:Enterprise XNUMX クライアントアプリケーションが起動され、外部接続の場合は比較的小さなインプロセス COM が起動されることです。サーバーが起動されます。つまり、オートメーションサーバーを介して作業する場合、クライアントアプリケーションの機能を使用して、ユーザーの対話型アクションと同様のアクションを実行できます。外部接続を使用する場合、ビジネスロジック関数のみを使用できます。これらの関数は、インプロセス COM サーバーが作成される接続のクライアント側と、XNUMXC:Enterprise サーバー上のビジネスロジックの呼び出しの両方で実行できます。側。

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

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

エンタープライズデータフォーマット

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

「1C:ERPエンタープライズマネジメント2.0」
「複雑な自動化2」
『企業会計』第 3.0 版
「CORP 企業の会計」、第 3.0 版
「小売」、エディション 2.0
『基本貿易管理』第 11 版
貿易管理、第 11 版
『給与・人事管理 CORP』第 3 版

データ交換に使用される形式は、エンタープライズデータ、XML に基づいています。この形式はビジネス指向です。この形式に記述されているデータ構造は、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: データ変換」があります。これは、標準の 1C 構成間でデータを変換および交換するためのプラットフォームメカニズムを使用しますが、サードパーティアプリケーションとの統合にも使用できます。

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

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

また、給与プロジェクトにおけるデータ交換の標準.

他の

言及する価値がある 1C:Enterprise システムと Web サイト間のプロトコル交換、商業情報交換標準コマースML (Microsoft、Intel、Price.ru およびその他の企業と共同開発)、トランザクションを取得するためのデータ交換の標準.

出所： habr.com

1Cとの統合方法

統合タスク

1C との統合オプション

1C:Enterprise プラットフォームの統合メカニズム

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

HTTP および Web サービス

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

外部データソース

データ交換メカニズム

外部コンポーネント

時代遅れの統合メカニズム

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

エンタープライズデータフォーマット

メッセージの確認

ハンドシェイクを必要としない簡素化されたデータ交換

カスタム統合ソリューション

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

他の

コメントを追加します返信をキャンセル

1Cとの統合方法

統合タスク

1C との統合オプション

1C:Enterprise プラットフォームの統合メカニズム

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

HTTP および Web サービス

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

外部データソース

データ交換メカニズム

外部コンポーネント

時代遅れの統合メカニズム

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

エンタープライズデータフォーマット

メッセージの確認

ハンドシェイクを必要としない簡素化されたデータ交換

カスタム統合ソリューション

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

他の

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル