Jaké jsou hlavní požadavky na podnikové aplikace? Mezi nejdůležitější patří následující úkoly:
- Snadnost změny/adaptace logiky fungování aplikace na měnící se obchodní úkoly.
- Snadnost integrace s jinými aplikacemi.
Jak je v 1C řešen první úkol, bylo stručně popsáno v sekci "Kustomizace a podpora" ; k tomuto zajímavému tématu se ještě vrátíme v jednom z budoucích článků. Dnes se ale zaměříme na druhý úkol, a to integraci.
Integrace úkolů
Integrace úkolů může mít různou podobu. Pro některé úkoly stačí jednoduchá interaktivní výměna dat – například pro zasílání seznamu zaměstnanců bance k vystavení plastových karet na mzdy. Pro složitější úkoly může být nezbytná plně automatizovaná výměna dat, možná s využitím obchodní logiky externího systému. Existují také specializované úkoly, jako je integrace s externím vybavením (například obchodní zařízení, mobilní skenery atd.) nebo s dědičnými nebo úzce specializovanými systémy (například systémy pro rozpoznávání RFID tagů). Je zásadní pro každý úkol vybrat nejvhodnější mechanismus integrace.
Možnosti integrace s 1C
Existují různé přístupy k realizaci integrace s aplikacemi 1C, který z nich zvolit – závisí na požadavcích úkolu.
- Realizace založená na , které poskytuje platforma, vlastním specializovaném API na straně aplikace 1C (například souboru Web- nebo HTTP služeb, které budou vyvolávat externí aplikace pro výměnu dat s aplikací 1C). Výhodou tohoto přístupu je odolnost API vůči změnám realizace na straně aplikace 1C. Specifikem přístupu je, že je třeba měnit zdrojový kód typového řešení 1C, což může potenciálně vyžadovat úsilí při slučování zdrojových kódů při přechodu na novou verzi konfigurace. V tomto případě může pomoci nová pokroková funkčnost – . Rozšíření jsou v podstatě mechanismem pluginů, který umožňuje vytváření doplňků aplikací, aniž by bylo nutné měnit samotné aplikace. Vyčlenění integračního API do rozšíření konfigurace umožní vyhnout se komplikacím při sloučení konfigurací během přechodu na novou verzi standardního řešení.
- Používání integračních mechanismů platformy, které poskytují externí přístup k objektovému modelu aplikace a nevyžadují úpravy aplikace nebo vytváření rozšíření. Výhodou tohoto přístupu je, že není nutné měnit aplikaci 1C. Nevýhodou je, že pokud byla aplikace 1C upravena, mohou být vyžadovány úpravy v integrované aplikaci. Příklad tohoto přístupu – použití integračního protokolu OData, implementovaného na straně platformy 1C:Enterprise (více o něm níže).
- Používání hotových aplikativních protokolů, realizovaných v typových řešeních 1C. Mnohé typové řešení od 1C a partnerů implementují na základě integračních mechanismů poskytovaných platformou své vlastní aplikativní protokoly, zaměřené na konkrétní úkoly. Při používání těchto mechanismů není nutné psát kód na straně aplikace 1C, protože využíváme standardní možnosti aplikativního řešení. Na straně aplikace 1C je třeba provést pouze určité nastavení.
Integrační mechanismy na platformě 1C:Enterprise
Import/export souborů
Představme si, že máme úkol obousměrné výměny dat mezi aplikací 1C a libovolnou aplikací. Například potřebujeme synchronizovat seznam produktů (adresář Nomenklatura) mezi aplikací 1C a libovolnou aplikací.

Pro vyřešení takového úkolu lze napsat rozšíření, které exportuje adresář Nomenklatura do souboru určitého formátu (textový, XML, JSON, …) a umí tento formát číst.
Na platformě je implementován mechanismus serializace aplikativních objektů do XML jak přímo, pomocí metod globálního kontextu ZapsatXML/ČístXML, tak i s pomocí pomocného objektu XDTO (XML Data Transfer Objects).
Jakýkoli objekt v systému 1C:Enterprise může být serializován do XML reprezentace a naopak.
Tato funkce vrátí reprezentaci objektu ve formátu XML:
Funkce Objekt_V_XML(Objekt)
ZáznamXML = Nový ZáznamXML();
ZáznamXML.UstanovitŘetězec();
ZapsatXML(ZáznamXML, Objekt);
Návrat ZáznamXML.Zavřít();
KonecFunkce
takto bude vypadat export katalogu Nomenklatura do XML pomocí XDTO:
&NaServeru
Procedura ExportXMLNaServeru()
NovýSériovýXDTO = SériovýXDTO;
NovýZáznamXML = Nový ZáznamXML();
NovýZáznamXML.OtevřítSoubor("C:DataNomenklatura.xml", "UTF-8");
NovýZáznamXML.ZapsatOznámeníXML();
NovýZáznamXML.ZapsatZačátekElementu("KatalogNomenklatura");
Výběr = Katalogy.Nomenklatura.Vybrat();
Když Výběr.Následující() Cyklus
ObjektNomenklatura = Výběr.ZískatObjekt();
NovýSériovýXDTO.ZapsatXML(NovýZáznamXML, ObjektNomenklatura, ÚčelTypuXML.Explicitní);
KonecCyklu;
NovýZáznamXML.ZapsatKonecElementu();
NovýZáznamXML.Zavřít();
KonecProcedury
Jednoduchou úpravou kódu exportujeme katalog do JSON. Produkty budou zapsány do pole; pro rozmanitost uvedeme anglickou variantu syntaxe:
&NaServeru
Procedura ExportJSONNaServeru()
NovýXDTOSériový = XDTOSeriový;
NovýJSONZapisovač = Nový JSONZapisovač();
NovýJSONZapisovač.OtevřítSoubor("C:DataNomenklatura.json", "UTF-8");
NovýJSONZapisovač.ZapsatZačátekObjektu();
NovýJSONZapisovač.ZapsatNázevVlastnosti("KatalogNomenklatura");
NovýJSONZapisovač.ZapsatZačátekPole();
Výběr = Katalogy.Nomenklatura.Vybrat();
Zatímco Výběr.Následující() Dělej
ObjektNomenklatura = Výběr.ZískatObjekt();
NovýJSONZapisovač.ZapsatZačátekObjektu();
NovýJSONZapisovač.ZapsatNázevVlastnosti("Nomenklatura");
NovýXDTOSériový.ZapsatJSON(NovýJSONZapisovač, ObjektNomenklatura, PřiděleníTypuXML.Implicitní);
NovýJSONZapisovač.ZapsatKonecObjektu();
KonecDěj;
NovýJSONZapisovač.ZapsatKonecPole();
NovýJSONZapisovač.ZapsatKonecObjektu();
NovýJSONZapisovač.Zavřít();
KonecProcedury
Nyní zbývá pouze předat data koncovému uživateli. Platforma 1C:Enterprise podporuje hlavní internetové protokoly HTTP, FTP, POP3, SMTP, IMAP, včetně jejich zabezpečených verzí. Pro přenos dat lze také použít HTTP a/nebo webové služby.
HTTP a webové služby

Aplikace 1C mohou implementovat své HTTP a webové služby, stejně jako volat HTTP a webové služby realizované třetími aplikacemi.
REST rozhraní a protokol OData
Od verze 8.3.5 může platforma 1C:Enterprise automaticky pro celé aplikační řešení. Jakýkoli konfigurační objekt (katalog, dokument, registr informací atd.) může být zpřístupněn pro získání a modifikaci dat přes REST rozhraní. Jako přístupový protokol platforma používá protokol verze 3.0. Publikace služeb OData se provádí z nabídky Konfigurátoru „Administrace -> Publikace na webovém serveru“, přepínač „Publikovat standardní rozhraní OData“ musí být označen. Podporovány jsou formáty atom/XML a JSON. Jakmile je aplikační řešení publikováno na webovém serveru, mohou k němu externí systémy přistupovat prostřednictvím REST rozhraní pomocí HTTP požadavků. Pro práci s aplikací 1C prostřednictvím protokolu OData není potřeba programování na straně 1C.
Takže, URL ve formátu http:////odata/standard.odata/Catalog_Номенклатура nám vrátí obsah katalogu Nomenklatura ve formátu XML — kolekci prvků entry (hlavička zprávy byla vynechána kvůli stručnosti):
http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')
2016-06-06T16:42:17
35d1f6e4-289b-11e6-8ba4-e03f49b16074
AAAAAgAAAAA=
false
000000001
Klima Mitsubishi
Výkon 2,5 kW, režimy provozu: topení/chlazení
http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')
...
Přidáním řetězce „?$format=application/json“ k URL získáme obsah katalogu Nomenklatura ve formátu JSON (URL ve formátu 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": "Klima Mitsubishi",
"Описание": "Výkon 2,5 kW, režimy provozu: topení/chlazení"
},{
"Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAwAAAAA=",
"DeletionMark": false,
"Code": "000000002",
"Description": "Klima Daikin",
"Описание": "Výkon 3 kW, režimy provozu: topení/chlazení"
}, …
Externí zdroje dat

V některých případech dochází k výměně dat prostřednictvím může se ukázat jako optimální řešení. Vnější datové zdroje jsou aplikačním objektem konfigurace 1C, který umožňuje interakci s jakoukoli databází kompatibilní s ODBC jak pro čtení, tak pro zápis. Vnější datové zdroje jsou dostupné jak ve Windows, tak v Linuxu.
Mechanismus výměny dat
je určen jak pro vytváření teritoriálně distribuovaných systémů na bázi 1C:Enterprise, tak pro organizaci výměny dat s jinými informačními systémy, které nejsou založeny na 1C:Enterprise.
Tento mechanismus se aktivně využívá při implementacích 1C, a rozsah úkolů, které se s jeho pomocí řeší, je velmi široký. To zahrnuje výměnu dat mezi aplikacemi 1C, nainstalovanými v pobočkách organizace, a výměnu mezi aplikací 1C a webovou stránkou internetového obchodu, a výměnu dat mezi serverovou aplikací 1C a mobilním klientem (vytvořeným pomocí mobilní platformy 1C:Enterprise), a mnohem víc.
Jedním z klíčových pojmů v mechanismu výměny dat je plán výměny. Plán výměny je speciální typ aplikačního objektu platformy 1C, který definuje zejména složení dat, která se budou podílet na výměně (jaké konkrétní referenční informace, dokumenty, registry atd.). Plán výměny rovněž obsahuje informace o účastnících výměny (tzv. uzlech výměny).
Druhá součást mechanismu výměny dat je mechanismus registrace změn. Tento mechanismus automaticky sleduje v systému změny dat, které mají být předány konečným uživatelům v rámci plánu výměny. S pomocí tohoto mechanismu platforma sleduje změny, které nastaly od poslední synchronizace, a umožňuje minimalizovat objem dat, která jsou předávána v rámci dalšího synchronizačního sezení.
Výmena údajov prebieha prostredníctvom XML správ určitej štruktúry. Správa obsahuje údaje, ktoré sa zmenili od poslednej synchronizácie s uzlom, a nejaké servisné informácie. Štruktúra správ podporuje číslovanie správ a umožňuje získať potvrdenia od uzla-prijímateľa o prijatí správ. Takéto potvrdenie sa nachádza v každej správe, ktorá prichádza od uzla-prijímateľa, vo forme čísla poslednej prijatej správy. Číslovanie správ umožňuje platforme pochopiť, aké údaje už boli úspešne prenesené na uzol-prijímateľ a vyhnúť sa opätovnému prenosu, pričom sa prenášajú len údaje, ktoré sa zmenili od prijatia poslednej správy s potvrdením o prijatých údajoch uzlom-prijímateľom. Pri takejto schéme práce je zabezpečená garantovaná dodávka aj pri nespoľahlivých komunikačných kanáloch a strate správ.
Externé komponenty
V niektorých prípadoch, pri riešení úloh integrácie, sa musíme stretávať so špecifickými požiadavkami, ako napríklad protokoly interakcie, formáty údajov, s ktorými platforma 1C:Enterprise nepočítala. Pre takýto okruh úloh je v platforme predpokladaná , ktorá umožňuje vytvárať dynamicky pripojiteľné moduly, ktoré rozširujú funkčnosť 1C:Enterprise.
Typickým príkladom úlohy s podobnými požiadavkami môže byť integrácia aplikácie 1C s obchodným zariadením, počínajúc váhami a končiac pokladničnými zariadeniami a skenermi čiarových kódov. Externé komponenty môžu byť pripojené tak na strane servera 1C:Enterprise, ako aj na klientskej strane (vrátane webového klienta, ako aj 1C:Enterprise). Technológia externých komponentov predpokladá dostatočne jednoduché a zrozumiteľné programové (C++) rozhranie na interakciu komponentov s platformou 1C:Enterprise, ktoré musí implementovať vývojár.
Možnosti, ktoré sa otvárajú pri používaní externých komponentov, sú veľmi široké. Môžeme realizovať interakciu podľa špecifického protokolu výmeny údajov s externými zariadeniami a systémami, integrovať špecifické algoritmy spracovania údajov a formátov údajov atď.
Zastaralé integrační mechanismy
Na platformě jsou k dispozici integrační mechanismy, které se nedoporučuje používat v nových řešeních; byly ponechány z hlediska zpětné kompatibility a také pro případ, že by druhá strana nemohla pracovat s modernějšími protokoly. Jedním z nich je práce s soubory formátu DBF (podporováno ve vestavěném jazyce pomocí objektu XBase).
Dalším zastaralým integračním mechanismem je použití technologie COM (dostupné pouze na platformě Windows). Platforma 1C:Enterprise poskytuje dva způsoby integrace pro Windows, které využívají technologii COM: Automatizační server a Externí připojení. Tyto způsoby jsou si velmi podobné, ale jedním z hlavních rozdílů je to, že v případě Automatizačního serveru se spustí plnohodnotná klientská aplikace 1C:Enterprise 8, zatímco v případě externího připojení se spustí relativně malý intraprocesní COM-server. To znamená, že v případě práce přes Automatizační server lze využít funkcionalitu klientské aplikace, provádět akce analogické interaktivním akcím uživatele. Při použití externího připojení lze využívat pouze funkce obchodní logiky, přičemž je možné je provádět jak na klientské straně připojení, kde se vytváří intraprocesní COM-server, tak vyvolávat obchodní logiku na straně serveru 1C:Enterprise.
Technologii COM lze také použít pro přístup k externím systémům z kódu aplikace na platformě 1C:Enterprise. V tomto případě aplikace 1C funguje jako COM-klient. Je však třeba připomenout, že tyto mechanismy budou fungovat pouze tehdy, pokud server 1C běží v prostředí Windows.
Integrační mechanismy realizované ve standardních konfiguracích
Formát EnterpriseData

V řadě konfigurací 1C (seznam níže) byl na základě výše popsaného platformového mechanismu výměny dat realizován hotový mechanismus pro výměnu dat s externími aplikacemi, který nevyžaduje změnu zdrojového kódu konfigurací (příprava na výměnu dat se provádí v nastaveních aplikovaných řešení):
- „1C:ERP Řízení podniku 2.0“
- „Komplexní automatizace 2“
- „Účetnictví podniku“, edice 3.0
- „Účetnictví podniku KORP“, edice 3.0
- „Maloobchod“, edice 2.0
- „Základní řízení obchodování“, vydání 11
- „Řízení obchodování“, vydání 11
- „Mzdová a personální správa KORP“, vydání 3
Pro výměnu dat se používá formát , založený na XML. Formát je orientován na podnikání – popsané struktury dat odpovídají obchodním subjektům (dokumentům a položkám katalogu), které jsou reprezentovány v programech 1C, například: potvrzení o provedení prací, příjmový pokladní doklad, kontragent, nomenklatura apod.
Výměna dat mezi aplikací 1C a třetími aplikacemi může probíhat:
- prostřednictvím vyhrazeného souborového adresáře
- přes FTP adresář
- přes webovou službu nasazenou na straně aplikace 1C. Soubor s daty se předává jako parametr webových metod
- přes elektronickou poštu
V případě výměny přes webovou službu bude třetí aplikace iniciovat datovou výměnu voláním odpovídajících webových metod aplikace 1C. V ostatních případech bude iniciátorem sezení výměny aplikace 1C (vložením souboru s daty do odpovídajícího adresáře nebo odesláním souboru s daty na nastavenou e-mailovou adresu).
Také se na straně 1C nastaví, jak často bude docházet k synchronizaci (pro varianty s výměnou souborů prostřednictvím adresáře a elektronické pošty):
- podle plánu (s danou periodicitou)
- manuálně; uživatel bude muset manuálně spouštět synchronizaci pokaždé, když to bude potřebovat
Potvrzování zpráv
Aplikace 1C vedou evidenci odeslaných a přijatých zpráv synchronizace a očekávají to samé od třetích aplikací. To umožňuje využít mechanismus číslování zpráv, popsaný výše v části „Mechanismus výměny dat“.
Aplikace 1C během synchronizace přenášejí pouze informace o změnách, které nastaly v obchodních entitách od poslední synchronizace (aby se minimalizoval objem přenášených informací). Při první synchronizaci aplikace 1C exportuje všechny obchodní entity (například položky z katalogu zboží) ve formátu EnterpriseData do XML souboru (protože všechny jsou pro externí aplikaci "nové"). Externí aplikace musí zpracovat informace z přijatého XML souboru od 1C a při následující synchronizaci umístit do souboru, odesílaného do 1C, ve speciální sekci XML informaci, že zpráva od 1C s určitém číslem byla úspěšně přijata. Potvrzovací zpráva je pro aplikaci 1C signálem, že všechny obchodní entity byly úspěšně zpracovány externí aplikací a informace o nich již není potřeba přenášet. Kromě potvrzení může XML soubor od externí aplikace také obsahovat data pro synchronizaci ze strany aplikace (například dokumenty realizace zboží a služeb).
Po obdržení potvrzovací zprávy aplikace 1C označuje všechny změny, které byly zaslány v předchozí zprávě, jako úspěšně synchronizované. Pouze nesynchronizované změny v obchodních entitách (vytváření nových entit, změny a mazání existujících) budou odeslány do externí aplikace při následující synchronizaci.

Při přenosu dat z externí aplikace do aplikace 1C se situace obrací. Externí aplikace musí odpovídajícím způsobem vyplnit sekci potvrzení v XML souboru a umístit obchodní data pro synchronizaci ze své strany ve formátu EnterpriseData.

Zjednodušená výměna dat bez potvrzování
Pro případy jednoduché integrace, kdy stačí pouze předávat informace z externí aplikace do aplikace 1C a není potřebný zpětný přenos dat z aplikace 1C do externí aplikace (například integrace online obchodu, který předává informace o prodeji do „1C:Účetnictví“), existuje zjednodušená varianta práce přes webovou službu (bez potvrzování), která nevyžaduje nastavení na straně aplikace 1C.
Specializovaná integrační řešení
Existuje standardní řešení „1C:Konverze dat“, které využívá mechanismy platformy pro konverzi a výměnu dat mezi standardními konfiguracemi 1C, ale může být také použito pro integraci s externími aplikacemi.
Integrace s bankovními řešeními
Standard , vyvinutý specialisty 1C před více než 10 lety, se v podstatě stal standardem odvětví v Rusku. Dalším krokem v tomto směru je technologie , která umožňuje odesílat platební dokumenty do banky a získávat výpisy z banky přímo ze systémových programů „1C:Podnikání“ stisknutím jednoho tlačítka v programu „1C“; přičemž není nutné instalovat a spouštět další programy na klientském počítači.
Existuje také .
Ostatní
Zaslouží si zmínku , standard výměny obchodních informací (vyvinutý ve spolupráci s Microsoftem, Intelem, Price.ru a dalšími společnostmi), .
Zdroj: habr.com
