Integreringsmetoder med 1C

Vilka är de viktigaste kraven för affärsapplikationer? Några av de främsta är följande uppgifter:

• Lätthet att ändra/anpassa applikationens arbetslogik till förändrade affärsbehov.
• Lätthet att integrera med andra applikationer.

Så som den första uppgiften löses i 1C, beskrevs kort i avsnittet "Anpassning och stöd" denna artikel; vi kommer återkomma till detta intressanta ämne i en av kommande artiklar. Idag handlar det om den andra uppgiften, om integration.

Integrationsuppgifter

Integrationsuppgifter kan vara olika. För vissa kan en enkel interaktiv datautbyte vara tillräcklig – till exempel för att överföra en lista över anställda till banken för utfärdande av lönekort. För mer komplexa uppgifter kan en helt automatiserad datautbyte vara nödvändig, eventuellt med anrop till affärslogiken i ett externt system. Det finns uppgifter av specialiserad karaktär, såsom integration med extern utrustning (till exempel försäljningsutrustning, mobila skannrar osv.) eller med arvtagna eller specialiserade system (till exempel med RFID-handlingar). Det är extremt viktigt för varje uppgift att välja den mest lämpliga integrationsmekanismen.

Integrationsmöjligheter med 1C

Det finns olika tillvägagångssätt för att implementera integration med 1C-applikationer, vilket man ska välja beror på uppgiftens krav.

1. Implementering baserad på integrationsmekanismer, som tillhandahålls av plattformen, ett eget specialiserat API på sidan av 1C-applikationen (till exempel en uppsättning web- eller HTTP-tjänster, som kommer att anropa externa applikationer för att utbyta data med 1C-applikationen). Fördelarna med denna metod är API:ts motståndskraft mot förändringar i implementeringen på sidan av 1C-applikationen. Kännetecknet för metoden är att man behöver ändra källkoden för standardlösningen i 1C, vilket potentiellt kan kräva insatser vid sammanslagning av källkoder vid övergång till en ny version av konfigurationen. I detta fall kan den nya progressiva funktionen hjälpa till – konfigurationsutvidgningar. Tillägg är i grunden en plugin-mekanism som gör det möjligt att skapa tillägg för applikationslösningar utan att ändra själva applikationslösningarna. Att flytta integrations-API:et till ett konfigurationstillägg gör det möjligt att undvika svårigheter vid sammanslagning av konfigurationer när man går över till en ny version av den standardiserade lösningen.
2. Användning av integrationsmekanismerna på plattformen som tillhandahåller extern åtkomst till applikationsmodellens objekt utan att kräva modifiering av applikationen eller skapande av ett tillägg. Fördelen med denna metod är att applikationen 1C inte behöver ändras. Nackdelen är att om applikationen 1C har modifierats kan det krävas justeringar i den integrerade applikationen. Ett exempel på denna metod är användningen av OData-protokollet för integration, som implementerats på 1C:Enterprise-plattformens sida (mer om det nedan).
3. Användning av färdiga applikationsprotokoll implementerade i standardlösningar från 1C. Många standardlösningar från 1C och dess partners implementerar sina egna applikationsprotokoll baserade på integrationsmekanismerna som tillhandahålls av plattformen, riktade mot specifika uppgifter. Vid användning av dessa mekanismer krävs ingen kodning på 1C-applikationens sida, eftersom vi använder de inbyggda funktionerna i applikationslösningen. På 1C-applikationens sida behöver vi bara göra vissa inställningar.

Integrationsmekanismer i 1C:Enterprise-plattformen

Import/export av filer

Låt oss anta att vi står inför uppgiften att ha en tvåvägsdataöverföring mellan 1C-applikationen och en godtycklig applikation. Till exempel, vi behöver synkronisera produktlistan (register Nomenklatur) mellan 1C-applikationen och en godtycklig applikation.

För att lösa denna uppgift kan man skriva ett tillägg som exporterar Nomenklaturregistret till en fil i ett visst format (text, XML, JSON, ...) och kan läsa detta format.

Plattformen har implementerat en mekanism för serialisering av applikationsobjekt till XML både direkt, genom metoderna i den globala kontexten SkrivaXML/LäsaXML, samt med hjälp av det hjälpbjektet XDTO (XML Data Transfer Objects).

Vilket objekt som helst i systemet 1C:Enterprise kan serialiseras till XML-representation och vice versa.

Denna funktion kommer att returnera en representation av objektet i form av XML:

Funktionen Objekt_I_XML(Objekt)
    RegistreraXML = Ny RegistreraXML();
    RegistreraXML.SättaSträng();
    SkrivaXML(RegistreraXML, Objekt);
    Retur RegistreraXML.Stäng();
SlutFunktion

så här kommer exporten av katalogen Nomenklatur att se ut i XML med hjälp av XDTO:

&

Procedur ExportXMLPåServern()	
	NySserializatorXDTO = SserializatorXDTO;
	NyRegistreraXML = Ny RegistreraXML();
	NyRegistreraXML.ÖppnaFil("C:DataNomenklatur.xml", "UTF-8");
	
	NyRegistreraXML.SkrivaTillKallelseXML();
	NyRegistreraXML.SkrivaStartElement("KatalogNomenklatur");
	
	Urval = Kataloger.Nomenklatur.Välja();
	
	Medans Urval.Nästa() Gör 
		ObjektNomenklatur = Urval.FåObjekt();
		NySserializatorXDTO.SkrivaXML(NyRegistreraXML, ObjektNomenklatur, TillämpningsTypXML.Uttrycklig);
	SlutPåGör;
	
	NyRegistreraXML.SkrivaSlutElement();
	NyRegistreraXML.Stäng();	
SlutProcedur

Genom en enkel omarbetning av koden exporterar vi katalogen till JSON. Varor kommer att lagras i en array; för variation ska vi ge den engelskspråkiga syntaxversionen:

&

Procedur ExportJSONPåServern()
	NyXDTOSerializator = XDTOSerializator;
	NyJSONSkribent = Ny JSONSkribent();
	NyJSONSkribent.ÖppnaFil("C:DataNomenklatur.json", "UTF-8");
	
	NyJSONSkribent.SkrivaStartObjekt();
	NyJSONSkribent.SkrivaEgenskapsNamn("KatalogNomenklatur");
	NyJSONSkribent.SkrivaStartArray();
	
	Urval = Kataloger.Nomenklatur.Välja();	
	
	Medans Urval.Nästa() Gör 
		NomenklaturObjekt = Urval.FåObjekt();
		
		NyJSONSkribent.SkrivaStartObjekt();
		
		NyJSONSkribent.SkrivaEgenskapsNamn("Nomenklatur");
		NyXDTOSerializator.SkrivaJSON(NyJSONSkribent, NomenklaturObjekt, XMLTypTillämpning.Underförstådd);
		
		NyJSONSkribent.SkrivaSlutObjekt();
	SlutPåGör;
	
	NyJSONSkribent.SkrivaSlutArray();
	NyJSONSkribent.SkrivaSlutObjekt();
	NyJSONSkribent.Stäng();	
SlutProcedur

Därefter återstår det bara att överföra data till slutkunden. Plattformen 1C:Enterprise stödjer de grundläggande internetprotokollen HTTP, FTP, POP3, SMTP, IMAP, inklusive deras säkra versioner. Data kan också överföras med HTTP och/eller webbservicer.

HTTP- och webbservicer

1C-appar kan implementera sina egna HTTP- och webbservicer, samt anropa HTTP- och webbservicer som implementerats av externa appar.

REST-gränssnitt och protokoll OData

Från version 8.3.5 kan plattformen 1C:Enterprise automatiskt skapa REST-gränssnitt för hela applikationslösningen. Varje konfigurationsobjekt (katalog, dokument, register etc.) kan göras tillgängligt för att hämta och modifiera data via REST-gränssnitt. Som åtkomstprotokoll använder plattformen ett protokoll OData version 3.0. Publicering av OData-tjänster görs från menyn Konfigurator "Administration -> Publicering på webbserver", och rutan "Publicera standard OData-gränssnitt" måste vara markerad. Formaten atom/XML och JSON stöds. När den applikationen har publicerats på webbservern kan externa system komma åt den via REST-gränssnittet med hjälp av HTTP-förfrågningar. För att arbeta med applikationen 1C via OData-protokollet krävs ingen programmering på 1C-sidan.

Så, URL som ser ut som http:////odata/standard.odata/Catalog_Produkter ger oss innehållet i produktkatalogen i XML-format — en samling av element entry (meddelandets huvud har utelämnats för korthet):

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