Måter å integrere med 1C

Hva er de viktigste kravene til forretningsapplikasjoner? Noen av de mest sentrale inkluderer følgende oppgaver:

• Letthet i å endre/tilpasse applikasjonens logikk til skiftende forretningsbehov.
• Letthet i integrasjon med andre applikasjoner.

Hvordan den første oppgaven løses i 1C, ble kort beskrevet i seksjonen «Tilpasning og støtte»; this articlevi vil komme tilbake til dette interessante emnet i en av fremtidige artikler. I dag skal vi snakke om den andre oppgaven, integrasjon.

Integrasjonsoppgaver

Integrasjonsoppgavene kan være forskjellige. For å løse enkelte oppgaver er det tilstrekkelig med en enkel interaktiv datautveksling – for eksempel for å sende en liste over ansatte til banken for utstedelse av lønnskort. For mer komplekse oppgaver kan det være nødvendig med en helt automatisert datautveksling, muligens med henvisning til forretningslogikken i det eksterne systemet. Det finnes også spesialiserte oppgaver, som integrasjon med eksternt utstyr (for eksempel betalingssystemer, mobile skannere osv.) eller med arvet eller spesialiserte systemer (for eksempel RFID-lesesystemer). Det er avgjørende å velge den mest hensiktsmessige integrasjonsmekanismen for hver oppgave.

Integrasjonsmuligheter med 1C

Det finnes ulike tilnærminger til å implementere integrasjon med 1C-applikasjoner, hvilken som velges avhenger av kravene til oppgaven.

1. Implementering basert på integrasjonsmekanismer, levert av plattformen, eller sitt eget spesialiserte API på siden av 1C-applikasjonen (for eksempel en serie Web- eller HTTP-tjenester som vil bli kalt av tredjepartsapplikasjoner for datautveksling med 1C-applikasjonen). Fordelen med denne tilnærmingen er robustheten til API-et mot endringer i implementeringen på siden av 1C-applikasjonen. En særtrekk ved tilnærmingen er at det kreves endringer i kildekoden til den typiske løsningen i 1C, noe som potensielt kan kreve innsats ved sammenslåing av kildekodene når man går over til en ny konfigurasjonsversjon. I dette tilfellet kan ny progresiv funksjonalitet komme til hjelp – konfigurasjonsutvidelser. Utvidelser er i essensen en plugin-mekanisme som gjør det mulig å lage tillegg til applikasjonsløsninger uten å endre selve applikasjonsløsningene. Å flytte integrasjons-API-en til konfigurasjonsutvidelsen vil unngå komplikasjoner ved sammenslåing av konfigurasjoner når man går over til en ny versjon av standardløsningen.
2. Bruken av integrasjonsmekanismer fra plattformen som gir ekstern tilgang til objektmodellen i applikasjonen uten at det kreves endringer i applikasjonen eller opprettelse av utvidelser. Fordelen med denne tilnærmingen er at man ikke trenger å endre 1C-applikasjonen. Ulempen er at hvis 1C-applikasjonen har blitt modifisert, kan det være nødvendig med tilpasninger i den integrerte applikasjonen. Et eksempel på en slik tilnærming er bruk av OData-protokollen for integrasjonen, implementert på 1C:Enterprise-plattformen (mer om det nedenfor).
3. Bruk av ferdige applikasjonsprotokoller implementert i standardløsninger fra 1C. Mange standardløsninger fra 1C og partnere implementerer sine egne applikasjonsprotokoller basert på integrasjonsmekanismene som tilbys av plattformen, og disse er rettet mot spesifikke oppgaver. Når man bruker disse mekanismene, er det ikke nødvendig å skrive kode på 1C-applikasjonssiden, da vi benytter de innebygde mulighetene til applikasjonsløsningen. På 1C-applikasjonen må vi bare utføre visse innstillinger.

Integrasjonsmekanismer i 1C:Enterprise-plattformen

Import/eksport av filer

La oss anta at vi står overfor oppgaven med toveiskommunikasjon mellom 1C-applikasjonen og en vilkårlig applikasjon. For eksempel trenger vi å synkronisere produktlisten (Oppslagsord Nomenklatur) mellom 1C-applikasjonen og en vilkårlig applikasjon.

For å løse denne oppgaven kan vi skrive en utvidelse som eksporterer oppslagsord Nomenklatur til en fil i et bestemt format (tekst, XML, JSON, …) og kan lese dette formatet.

Plattformen har implementert en mekanisme for serialisering av applikasjonsobjekter til XML både direkte, gjennom metodene i global kontekst SkriveXML/LeseXML, og ved hjelp av et hjelpeobjekt XDTO (XML Data Transfer Objects).

Ethvert objekt i 1C:Enterprise-systemet kan bli serialisert til XML-representasjon og omvendt.

Denne funksjonen vil returnere objektets representasjon i form av 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

Далее останется только передать данные конечному потребителю. Платформа 1С:Предприятие поддерживает основные интернет-протоколы HTTP, FTP, POP3, SMTP, IMAP, включая их безопасные версии. Также для передачи данных можно использовать HTTP и/или Web-сервисы.

HTTP- и веб-сервисы

Приложения 1С могут реализовывать свои HTTP- и веб-сервисы, а также вызывать HTTP- и веб-сервисы, реализованные сторонними приложениями.

REST интерфейс и протокол OData

Начиная с версии 8.3.5 платформа 1С:Предприятие может автоматически формировать REST интерфейс для всего прикладного решения. Любой объект конфигурации (справочник, документ, регистр сведений и т.д.) можно сделать доступным для получения и модификации данных через REST интерфейс. В качестве протокола доступа платформа использует протокол OData versjon 3.0. Publisering av OData-tjenester utføres fra menyen i Konfiguratoren «Administrasjon -> Publisering på webserver», avmerkingsboksen «Publiser standard OData-grensesnitt» må være merket. Atom/XML og JSON-formater støttes. Etter at den applikative løsningen er publisert på webserveren, kan tredjepartssystemer få tilgang til den via REST-grensesnittet ved hjelp av HTTP-forespørsel. For å arbeide med 1C-applikasjonen via OData-protokollen kreves det ingen programmering på 1C-siden.

Dermed vil en URL som http:////odata/standard.odata/Catalog_Nomenklatura returnere innholdet i katalogen Nomenklatura i XML-format — en samling elementer entry (meldingshodet utelatt for kortfattethet):

http://server/Config/odata/standard.odata/Catalog_Nomenkatura(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')