1C-თან ინტეგრაციის მეთოდები

რა არის ყველაზე მნიშვნელოვანი მოთხოვნები ბიზნეს აპლიკაციებისთვის? ზოგიერთი ყველაზე მნიშვნელოვანი ამოცანაა შემდეგი:

• აპლიკაციის ლოგიკის შეცვლის/ადაპტაციის სიმარტივე ბიზნეს ამოცანების შეცვლასთან.
• მარტივი ინტეგრაცია სხვა პროგრამებთან.

როგორ წყდება პირველი ამოცანა 1C-ში, მოკლედ იყო აღწერილი "მორგება და მხარდაჭერა" განყოფილებაში ამ მუხლის; ამ საინტერესო თემას მომავალ სტატიაში დავუბრუნდებით. დღეს ჩვენ ვისაუბრებთ მეორე ამოცანაზე, ინტეგრაციაზე.

ინტეგრაციის ამოცანები

ინტეგრაციის ამოცანები შეიძლება იყოს განსხვავებული. ზოგიერთი პრობლემის გადასაჭრელად საკმარისია მონაცემთა მარტივი ინტერაქტიული გაცვლა - მაგალითად, თანამშრომლების სიის გადარიცხვა ბანკში სახელფასო პლასტიკური ბარათების გასაცემად. უფრო რთული ამოცანებისთვის შეიძლება საჭირო გახდეს მონაცემთა სრულად ავტომატური გაცვლა, შესაძლოა გარე სისტემის ბიზნეს ლოგიკის მითითებით. არის ამოცანები, რომლებიც სპეციალიზირებულია ბუნებით, როგორიცაა ინტეგრაცია გარე მოწყობილობებთან (მაგალითად, საცალო აღჭურვილობა, მობილური სკანერები და ა.შ.) ან ძველებურ ან მაღალ სპეციალიზებულ სისტემებთან (მაგალითად, RFID ტეგების ამოცნობის სისტემებით). უაღრესად მნიშვნელოვანია თითოეული ამოცანისთვის ყველაზე შესაფერისი ინტეგრაციის მექანიზმის შერჩევა.

ინტეგრაციის ვარიანტები 1C-თან

1C აპლიკაციებთან ინტეგრაციის განხორციელების სხვადასხვა მიდგომა არსებობს; რომელი აირჩიოს დამოკიდებულია დავალების მოთხოვნებზე.

1. განხორციელებაზე დაფუძნებული ინტეგრაციის მექანიზმებიპლატფორმის მიერ მოწოდებული, საკუთარი სპეციალიზებული API 1C აპლიკაციის მხარეს (მაგალითად, ვებ ან HTTP სერვისების ნაკრები, რომელიც მოუწოდებს მესამე მხარის აპლიკაციებს მონაცემთა გაცვლისთვის 1C აპლიკაციასთან). ამ მიდგომის უპირატესობა არის API-ის წინააღმდეგობა 1C განაცხადის მხარეს განხორციელების ცვლილებების მიმართ. მიდგომის თავისებურება ის არის, რომ აუცილებელია სტანდარტული 1C გადაწყვეტის წყაროს კოდის შეცვლა, რაც შეიძლება პოტენციურად მოითხოვოს ძალისხმევა წყაროს კოდების შერწყმისას, კონფიგურაციის ახალ ვერსიაზე გადასვლისას. ამ შემთხვევაში, ახალი პროგრესული ფუნქციონალობა შეიძლება მოვიდეს სამაშველოში - კონფიგურაციის გაფართოებები. გაფართოებები, არსებითად, არის დანამატის მექანიზმი, რომელიც საშუალებას გაძლევთ შექმნათ დამატებები აპლიკაციის გადაწყვეტილებებში თავად აპლიკაციის გადაწყვეტილებების შეცვლის გარეშე. ინტეგრაციის API-ს კონფიგურაციის გაფართოებაში გადატანა საშუალებას მოგცემთ თავიდან აიცილოთ სირთულეები კონფიგურაციების შერწყმისას სტანდარტული გადაწყვეტის ახალ ვერსიაზე გადასვლისას.
2. პლატფორმის ინტეგრაციის მექანიზმების გამოყენება, რომლებიც უზრუნველყოფენ გარე წვდომას აპლიკაციის ობიექტის მოდელზე და არ საჭიროებს აპლიკაციის შეცვლას ან გაფართოების შექმნას. ამ მიდგომის უპირატესობა ის არის, რომ არ არის საჭირო 1C აპლიკაციის შეცვლა. მინუსი - თუ 1C აპლიკაცია გაუმჯობესდა, მაშინ შეიძლება საჭირო გახდეს გაუმჯობესება ინტეგრირებულ აპლიკაციაში. ამ მიდგომის მაგალითია OData პროტოკოლის გამოყენება ინტეგრაციისთვის, რომელიც განხორციელებულია 1C:Enterprise პლატფორმის მხარეს (დაწვრილებით ამის შესახებ ქვემოთ).
3. სტანდარტული 1C გადაწყვეტილებებში დანერგილი მზა განაცხადის პროტოკოლების გამოყენება. ბევრი სტანდარტული გადაწყვეტა 1C-დან და პარტნიორებიდან ახორციელებს საკუთარ აპლიკაციის პროტოკოლებს, რომლებიც ორიენტირებულია კონკრეტულ ამოცანებზე, პლატფორმის მიერ მოწოდებული ინტეგრაციის მექანიზმების საფუძველზე. ამ მექანიზმების გამოყენებისას არ არის საჭირო კოდის დაწერა 1C განაცხადის მხარეს, რადგან ჩვენ ვიყენებთ აპლიკაციის გადაწყვეტის სტანდარტულ შესაძლებლობებს. 1C აპლიკაციის მხარეს, ჩვენ მხოლოდ გარკვეული პარამეტრების გაკეთება გვჭირდება.

ინტეგრაციის მექანიზმები 1C:Enterprise პლატფორმაში

ფაილების იმპორტი/ექსპორტი

დავუშვათ, რომ ჩვენ გვაქვს ამოცანა ორმხრივი მონაცემთა გაცვლა 1C აპლიკაციასა და თვითნებურ აპლიკაციას შორის. მაგალითად, ჩვენ გვჭირდება პროდუქტების სიის სინქრონიზაცია (ნომენკლატურის დირექტორია) 1C აპლიკაციასა და თვითნებურ აპლიკაციას შორის.

ამ პრობლემის გადასაჭრელად შეგიძლიათ დაწეროთ გაფართოება, რომელიც ჩამოტვირთავს ნომენკლატურის დირექტორიას გარკვეული ფორმატის ფაილში (ტექსტი, XML, JSON, ...) და შეუძლია წაიკითხოს ეს ფორმატი.

პლატფორმა ახორციელებს XML-ში აპლიკაციის ობიექტების სერიულიზაციის მექანიზმს, როგორც უშუალოდ WriteXML/ReadXML გლობალური კონტექსტური მეთოდების მეშვეობით, ასევე XDTO (XML Data Transfer Objects) დამხმარე ობიექტის გამოყენებით.

ნებისმიერი ობიექტი 1C:Enterprise სისტემაში შეიძლება გადაიზარდოს XML წარმომადგენლობაში და პირიქით.

ეს ფუნქცია დააბრუნებს ობიექტის XML წარმოდგენას:

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

ასე გამოიყურება ნომენკლატურის დირექტორიის XML-ში ექსპორტი XDTO-ს გამოყენებით:

&НаСервере
Процедура Экспорт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 და/ან ვებ სერვისები მონაცემთა გადასაცემად.

HTTP და ვებ სერვისები

1C აპლიკაციებს შეუძლიათ განახორციელონ საკუთარი HTTP და ვებ სერვისები, ასევე დარეკონ HTTP და ვებ სერვისები, რომლებიც განხორციელებულია მესამე მხარის აპლიკაციების მიერ.

REST ინტერფეისი და OData პროტოკოლი

8.3.5 ვერსიიდან დაწყებული, 1C:Enterprise პლატფორმას შეუძლია ავტომატურად შექმენით REST ინტერფეისი მთელი განაცხადის გადაწყვეტისთვის. ნებისმიერი კონფიგურაციის ობიექტი (ცნობარი, დოკუმენტი, საინფორმაციო რეესტრი და ა.შ.) შეიძლება ხელმისაწვდომი გახდეს მონაცემების მისაღებად და შესაცვლელად REST ინტერფეისის საშუალებით. პლატფორმა იყენებს პროტოკოლს, როგორც წვდომის პროტოკოლს ოდატა ვერსია 3.0. OData სერვისების გამოქვეყნება ხორციელდება კონფიგურატორის მენიუდან "ადმინისტრაცია -> გამოქვეყნება ვებ სერვერზე", უნდა იყოს მონიშნული ველი "გამოქვეყნების სტანდარტული OData ინტერფეისი". მხარდაჭერილია Atom/XML და JSON ფორმატები. მას შემდეგ, რაც განაცხადის გადაწყვეტა გამოქვეყნდება ვებ სერვერზე, მესამე მხარის სისტემებს შეუძლიათ მასზე წვდომა REST ინტერფეისის მეშვეობით HTTP მოთხოვნების გამოყენებით. 1C აპლიკაციასთან მუშაობისთვის OData პროტოკოლით, პროგრამირება 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 кВт, режимы работы: тепло/холод"
}, …

მონაცემთა გარე წყაროები

ზოგიერთ შემთხვევაში, მონაცემთა გაცვლა მეშვეობით გარე მონაცემთა წყაროები შეიძლება იყოს საუკეთესო გამოსავალი. მონაცემთა გარე წყაროები არის 1C აპლიკაციის კონფიგურაციის ობიექტი, რომელიც საშუალებას გაძლევთ ურთიერთქმედება ნებისმიერ ODBC-თან თავსებად მონაცემთა ბაზასთან, როგორც წასაკითხად, ასევე წერისთვის. გარე მონაცემთა წყაროები ხელმისაწვდომია როგორც Windows-ზე, ასევე Linux-ზე.

მონაცემთა გაცვლის მექანიზმი

მონაცემთა გაცვლის მექანიზმი განკუთვნილია როგორც 1C:Enterprise-ზე დაფუძნებული გეოგრაფიულად განაწილებული სისტემების შესაქმნელად, ასევე მონაცემთა გაცვლის ორგანიზებისთვის სხვა საინფორმაციო სისტემებთან, რომლებიც არ არის დაფუძნებული 1C:Enterprise-ზე.

ეს მექანიზმი აქტიურად გამოიყენება 1C დანერგვაში და მისი დახმარებით მოგვარებული ამოცანების სპექტრი ძალიან ფართოა. ეს მოიცავს მონაცემთა გაცვლას ორგანიზაციის ფილიალებში დაინსტალირებულ 1C აპლიკაციებს შორის და 1C აპლიკაციასა და ონლაინ მაღაზიის ვებსაიტს შორის და მონაცემთა გაცვლას 1C სერვერის აპლიკაციასა და მობილურ კლიენტს შორის (შექმნილია 1C:Enterprise მობილური პლატფორმის გამოყენებით) და ბევრი რამ. მეტი.

მონაცემთა გაცვლის მექანიზმში ერთ-ერთი მთავარი კონცეფციაა გაცვლის გეგმა. გაცვლის გეგმა არის 1C განაცხადის პლატფორმის სპეციალური ტიპის ობიექტი, რომელიც განსაზღვრავს, კერძოდ, მონაცემთა შემადგენლობას, რომელიც მიიღებს მონაწილეობას გაცვლაში (რომელი დირექტორიები, დოკუმენტები, რეგისტრები და ა.შ.). გაცვლის გეგმა ასევე შეიცავს ინფორმაციას გაცვლის მონაწილეების (ე.წ. გაცვლითი კვანძების) შესახებ.
მონაცემთა გაცვლის მექანიზმის მეორე კომპონენტია ცვლილების რეგისტრაციის მექანიზმი. ეს მექანიზმი ავტომატურად აკონტროლებს სისტემას მონაცემების ცვლილებებზე, რომლებიც უნდა გადაეცეს საბოლოო მომხმარებლებს გაცვლის გეგმის ფარგლებში. ამ მექანიზმის გამოყენებით, პლატფორმა აკონტროლებს ცვლილებებს, რომლებიც მოხდა ბოლო სინქრონიზაციის შემდეგ და საშუალებას გაძლევთ მინიმუმამდე დაიყვანოთ მონაცემების რაოდენობა, რომელიც გადაცემულია მომდევნო სინქრონიზაციის სესიაზე.

მონაცემთა გაცვლა ხდება გარკვეული სტრუქტურის XML შეტყობინებების გამოყენებით. შეტყობინება შეიცავს მონაცემებს, რომლებიც შეიცვალა ბოლო სინქრონიზაციის შემდეგ კვანძთან და სერვისის გარკვეულ ინფორმაციას. შეტყობინებების სტრუქტურა მხარს უჭერს შეტყობინებების ნუმერაციას და საშუალებას გაძლევთ მიიღოთ დადასტურება მიმღების კვანძიდან, რომ შეტყობინებები მიღებულია. ასეთ დადასტურებას შეიცავს მიმღები კვანძიდან მოსულ თითოეულ შეტყობინებაში, ბოლო მიღებული შეტყობინების ნომრის სახით. შეტყობინებების ნუმერაცია საშუალებას აძლევს პლატფორმას გაიგოს, რა მონაცემები უკვე წარმატებით იქნა გადაცემული მიმღებ კვანძში და თავიდან აიცილოს ხელახალი გადაცემა მხოლოდ იმ მონაცემების გადაცემით, რომლებიც შეიცვალა მას შემდეგ, რაც გაგზავნის კვანძმა მიიღო ბოლო შეტყობინება მიმღები კვანძის მიერ მიღებული მონაცემების ქვითრით. ეს ოპერაციული სქემა უზრუნველყოფს გარანტირებულ მიწოდებას, თუნდაც არასანდო გადაცემის არხებით და შეტყობინებების დაკარგვით.

გარე კომპონენტები

რიგ შემთხვევებში, ინტეგრაციის პრობლემების გადაჭრისას, უნდა გაუმკლავდეთ კონკრეტულ მოთხოვნებს, მაგალითად, ურთიერთქმედების პროტოკოლებს, მონაცემთა ფორმატებს, რომლებიც არ არის გათვალისწინებული 1C: Enterprise პლატფორმაში. დავალებების ასეთი სპექტრისთვის, პლატფორმა უზრუნველყოფს გარე კომპონენტის ტექნოლოგია, რომელიც საშუალებას გაძლევთ შექმნათ დინამიურად დანამატი მოდულები, რომლებიც აფართოებენ 1C:Enterprise-ის ფუნქციონირებას.

მსგავსი მოთხოვნების მქონე დავალების ტიპიური მაგალითი იქნება 1C აპლიკაციის გადაწყვეტის ინტეგრირება საცალო აღჭურვილობით, დაწყებული სასწორებიდან სალარო აპარატებამდე და შტრიხკოდების სკანერებამდე. გარე კომპონენტები შეიძლება იყოს დაკავშირებული როგორც 1C: Enterprise სერვერის მხარეს, ასევე კლიენტის მხარეს (მათ შორის, მაგრამ არ შემოიფარგლება, ვებ კლიენტის, ასევე მობილური პლატფორმის შემდეგი ვერსია 1C: საწარმო). გარე კომპონენტების ტექნოლოგია უზრუნველყოფს საკმაოდ მარტივ და გასაგებ პროგრამულ ინტერფეისს (C++) კომპონენტების ურთიერთქმედებისთვის 1C:Enterprise პლატფორმასთან, რომელიც უნდა განხორციელდეს დეველოპერის მიერ.

შესაძლებლობები, რომლებიც იხსნება გარე კომპონენტების გამოყენებისას, ძალიან ფართოა. თქვენ შეგიძლიათ განახორციელოთ ურთიერთქმედება მონაცემთა გაცვლის კონკრეტული პროტოკოლის გამოყენებით გარე მოწყობილობებთან და სისტემებთან, შექმენით კონკრეტული ალგორითმები მონაცემთა და მონაცემთა ფორმატების დამუშავებისთვის და ა.შ.

მოძველებული ინტეგრაციის მექანიზმები

პლატფორმა უზრუნველყოფს ინტეგრაციის მექანიზმებს, რომლებიც არ არის რეკომენდებული ახალ გადაწყვეტილებებში გამოსაყენებლად; ისინი რჩებიან ჩამორჩენილი თავსებადობის მიზეზების გამო და ასევე იმ შემთხვევაში, თუ მეორე მხარე ვერ იმუშავებს უფრო თანამედროვე პროტოკოლებით. ერთ-ერთი მათგანი მუშაობს DBF ფორმატის ფაილებთან (მხარდაჭერილია ჩაშენებულ ენაში XBase ობიექტის გამოყენებით).

კიდევ ერთი მემკვიდრეობითი ინტეგრაციის მექანიზმი არის COM ტექნოლოგიის გამოყენება (ხელმისაწვდომია მხოლოდ Windows პლატფორმაზე). 1C: Enterprise პლატფორმა უზრუნველყოფს Windows-ის ინტეგრაციის ორ მეთოდს COM ტექნოლოგიის გამოყენებით: ავტომატიზაციის სერვერი და გარე კავშირი. ისინი ძალიან ჰგვანან, მაგრამ ერთ-ერთი ფუნდამენტური განსხვავება ისაა, რომ ავტომატიზაციის სერვერის შემთხვევაში, სრულფასოვანი 1C: Enterprise 8 კლიენტის აპლიკაცია იხსნება, ხოლო გარე კავშირის შემთხვევაში, შედარებით მცირე მიმდინარე COM. სერვერი გაშვებულია. ანუ, თუ თქვენ მუშაობთ ავტომატიზაციის სერვერის საშუალებით, შეგიძლიათ გამოიყენოთ კლიენტის აპლიკაციის ფუნქციონირება და შეასრულოთ მოქმედებები მომხმარებლის ინტერაქტიული მოქმედებების მსგავსი. გარე კავშირის გამოყენებისას შეგიძლიათ გამოიყენოთ მხოლოდ ბიზნეს ლოგიკის ფუნქციები და მათი შესრულება შესაძლებელია როგორც კავშირის კლიენტის მხარეს, სადაც იქმნება მიმდინარე COM სერვერი, ასევე შეგიძლიათ დარეკოთ ბიზნეს ლოგიკა 1C:Enterprise სერვერზე. მხარე.

COM ტექნოლოგია ასევე შეიძლება გამოყენებულ იქნას გარე სისტემებზე წვდომისათვის აპლიკაციის კოდიდან 1C:Enterprise პლატფორმაზე. ამ შემთხვევაში, 1C აპლიკაცია მოქმედებს როგორც COM კლიენტი. მაგრამ უნდა გვახსოვდეს, რომ ეს მექანიზმები იმუშავებს მხოლოდ იმ შემთხვევაში, თუ 1C სერვერი მუშაობს Windows გარემოში.

ინტეგრაციის მექანიზმები დანერგილი სტანდარტულ კონფიგურაციებში

საწარმოს მონაცემთა ფორმატი

1C რიგ კონფიგურაციაში (ქვემოთ სიაში), ზემოთ აღწერილი პლატფორმის მონაცემთა გაცვლის მექანიზმის საფუძველზე, დანერგილია მზა მექანიზმი მონაცემთა გაცვლის გარე აპლიკაციებთან, რომელიც არ საჭიროებს კონფიგურაციის წყაროს კოდის შეცვლას (მონაცემებისთვის მომზადება გაცვლა ხდება აპლიკაციის გადაწყვეტილებების პარამეტრებში):

• "1C:ERP Enterprise Management 2.0"
• "კომპლექსური ავტომატიზაცია 2"
• "საწარმოთა ბუღალტერია", გამოცემა 3.0
• "CORP საწარმოს აღრიცხვა", გამოცემა 3.0
• "საცალო", გამოცემა 2.0
• "საბაზისო ვაჭრობის მენეჯმენტი", გამოცემა 11
• ვაჭრობის მენეჯმენტი, გამოცემა 11
• "ხელფასები და პერსონალის მართვა CORP", გამოცემა 3

მონაცემთა გაცვლისთვის გამოყენებული ფორმატი არის EnterpriseDataXML-ზე დაფუძნებული. ფორმატი არის ბიზნესზე ორიენტირებული - მასში აღწერილი მონაცემთა სტრუქტურები შეესაბამება 1C პროგრამებში წარმოდგენილ ბიზნეს სუბიექტებს (დოკუმენტებს და დირექტორიას ელემენტებს), მაგალითად: დასრულების აქტი, ფულადი სახსრების მიღების ორდერი, კონტრაგენტი, ნივთი და ა.შ.

მონაცემთა გაცვლა 1C აპლიკაციასა და მესამე მხარის აპლიკაციას შორის შეიძლება მოხდეს:

• გამოყოფილი ფაილის დირექტორიაში
• FTP დირექტორიაში
• ვებ სერვისის მეშვეობით, რომელიც განლაგებულია 1C აპლიკაციის მხარეს. მონაცემთა ფაილი გადაეცემა როგორც პარამეტრი ვებ მეთოდებს
• ელფოსტით

ვებ სერვისის საშუალებით გაცვლის შემთხვევაში, მესამე მხარის აპლიკაცია დაიწყებს მონაცემთა გაცვლის სესიას 1C აპლიკაციის შესაბამისი ვებ მეთოდების გამოძახებით. სხვა შემთხვევაში, გაცვლის სესიის ინიციატორი იქნება 1C აპლიკაცია (მონაცემთა ფაილის შესაბამის დირექტორიაში განთავსებით ან მონაცემთა ფაილის კონფიგურირებულ ელ.ფოსტის მისამართზე გაგზავნით).
ასევე 1C მხარეს შეგიძლიათ დააკონფიგურიროთ რამდენად ხშირად მოხდება სინქრონიზაცია (ფაილის გაცვლის ვარიანტებისთვის დირექტორიასა და ელ.ფოსტის საშუალებით):

• გრაფიკის მიხედვით (მითითებული სიხშირით)
• ხელით; მომხმარებელს მოუწევს ხელით დაიწყოს სინქრონიზაცია ყოველ ჯერზე, როცა მას ეს დასჭირდება

შეტყობინებების აღიარება

1C აპლიკაციები ინახავს გაგზავნილი და მიღებული სინქრონიზაციის შეტყობინებების ჩანაწერებს და იგივეს მოელიან მესამე მხარის აპლიკაციებისგან. ეს საშუალებას გაძლევთ გამოიყენოთ შეტყობინებების ნუმერაციის მექანიზმი, რომელიც აღწერილია "მონაცემთა გაცვლის მექანიზმის" განყოფილებაში.

სინქრონიზაციის დროს, 1C აპლიკაციები გადასცემენ მხოლოდ ინფორმაციას ბოლო სინქრონიზაციის შემდეგ ბიზნეს სუბიექტებთან მომხდარი ცვლილებების შესახებ (გადაცემული ინფორმაციის ოდენობის შესამცირებლად). პირველი სინქრონიზაციის დროს, 1C აპლიკაცია ატვირთავს ყველა ბიზნეს სუბიექტს (მაგალითად, ელემენტის საცნობარო წიგნის ელემენტებს) EnterpriseData ფორმატში XML ფაილში (რადგან ისინი ყველა "ახალია" გარე აპლიკაციისთვის). მესამე მხარის აპლიკაციამ უნდა დაამუშაოს ინფორმაცია 1C-დან მიღებული XML ფაილიდან და მომდევნო სინქრონიზაციის სესიის დროს 1C-ზე გაგზავნილ ფაილში, სპეციალურ XML განყოფილებაში მოათავსოს ინფორმაცია, რომ 1C-დან გაგზავნა გარკვეული ნომრით წარმატებით დასრულდა. მიღებული. მიღების შეტყობინება არის სიგნალი 1C აპლიკაციისთვის, რომ ყველა ბიზნეს სუბიექტი წარმატებით იქნა დამუშავებული გარე აპლიკაციის მიერ და აღარ არის საჭირო მათ შესახებ ინფორმაციის გადაცემა. ქვითრის გარდა, მესამე მხარის აპლიკაციიდან XML ფაილი ასევე შეიძლება შეიცავდეს მონაცემებს აპლიკაციის მიერ სინქრონიზაციისთვის (მაგალითად, საქონლისა და მომსახურების გაყიდვის დოკუმენტები).

მიღების შეტყობინების მიღების შემდეგ, 1C აპლიკაცია აღნიშნავს ყველა ცვლილებას, რომელიც გადაცემულ იქნა წინა შეტყობინებაში, როგორც წარმატებით სინქრონიზებული. მხოლოდ არასინქრონიზებული ცვლილებები ბიზნეს სუბიექტებში (ახალი სუბიექტების შექმნა, არსებულის შეცვლა და წაშლა) გაიგზავნება გარე აპლიკაციაში მომდევნო სინქრონიზაციის სესიაზე.

გარე აპლიკაციიდან 1C აპლიკაციაში მონაცემების გადატანისას, სურათი შებრუნებულია. გარე აპლიკაციამ შესაბამისად უნდა შეავსოს XML ფაილის ქვითრის განყოფილება და განათავსოს ბიზნეს მონაცემები სინქრონიზაციისთვის EnterpriseData ფორმატში.

მონაცემთა გამარტივებული გაცვლა ხელის ჩამორთმევის გარეშე

მარტივი ინტეგრაციის შემთხვევებისთვის, როდესაც საკმარისია მხოლოდ მესამე მხარის აპლიკაციიდან ინფორმაციის გადატანა 1C აპლიკაციაში და 1C აპლიკაციიდან მესამე მხარის აპლიკაციაზე მონაცემების უკუ გადაცემა არ არის საჭირო (მაგალითად, ონლაინ ინტეგრაცია მაღაზია, რომელიც გადასცემს გაყიდვების ინფორმაციას 1C: ბუღალტრული აღრიცხვა), არის ვებ სერვისით მუშაობის გამარტივებული ვარიანტი (დადასტურების გარეშე), რომელიც არ საჭიროებს პარამეტრებს 1C აპლიკაციის მხარეს.

ინდივიდუალური ინტეგრაციის გადაწყვეტილებები

არსებობს სტანდარტული გადაწყვეტა "1C: მონაცემთა კონვერტაცია", რომელიც იყენებს პლატფორმის მექანიზმებს სტანდარტული 1C კონფიგურაციებს შორის მონაცემების კონვერტაციისა და გაცვლისთვის, მაგრამ ასევე შეიძლება გამოყენებულ იქნას მესამე მხარის აპლიკაციებთან ინტეგრაციისთვის.

ინტეგრაცია საბანკო გადაწყვეტილებებთან

სტანდარტული "კლიენტ ბანკი"1C სპეციალისტების მიერ 10 წელზე მეტი ხნის წინ შემუშავებული, რეალურად გახდა ინდუსტრიის სტანდარტი რუსეთში. შემდეგი ნაბიჯი ამ მიმართულებით არის ტექნოლოგია DirectBank, რომელიც საშუალებას გაძლევთ გააგზავნოთ გადახდის დოკუმენტები ბანკში და მიიღოთ განცხადებები ბანკიდან პირდაპირ 1C:Enterprise სისტემის პროგრამებიდან 1C პროგრამაში ერთი ღილაკის დაჭერით; არ საჭიროებს დამატებითი პროგრამების ინსტალაციას და გაშვებას კლიენტის კომპიუტერზე.

ასევე არსებობს სახელფასო პროექტებში მონაცემთა გაცვლის სტანდარტი.

სხვა

აღნიშვნის ღირსია გაცვლის პროტოკოლი 1C: Enterprise სისტემასა და ვებსაიტს შორის, კომერციული ინფორმაციის გაცვლის სტანდარტი CommerceML (შემუშავებული Microsoft-თან, Intel-თან, Price.ru-სთან და სხვა კომპანიებთან ერთად), ტრანზაქციების შესაძენად მონაცემთა გაცვლის სტანდარტი.

წყარო: www.habr.com