Inzerce na portálu

Publikovat standardní rozhraní odata.

Tisknout (Ctrl+P)

Můžete se podívat na druhý díl

Obecná informace

V platformové verzi 8.3.5.1068 , zveřejněné v září 2015, se objevil mechanismus pro integraci 1C s externími programy prostřednictvím technologie rozhraní REST. Platforma používá jako přístupový protokol protokol OData. Jedná se o otevřený webový protokol pro dotazování a aktualizaci dat. Umožňuje vám manipulovat s daty pomocí HTTP příkazů jako požadavků. Ve verzi 8.3.5.1068 bylo možné přijímat odpovědi pouze ve formátu Atom/XML . Počínaje vydáním 8.3.8.1652 v srpnu 2017 se však objevila druhá možnost pro příjem dat ve formátu JSON (JavaScript Object Notation). . Ve srovnání s XML je snadno čitelný pro lidi a zabírá méně místa. Všechny prohlížeče mají navíc vestavěné nástroje pro práci s JSON.

Práci s protokolem OData na platformě 1C: Enterprise najdete v knize 1C: Developer's Guide v kapitole 17 Mechanismy internetových služeb, odstavec 17.2.1 Standardní rozhraní OData. Můžete se také podívat na příklady rozšíření podpory pro protokol OData,

Výhoda použití rozhraní REST. dochází k závěru, že pro přístup k systémovým datům z externí aplikace není nutná žádná úprava kódu aplikační řešení(například pokud je podporováno aplikační řešení). Chcete-li získat tento přístup, musíte aplikaci publikovat na webový server specifickým způsobem a určit, které konfigurační objekty budou tímto způsobem použity. Systémy třetích stran pak mohou přistupovat k vaší aplikaci pomocí požadavků HTTP.

Publikování standardního rozhraní OData se provádí pomocí publikačního dialogu na webovém serveru (Administrace - Publikování na webový server) a popsané v knize 1C:Enterprise 8.3. „Příručka správce“.
Důležité! Aby byly konfigurační objekty přístupné přes standardní rozhraní OData, musí být toto povoleno pomocí metody globálního kontextu SetComposition of StandardInterfaceOData().
Mechanismus pro nastavení kompozice objektů dostupných pomocí standardního rozhraní OData lze provést jako externí zpracování. To nevyžaduje úpravu aplikačního řešení.

Pro interakci s externím webovým serverem REST od 1C:Enterprise používáme nástroje dostupné na platformě pro práci s objekty HTTP: HTTPConnection, HTTPRequest a HTTPResponse.

V této sérii článků ukážu příklady typických operací pomocí odpovídající metody HTTP;

  • Příjem dat - způsob DOSTAT;
  • Vytvoření objektu - metoda POŠTA;
  • Aktualizovat data: metoda NÁPLAST– v tomto případě můžete zadat pouze ty vlastnosti, které je třeba aktualizovat; metoda DÁT– v tomto případě je nutné uvést všechny vlastnosti entity;
  • Mazání dat - metoda VYMAZAT.

1. Příklady pořizování dat. Metoda HTTP GET

Server bude databáze publikovaná na webovém serveru s názvem WebBuh(Demo databáze “Enterprise Accounting 3.0”). Jako formát pro výměnu dat použiji formát JSON. Více informací o práci s JSON je napsáno v dostupné dokumentaci. Chcete-li přijímat data ze serveru pomocí metody HTTP GET, musíte vytvořit objekt Čtení JSONčíst data JSON postupně ze souboru nebo řetězce. Chcete-li organizovat sekvenční nahrávání objektů a textů na serveru pomocí metody HTTP POST PATCH PUT, musíte vytvořit objekt Záznam JSON. Všimněte si, že metoda DELETE nevyžaduje JSON.

Abych ilustroval tok čtení a zápisu JSON při přístupu k rozhraní REST, zavolám následující uživatelsky definovanou funkci pro obecné účely Zavolejte HTTPMethodOnServer :

&Na serveru // <Описание функции>// // Možnosti: // - Řetězec obsahující název metody HTTP pro požadavek ("POST"."PATCH", "PUT" ,"GET","DELETE" // - objekt HTTPConnection //<АдресРесурса>- Řetězec http zdroje, na který bude HTTP požadavek odeslán. //<ОтправляемыеДанные>- Struktura nebo shoda obsahující data odeslaná na zadanou adresu ke zpracování // na serveru pomocí zadané metody HTTP "POST" nebo "PATCH" nebo "PUT" // Návratová hodnota: // Struktura odpovědi serveru v závislosti na metoda HTTP// Funkce Volání HTTPMethodOnServer(HTTPMethod, HTTPConnection, ResourceAddress, SentData = Nedefinováno) // Vytvořte požadavek HTTP Záhlaví = new Match(); Nadpisy. Vložit("Typ obsahu", "aplikace/json"); HTTP požadavek = nový HTTP požadavek ( ResourceAddress, záhlaví ); // Napište Json pro vytvoření a aktualizaci dat If HTTPMethod = "POST" nebo HTTPMethod = "PATCH" nebo HTTPMethod = "PUT" Then JSON Record = New JSON Record ; ParametryJSON = Nový ParametersRecordsJSON(Line WrapJSON.Auto,"",True); RecordJSON.SetString(ParametryJSON); WriteJSON(WriteJSON, Odeslaná data ); // Odeslaná data jsou v tomto případě vyžadovány LineForBody = RecordJSON.Close(); RequestHTTP.SetBodyFromString(StringForBody, Kódování textu.UTF8, UsingByteOrderMark.Nepoužívat); endIf; // Volání metody HTTPConnection Method ResponseHTTP = HTTPConnection.CallHTTPMethod(HTTPMethod, HTTPRequest) ; Struktura odpovědi= Nová struktura; Struktura odpovědi.Insert("StatusCode", ResponseHTTP.StatusCode); // Čtení JSON pouze pro metodu GET Li HTTPMethod="GET" Potom TryReadJSON = NewReadJSON ; ServerResponse = ResponseHTTP.GetBodyAsString("UTF-8"); ReadJSON.SetString(ServerResponse); Shoda = ReadJSON(ReadJSON,Skutečný); Struktura odpovědi.Insert("ServerResponse",Korespondence) ; Struktura odpovědi.Vložte (" Odezva serveru Undecrypted", ServerResponse); Výjimka Zpráva(ErrorDescription()); Návrat Nedefinováno; EndPokus; EndIf; Vrátit se Struktura odpovědi ; EndFunction // Volání HTTPMethodOnServer()

Pro příjem ze serveru v formát JSON při přístupu k rozhraní REST aplikačního řešení musíte zadat adresu zdroje $format=json. Nebo zadejte typ MIME "application/json" v názvu:

Záhlaví = new Match(); Headings.Insert("Content-Type", "aplikace/json") ; ResourceAddress = " WebBuh/odata/standard.odata/ ?$format=json" RequestHTTP = Nový HTTPRequest(ResourceAddress, Headers);

Rys globálního kontextu ReadJSON(ReadJSON, True)

  • Pokud je druhý parametr nastaven na hodnotu True, čtěte objekt JSON bude dokončena v Korespondence.Pokud je nastaveno na False, objekty budou načteny do objektu typu Struktura.
  • Při deserializaci objektů JSON do struktury si musíte být vědomi požadavků na klíč struktury. Pokud je při deserializaci objektu nalezen název vlastnosti, který není platný pro klíč struktury, bude vyvolána výjimka.

1. 1 Konfigurace parametrů připojení HTTP

Pro organizaci klientské části interakce s externím webovým serverem REST jsem vytvořil konfiguraci klienta založenou na BSP od začátku. Pomocí této konfigurace jsem vytvořil referenci pro nastavení parametrů připojení (viz obr. 1)

Obr. 1 Adresář pro nastavení parametrů pro připojení HTTP k externí informační bezpečnosti přes rozhraní zbytek

Po stisknutí tlačítka Zkontrolujte odpověď serveru, je volána procedura, ve které se klient pokusí obdržet odpověď ze serveru. Programový kód Postup je napsán níže:

&OnClient Postup CheckConnection(Command) Adresa = Object.ServerAddress; Uživatel = Object.User; Heslo = Object.Password; Název databáze = Název; Port = ? (Objekt.Port<>0,Object.Port,80); HTTPConnection = Nové HTTP připojení (adresa, port, uživatel, heslo); ResourceAddress = Název databáze + "/odata/standard.odata/ $metadata "; //Volání vlastní funkce Struktura odpovědi= B Zavolejte HTTPMethodOnServer("DOSTAT" , HTTPConnection, ResourceAddress) ; Li Struktura odpovědi <> Nedefinováno Potom General PurposeClientServer.NotifyUser("Status Code"+Response Structure.Status Code); Nekonečný; Konec procedury

Účelem tohoto postupu je kontrola služby a zda uživatel správně zadal parametry připojení. Chcete-li to provést, stačí provést požadavek GET:
HTTPConnection.CallHTTPMetoda( "DOSTAT", HTTP požadavek);
pomocí adresy zdroje:
ResourceAddress =BaseName+ “/odata/standard.odata/ “;
Službu můžete také zkontrolovat ve svém prohlížeči pomocí
URL http://host/WebBuh/odata/standard.odata. Výsledkem takového dotazu je pouze seznam entit. Pro získání plný popis standardní rozhraní OData (seznam dostupných entit, jejich atributů a funkcí ve formě XML
document.) musíte provést požadavek GET pomocí parametru $metadata. URL http://host/WebBuh/odata/standard.odata/$metadata. Detailní popis Dokument lze získat na http://www.odata.org/documentation/ (v angličtině).
Odpovědi můžete dostávat ve formátu Atom/XML nebo JSON. Stavové kódy odpovědi HTTP lze zobrazit Odpovědi v rozsahu:

  • 100-199 – informační odpovědi o tom, že požadavek klienta byl přijat a zpracovává se.
  • 200-299 – znamená, že požadavek klienta byl úspěšně zpracován.
  • 300-399 znamená, že požadavek nebyl dokončen a klient musí provést nějakou akci, aby požadavek splnil.
  • 400-499 – informuje o chybách na straně klientské aplikace. Tyto kódy mohou také naznačovat, že jsou od klienta vyžadovány další informace.
  • 500-599 - Informuje o chybě na straně serveru, což znamená, že server narazil na chybu a pravděpodobně nebude schopen splnit požadavek klienta.

1.2 Hledání objektu podle ID

Následující funkce je určena k vyhledání referenční knihy nebo dokumentu podle unikátní identifikátor na serveru. Pokud je objekt nalezen, funkce vrátí hodnotu řetězce identifikátoru (Ref_Key), jinak vrátí nedefinováno. Funkce jsou předány následující parametry:

  • HTTPConnection – Objekt typu HTTPConnection
  • PublicationName – název publikované databáze serveru
  • Element – ​​identifikátor entity objektu, např. Katalog_Organizace nebo Dokument_- adresář organizace.
  • Identifikátor – Identifikátor objektu, který se má na serveru hledat, např. Organization.UniqueIdentifier()
Funkce &OnServer SearchObjectByGUID (HTTPConnection,PublicationName,Element,UniqueIdentifier) GUID = String(UniqueIdentifier); // převod na řetězec ResourceAddress = + Element+ "(guid""+ GUID+ "")?$format=json" ; Struktura odpovědi = BZavolejte HTTPMethodOnServer("DOSTAT" , HTTPConnection, ResourceAddress) ; Li Struktura odpovědi .StatusCode >= 400 Pak //General PurposeClientServer.NotifyUser(Element+ "Error"+ResponseStructure.StatusCode+ //GeneralPurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUndecrypted); Návrat nedefinovaný; EndIf; Shoda = Struktura odpovědi. ReplyServer a; Pole = Shoda["value"]; If Array = Undefined Then Return Match["Ref_Key"] Jinak Return Array["Ref_Key"]; endIf; EndFunction

Parametr ResourceAddress slouží k přístupu ke službě REST. Chcete-li zkontrolovat fungování služby, můžete v prohlížeči zadat zdroj takto

http://(WebServerAddress)/(PublicationName)/odata/standard.odata/(Element)?(Parameters) ,Kde

  • Adresa webového serveru– Adresa webového serveru, na kterém je služba publikována, například Localhost
  • Název Publikace– název infobáze zadaný při publikování řešení
  • /odata/standard.odata/ – Značka přístupu ke standardnímu rozhraní OData
  • Živel – identifikátor zdroje nebo předdefinované zdroje. Například Catalog_Account(guid’value’).
  • Možnosti– parametry zdroje. Používá se například pro výběr, akceptovaným způsobem pro požadavky HTTP: ?key=value&key2=value2

1.3 Hledání objektu pomocí vyhledávacích polí

Následující uživatelsky definovaná funkce je navržena pro vyhledávání objektu pomocí vyhledávacích polí v případě, že je objekt podle identifikačního čísla. Řetězec funkčních objektů Ref_Key –identifikační číslo.

Funkce &OnServer P searchObjectBySearchFields(HTTPConnection,PublicationName,Element,SearchFields) Podmínka = "" ; Pro každou klíčovou hodnotu ze smyčky vyhledávacího pole Stav = Stav + KeyValue.Key+ "ekv"" + KeyValue.Value+ "" a "; EndCycle; Text žádosti =Lev(stav, StrLength(stav)-5); // odstranění posledních 5 znaků ResourceAddress= Název publikace+ "/odata/standard.odata/" +Element+ "?$filter=" + Text žádosti+ "&$format=json& $select=Ref_Key" ; //Zavolejte moji vlastní funkci Struktura odpovědi= CallHTTPMethodOnServer( "DOSTAT",HTTPConnection,ResourceAddress); Li Struktura odpovědi .StatusCode >= 400 Pak //General PurposeClientServer.NotifyUser(Element+ "Error"+ResponseStructure.StatusCode); //General PurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUndecrypted); Návrat nedefinovaný; endIf; Shoda = Struktura odpovědi. ReplyServer a; Pole = Shoda["value" ]; If Array = Undefined Then Return Match ["Ref_Key" ] Jinak Return Array ["Ref_Key" ]; endIf; EndFunction

Jak je vidět z těla procedury P searchObjectBySearchFields, výběr začíná klíčovým slovem$filtrv adrese zdroje. Formální parametrVyhledávací pole –toto je korespondence, která obsahuje jména a hodnoty podrobností.

Upozorňujeme, že názvy podrobností někdy nejsou zřejmé. Je třeba si uvědomit, že u referenčních knih:

  • Kód - kód,
  • Popis – Název
  • DeleteMark – značka smazání,
  • IsFolder – znak skupiny,
  • Parent_Key – rodič.
  • Pokud je atribut referenčního typu, měla by být k jeho názvu přidána přípona _Key, například Account_Key.

Pro dokumenty:

  • Číslo – číslo dokladu,
  • Datum – datum dokumentu.

Operace logického výběru

  • eq - rovná se; /Catalog_Cities?$filter=Název eq ‚Hlavní‘;
  • ne - Nerovná se; /Catalog_Cities?$filter=Název ne ‚Perm‘;
  • gt - Více; /Catalog_Products?$filter= Cena 10 gt;
  • ge - větší nebo rovno; /Catalog_Products?$filter=Cena ge 10;
  • lt - Méně; /Catalog_Products?$filter=Cena lt 10;
  • le - menší nebo rovno; /Catalog_Products?$filter=Cena le 10;
  • nebo - logické OR; /Katalog_ Produkty ?$filter= Cena lt 10 nebo Cena 100 gt;
  • a - logické AND; / Katalog _Produkty?$ filtr =Cena g t 10 a Cena l t 100;
  • ne - Negace; /Katalog_ Produkty ?$filter=not (cena ekv 10);

Všimněte si také, že hodnota skutečného parametru Živel(nebo entita)), kterou předám funkci se tvoří podle následujícího pravidla:

Název Prefix_ConfigurationObjectName_Name Přípona.

Pomocí standardního rozhraní OData můžete přistupovat k následujícím objektům ( Předpona jména):

  • Adresář - Katalog;
  • Dokument - Dokument;
  • Deník dokumentů - DocumentJournal;
  • Konstantní - Konstantní;
  • Burzovní plán - ExchangePlan;
  • Účtová osnova - ChartOfAccounts
  • Tabulka typů výpočtů - ChartOfCalculationTypes;
  • Tabulka charakteristických typů - ChartOfCharacteristicTypes;
  • Registr informací - InformationRegister;
  • Accumulation Register - AccumulationRegister;
  • Registr kalkulací - CalculationRegister;
  • Účetní evidence - AccountingRegister;
  • Obchodní proces - BusinessProcess;
  • Úkol – Úkol.

ConfigurationObjectName- vlastnost „Name“ konfiguračního objektu, jak je specifikována v konfigurátoru.

Přípona jména- potřebné k objasnění názvu zdroje, volitelné, může nabývat následujících hodnot:

  • Název tabulkové části objektu;
  • Název virtuální tabulky objektu;
  • RowType - řádek tabulkové části objektu;
  • RecordType - samostatný záznam registru.

Parametry pro přístup ke zdrojům

Po vytvoření názvu zdroje je třeba definovat parametry pro přístup ke zdroji, např. ?$filtr= Význam &$ formát=json& $select= Ref_Key ,

  • $filtr- výběr při příjmu dat
  • $ formát- označuje formát vrácených dat,
  • $vybrat- výpis vlastností entity, které budou zahrnuty do výsledku dotazu;
  • $metadata- vrátí popis standardního rozhraní OData (používá se bez uvedení přípony názvu, příklad na jednom z obrázků výše);
  • $top- omezení počtu vrácených záznamů;
  • $přeskočit- odstraní zadaný počet záznamů z výsledku dotazu;
  • $počet- vrátí počet záznamů ve výběru dotazu;
  • $inlinecount=allpage(=none)- k výsledku dotazu přidá informaci o počtu záznamů
  • $orderby=<Реквизит1>vzestupně,<Реквизит2>desc- řazení výsledku dotazu
  • povolit Pouze- pouze povolené (používané bez znaku „$“).

1.4 Získejte řadu položek registru informací

Podívejme se na příklad získání pole registračních záznamů obsahujících celá jména jednotlivců, například historii změn celého jména jednotlivce

Název Publikace = "WebBuh"; Element = "InformationRegister_Jméno jednotlivců"; Období = Nedefinováno; ReferenceType Data= new Structure(); D DataReferenceType.Insert("Jednotlivec",Jednotlivý_klíč); DataNON-ReferenceType= new Structure(); DataNON-ReferenceType.Insert("Individual_Type", "StandardODATA.Catalog_Individuals") Pole = GetRegisterInfoSet(HTTPConnection,PublicationName,Element,Period, RozměryReferenceTyp, Rozměry nereferenčního typu)

Tělo funkce GetInfoRegisterRecordSet, která je volána v tomto příkladu, je zobrazeno níže

Funkce &OnServer GetSetRecordRegisterInformation(HTTPConnection,PublicationName,Element,Period =Nedefinováno, RozměryReferenceTyp= Nedefinováno Rozměry nereferenčního typu= Nedefinováno) Text požadavku = "" ; Pokud Období<>Nedefinováno Potom FormattedPeriod= Formát (období,"DF=rrrr-MM-ddTHH:mm:ss"); RequestText = "Period = datetime"" + FormattedPeriod + """ ; endIf; Li RozměryReferenceTyp <>Nedefinováno potom pro každou klíčovou hodnotu RozměryReferenceTyp Cyklicky zapnuto = ? ( ValueFilled(QueryText), "," ","); RequestText = RequestText+ zapnuto + KeyValue.Key+ "=guid(""+ KeyValue.Value+ "")"; EndCycle; EndIf; If Rozměry nereferenčního typu<> Nedefinováno Potom Pro každý klíč Význam Rozměry nereferenčního typu Cyklus Dotaz = ? ( ValueFilled(QueryText), "," ","); QueryText = QueryText + Fed+ K keyMeaning.Key + "=" + KeyValue.Value; EndCycle; endIf; ResourceAddress=PublicationName + " /odata/standard.odata/" + Element + "("+ Text dotazu + + ") ?$format=json"; //Zavolejte moji vlastní funkci Struktura odpovědi = Zavolejte HTTPMethodOnServer("GET",HTTPConnection,ResourceAddress); Li Struktura odpovědi.StatusCode >= 400 Pak//General PurposeClientServer.NotifyUser(Element+ "Error"+ResponseStructure.StatusCode); //General PurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUndecrypted); Návrat nedefinovaný; endIf; Shoda = 0

Přehled OData

OData je webové rozhraní API pro přístup a manipulaci s daty. Je podobný mini-ODBC a JDBC API, ale je jedinečně zaměřen na internet. Přesněji řečeno, OData umožňuje klientům vytvářet URI pro pojmenování sady entit, filtrování entit obsažených v této sadě a sledování vztahů k souvisejícím entitám a kolekcím entit. Pro získání dodatečné informace viz Úvod OData: Přístup k datům pro web, cloud, mobilní zařízení a další mobilní zařízení atd.).

Obrázek 1: Zpřístupnění databáze internetu pomocí univerzálního poskytovatele OData

Diagram na obrázku 1 ukazuje, jak lze zdroj, jako je databáze, zpřístupnit internetu prostřednictvím univerzálního poskytovatele OData. Syntaxe OData umožňuje s daty ve výše uvedené databázi různými způsoby manipulovat (vytvářet, aktualizovat, mazat, dotazovat) pomocí webových prohlížečů.

Obrázek 2. CSDL (Conceptual Schema Definition Language)

Obrázek 2 ukazuje schéma CSDL (Conceptual Schema Definition Language). CSDL je volitelný nástroj, který pomáhá náročným aplikacím porozumět struktuře vystavených dat. CSDL je podobný metadatům v JDBC a ODBC, pomáhá klientským aplikacím pochopit, k čemu přesně přistupují.

Na internetu jsou tisíce webových API. OData je jedním příkladem takového API. Více informací o webových rozhraních API lze nalézt na webových stránkách: Programmable Web. Standardizace takových rozhraní zlepší konsolidaci v této důležité technologické oblasti a pomůže inovacím držet krok s potřebami trhu, zejména podporou nových návrhů dat a iniciativ otevřených dat.

OData v organizaci OASIS

Návrh charty OData byl předložen Organizaci pro rozvoj strukturovaných informačních standardů (OASIS). Níže je uveden výňatek textu z tohoto dokumentu.

Práce bude zaměřena na dosažení následujících cílů.

  • Vytvoření datových služeb RESTful založených na HTTP, schopnost identifikovat zdroje pomocí URI (Uniform Resource Identifier) ​​​​a definovat zdroje pomocí abstraktního datového modelu, možnost publikovat a upravovat webovými klienty pomocí jednoduchých zpráv HTTP.
  • Vystavování a získávání informací z různých zdrojů, včetně, ale nejen, relačních databází, souborové systémy, redakční systémy a tradiční webové stránky.

Dokumenty specifikace OData předložené OASIS, stejně jako návrh charty, jsou k dispozici na následujících odkazech.

Kromě specifikací OData byly organizaci OASIS předloženy následující čtyři dokumenty s rozšířeními OData.

Tyto rozšiřující dokumenty jsou určeny k zahájení práce na navrhovaném technickém výboru OASIS OData. Úplnou chartu a dokumenty rozšíření OData si můžete přečíst na webu OASIS.

Produkty OData a IBM

Následující produkty IBM podporují OData.

  • Produkt na podporu přístupu od různých klientů.
  • Produkty DB2 a Informix jsou schopny používat OData prostřednictvím Microsoft Visual Studio. Více detailní informace na toto téma obsahuje .

Příklady OData

Tento odstavec nabízí několik jednoduché příklady na OData s přístupem ke službě Netflix.

Výchozí Žánry Tituly . . . . . . Tituly http://odata.netflix.com/v2/Catalog/Titles/ 2012-05-23T21:41:18Z Zpěvák Anthony Kiedis, baskytarista Flea,... 2012-01-31T09:45:16Z . . . http://odata.netflix.com/v2/Catalog/Titles("13aly") Red Hot Chili Peppers: Funky Monks Zpěvák Anthony Kiedis, baskytarista Flea, bubeník Chad Smith... 2012-01-31T09:45:16Z . . . 13aly Red Hot Chili Peppers: Funky Monks Red Hot Chili Peppers: Funky Monks Zpěvák Anthony Kiedis, baskytarista Flea, bubeník Chad Smith... 3.4 1991 . . .

OData a další webová rozhraní API

Dnes se používají tisíce webových rozhraní API. Mezi oblíbená API v této kategorii patří mapové služby. K červnu 2012 bylo na webových stránkách Programmable Web uvedeno více než 6 000 webových rozhraní API (viz příspěvek s názvem: Obchodní modely API se dostávají do centra pozornosti). Nedávná studie Vordel zjistila, že „polovina podniků přijímá rozhraní API k budování nových obchodních kanálů“, přičemž 25 % těchto rozhraní API je vyvinuto speciálně pro mobilní aplikace.

Jednou oblastí zájmu je, jak OData souvisí s úsilím Linked Data API. Pracovní skupina W3C Linked Data Platform (LDP) a technický výbor OASIS OData se snaží specifikovat API typu REST pro získávání a manipulaci s daty na internetu pomocí různých datových modelů. Platforma LDP je založena na datovém modelu specifikovaném společností Microsoft a má svůj původ v modelu vztahu entit Petera Chena formulovaném v roce 1976 (Peter Chen Model EDM se stále používá při návrhu relačních databází). transformace informací na entity a vztahy Tento model používá hodnoty specifické pro doménu, jako jsou čísla sociálního pojištění, čísla faktur a čísla položek, k odkazování na zdroje a jejich vlastnosti a k ​​propojení informací.

EDM prezentuje informace způsobem, který je známý mnoha datovým vědcům. To vývojářům výrazně usnadňuje pochopení a používání tohoto modelu. RDF umožňuje propojovat data v globálním měřítku a podporuje vyvozování prostřednictvím vyvozování – to znamená, že umožňuje odvodit nová fakta z existujících informací pomocí univerzálních identifikátorů, přidružených definic a vlastností.

Vytváření adaptérů mezi heterogenními webovými rozhraními API je zcela možné. Například prototypový adaptér pro propojování pracovních položek řešení získaného prostřednictvím API založeného na propojených datech s názvem OSLC (Open Services for Life Cycle Collaboration) a dokumenty společnosti Microsoft Sharepointy získané prostřednictvím OData lze nalézt na následujícím odkazu: http://wiki.eclipse.org/Lyo/SharepointAdapter.

Jak se trh rozšiřuje, objevují se nová API. I když se jejich možnosti mohou v různé míře překrývat, není pochyb o tom, že vývojáři budou v této slibné technologické oblasti pokračovat v inovacích, jakmile budou identifikovány nové případy použití.

Poděkování

Vyjadřuji hlubokou vděčnost svým kolegům za jejich zpětnou vazbu a návrhy: Elizabeth Cleary, Andrew Eisenberg, Diane Jordan, Arnaud Le Hors.

Představme si na chvíli, že máme informační základny na platformě 1C:Enterprise 8, s jejichž daty potřebujeme pravidelně pracovat. Ale bohužel nemáme možnost provést žádné vlastní změny v jejich konfiguraci. To je možné (pokud existuje plnohodnotná platforma); nebo zdarma "1C:UNF pro Ukrajinu. Micro"; nebo kvůli výhodám automatická aktualizace nechceme odebrat podporu; nebo servisní společnost jmenovala náklady na své služby, které nedostaly schválení od vedení, ale neexistuje žádný interní „programátor 1C“...

A v takových podmínkách dostanete za úkol integrovat tuto databázi a nějaký externí systém. Co bychom měli dělat a jaké máme možnosti? Je možné mě doplnit v komentářích, ale zatím vidím přesně 5 způsobů:

  1. Přístup k databázi prostřednictvím rodiny COM objekty(V83.ComConnector a starší). Omezení: Platforma musí být nainstalována v systému Windows.
  2. Přímý přístup do databázových tabulek. Zde je příklad pro DBMS. . Omezení: zákaz přímého přístupu k datům v licenční smlouvě; nestabilita získaného přístupu; změna dat může vést k narušení logické integrity databáze.
  3. Počínaje verzí platformy 8.3.5 bylo možné poskytovat přístup k datům prostřednictvím automatické rozhraní REST založené na protokolu OData v.3.0. Omezení: Musíte nainstalovat webový server a rozšiřující modul webového serveru dodávaný s platformou.
  4. Počínaje verzí platformy 8.3.6 to bylo prodlužovací mechanismus, která vám umožňuje „nacvaknout“ nové funkce bez provádění změn v hlavní konfiguraci. Mezi nové funkce jsou pro nás zajímavé WEB a HTTP služby. Od verze platformy 8.3.11 byla k dispozici možnost rozšířit strukturu databázových tabulek (přidáním nových detailů pro ukládání dat služeb pro účely integrace). Omezení: je nutné mít programátora, který bude rozšíření vyvíjet a sledovat jeho výkon při aktualizacích; Pro služby je třeba nainstalovat webový server a rozšiřující modul webového serveru dodávaný s platformou.
  5. Můžete odmítnout "okamžitý přístup" a pak můžeme použít zahájení vnější ošetření pomocí parametru příkazový řádek/Vykonat. V takovém scénáři můžete pravidelně spouštět nějaké zpracování podle plánu, které zkontroluje externí zdroj pro pokyny k provedení a umístí tam výsledky své práce. Můžete také nezávisle spustit klientskou aplikaci 1C, abyste mohli vypracovat své příkazy, pokud máte přístup k OS, ve kterém je databáze umístěna. Omezení: je nutné mít programátora, který zpracování vytvoří; přítomnost časového zpoždění v reakci systému na hodnotu intervalu mezi spuštěními v plánovači nebo na čas spuštění klientské aplikace.

Mezi 5 možnostmi je tedy pro správce nejrychlejší a nejsnazší automatický přístup přes protokol oData. Tato možnost je multiplatformní.

A varianta s protokolem oData je levnější z pohledu vývoje spojení s databází 1C. Faktem je, že Microsoft to aktivně propaguje. Kromě vydání OData SDK pro vývoj pod .NET, AJAX, PHP, Java, JavaScript, WebOS a Objective-C tato společnost implementovala tento protokol do svých oblíbených produktů: Excel, PowerPoint, SharePoint, MsSQL a další. Nemusíte tedy vytvářet vlastní verzi CommerceML a analyzovat texty XML a JSON jak na vaší straně, tak na straně databáze 1C, jako byste implementovali své vlastní WEB a HTTP služby. Při používání OData budete mít okamžitě připravené knihovny pro získávání či úpravu dat pro použití ve vašem externím systému, přičemž na straně databáze 1C bude vše probíhat automaticky.

Už uplynula minuta?

Můžeme si vydechnout – už nemáme žádná omezení a můžeme si dělat jakoukoli integraci, kterou chceme! Na začátku jsem konkrétně omezil naši představivost, abych nevyjmenoval všechny možnosti ze slavné knihy „Integration Technologies 1C: Enterprise“ ISBN 978-5-9677-1462-7 od D.I. a Khrustaleva E.Yu (a hlavně neztrácejte čas seznamováním slabé stránky tyto možnosti). Můžete mě vzít za slovo zde nebo můžete zahájit diskuzi v komentářích, ale stále nejatraktivnější zůstává varianta s OData.

Koho toto téma zajímá, navštivte prosím oficiální stránky protokolu - www.odata.org. Ještě jednou bych vás rád upozornil na skutečnost, že i přes to, že současná verze protokol je již 4.0 a byl standardizován konsorciem OASIS 17. března 2014, ale platforma 1C:Enterprise 8 stále používá protokol více raná verze 3.0. Mimochodem, nezapomeňte se podívat na sekci ekosystém protokolu a obdivovat zmínku o našem 1C:Enterprise, který je na seznamu první :))

Požadovaná nastavení

Jak jsem již zmínil, musíte mít webový server. Počínaje verzí 8.4 bude mít serverová část platformy již svůj vlastní webový server, ale zatím musíme používat servery třetích stran – IIS nebo Apache. Jak vše nastavit je dobře popsáno ve žluté brožurce pro administrátora. Pokud ale máte rádi obrázky a zkušenosti jiných lidí, tak zde je rychlé vyhledávání: , a samozřejmě :) Nemohu ručit za úplnost a relevantnost údajů uvedených v těchto článcích a s autory se vůbec nevyznám . Pokud se vyskytnou problémy, přečtěte si Příručku správce pro vaši verzi platformy – je tam vše, co potřebujete.

Jakmile už máte nainstalovaný webový server a při spuštění již nepadá kvůli problémům s rozšířením přístupu k 1C (hádejme - nainstalovali jste 32bitový Apache a 64bitovou platformu), zbývá jen velmi málo. V konfigurátoru přejděte do nabídky "Správa" a klikněte na příkaz "Publikovat na webovém serveru...". V okně, které se objeví, musíte uvést následující důležité body:

  • Název vaší databáze v poli „Název“, pomocí kterého k ní webový server poskytne přístup (pokud nechcete problémy, nepište azbukou);
  • Zadejte webový server, na kterém je nainstalován tento počítač(pokud máte nainstalované dva webové servery, pak bude v rozevíracím seznamu možnost);
  • Cesta k publikačnímu adresáři, ke kterému by měl mít váš vybraný webový server přístup;
  • A co je nejdůležitější, zaškrtněte políčko „Publikovat standardní rozhraní OData“!

Po kliknutí na tlačítko „Publikovat“ se podél cesty zadané v nastavení vytvoří soubor default.vrd (soubor XML obsahující data, která jste provedli v nastavení publikování) a záznam o vaší publikaci se stejným název bude přidán do konfigurace webového serveru, jak jste uvedli. Po publikování by měl být webový server restartován.

Několik poznámek k publikaci. Pokud chcete publikovat několik databází, pak by každá z nich měla mít svůj vlastní katalog. Okamžitě přemýšlejte o uživateli, který se chystá přistupovat k databázi - musí mít potřebné role a jméno latinkou bez speciálních znaků (pokud chcete v budoucnu bojovat s kódováním, můžete jméno vytvořit v ruštině s mezerami) . Pokud pracujete ve Windows a máte povoleno UAC, měli byste před publikováním spustit konfigurátor jako správce. Pokud pracujete na Linuxu – vydržte, věříme ve vás! :)

Takto vypadá funkční default.vrd s publikovaným rozhraním OData:

Jak je vidět z publikačního souboru, webserveru je absolutně jedno, kde se infobáze fyzicky nachází, cesta k ní je zapsána úplně stejně, jako ji zapisujete do seznamu databází úvodní okno. Hlavní je, že přístupové rozšíření je nainstalováno na stejném počítači s webovým serverem a umístění databáze je fyzicky přístupné přes síť službě webserveru s právy modifikace. Problémy mohou nastat i se získáním licence a budete se muset ponořit do souboru nethasp.ini, ale to jsou všechno standardní postupy pro běžnou instalaci platformy.

Po publikování a restartování serveru můžeme zkontrolovat výsledky v prohlížeči. Chcete-li to provést, musíte zadat název webového serveru, poté název databáze z publikace a poté cestu /odata/standard.odata/ . Měli byste být požádáni o heslo a uvidíte něco podobného:

Abych demonstroval možnosti technologie popsané v článku, použil jsem konfiguraci „Trade Management (základní)“, vydání 10.3, ve které je režim kompatibility nastaven na „Version 8.2.13“, a proto jsou všechna metadata okamžitě dostupná prostřednictvím Rozhraní REST a volání funkce SetCompositionStandardInterfaceOData() pro řízení dostupnosti kompozice je zakázáno.

Pokud máte upravenou verzi obchodování 10.3, u které jste nastavili režim kompatibility na „Version 8.3.5“ nebo vyšší, nebo pokud máte modernější konfigurace, pak budou všechna metadata ve výchozím nastavení skryta a budete muset použít speciální zpracování k označení viditelnosti požadovaných údajů. Abyste neztráceli čas vytvářením vlastního zpracování, můžete využít moji práci, která je vhodná pro běžné i spravované rozhraní (viz přílohy).

dunění...

Abych byl upřímný, moc jsem této myšlence s vlastním seznamem metadat nerozuměl. Nějaké polovičaté řešení. Pokud bylo cílem zvýšit bezpečnost, proč je tedy povoleným datům okamžitě udělen úplný přístup k úpravám a mazání, a nikoli vyladěnější práva s možností poskytovat pouze pro čtení? Otázku práv můžete samozřejmě vyřešit pomocí speciálně nakonfigurované role, ale to už je zbytečná úprava řešení aplikace a ani v tomto případě nikoho do databáze přes rozhraní REST nepustím kromě serveru skripty mého webu (back-end), které rozhodnou, co dát a co ne.

Pokud chtěli minimalizovat množství přenášených informací, pak ještě pochybnějším rozhodnutím je podívat se na metadata jen párkrát, aby si prostudovali funkčnost a pak s daty pracovali. Bylo by logické provádět optimalizace konkrétně v datech? Bylo by totiž možné omezit seznam polí požadovaných od objektů a zvláště důležité je omezit zveřejňované informace pomocí parametru $expand, který stáhne celý přidružený objekt, když potřebujeme pouze jedno nebo dvě pole z to.

Co bude dál?

Myslím, že vám můžeme pogratulovat – vše máte nastavené a funguje! Jaké jsou další kroky? Vše záleží na tom, proč jste potřebovali organizovat přístup k databázi – vyměňovat si informace s firemním webem, provozovat mobilní aplikaci, propojit se s firemním softwarem...

Pokud si potřebujete na webu vytvořit něco jako uživatelský účet s historií vzájemných vypořádání, aktuálními cenami zohledňujícími osobní slevy, zadávání objednávek a další vychytávky, tak na oficiálních stránkách máme k dispozici několik hotových knihoven. Existuje dokonce celý framework OpenUI5 od SAP, který na základě dat přijatých přes protokol OData umožňuje vytvořit plnohodnotnou business aplikaci. Obecně svoboda pro kompetentního JS programátora.

Upozornění na „kola“

Pravděpodobně se vám po přečtení poslední věty mohou rozzářit oči – „K čertu se standardním webovým klientem 1C S takovými možnostmi si vytvořím vlastní rozhraní k databázi s blackjackem a příjemnou společností.“ Být vámi, nespěchal bych v tomto oboru konkurovat společnosti 1C, kde zkušení weboví vývojáři již několik let tvoří to, co po tom všichni vidíme. Opravdu chcete opakovat nechvalně známý „Dominikánský projekt“?

Tvůrci mi mohou namítnout – ten risk stojí za námahu a již vznikly produkty, které jsou téměř připraveny pro komerční využití. Zaměstnanci Oknosoftu se zde často rádi chlubí, že na jejich rozvoj na další roky stojí fronta klientů. A jsem za ně upřímně rád - kluci našli své místo. Z jejich článků jsem ale nabyl dojmu, že jejich komplex metadata.js je webovou obdobou kdysi oblíbeného programu „Extensions for Pocket Computers“ od firmy DISCO, který běžným programátorům 1C umožňoval psát aplikace pro chytré telefony. A kde je tento program nyní? Stejná funkce pro vývoj mobilních řešení (a ještě bohatší a dále velké množství platformy) 1C sama dala zdarma v rámci dodávky své platformy.

Z osobní zkušenosti. V určitém okamžiku, po mé poznámce „že to nelze provést ve webovém klientovi 1C“, se moje bývalá společnost rozhodla vytvořit vlastní alternativní webové rozhraní. Najali jsme několik vývojářů JavaScriptu, jako základ pro front-end jsme vzali tehdy oblíbenou knihovnu rozhraní s krásnými mřížkami a grafy a pro server jsme zvolili node.js. Pro tento projekt jsem implementoval rozhraní pro přístup k datům SOAP (služby HTTP ještě neexistovaly) a během pár týdnů jsme obdrželi krásnou formu seznamů objednávek. Nevím přesně, co se při vývoji stalo, ale po několika měsících hrdinského boje proti totálnímu útoku chyb byl projekt uzavřen a vývojáři se rozloučili. Programátoři společnosti 1C však v tuto chvíli neseděli nečinně, ale vydali řadu aktualizací, po kterých bylo používání standardního webového klienta o něco příjemnější.

Řekněme, že nejsme kompetentní JS programátoři, ale chceme na stránky umístit nějaký seznam. Otevřel jsem článek se seznamem nejpopulárnějších knihoven pro tvorbu tabulek současnosti a našel v něm jednoduchou knihovnu jsGrid právě pro náš případ. Prostudujeme jejich web, vezmeme si příklad jejich kódu pro používání OData a vložíme tam cestu k našim datům.

Abych byl úplně líný a nic pro náš příklad nenaprogramoval, potřebuji si vyžádat plnohodnotnou tabulku bez nutnosti načítání řetězcových reprezentací přes odkazy. Ve standardním UT10.3 není v tomto ohledu příliš bohatý výběr, a proto vezmu adresář Contractors.

Nyní přichází ta zábavná část. Jak můžeme vygenerovat řetězec dotazu pro čtení dat, která potřebujeme? Je to jednoduché! Podívejme se na naši cestu ke kořenu OData (pro mě je to ), abychom viděli, jak se tato referenční kniha správně nazývá - Katalog_Protistrany. Dále otevřete adresu v novém okně http://localhost/DemoTrdBase/odata/standard.odata/Katalog_Protistranyuvidíme obsah celého adresáře ve formátu XML. Ale pro náš příklad potřebujeme JSON, a proto musíme do řádku přidat parametr:$format=json - bude to fungovat http://localhost/DemoTrdBase/odata/standard.odata/Katalog_Protistrany? $format=json . Skupiny nás tedy nezajímají, takže je odstraníme pomocí parametru filtrování:$filter=IsFolder eq false - bude to fungovat http://localhost/DemoTrdBase/odata/standard.odata/Katalog_Protistrany? $format=json & $filter=IsFolder eq false . Blok parametrů, jak jste si již všimli, začíná symbolem „?“ a samotné parametry jsou navzájem spojeny symbolem „&“. Úplný seznam Dostupné parametry a funkce naleznete v dokumentaci platformy.

Výsledný soubor umístíme do adresáře, který je na vašem webovém serveru nakonfigurován jako kořenový adresář. To je nezbytné, aby se „domény“ stránky a požadovaná data shodovaly, jinak se zobrazí nekonečný indikátor aktualizace a chyba v protokolech: "Na požadovaném zdroji není přítomno žádné záhlaví „Access-Control-Allow-Origin“. Původ "null" proto není povolen. Odpověď měla stavový kód HTTP 401. "


Doslova pár minut stráveného času a už máme slušnou cedulku, která se dokonce automaticky rozkládá na stránkách. Jen požadavek na autentizaci vypadá trochu nešikovně a abych pokaždé nezadával login a heslo, napsal jsem je rovnou do řádku pro přístup. Výsledný soubor se ukázal být docela jednoduchý a každý si ho může snadno zopakovat, ale pro každý případ ho vložím i do příloh.

A vůbec bez programování?

Webové stránky, mobilní aplikace, message bus a další slova zní skvěle pro každého IT specialistu, ale nenacházejí odezvu v srdcích vysoce postavených šéfů. Jejich hlavním pracovním nástrojem je Excel, pro který hoří iracionální láskou i s výkonným reportovacím subsystémem ze svých 1C databází. A v tuto chvíli si pamatujeme, že to byl Microsoft, kdo přišel se standardem OData a implementoval jej do svých programů počínaje Office 2010. kancelářské programy můžeme buď jednoduše prohlížet tabulky s daty, nebo pomocí dotazovacích modulů získat více zajímavých informací najednou, aniž bychom museli propojovat tabulky z různých listů.

Zajímají nás například dlužníci. V UT10 je získáme z virtuální tabulky zůstatků registru akumulace Vzájemná vypořádání s protistranami, a to filtrem tak, aby výše dluhu byla větší než nula (jinak se jedná o zálohy). Datum nenastavím, protože mě zajímají aktuální údaje. Pro moji databázi to bude následující odkaz: http://localhost/DemoTrdBase/odata/standard.odata/AccumulationRegister_Vzájemné vypořádání s protistranami/Balance?$filter=AmountBalance gt 0

Když se podíváme na výsledek, můžeme si všimnout, že nemáme pohledy pro protistrany, ale pouze klíče pro tabulku adresáře protistran. Proto si vyžádáme i tyto pomocné údaje. Chcete-li to provést, použijte odkaz bez filtrů: http://localhost/DemoTrdBase/odata/standard.odata/Catalog_Counterparties

A nyní jednoduchý sled kroků:

  1. Otevřete Excel (mám verzi 2016; pokud máte 2010 nebo 2013, nabídka se může mírně lišit)
  2. Sledujeme navigační cestu: „Data“ / „Vytvořit požadavek“ / „Z jiných zdrojů“ / „Z kanálu ODATA“.
  3. Uvádíme odkaz na registr vzájemných zúčtování
  4. Na autorizačním formuláři vyberte třetí možnost „Základní“ a uveďte své přihlašovací jméno/heslo. Klikněte na "Připojit".
  5. V okně editoru požadavků, které se otevře, místo názvu „Požadavek1“ dáme něco zajímavějšího - „Vzájemné vyrovnání“
  6. Uprostřed okna editoru dotazů vidíme sloupec „Seznam“ se slovem „Záznam“ na každém řádku. Můžeme buď použít kontextový příkaz "To Table" nebo kliknout na odpovídající tlačítko v nabídce "Transform" editoru. Odpovězte „OK“ na otázku, která se objeví.
  7. Nyní se sloupec nazývá "Column1" a vedle něj je tlačítko se šipkami v různých směrech. Klikněte na to. Popis existujících sloupců bude stažen ze serveru. Zrušte zaškrtnutí všech políček a ponechte je pouze ve sloupcích „Klíč_účtu“ a „Zůstatek částky“. Klikněte na „OK“ a objeví se tabulka sestávající ze dvou vybraných sloupců s údaji, které potřebujeme.
  8. Takové dimenze jako organizace, smlouva a transakce zůstaly mimo naši pozornost, ale stále byly požadovány. V důsledku toho nyní máme protistrany s různými částkami. Lze je sbalit pomocí seskupování. Chcete-li to provést z nabídky nebo z kontextu, zavolejte příkaz "Seskupit podle". V polích seskupení ponechte pouze protistranu a pole s částkou vymažte. Nový sloupec pojmenujte „Dluh“, v operaci vyberte „Částka“ a ve sloupci uveďte pole pro naši částku. Klikněte na "Ok" a ve výsledku dostaneme o něco méně záznamů.
  9. Nyní musíme dešifrovat protistrany. Chcete-li to provést, v levém panelu „Dotazy“, kde je již aktuální požadavek „Vzájemná vypořádání“, volejte kontextová nabídka a vyberte Nový dotaz / Jiné zdroje / Zdroj ODATA. V okně, které se objeví, uveďte cestu k adresáři protistran. Poté znovu zadejte přihlašovací jméno/heslo pro autorizaci, v náhledu klikněte na „OK“ a pojmenujte nový požadavek „Protistrany“.
  10. Vraťme se k požadavku „Vzájemné vyrovnání“ (klikněte na název v panelu požadavku).
  11. Nyní spojíme naše dva dotazy. Chcete-li to provést, zavolejte v hlavní nabídce editoru příkaz "Spojit" / "Spojit dotazy". V okně návrháře svazu bude naše tabulka vzájemných vypořádání. Uprostřed v rozevíracím okně vyberte požadavek „Protistrany“. Typ připojení zůstává výchozí (levý vnější). Dále klepnutím vyberte sloupce pro podmínku sloučení. Souhlasíme se vším, co je nám dále nabízeno.
  12. Po sloučení jsme dostali nový sloupec „Protistrany“ se známým tlačítkem s vícesměrnými šipkami. Klikněte na toto tlačítko a vyberte sloupce, které nás zajímají. Pro zábavu vyberte „NameFull“ a „Parent“ (skupina). Sloupec "Rodič" nás také vyzývá k otevření - vyberte v něm pole "Popis" (obvyklý název adresáře).
  13. Udělejme to krásně. První sloupec můžeme smazat klíčem protistrany. Sloupec skupiny nazveme „Skupina“, sloupci s názvem protistrany dáme název „Protistrany“ a sloupec dluhu přesuneme na konec výsledné tabulky.
  14. Nyní můžeme kliknout na hlavní tlačítko editor - "Zavřít a načíst".
  15. Načtenou tabulku pak můžete použít jako data pro kontingenční tabulku nebo kontingenční graf. Nebo při vytváření těchto nových objektů zadáme jako zdroj dat náš dotaz „Settlements“.

Ale jak se říká, je lepší jednou vidět, než stokrát slyšet. Snažil jsem se nahrát stejnou sekvenci akcí na video. A hned upozorňuji, že až to zopakujete, bude to trochu jinak – bude se vyžadovat autorizace, jak jsem uvedl výše. Je to tak, že v době nahrávání videa si Excel již pamatoval moje přihlašovací jméno a heslo.

Výsledek

Doufám, že můj článek byl užitečný. Nahlásil jsem existenci a výhody nová technologie platformy. Také podrobně vysvětlil nastavení přístupu v informační základna pomocí protokolu OData a uvedl několik příkladů praktického použití.

Aby nevznikaly předsudky, ke kterým lze přístup přes OData pouze využít spravované rozhraní na nejnovější verze platformě, zvolil jsem demo konfigurační základ „Trade Management (basic), rev 10.3“ v režimu kompatibility 8.2 jako příklad školení. I na databázi takové konfigurace můžete pomocí několika kliknutí myší získat aktuální údaje o dluzích v excelovém sešitu a stejným způsobem můžete snadno získat aktuální stavy skladů, údaje o prodeji a další užitečné informace.

P.S. Pokračování tohoto článku, který pojednává o operacích vytváření a změny dat, je zveřejněno na

V 1C:Enterprise, počínaje verzí 8.3.5, může platforma automaticky generovat REST rozhraní pro celou konfiguraci. Pracuje pomocí protokolu OData a umožňuje práci s adresáři, dokumenty a registry přes webový server. Obecně platí, že rychlost příjmu dat je o několik řádů vyšší než přes COM nebo soubory, což je dobrá zpráva.

Pro různé operace se používají různé dotazy:

  • GET – slouží k příjmu dat;
  • POST – používá se k vytváření objektů;
  • PATCH – úprava existujícího objektu;
  • DELETE – smazání objektu.

Předpony se používají pro přístup k různým objektům:

  • Adresář - Katalog;
  • Dokument - Dokument;
  • Deník dokumentů - DocumentJournal;
  • Konstantní - Konstantní;
  • Burzovní plán - ExchangePlan;
  • Účtová osnova - ChartOfAccounts
  • Tabulka typů výpočtů - ChartOfCalculationTypes;
  • Tabulka charakteristických typů - ChartOfCharacteristicTypes;
  • Registr informací - InformationRegister;
  • Accumulation Register - AccumulationRegister;
  • Registr kalkulací - CalculationRegister;
  • Účetní evidence - AccountingRegister;
  • Obchodní proces - BusinessProcess;
  • Úkol – Úkol.

Pomocí protokolu ODATA můžete také použít vestavěné metody objektů při provádění požadavků POST.

  • Pro dokument – ​​​​Post() a Unpost();
  • Pro úkol – ExecuteTask();
  • Pro obchodní proces – Start();
  • Pro registr informací – SliceLast() a SliceFirst();
  • Pro akumulační registr a účetní registr – Balance(), Turnovers() a BalanceAndTurnovers();
  • Pro výpočetní registr – ScheduleData(), ActualActionPeriod(),<ИмяПерерасчета>() a Základna<Имя базового регистра расчета>().

Chcete-li začít pracovat s tímto rozhraním, musíte jej publikovat. To se provádí prostřednictvím nabídky konfigurátoru „Administrace“ – „Publikovat na webovém serveru“, zaškrtněte políčko „Publikovat standardní rozhraní OData“ a klikněte na „Publikovat“.

Po zveřejnění lze protokol zkontrolovat na http://<ИмяСервера>/<ИмяБазы>/odata/standard.odata. V odpovědi bychom měli obdržet celé složení zveřejněných tabulek. Mělo by to vypadat podobně jako na obrázku níže.


Pokud je po publikování rozhraní REST složení publikovaných dat prázdné, musíte použít metodu Set Contents of the Standard OData Interface. Na vstupu má 1 parametr typu „pole“. Do pole musíte přidat metadata, která je třeba publikovat.

Složení = nové pole;
Composition.Add(Metadata.Directories.Protistrany);
SetCompositionofStandardInterfaceOData(Composition);

http://<ИмяСервера>/<ИмяБазы><ИмяСправочника>

Při požadavku můžete použít následující parametry:

vybrat – v tomto parametru označujeme pole, která potřebujeme;

formát – nastavíme formát, ve kterém chceme odpověď obdržet (XML nebo JSON), výchozí XML

odata – pokud v odpovědi nepotřebujeme popis metadat, napište „odata=nometadata“

filtr – zde označujeme výběry.

Jak jsem psal výše, odpověď můžeme získat ve dvou XML formáty nebo JSON, výchozí je XML. Abyste mohli přijímat data ve formátu JSON, potřebujete URL adresa přidat „?$format=application/json“.

http://<ИмяСервера>/<ИмяБазы>/odata/standard.odata/Catalog_<ИмяСправочника>?$format=application/json

V zásadě potřebujeme získat konkrétní prvek adresáře a ne všechny jeho položky. K tomu používáme kouzelné slovo "filtr".

http://<ИмяСервера>/<ИмяБазы>/odata/standard.odata/Catalog_<ИмяСправочника>?$format=application/json&$filter=Ref_Key eq guid’UID’

Pokud jste si všimli, URL obsahuje dva parametry $format a $filter, mohou být umístěny v libovolném pořadí, hlavní je, že před prvním parametrem je znak “ ? “ a před druhým” & “. Logika je zde následující: v první části uvádíme adresu adresáře a ve druhé parametry. Tyto části jsou odděleny znakem „ ? “, ale samotné parametry jsou odděleny znaménkem “ & “. Pokud to znázorníte schematicky, vypadá to takto

Tabulka adres ? $Parameter1=Parameter1Hodnota & $Parameter2=Parameter2Value

Byla implementována možnost automatického generování rozhraní REST OData pro celé aplikační řešení. Díky tomu jsme mohli poskytnout plný přístup aplikace třetí strany do databáze 1C jen několika kliknutími.

Tento mechanismus navržený k řešení několika běžných problémů:

  • Nahrávání/stahování dat do/z aplikačního řešení;
  • Integrace s webovými stránkami (on-line obchody);
  • Zvýšení funkčnosti aplikačního řešení bez změny konfigurace;
  • Integrace s jinými podnikovými systémy (někdy bez dalšího programování).

Rozhraní OData REST lze použít k výměně dat mezi databázemi 1C, ale protože pro to již existují jiné, pohodlnější mechanismy, hlavní účel rozhraní OData REST je spatřován v integraci se systémy třetích stran.

A to je opravdu pohodlné, vezmeme-li v úvahu, že klienti OData existují na všech hlavních platformách, lze si stáhnout odpovídající knihovny.

V tomto článku se pokusím podrobně pohovořit o tom, co je rozhraní OData REST a jak jej lze použít.

Publikování rozhraní REST OData

Pro použití rozhraní OData je potřeba jej publikovat a k tomu potřebujeme webový server - Apache 2.2 nebo IIS (od verze také Apache 2.4). Poté musíte přejít do nabídky „Správa“ -> „Publikovat na webovém serveru...“.

V okně, které se otevře, vyplňte požadovaná pole a klikněte na „Publikovat“:

Poté budete muset určit složení rozhraní OData, tzn. označte, které konfigurační objekty jsou v něm zahrnuty a které ne (zpočátku v kompozici není jediný objekt).

Můžete to udělat nějak takto:

&Procedura OnServer SetODataOnServer() tArray = Nové pole; tArray.Add(Metadata.Adresáře.Produkty); SetComposition ofStandardInterfaceOData(tArray); Konec procedury

&Na serveru

Procedura SetODataOnServer()

tArray= Nové pole;

tArray. Add(Metadata. Adresáře. Produkty) ;

SetComposition ofStandardInterfaceOData(tArray) ;

Konec procedury