Jaké jsou nejdůležitější požadavky na podnikové aplikace? Některé z nejdůležitějších úkolů jsou následující:
- Snadná změna/přizpůsobení aplikační logiky měnícím se obchodním úkolům.
- Snadná integrace s jinými aplikacemi.
Jak je vyřešen první úkol v 1C, bylo stručně popsáno v části „Přizpůsobení a podpora“. ; K tomuto zajímavému tématu se vrátíme v příštím článku. Dnes budeme hovořit o druhém úkolu, integraci.
Integrační úkoly
Integrační úkoly mohou být různé. K vyřešení některých problémů postačí jednoduchá interaktivní výměna dat – například předání seznamu zaměstnanců bance pro vydání platových plastových karet. U složitějších úkolů může být nezbytná plně automatizovaná výměna dat, případně s odkazem na obchodní logiku externího systému. Existují úkoly, které jsou specializovaného charakteru, jako je integrace s externím zařízením (například maloobchodní zařízení, mobilní skenery atd.) nebo se staršími nebo vysoce specializovanými systémy (například se systémy rozpoznávání značek RFID). Je nesmírně důležité vybrat pro každý úkol nejvhodnější integrační mechanismus.
Možnosti integrace s 1C
Existují různé přístupy k implementaci integrace s aplikacemi 1C; který zvolit, závisí na požadavcích úlohy.
- Na základě implementace poskytuje platforma vlastní specializované API na straně aplikace 1C (například sada webových nebo HTTP služeb, které budou volat aplikace třetích stran k výměně dat s aplikací 1C). Výhodou tohoto přístupu je odolnost API vůči změnám v implementaci na straně aplikace 1C. Zvláštností přístupu je, že je nutné změnit zdrojový kód standardní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 přijít na pomoc nová progresivní funkce - . Rozšíření jsou v podstatě mechanismem zásuvných modulů, který vám umožňuje vytvářet doplňky k aplikačním řešením, aniž byste měnili samotná aplikační řešení. Přesunutí integračního API do konfiguračního rozšíření vám umožní vyhnout se potížím při slučování konfigurací při přechodu na novou verzi standardního řešení.
- Používání mechanismů integrace platformy, které poskytují externí přístup k aplikačnímu objektovému modelu a nevyžadují úpravu aplikace nebo vytvoření rozšíření. Výhodou tohoto přístupu je, že není potřeba měnit aplikaci 1C. Mínus - pokud byla vylepšena aplikace 1C, mohou být vyžadována vylepšení v integrované aplikaci. Příkladem tohoto přístupu je využití protokolu OData pro integraci, implementovaného na straně platformy 1C:Enterprise (více o něm níže).
- Použití hotových aplikačních protokolů implementovaných ve standardních 1C řešeních. Mnoho standardních řešení od 1C a partnerů implementuje své vlastní aplikační protokoly zaměřené na konkrétní úkoly na základě integračních mechanismů poskytovaných platformou. Při použití těchto mechanismů není potřeba psát kód na straně aplikace 1C, protože Využíváme standardní možnosti aplikačního řešení. Na straně aplikace 1C musíme provést pouze určitá nastavení.
Integrační mechanismy v platformě 1C:Enterprise
Import/export souborů
Předpokládejme, že stojíme před úkolem obousměrné výměny dat mezi aplikací 1C a libovolnou aplikací. Potřebujeme například synchronizovat seznam produktů (adresář Nomenclature) mezi aplikací 1C a libovolnou aplikací.
Chcete-li tento problém vyřešit, můžete napsat rozšíření, které stáhne adresář Nomenclature do souboru určitého formátu (text, XML, JSON, ...) a dokáže tento formát přečíst.
Platforma implementuje mechanismus pro serializaci aplikačních objektů v XML jak přímo, prostřednictvím metod globálního kontextu WriteXML/ReadXML, tak pomocí pomocného objektu XDTO (XML Data Transfer Objects).
Jakýkoli objekt v systému 1C:Enterprise lze serializovat do reprezentace XML a naopak.
Tato funkce vrátí XML reprezentaci objektu:
Функция Объект_В_XML(Объект)
ЗаписьXML = Новый ЗаписьXML();
ЗаписьXML.УстановитьСтроку();
ЗаписатьXML(ЗаписьXML, Объект);
Возврат ЗаписьXML.Закрыть();
КонецФункции
Takto bude vypadat export adresáře Nomenclature do XML pomocí XDTO:
&НаСервере
Процедура ЭкспортXMLНаСервере()
НовыйСериализаторXDTO = СериализаторXDTO;
НоваяЗаписьXML = Новый ЗаписьXML();
НоваяЗаписьXML.ОткрытьФайл("C:DataНоменклатура.xml", "UTF-8");
НоваяЗаписьXML.ЗаписатьОбъявлениеXML();
НоваяЗаписьXML.ЗаписатьНачалоЭлемента("СправочникНоменклатура");
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектНоменклатура = Выборка.ПолучитьОбъект();
НовыйСериализаторXDTO.ЗаписатьXML(НоваяЗаписьXML, ОбъектНоменклатура, НазначениеТипаXML.Явное);
КонецЦикла;
НоваяЗаписьXML.ЗаписатьКонецЭлемента();
НоваяЗаписьXML.Закрыть();
КонецПроцедуры
Pouhou úpravou kódu exportujeme adresář do JSON. Produkty budou zapsány do pole; Pro zpestření je zde anglická verze syntaxe:
&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
Pak už zbývá jen předat data koncovému spotřebiteli. Platforma 1C:Enterprise podporuje hlavní internetové protokoly HTTP, FTP, POP3, SMTP, IMAP včetně jejich zabezpečených verzí. K přenosu dat můžete také použít HTTP a/nebo webové služby.
HTTP a webové služby
Aplikace 1C mohou implementovat vlastní HTTP a webové služby, stejně jako volání HTTP a webových služeb implementovaných aplikacemi třetích stran.
Rozhraní REST 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 (adresář, dokument, informační registr atd.) může být zpřístupněn pro příjem a úpravu dat prostřednictvím rozhraní REST. Platforma používá protokol jako přístupový protokol verze 3.0. Publikování služeb OData se provádí z nabídky Konfigurátoru „Administrace -> Publikování na webovém serveru“, musí být zaškrtnuto políčko „Publikovat standardní rozhraní OData“. Podporovány jsou formáty Atom/XML a JSON. Po zveřejnění aplikačního řešení na webovém serveru k němu mohou systémy třetích stran přistupovat prostřednictvím rozhraní REST pomocí HTTP požadavků. Pro práci s aplikací 1C prostřednictvím protokolu OData není nutné programování na straně 1C.
Takže URL jako http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура nám vrátí obsah katalogu nomenklatury ve formátu XML - kolekce vstupních prvků (název zprávy je pro stručnost vynechán):
<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"/>
...
Přidáním řetězce „?$format=application/json“ k URL získáme obsah katalogu Nomenklatury ve formátu JSON (URL formuláře 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 кВт, режимы работы: тепло/холод"
}, …
Externí zdroje dat
V některých případech výměna dat přes může být nejlepším řešením. Externí zdroje dat jsou aplikační konfigurační objekt 1C, který umožňuje interakci s jakoukoli databází kompatibilní s ODBC, a to jak pro čtení, tak pro zápis. Externí zdroje dat jsou k dispozici v systémech Windows i Linux.
Mechanismus výměny dat
je určen jak pro vytváření geograficky distribuovaných systémů založených na 1C:Enterprise, tak pro organizování výměny dat s jinými informačními systémy, které nejsou založeny na 1C:Enterprise.
Tento mechanismus se aktivně používá v implementacích 1C a rozsah úloh řešených s jeho pomocí 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 webem 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 mnoho dalšího. více.
Jedním z klíčových konceptů v mechanismu výměny dat je plán výměny. Výměnný plán je speciální typ objektu aplikační platformy 1C, který určuje zejména složení dat, která se výměny budou účastnit (které adresáře, dokumenty, registry atd.). Výměnný plán obsahuje také informace o účastnících výměny (tzv. exchange nodes).
Druhou součástí mechanismu výměny dat je mechanismus registrace změn. Tento mechanismus automaticky sleduje v systému změny v datech, která musí být v rámci výměnného plánu předána koncovým uživatelům. Pomocí tohoto mechanismu platforma sleduje změny, ke kterým došlo od poslední synchronizace, a umožňuje minimalizovat množství dat přenesených během příští synchronizační relace.
Výměna dat probíhá pomocí XML zpráv určité struktury. Zpráva obsahuje data, která se od poslední synchronizace s uzlem změnila, a některé informace o službě. Struktura zpráv podporuje číslování zpráv a umožňuje přijímat potvrzení od uzlu příjemce, že zprávy byly přijaty. Takové potvrzení je obsaženo v každé zprávě přicházející z přijímacího uzlu ve formě čísla poslední přijaté zprávy. Číslování zpráv umožňuje platformě porozumět tomu, jaká data již byla úspěšně přenesena do přijímacího uzlu, a vyhnout se opakovanému přenosu přenášením pouze dat, která se změnila od doby, kdy odesílající uzel přijal poslední zprávu s potvrzením o datech přijatých přijímacím uzlem. Toto provozní schéma zajišťuje garantované doručení i při nespolehlivých přenosových kanálech a ztrátě zpráv.
Externí komponenty
V řadě případů se při řešení integračních problémů musíme vypořádat se specifickými požadavky, například na interakční protokoly, datové formáty, které platforma 1C:Enterprise neposkytuje. Pro takový rozsah úkolů platforma poskytuje , který umožňuje vytvářet dynamicky zásuvné moduly rozšiřující funkčnost 1C:Enterprise.
Typickým příkladem úkolu s podobnými požadavky by byla integrace aplikačního řešení 1C s maloobchodním vybavením, od vah po pokladny a snímače čárových kódů. Externí komponenty lze připojit jak na straně serveru 1C:Enterprise, tak na straně klienta (včetně, ale bez omezení, webového klienta a také 1C:Podnik). Technologie externích komponent poskytuje celkem jednoduché a srozumitelné softwarové (C++) rozhraní pro interakci komponent s platformou 1C:Enterprise, kterou musí implementovat vývojář.
Možnosti, které se otevírají při použití externích komponent, jsou velmi široké. Můžete implementovat interakci pomocí specifického protokolu pro výměnu dat s externími zařízeními a systémy, zabudovat specifické algoritmy pro zpracování dat a datových formátů atd.
Zastaralé integrační mechanismy
Platforma poskytuje integrační mechanismy, které se nedoporučují pro použití v nových řešeních; jsou ponechány z důvodů zpětné kompatibility a také v případě, že druhá strana nemůže pracovat s modernějšími protokoly. Jedním z nich je práce se soubory formátu DBF (podporované ve vestavěném jazyce pomocí objektu XBase).
Dalším starším integračním mechanismem je použití technologie COM (dostupné pouze na platformě Windows). Platforma 1C:Enterprise poskytuje dvě integrační metody pro Windows pomocí technologie COM: Automation server a External connection. Jsou si velmi podobné, ale jedním ze zásadních rozdílů je, že v případě Automation serveru je spuštěna plnohodnotná klientská aplikace 1C:Enterprise 8 a v případě externího připojení relativně malý průběžný COM server je spuštěn. To znamená, že pokud pracujete prostřednictvím serveru Automation, můžete používat funkce klientské aplikace a provádět akce podobné interaktivním akcím uživatele. Při použití externího připojení můžete používat pouze funkce obchodní logiky a lze je spouštět jak na straně klienta připojení, kde je vytvořen průběžný server COM, tak můžete volat obchodní logiku na serveru 1C:Enterprise. boční.
Technologie COM může být také použita pro přístup k externím systémům z aplikačního kódu na platformě 1C:Enterprise. V tomto případě se aplikace 1C chová jako COM klient. Je však třeba připomenout, že tyto mechanismy budou fungovat pouze v případě, že server 1C pracuje v prostředí Windows.
Integrační mechanismy implementované ve standardních konfiguracích
Enterprise Data Format
V řadě konfigurací 1C (seznam níže) je na základě výše popsaného mechanismu výměny dat platformy implementová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 data výměna se provádí v nastavení aplikačních řešení):
- "1C:ERP Enterprise Management 2.0"
- "Komplexní automatizace 2"
- "Podnikové účetnictví", vydání 3.0
- "Účetnictví pro podnik CORP", vydání 3.0
- "Maloobchod", vydání 2.0
- "Základní řízení obchodu", vydání 11
- Správa obchodu, vydání 11
- „Platy a personální management CORP“, vydání 3
Formát používaný pro výměnu dat je , založené na XML. Formát je obchodně orientovaný - datové struktury v něm popsané odpovídají podnikatelským subjektům (dokumentům a prvkům adresáře) prezentovaným v programech 1C, například: akt dokončení, příkaz k příjmu hotovosti, protistrana, položka atd.
Výměna dat mezi aplikací 1C a aplikací třetí strany může nastat:
- prostřednictvím vyhrazeného adresáře souborů
- přes FTP adresář
- prostřednictvím webové služby nasazené na straně aplikace 1C. Datový soubor je předán jako parametr webovým metodám
- prostřednictvím e-mailu
V případě výměny prostřednictvím webové služby zahájí aplikace třetí strany relaci výměny dat voláním odpovídajících webových metod aplikace 1C. V ostatních případech bude iniciátorem výměnné relace aplikace 1C (umístěním datového souboru do příslušného adresáře nebo odesláním datového souboru na nakonfigurovanou e-mailovou adresu).
Také na straně 1C můžete nakonfigurovat, jak často bude probíhat synchronizace (u možností s výměnou souborů přes adresář a e-mail):
- podle harmonogramu (se stanovenou frekvencí)
- ručně; uživatel bude muset synchronizaci spustit ručně pokaždé, když ji bude potřebovat
Potvrzení zpráv
Aplikace 1C uchovávají záznamy o odeslaných a přijatých synchronizačních zprávách a totéž očekávají od aplikací třetích stran. To vám umožní používat mechanismus číslování zpráv popsaný výše v části „Mechanismus výměny dat“.
Během synchronizace přenášejí aplikace 1C pouze informace o změnách, ke kterým došlo u obchodních subjektů od poslední synchronizace (aby se minimalizovalo množství přenášených informací). Během první synchronizace aplikace 1C nahraje všechny obchodní entity (například položky referenční knihy položek) ve formátu EnterpriseData do souboru XML (protože jsou všechny „nové“ pro externí aplikaci). Aplikace třetí strany musí zpracovat informace ze souboru XML přijatého od 1C a během příští synchronizační relace umístit do souboru odeslaného do 1C do speciální sekce XML informaci, že zpráva od 1C s určitým číslem byla úspěšně dokončena. přijaté. Zpráva o příjmu je signálem pro aplikaci 1C, že všechny podnikatelské subjekty byly úspěšně zpracovány externí aplikací a již není třeba o nich přenášet informace. XML soubor z aplikace třetí strany může kromě účtenky obsahovat také data pro synchronizaci aplikací (například doklady o prodeji zboží a služeb).
Po přijetí zprávy o příjmu aplikace 1C označí všechny změny přenesené v předchozí zprávě jako úspěšně synchronizované. Do externí aplikace budou během příští synchronizační relace odeslány pouze nesynchronizované změny obchodních entit (vytváření nových entit, změna a mazání stávajících).
Při přenosu dat z externí aplikace do aplikace 1C je obraz obrácený. Externí aplikace musí odpovídajícím způsobem vyplnit příjmovou část souboru XML a umístit obchodní data pro synchronizaci ze své strany ve formátu EnterpriseData.
Zjednodušená výměna dat bez handshake
Pro případy jednoduché integrace, kdy stačí pouze přenést informace z aplikace třetí strany do aplikace 1C a není vyžadován zpětný přenos dat z aplikace 1C do aplikace třetí strany (například integrace online obchod, který přenáší informace o prodeji do 1C: Accounting), je zde zjednodušená možnost práce přes webovou službu (bez potvrzení), která nevyžaduje nastavení na straně aplikace 1C.
Integrační řešení na míru
Existuje standardní řešení „1C: Data Conversion“, které využívá mechanismy platformy pro konverzi a výměnu dat mezi standardními konfiguracemi 1C, ale lze jej použít i pro integraci s aplikacemi třetích stran.
Integrace s bankovními řešeními
Standardní , vyvinutý specialisty 1C před více než 10 lety, se ve skutečnosti stal v Rusku průmyslovým standardem. Dalším krokem v tomto směru je technologie , který umožňuje odesílat platební doklady do banky a přijímat výpisy z banky přímo z programů systému 1C:Enterprise stisknutím jednoho tlačítka v programu 1C; nevyžaduje instalaci a spouštění dalších programů na klientském počítači.
Tam jsou také .
ostatní
Stojí za zmínku , standard výměny komerčních informací (vyvinuté společně s Microsoft, Intel, Price.ru a dalšími společnostmi), .
Zdroj: www.habr.com