Integrationsmöglichkeiten mit 1C

Welche wichtigsten Anforderungen werden an Geschäftsapplikationen gestellt? Zu den wichtigsten gehören die folgenden Aufgaben:

• Die einfache Änderung/Anpassung der Arbeitslogik der Anwendung an sich ändernde Geschäftsaufgaben.
• Die einfache Integration mit anderen Anwendungen.

Wie in 1C die erste Aufgabe gelöst wird, wurde kurz im Abschnitt „Anpassung und Unterstützung“ beschrieben, dieses Artikels; wir werden auf dieses interessante Thema in einem der kommenden Artikel zurückkommen. Heute geht es um die zweite Aufgabe, die Integration.

Integrationsaufgaben

Integrationsaufgaben können unterschiedlich sein. Für einige reicht ein einfacher interaktiver Datenaustausch – zum Beispiel für die Übermittlung einer Liste von Mitarbeitern an die Bank zur Ausstellung von Gehaltskarten. Für komplexere Aufgaben kann ein vollständig automatisierter Datenaustausch erforderlich sein, möglicherweise mit Zugriff auf die Geschäftslogik eines externen Systems. Es gibt Aufgaben, die einen spezialisierten Charakter haben, wie die Integration mit externen Geräten (z. B. Handelsgeräten, mobilen Scannern usw.) oder mit veralteten oder spezialisierten Systemen (z. B. mit RFID-Tag-Erkennungssystemen). Es ist äußerst wichtig, für jede Aufgabe den passendsten Integrationsmechanismus auszuwählen.

Integrationsmöglichkeiten mit 1C

Es gibt verschiedene Ansätze zur Umsetzung der Integration mit 1C-Anwendungen, welcher davon gewählt wird, hängt von den Anforderungen der Aufgabe ab.

1. Implementierung auf der Grundlage von Integrationsmechanismen, die von der Plattform bereitgestellt werden, eines eigenen spezialisierten APIs auf der Seite der 1C-Anwendung (z. B. einer Reihe von Web- oder HTTP-Diensten, die externe Anwendungen aufrufen, um Daten mit der 1C-Anwendung auszutauschen). Der Vorteil dieses Ansatzes ist die Stabilität des APIs gegenüber Änderungen der Implementierung auf Seiten der 1C-Anwendung. Ein Merkmal des Ansatzes ist, dass der Quellcode der typischen 1C-Lösung geändert werden muss, was potenziell Aufwand bei der Zusammenführung der Quellcodes beim Übergang auf eine neue Version der Konfiguration verursachen kann. In diesem Fall kann neue progressive Funktionalität hilfreich sein – die Erweiterungen der Konfiguration. Erweiterungen sind im Wesentlichen ein Plugin-Mechanismus, der es ermöglicht, Ergänzungen für Anwendungs-lösungen zu erstellen, ohne die eigentlichen Anwendungs-lösungen zu ändern. Die Auslagerung der Integrations-API in die Konfigurations-erweiterung ermöglicht es, Schwierigkeiten beim Zusammenführen von Konfigurationen beim Wechsel auf eine neue Version der Standardlösung zu vermeiden.
2. Die Nutzung der Integrationsmechanismen der Plattform, die externen Zugriff auf das Objektmodell der Anwendung ermöglichen und keine Änderungen an der Anwendung oder die Erstellung einer Erweiterung erfordern. Der Vorteil dieses Ansatzes ist, dass die Anwendung 1C nicht geändert werden muss. Der Nachteil besteht darin, dass, wenn die Anwendung 1C angepasst wurde, möglicherweise Anpassungen in der zu integrierenden Anwendung erforderlich sind. Ein Beispiel für diesen Ansatz ist die Nutzung des OData-Protokolls zur Integration, das auf der Seite der Plattform 1C:Enterprise implementiert ist (nähere Informationen dazu weiter unten).
3. Die Nutzung fertiger Anwendungsprotokolle, die in den Standardlösungen von 1C implementiert sind. Viele Standardlösungen von 1C und Partnern implementieren auf der Grundlage der von der Plattform bereitgestellten Integrationsmechanismen ihre eigenen Anwendungsprotokolle, die auf spezifische Aufgaben ausgerichtet sind. Bei der Verwendung dieser Mechanismen ist es nicht erforderlich, Code auf der Seite der Anwendung 1C zu schreiben, da wir die Standardfunktionen der Anwendungs-lösung nutzen. Auf der Seite der Anwendung 1C müssen wir nur bestimmte Einstellungen vornehmen.

Integrationsmechanismen in der Plattform 1C:Enterprise

Import/Export von Dateien

Angenommen, wir haben die Aufgabe eines bidirektionalen Datenaustauschs zwischen der Anwendung 1C und einer beliebigen Anwendung. Zum Beispiel müssen wir die Liste der Produkte (Verzeichnis Nomenklatur) zwischen der Anwendung 1C und einer beliebigen Anwendung synchronisieren.

Zur Lösung dieser Aufgabe könnte man eine Erweiterung schreiben, die das Verzeichnis Nomenklatur in eine Datei eines bestimmten Formats (Text, XML, JSON, ...) exportiert und in der Lage ist, dieses Format zu lesen.

In der Plattform ist ein Mechanismus zur Serialisierung von Anwendungsobjekten in XML sowohl direkt über die Methoden des globalen Kontextes ЗаписатьXML/ЧтениеXML als auch mithilfe des Hilfsobjekts XDTO (XML Data Transfer Objects) implementiert.

Jedes Objekt im System 1C:Enterprise kann in eine XML-Darstellung und umgekehrt serialisiert werden.

Diese Funktion gibt die Darstellung des Objekts im XML-Format zurück:

Funktion Objekt_Im_XML(Objekt)
    AufzeichnungsXML = Neuer AufzeichnungsXML();
    AufzeichnungsXML.SetzeZeile();
    SchreibeXML(AufzeichnungsXML, Objekt);
    Rückgabe AufzeichnungsXML.Schließen();
EndeFunktion

So wird der Export des Verzeichnisses Nomenklatur in XML mit Hilfe von XDTO aussehen:

&AtServer
Prozedur ExportXMLAufServer()	
	NeuerSerializerXDTO  = SerializerXDTO;
	NeueAufzeichnungXML = Neuer AufzeichnungsXML();
	NeueAufzeichnungXML.DateiÖffnen("C:DataNomenklatur.xml", "UTF-8");
	
	NeueAufzeichnungXML.SchreibeXMLDeklaration();
	NeueAufzeichnungXML.SchreibeElementanfang("VerzeichnisNomenklatur");
	
	Auswahl = Verzeichnisse.Nomenklatur.Auswählen();
	
	Während Auswahl.Nächster() Schleife 
		ObjektNomenklatur = Auswahl.BekommeObjekt();
		NeuerSerializerXDTO.SchreibeXML(NeueAufzeichnungXML, ObjektNomenklatur, ZweckTypXML.Eindeutig);
	EndeSchleife;
	
	NeueAufzeichnungXML.SchreibeElementende();
	NeueAufzeichnungXML.Schließen();	
EndeProzedur

Mit einer einfachen Umgestaltung des Codes exportieren wir das Verzeichnis als JSON. Die Produkte werden in einem Array gespeichert; zur Abwechslung geben wir die englische Syntaxvariante an:

&AtServer
Prozedur ExportJSONAufServer()
	NeuerXDTOSerializer  = XDTOSerializer;
	NeuerJSONSchreiber = Neuer JSONSchreiber();
	NeuerJSONSchreiber.DateiÖffnen("C:DataNomenklatur.json", "UTF-8");
	
	NeuerJSONSchreiber.SchreibeObjektanfang();
	NeuerJSONSchreiber.SchreibeEigenschaftsname("VerzeichnisNomenklatur");
	NeuerJSONSchreiber.SchreibeArrayanfang();
	
	Auswahl = Kataloge.Nomenklatur.Auswählen();	
	
	Während Auswahl.Nächster() Tue 
		NomenklaturObjekt = Auswahl.BekommeObjekt();
		
		NeuerJSONSchreiber.SchreibeObjektanfang();
		
		NeuerJSONSchreiber.SchreibeEigenschaftsname("Nomenklatur");
		NeuerXDTOSerializer.SchreibeJSON(NeuerJSONSchreiber, NomenklaturObjekt, XMLTypzuweisung.Implizit);
		
		NeuerJSONSchreiber.SchreibeObjektende();
	EndeTu;
	
	NeuerJSONSchreiber.SchreibeArrayende();
	NeuerJSONSchreiber.SchreibeObjektende();
	NeuerJSONSchreiber.Schließen();	
EndeProzedur

Danach bleibt nur noch, die Daten an den Endverbraucher zu übergeben. Die Plattform 1C:Unternehmen unterstützt die gängigen Internetprotokolle HTTP, FTP, POP3, SMTP, IMAP, einschließlich ihrer sicheren Versionen. Auch für die Datenübertragung können HTTP und/oder Webdienste verwendet werden.

HTTP- und Webdienste

1C-Anwendungen können ihre eigenen HTTP- und Webdienste implementieren sowie HTTP- und Webdienste von Drittanwendungen aufrufen.

REST-Schnittstelle und OData-Protokoll

Beginnend mit Version 8.3.5 kann die Plattform 1C:Unternehmen automatisch eine REST-Schnittstelle erstellen für die gesamte Anwendungslösung. Jedes Konfigurationselement (Verzeichnis, Dokument, Informationsregister usw.) kann für den Datenabruf und die Datenmodifikation über die REST-Schnittstelle zugänglich gemacht werden. Als Zugriff Protokoll verwendet die Plattform das Protokoll OData Version 3.0. Die Veröffentlichung von OData-Diensten erfolgt über das Menü des Konfigurators „Administration -> Veröffentlichung auf dem Webserver“, das Kontrollkästchen „Standard-OData-Schnittstelle veröffentlichen“ muss markiert sein. Es werden die Formate Atom/XML und JSON unterstützt. Nachdem die Anwendungslösung auf dem Webserver veröffentlicht wurde, können externe Systeme über die REST-Schnittstelle mit HTTP-Anfragen darauf zugreifen. Für die Arbeit mit der 1C-Anwendung über das OData-Protokoll ist keine Programmierung auf der 1C-Seite erforderlich.

So, eine URL im Format http:////odata/standard.odata/Catalog_Номенклатура gibt uns den Inhalt des Katalogs Nomenklatur im XML-Format zurück – eine Sammlung von Elementen entry (der Nachrichtentitel wurde zur Kürze weggelassen):

http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')