Možnosti prístupu k zdrojom

Predstavme si na chvíľu, že na platforme 1C:Enterprise 8 máme infobázy, s dátami ktorých musíme pravidelne pracovať. Ale, bohužiaľ, nemáme možnosť vykonať žiadne zmeny v ich konfigurácii. Možno to (za prítomnosti plnohodnotnej platformy); alebo zadarmo "1C: UNF pre Ukrajinu. Micro"; alebo z dôvodu výhod automatických aktualizácií nechceme zrušiť podporu; alebo servisná spoločnosť vymenovala náklady na svoje služby, ktoré nedostali schválenie od vedenia a neexistuje žiadny vlastný „programátor 1C“ ...

A v takýchto podmienkach dostanete za úlohu integrovať túto základňu a nejaký externý systém. Čo robiť a aké máme možnosti? Je možné ma doplniť v komentároch, ale zatiaľ vidím presne 5 spôsobov:

1. Prístup k databáze cez rodinu COM objekty(V83.ComConnector a staršie). Obmedzenie: Platforma musí byť nainštalovaná v systéme Windows.
2. Priamy prístup do databázových tabuliek. Tu je príklad pre DBMS. . Obmedzenie: zákaz priameho prístupu k údajom v licenčnej zmluve; nestabilita prijatého prístupu; zmena údajov môže viesť k narušeniu logickej integrity databázy.
3. Od verzie platformy 8.3.5 bolo možné poskytovať prístup k údajom prostredníctvom automatické rozhranie REST založené na protokole OData v.3.0. Obmedzenie: Webový server a modul rozšírenia webového servera musíte nainštalovať z dodávky platformy.
4. Od verzie platformy 8.3.6 predlžovací mechanizmus, ktorý vám umožňuje „upevniť“ novú funkcionalitu bez vykonania zmien v hlavnej konfigurácii. Medzi nové funkcionality patria WEB a HTTP služby, ktoré sú pre nás zaujímavé. Od verzie platformy 8.3.11 sa sprístupnila možnosť rozšírenia štruktúry databázových tabuliek (pridanie nových detailov pre ukladanie servisných dát pre účely integrácie). Obmedzenie: je potrebné mať programátora, ktorý bude rozšírenie vyvíjať a bude sledovať jeho výkon pri aktualizáciách; pre služby je potrebné nainštalovať webový server a modul rozšírenia webového servera z dodávky platformy.
5. Môžeme odmietnuť "okamžitý prístup" a potom môžeme použiť spustenie externého spracovania pomocou voľby príkazového riadka /Execute. V takomto scenári môžete vykonať pravidelné plánované spustenie nejakého spracovania, ktoré skontroluje externý zdroj, či neobsahuje pokyny na vykonanie a umiestni tam výsledky svojej práce. Môžete tiež nezávisle spustiť klientsku aplikáciu 1C na vypracovanie svojich príkazov, ak máte prístup k OS, v ktorom sa základňa nachádza. Obmedzenie: je potrebné mať programátora, ktorý vytvorí spracovanie; prítomnosť časového oneskorenia v reakcii systému na hodnotu intervalu medzi spustením v plánovači alebo na čas spustenia klientskej aplikácie.

Spomedzi 5 možností je teda pre správcu najrýchlejší a najjednoduchší automatický prístup cez protokol oData. Rovnaká možnosť je multiplatformová.

A možnosť s protokolom oData je lacnejšia, pokiaľ ide o vývoj prepojenia s databázou 1C. Faktom je, že Microsoft na to tvrdo tlačí. Okrem uvoľnenia OData SDK pre vývoj .NET, AJAX, PHP, Java, JavaScript, WebOS a Objective-C spoločnosť implementovala tento protokol do svojich obľúbených produktov: Excel, PowerPoint, SharePoint, MsSQL a ďalších. Nemusíte teda vytvárať svoju vlastnú verziu CommerceML a analyzovať texty XML a JSON na vašej strane aj na strane základne 1C, ako keby ste implementovali svoje vlastné WEB a HTTP služby. Pri používaní OData budete mať okamžite pripravené knižnice na získanie alebo úpravu dát pre použitie vo vašom externom systéme, pričom všetko bude prebiehať automaticky na základnej strane 1C.

Minúta už uplynula?

Môžeme si vydýchnuť – už nemáme žiadne obmedzenia a môžeme si robiť akúkoľvek integráciu, akú chceme! Na začiatku som špeciálne obmedzil našu predstavivosť, aby som bolestne nevymenoval všetky možnosti zo známej knihy „1C: Enterprise Integration Technologies“ ISBN 978-5-9677-1462-7 od D.I.Goncharova. a Khrustaleva E.Yu (a ešte viac nestrácajte čas vymenovaním slabín týchto možností). Môžete ma brať za slovo tu alebo môžete začať diskusiu v komentároch, no stále je najatraktívnejšia možnosť OData.

Pre tých, ktorých táto téma zaujíma, navštívte oficiálnu stránku protokolu - www.odata.org. Ešte raz upozorňujem na skutočnosť, že aktuálna verzia protokolu je už 4.0 a bola štandardizovaná konzorciom OASIS 17. marca 2014, ale platforma 1C:Enterprise 8 stále používa protokol staršej verzie 3.0 . Mimochodom, nezabudnite sa pozrieť do sekcie ekosystémového protokolu a obdivovať zmienku o našom 1C:Enterprise, ktorý je prvý na zozname :))

Požadované nastavenia

Ako som už spomenul, musíte mať webový server. Od verzie 8.4 bude mať serverová časť platformy už vlastný webový server, ale zatiaľ musíme použiť servery tretích strán – IIS alebo Apache. Ako všetko nastaviť je dobre popísané v žltej brožúrke pre administrátora. Ale ak máte radi obrázky a skúsenosti iných ľudí, tak som to stiahol do vyhľadávania: , a samozrejme :) Nemôžem ručiť za úplnosť a relevantnosť údajov uvedených v týchto článkoch a s autormi sa vôbec nevyznám . Ak máte nejaké problémy, prečítajte si príručku správcu pre vašu verziu platformy – je tam všetko, čo potrebujete.

Po tom, čo už máte nainštalovaný webový server a už nepadá pri štarte kvôli problémom s rozšírením prístupu k 1C (hádajme - nainštalovali ste 32-bitový Apache a 64-bitovú platformu), zostáva len veľmi málo. V konfigurátore prejdite do ponuky „Správa“ a kliknite na príkaz „Publikovať na webovom serveri ...“. V zobrazenom okne musíte zadať nasledujúce dôležité body:

• Názov vašej databázy v poli "Názov", ktorým webový server poskytne prístup k nej (ak nechcete mať problémy, nepíšte v azbuke);
• Zadajte webový server, ktorý je nainštalovaný na tomto počítači (ak máte nainštalované dva webové servery, potom bude v rozbaľovacom zozname možnosť výberu);
• Cesta k publikačnému adresáru, ku ktorému by mal mať váš vybraný webový server prístup;
• A čo je najdôležitejšie – zaškrtávacie políčko „Publikovať štandardné rozhranie OData“!

Po kliknutí na tlačidlo „Publikovať“ sa na ceste zadanej v nastaveniach vytvorí súbor default.vrd (súbor XML, ktorý obsahuje údaje, ktoré ste vytvorili v nastaveniach publikovania) a záznam o vašej publikácii s týmto názvom sa pridá do konfigurácie webového servera, čo ste zadali. Po zverejnení by sa mal webový server reštartovať.

Niekoľko poznámok k publikovaniu. Ak máte niekoľko databáz na publikovanie, potom každá z nich musí mať svoj vlastný adresár. Okamžite premýšľajte o používateľovi, ktorý sa chystá pristupovať k databáze - musí mať potrebné úlohy a meno v latinke bez špeciálnych znakov (ak chcete v budúcnosti bojovať s kódovaním, môžete si vytvoriť meno v ruštine s medzerami) . Ak pracujete v systéme Windows a máte povolené UAC, pred publikovaním by ste mali spustiť konfigurátor ako správca. Ak pracujete na Linuxe – vydržte, veríme vám! :)

Takto vyzerá fungujúci default.vrd s publikovaným rozhraním OData:

Ako vidno z publikačného súboru, webserveru je absolútne jedno, kde sa infobáza fyzicky nachádza, cesta k nej sa zapisuje rovnako, ako ju zapisujete do zoznamu báz v úvodnom okne. Hlavná vec je, že rozšírenie prístupu je nainštalované na tom istom počítači s webovým serverom a umiestnenie databázy je fyzicky dostupné cez sieť pre službu web server s právami na zmenu. Problémy môžu byť aj so získaním licencie a budete sa musieť ponoriť do súboru nethasp.ini, ale to sú všetko štandardné postupy pre bežnú inštaláciu platformy.

Po dokončení publikácie a reštartovaní servera môžeme skontrolovať výsledky v prehliadači. Ak to chcete urobiť, musíte zadať názov webového servera, potom názov databázy z publikácie a potom cestu /odata/standard.odata/ . Mali by ste byť vyzvaní na zadanie hesla a uvidíte niečo podobné tomuto:

Na demonštráciu možností technológie diskutovanej v článku som si zobral konfiguráciu „Trade Management (basic)“, vydanie 10.3“, v ktorej je režim kompatibility nastavený na „Verzia 8.2.13“ a teda všetky metadáta sú okamžite dostupné cez rozhranie REST a volanie funkcie SetCompositionStandardInterfaceOData() na kontrolu dostupnosti kompozície sú zakázané.

Ak máte upravený obchod 10.3, v ktorom nastavíte režim kompatibility na „Verzia 8.3.5“ alebo vyššiu, alebo ak máte modernejšie konfigurácie, všetky metadáta budú predvolene skryté a budete musieť použiť špeciálne spracovanie na označenie viditeľnosť požadovaných údajov. Aby ste nestrácali čas vytváraním vlastného spracovania, môžete využiť moju prácu, ktorá je vhodná pre bežné aj riadené rozhrania (viď prílohy).

šomranie...

Aby som bol úprimný, tejto myšlienke s vlastným zoznamom metadát som veľmi nerozumel. Nejaké polovičné riešenie. Ak bolo cieľom zvýšiť bezpečnosť, prečo je potom povolený prístup k údajom okamžite s úplným prístupom k úpravám a odstraňovaniu, a nie doladiť práva s možnosťou poskytovať iba na čítanie? Otázku práv samozrejme môžete vyriešiť pomocou špeciálne nakonfigurovanej role, ale to je už zbytočná úprava aplikovaného riešenia a ani v tomto prípade nikoho do databázy cez REST rozhranie nepustím okrem servera skripty mojej stránky (back-end), ktoré rozhodnú o tom, čo dá a čo nie.

Ak by chceli minimalizovať množstvo prenášaných informácií, tak ešte pochybnejším rozhodnutím je pozrieť si metadáta len niekoľkokrát, aby ste si preštudovali funkčnosť a následne s dátami pracovali. Bolo by logické vykonať optimalizáciu v údajoch? Koniec koncov, bolo by možné obmedziť zoznam polí požadovaných od objektov a obzvlášť dôležité je obmedziť informácie zverejňované parametrom $ expand, ktorý stiahne celý priradený objekt, pričom z neho potrebujeme iba jedno alebo dve polia. .

A čo ďalej?

Myslím, že vám môžeme zablahoželať - všetko je nastavené a funguje pre vás! Aké sú ďalšie kroky? Všetko závisí od toho, prečo ste potrebovali organizovať prístup k databáze – vymieňať si informácie s firemnou webovou stránkou, prevádzkovať mobilnú aplikáciu, prepojiť sa s firemným softvérom...

Ak si chcete urobiť niečo ako používateľský účet na stránke s poskytovaním histórie vzájomných vysporiadaní, aktuálnych cien, zohľadnenia osobných zliav, zadania objednávky a iných vychytávok, tak na oficiálnej stránke máme niekoľko hotových knižníc v našich službách. Existuje dokonca celý rámec OpenUI5 od SAP, ktorý umožňuje vytvárať plnohodnotnú biznis aplikáciu na základe databázy získanej cez protokol OData. Vo všeobecnosti priestor pre kompetentného programátora JS.

Pozor na „bicykle“

Pravdepodobne by sa vám po prečítaní poslednej frázy mohli rozžiariť oči - "Do pekla so štandardným webovým klientom 1C! S takými možnosťami si vytvorím vlastné rozhranie k databáze s blackjackom a príjemnou spoločnosťou." Ale na tvojom mieste by som sa v tejto oblasti neponáhľal konkurovať 1C, kde skúsení weboví vývojári už niekoľko rokov vytvárajú to, čo všetci vidíme. Naozaj chcete zopakovať smutnú slávu „dominikánskeho projektu“?

Tvorcovia mi môžu namietať a - ten risk stojí za námahu a už vznikli takmer hotové komerčné produkty. Zamestnanci Oknosoftu sa tu často radi chvália, že na ich rozvoj stojí rad zákazníkov na ďalšie roky. A som za nich úprimne šťastný - chlapci si našli svoje miesto. No podľa ich článkov som nadobudol dojem, že ich komplex metadata.js je webovou obdobou kedysi obľúbeného programu DISCo Extensions for Pocket Computers, ktorý umožňoval bežným programátorom 1C písať aplikácie pre smartfóny. A kde je tento program teraz? Samotná spoločnosť 1C poskytla rovnakú funkcionalitu na vývoj mobilných riešení (a ešte bohatších a pre viac platforiem) zadarmo ako súčasť dodávky svojej platformy.

Z osobnej skúsenosti. V určitom momente, po mojej poznámke „že to nie je možné urobiť vo webovom klientovi 1C“, sa moja bývalá spoločnosť rozhodla vytvoriť vlastné alternatívne webové rozhranie. Najali sme niekoľko vývojárov JavaScriptu, ako základ pre front-end sme vzali nejakú vtedy populárnu knižnicu rozhrania s krásnymi mriežkami a grafmi a pre server sme vybrali node.js. Pre tento projekt som implementoval rozhranie pre prístup k dátam SOAP (vtedy ešte neboli žiadne HTTP služby) a za pár týždňov sme dostali krásnu formu zoznamov objednávok. Neviem presne, čo sa tam pri vývoji stalo, ale po niekoľkých mesiacoch hrdinského boja proti totálnemu útoku chýb bol projekt uzavretý a vývojári sa rozlúčili. Programátori spoločnosti 1C však v tom čase nesedeli nečinne, ale vydali množstvo aktualizácií, po ktorých bolo používanie štandardného webového klienta o niečo príjemnejšie.

Povedzme, že nie sme kompetentní JS programátori, ale chceme na stránku zavesiť nejaký zoznam. Otvoril som článok so zoznamom najobľúbenejších knižníc na vytváranie tabuliek súčasnosti a našiel som v ňom jednoduchú knižnicu jsGrid práve pre náš prípad. Preštudujeme si ich stránku, vezmeme si príklad ich kódu na používanie OData a vložíme tam cestu k našim údajom.

Aby som bol úplne lenivý a nič nenaprogramoval pre náš príklad, potrebujem si vyžiadať plnohodnotnú tabuľku bez nutnosti načítavania reťazcových reprezentácií odkazmi. V typickom UT10.3 nie je v tomto smere výber príliš bohatý, a preto si vezmem adresár Counterparties.

Teraz to najzaujímavejšie. Ale ako vytvoriť reťazec dotazu na čítanie údajov, ktoré potrebujeme? Je to jednoduché! Pozeráme sa na našu cestu ku koreňu OData (pre mňa to je), ako sa tento adresár správne volá - Katalóg_Dodávatelia. Potom otvorte adresu v novom okne http://localhost/DemoTrdBase/odata/standard.odata/Katalóg_Dodávateliauvidíme obsah celého adresára vo formáte XML. Ale pre náš príklad potrebujeme JSON, a preto musíme do reťazca pridať parameter:$format=json - bude to fungovať http://localhost/DemoTrdBase/odata/standard.odata/Katalóg_Dodávatelia? $format=json . Skupiny nás teda nezaujímajú a odstránime ich pomocou parametra filtra:$filter=IsFolder eq false - bude to fungovať http://localhost/DemoTrdBase/odata/standard.odata/Katalóg_Dodávatelia? $format=json & $filter=IsFolder eq false . Blok parametrov, ako ste si už všimli, začína symbolom „?“ a samotné parametre sú navzájom spojené symbolom „&“. Úplný zoznam dostupných možností a funkcií nájdete v dokumentácii platformy.

Výsledný súbor vložíme do adresára, ktorý je nakonfigurovaný ako koreňový na vašom webovom serveri. Je to potrebné, aby sa „domény“ stránky a požadované údaje zhodovali, inak sa vám zobrazí nekonečný indikátor aktualizácie a chyba v protokoloch: "V požadovanom zdroji sa nenachádza hlavička „Access-Control-Allow-Origin“. Pôvod "null" preto nie je povolený. Odpoveď mala stavový kód HTTP 401. "

Doslova pár minút stráveného času a už máme slušný nápis, ktorý je dokonca automaticky označený na stránkach. Len požiadavka na autentifikáciu vyzerá trochu nemotorne a aby som zakaždým nezadával prihlasovacie meno a heslo, hneď som ich zaregistroval do prístupového riadku. Výsledný súbor sa ukázal byť celkom jednoduchý a každý si ho ľahko zopakuje, no pre každý prípad ho umiestnim aj do príloh.

Čo tak žiadne programovanie?

Webové stránky, mobilné aplikácie, zbernica správ a ďalšie slová pre každého IT špecialistu znejú cool, ale nenachádzajú odozvu v srdciach vysokých šéfov. Ich hlavným pracovným nástrojom je Excel, ku ktorému horia iracionálnou láskou aj keď majú výkonný reportingový subsystém zo svojich 1C databáz. A v tejto chvíli si pamätáme, že to bol Microsoft, kto prišiel so štandardom OData a implementoval ho do svojich programov počnúc Office 2010. V kancelárskych programoch si môžeme buď jednoducho prezerať dátové tabuľky, alebo pomocou dotazovacích mechanizmov získať zaujímavejšie informácie na čas bez toho, aby ste museli spájať tabuľky z rôznych listov.

Zaujímajú nás napríklad dlžníci. V UT10 ich vieme získať z virtuálnej tabuľky zostatkov akumulačného registra Vzájomné vyrovnania s protistranami tak, že nasadíme filter tak, aby výška dlhu bola väčšia ako nula (inak ide o preddavky). Termín neuvediem, nakoľko ma zaujímajú aktuálne údaje. Pre moju základňu to bude nasledujúci odkaz: http://localhost/DemoTrdBase/odata/standard.odata/AccumulationRegister_Calculations with counterparties/Balance?$filter=AmountBalance gt 0

Po prezretí výsledku si môžeme všimnúť, že nemáme pohľady pre protistrany, ale iba kľúče pre tabuľku adresára protistrany. Preto si vyžiadame aj tieto pomocné údaje. Ak to chcete urobiť, použite odkaz bez filtrov: http://localhost/DemoTrdBase/odata/standard.odata/Catalog_Contractors

A teraz jednoduchá postupnosť krokov:

1. Otvorte Excel (mám verziu 2016; ak máte 2010 alebo 2013, ponuka sa môže mierne líšiť)
2. Sledujeme navigačnú cestu: "Údaje" / "Vytvoriť dopyt" / "Z iných zdrojov" / "Z kanála ODATA".
3. Uvádzame náš odkaz na register vzájomných vyrovnaní
4. Na autorizačnom formulári vyberte tretiu možnosť „Základné“ a zadajte prihlasovacie meno / heslo. Kliknite na „Pripojiť“.
5. V okne editora dotazov, ktoré sa otvorí, namiesto názvu „Žiadosť1“ dáme pre nás niečo zaujímavejšie – „Vyrovnania“
6. V strede okna editora dotazov vidíme stĺpec „Zoznam“, kde každý riadok obsahuje slovo „Záznam“. Môžeme použiť buď kontextový príkaz "Do tabuľky" alebo kliknúť na príslušné tlačidlo v ponuke editora "Transformovať". Odpovedzte na otázku „OK“.
7. Teraz sa stĺpec nazýva "Stĺpec1" a vedľa neho je tlačidlo so šípkami v rôznych smeroch. Kliknite naň. Opis existujúcich stĺpcov bude stiahnutý zo servera. Zrušte začiarknutie všetkých políčok a ponechajte ich iba v stĺpcoch „Kľúč_účtu“ a „Kontrola sumy“. Kliknite na „OK“ a objaví sa tabuľka s dvoma vybranými stĺpcami s údajmi, ktoré potrebujeme.
8. Mimo našej pozornosti boli také dimenzie ako organizácia, zmluva a obchod, ale stále boli požadované. Výsledkom je, že teraz máme linky protistrany s rôznymi sumami. Môžu byť zbalené pomocou zoskupovania. Ak to chcete urobiť, buď z ponuky alebo z kontextu, zavolajte príkaz "Zoskupiť podľa". V poliach zoskupenia ponechajte iba protistranu a pole so sumou vymažte. Nový stĺpec pomenujte „Dlh“, v operácii vyberte „Suma“ a v stĺpci uveďte pole našej sumy. Kliknite na "OK" a v dôsledku toho dostaneme o niečo menej záznamov.
9. Teraz musíme dešifrovať protistrany. Ak to chcete urobiť, v ľavom paneli „Žiadosti“, kde už existuje aktuálna požiadavka „Vyrovnania“, zavolajte do kontextového menu a vyberte „Nová požiadavka“ / „Iné zdroje“ / „Kanál ODATA“. V zobrazenom okne zadajte cestu k adresáru protistrany. Ďalej znova zadajte autorizačné prihlasovacie meno/heslo, v náhľade kliknite na „OK“ a novú požiadavku pomenujte „Účty“.
10. Vráťme sa k dotazu „Vyrovnania“ (kliknite na názov na paneli dotazu).
11. Teraz spojme naše dve otázky. Za týmto účelom zavolajte v hlavnom menu editora príkaz "Spojiť" / "Zlúčiť dopyty". V okne projektanta zväzu bude naša tabuľka vzájomného zúčtovania. V strede v rozbaľovacom poli vyberte dopyt „Účty“. Typ pripojenia zostáva štandardne nastavený (ľavý vonkajší). Potom kliknutím vyberte stĺpce pre podmienku spojenia. Súhlasíme so všetkým, čo sa nám nižšie ponúka.
12. Po zlúčení sme dostali nový stĺpec „Účty“ so známym tlačidlom s viacsmerovými šípkami. Klikneme na toto tlačidlo a vyberieme stĺpce, ktoré nás zaujímajú. Pre zaujímavosť zvoľte "NameFull" a "Parent" (skupina). Stĺpec "Rodič" nás tiež pozýva na otvorenie - vyberte v ňom pole "Popis" (bežný názov adresára).
13. Urobme si to krásne. Prvý stĺpec môžeme vymazať kľúčom protistrany. Skupinový stĺpec pomenujeme „Skupina“, stĺpci s názvom protistrany dáme názov „Protistrany“ a stĺpec dlhu presunieme na koniec výslednej tabuľky.
14. Teraz môžeme kliknúť na tlačidlo hlavného editora - "Zavrieť a načítať".
15. Potom môžete prevzatú tabuľku použiť ako údaje pre kontingenčnú tabuľku alebo kontingenčný graf. Alebo pri vytváraní týchto nových objektov špecifikujeme ako zdroj údajov našu požiadavku „Vzájomné vyrovnania“.

Ale ako sa hovorí, je lepšie raz vidieť ako stokrát počuť. Snažil som sa nahrať rovnakú postupnosť akcií na video. A hneď upozorňujem, že keď to zopakujete, bude to trochu inak – bude sa žiadať autorizácia, ako som už vyššie spomínal. Práve v čase nahrávania videa si Excel už pamätal moje používateľské meno a heslo.

Výsledky

Dúfam, že môj článok bol užitočný. Informoval som o existencii a výhodách novej technológie platformy. Podrobne vysvetlil aj konfiguráciu prístupu k infobáze cez protokol OData a uviedol niekoľko príkladov praktického využitia.

Aby som predišiel predsudkom, že prístup OData je možné použiť len pre spravované rozhranie na najnovších verziách platformy, ako tréningový príklad som zvolil demo konfiguračnú databázu „Trade Management (basic), vydanie 10.3“ v režime kompatibility 8.2. Aj s databázou takejto konfigurácie sa pár kliknutiami myšou dostanete k aktuálnym údajom o dlhoch v excelovom zošite a rovnako jednoduché by bolo aj získanie aktuálnych stavov zásob, údaje o predaji a ďalšie užitočné informácie.

P.S. Pokračovanie tohto článku, ktorý pojednáva o operáciách vytvárania a úpravy údajov, je uverejnené na

V 1C:Enterprise, počnúc verziou 8.3.5, môže platforma automaticky generovať REST rozhranie pre celú konfiguráciu. Pracuje na protokole OData a umožňuje prácu s adresármi, dokumentmi a registrami cez webový server. Vo všeobecnosti je rýchlosť prijímania dát o niekoľko rádov vyššia ako cez COM alebo súbory, čo je dobrá správa.

Pre rôzne operácie sa používajú rôzne dotazy:

• GET - používa sa na získanie údajov;
• POST - používa sa na vytváranie objektov;
• PATCH - úprava existujúceho objektu;
• DELETE - vymazanie objektu.

Predpony sa používajú na prístup k rôznym objektom:

• Adresár - Katalóg;
• Dokument - Dokument;
• Dokumentový denník - DocumentJournal;
• Konštantný - Konštantný;
• Výmenný plán - Výmenný plán;
• Účtová osnova - ChartOfAccounts
• Plán typu výpočtu - ChartOfCalculationTypes;
• Tabuľka typov charakteristík - ChartOfCharacteristicTypes;
• Register informácií - InformationRegister;
• Register akumulácie - Register akumulácie;
• Register výpočtov - CalculationRegister;
• Účtovný register - AccountingRegister;
• Obchodný proces - BusinessProcess;
• Úloha - Úloha.

Pomocou protokolu ODATA môžete tiež použiť vstavané metódy objektov vykonávaním požiadaviek POST.

• Pre dokument Post() a Unpost();
• Pre úlohu - ExecuteTask();
• Pre obchodný proces - Start();
• Pre informáciu sa zaregistrujte - SliceLast() a SliceFirst();
• Pre register akumulácie a účtovný register - Balance(), Turnovers() a BalanceAndTurnovers();
• Pre register výpočtov – ScheduleData(), ActualActionPeriod(),<ИмяПерерасчета>() a Základ<Имя базового регистра расчета>().

Ak chcete začať pracovať s týmto rozhraním, musíte ho zverejniť. Urobíte to cez menu konfigurátora „Administrácia“ – „Publikovať na webovom serveri“, zaškrtnite políčko „Zverejniť štandardné rozhranie OData“ a kliknite na „Publikovať“.

Po zverejnení je možné fungovanie protokolu skontrolovať na http://<ИмяСервера>/<ИмяБазы>/odata/standard.odata. Ako odpoveď musíme dostať celé zloženie zverejnených tabuliek. Malo by to vyzerať ako na obrázku nižšie.

Ak je po zverejnení rozhrania REST zloženie publikovaných údajov prázdne, musíte použiť metódu SetStandardODataInterfaceComposition. Na vstupe má 1 parameter typu „pole“. Do poľa musíte pridať metadáta, ktoré chcete zverejniť.

Zloženie = nové pole;
Composition.Add(Metadáta.Katalógy.Účty);
SetCompositionStandardInterfaceOData(Composition);

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

Pri dotazovaní môžete použiť nasledujúce možnosti:

vybrať - v tomto parametri špecifikujeme polia, ktoré potrebujeme;

formát - nastavíme formát, v ktorom chceme odpoveď dostať (XML alebo JSON), predvolený je XML

odata - ak v odpovedi nepotrebujeme popis metadát, napíšeme „odata=nometadata“

filter - tu uvádzame výbery.

Ako som písal vyššie, odpoveď môžeme dostať v dvoch formátoch XML alebo JSON, štandardne sa používa XML. Ak chcete získať údaje vo formáte JSON, musíte do adresy URL pridať „?$format=application/json“.

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

V podstate potrebujeme získať konkrétny prvok adresára a nie všetky jeho položky. Na to používame čarovné slovíčko "filter".

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

Ak ste si všimli, URL obsahuje dva parametre $format a $filter, dajú sa umiestniť v ľubovoľnom poradí, hlavné je, že prvému parametru musí predchádzať znak “ ? "a pred druhým" & “. Logika je tu taká, v prvej časti uvádzame adresu adresára a v druhej parametre. Tieto časti sú oddelené znakom „ ? “, ale samotné parametre sú oddelené znakom “ & “. Schematicky to vyzerá takto

AddressTables ? $Parameter1=Hodnota parametra1 & $Parameter2=Hodnota parametra2

Bola implementovaná možnosť automatického generovania rozhrania OData REST pre celé aplikačné riešenie. Máme teda možnosť poskytnúť úplný prístup k aplikácii tretej strany do databázy 1C len niekoľkými kliknutiami.

Tento mechanizmus je určený na riešenie niekoľkých bežných úloh:

• Nahrávanie / načítanie údajov do / z aplikačného riešenia;
• Integrácia s internetovými stránkami (on-line obchody);
• Zvýšenie funkčnosti aplikovaného riešenia bez zmeny konfigurácie;
• Integrácia s inými podnikovými systémami (niekedy bez dodatočného programovania).

Rozhranie OData REST možno použiť na výmenu údajov medzi databázami 1C, ale keďže na to už existujú iné, pohodlnejšie mechanizmy, hlavný účel rozhrania OData REST sa vidí v integrácii so systémami tretích strán.

A to je naozaj výhodné, ak vezmeme do úvahy, že klienti OData existujú na všetkých hlavných platformách, príslušné knižnice je možné stiahnuť.

V tomto článku sa pokúsim podrobne vysvetliť, čo je rozhranie OData REST a ako sa dá použiť.

Publikovanie rozhrania OData REST

Aby ste mohli používať rozhranie OData, musíte ho publikovať a na to potrebujeme webový server - Apache 2.2 alebo IIS (od verzie aj Apache 2.4). Potom musíte prejsť do ponuky „Správa“ -> „Publikovanie na webovom serveri ...“.

V okne, ktoré sa otvorí, vyplňte požadované polia a kliknite na „Publikovať“:

Potom bude potrebné určiť zloženie rozhrania OData, t.j. uveďte, ktoré konfiguračné objekty sú v ňom zahrnuté a ktoré nie (na začiatku nie je v kompozícii jediný objekt).

Môžete to urobiť takto:

&AtServer Procedúra SetODataAtServer() tArray = Nové pole; tArray.Add(Metadata.Katalogy.Produkty); SetStandardInterface CompositionOData(tArray); EndProcedure

Tlačiť (Ctrl+P)

Druhú časť je možné vidieť

Všeobecné informácie

Vo verzii platformy 8.3.5.1068 , zverejnenom v septembri 2015, sa objavil mechanizmus na integráciu 1C s externými programami prostredníctvom technológie REST rozhranie. Platforma používa ako prístupový protokol protokol OData. Je to otvorený webový protokol na vyhľadávanie a aktualizáciu údajov. Umožňuje vám manipulovať s údajmi pomocou príkazov HTTP ako požiadaviek. Odpovede vo verzii 8.3.5.1068 bolo možné prijímať len vo formáte Atom/XML . Od vydania 8.3.8.1652 v auguste 2017 sa však objavila druhá možnosť získavania údajov vo formáte JSON (JavaScript Object Notation). . V porovnaní s XML je pre ľudí ľahko čitateľný a zaberá menej miesta. Všetky prehliadače majú navyše vstavané nástroje na prácu s JSON.

Prácu s protokolom OData na platforme 1C: Enterprise nájdete v knihe 1C: Developer's Guide v kapitole 17 Mechanizmy internetových služieb, odstavec 17.2.1 Štandardné rozhranie OData. Môžete sa tiež pozrieť na príklady rozšírenia podpory protokolu OData,

Využite výhodu REST rozhranie. dochádza k záveru, že na získanie prístupu k systémovým údajom z externej aplikácie nie je potrebná úprava kódu aplikačného riešenia (napríklad ak je aplikačné riešenie podporované). Ak chcete získať tento prístup, musíte aplikáciu publikovať na webovom serveri špeciálnym spôsobom a špecifikovať, ktoré konfiguračné objekty sa budú týmto spôsobom používať. Potom môžu systémy tretích strán pristupovať k vašej aplikácii pomocou požiadaviek HTTP.

Publikovanie štandardného rozhrania OData sa vykonáva pomocou publikačného dialógu na webovom serveri (Administrácia - Publikovanie na webovom serveri) a je popísané v knihe 1C:Enterprise 8.3. "Príručka správcu".
Dôležité! Aby boli konfiguračné objekty dostupné cez štandardné rozhranie OData, musíte to povoliť pomocou metódy globálneho kontextu Nastaviť zloženie StandardODataInterface().
Mechanizmus nastavenia zloženia objektov dostupných cez štandardné rozhranie OData je možné vykonať ako externé spracovanie. To si nevyžaduje úpravu aplikovaného riešenia.

Na interakciu s externým webovým serverom REST od 1C:Enterprise sa používajú nástroje dostupné v platforme na prácu s HTTP: objekty HTTPConnection, HTTPRequest a HTTPResponse.

V tejto sérii článkov ukážem príklady typických operácií pomocou zodpovedajúcej metódy HTTP;

• Získavanie údajov – metóda GET;
• Vytváranie objektov – metóda POST;
• Aktualizácia údajov: metóda ZÁPLATA- v tomto prípade môžete zadať iba tie vlastnosti, ktoré je potrebné aktualizovať; metóda PUT– v tomto prípade je potrebné špecifikovať všetky vlastnosti entity;
• Vymazanie údajov - metóda VYMAZAŤ.

1. Príklady získavania údajov. HTTP metóda GET

Server bude databáza zverejnená na webovom serveri s názvom webbuh(Ukážková báza „Účtovníctvo podniku 3.0“). Ako formát výmeny údajov použijem formát JSON. Viac informácií o práci s JSON je napísané v dostupnej dokumentácii. Ak chcete prijímať údaje zo servera pomocou metódy GET HTTP, musíte vytvoriť objekt Čítanie JSON na sekvenčné čítanie údajov JSON zo súboru alebo reťazca. Ak chcete organizovať sekvenčné nahrávanie objektov a textov na server pomocou metódy POST PATCH PUT HTTP, musíte vytvoriť objekt Vstup JSON. Všimnite si, že metóda DELETE nevyžaduje JSON.

Ako ilustráciu streamovania čítania a zápisu JSON pri prístupe k rozhraniu REST zavolám nasledujúcu univerzálnu vlastnú funkciu ZavolajteHTTPMethodOnServer :

Ak chcete prijímať zo servera vo formáte JSON, pri prístupe k rozhraniu REST aplikácie musíte zadať adresu zdroja $format=json. Alebo zadajte typ MIME application/json v názve:

Funkcia globálneho kontextu ReadJSON(ReadJSON, True)

• Ak je hodnota druhého parametra nastavená na True , čítanie objektu JSON sa uskutoční v Zhoda.Ak je nastavené na False , objekty budú načítané do objektu typu Štruktúra.
• Pri deserializácii objektov JSON do štruktúry si uvedomte požiadavky na kľúč štruktúry. Ak deserializácia objektu nájde názov vlastnosti, ktorý nie je platný pre kľúč štruktúry, bude vyvolaná výnimka.

1. 1 Konfigurácia parametrov pripojenia HTTP

Na organizáciu klientskej časti interakcie s externým webovým serverom REST som od začiatku vytvoril konfiguráciu klienta založenú na BSP. Na tejto konfigurácii som vytvoril adresár pre nastavenie parametrov pripojenia (viď obr. 1)

Obr. 1 Referenčná príručka pre konfiguráciu parametrov HTTP pripojenia k externému IB cez ostatné rozhranie

Po stlačení tlačidla Skontrolujte odozvu servera volá sa procedúra, pomocou ktorej sa klient pokúsi prijať odpoveď servera. Programový kód pre postup je napísaný nižšie:

Účelom tohto postupu je servisná kontrola ači používateľ správne zadal parametre pripojenia. Ak to chcete urobiť, stačí zadať požiadavku GET:
HTTPConnection.CallHTTPMmethod( "GET", Žiadosť HTTP);
pomocou adresy zdroja:
Adresa zdroja =BaseName+ “/odata/standard.odata/ “;
Fungovanie služby môžete skontrolovať aj v prehliadači pomocou
URL http://host/WebBuh/odata/standard.odata. V dôsledku takéhoto dotazu sa získa iba zoznam entít. Úplný popis štandardného rozhrania OData (zoznam dostupných entít, ich atribútov a funkcií vo forme XML-
dokument.) musíte zadať požiadavku GET pomocou parametra $metadata. URL http://host/WebBuh/odata/standard.odata/$metadata. Podrobný popis dokumentu možno nájsť na http://www.odata.org/documentation/ (v angličtine).
Odpovede môžete dostávať vo formáte Atom/XML alebo JSON. Stavové kódy odpovede HTTP je možné zobraziť Odpovede v rozsahoch:

• 100-199 – informačné odpovede o tom, že požiadavka klienta bola akceptovaná a spracováva sa.
• 200-299 – znamená, že požiadavka klienta bola úspešne spracovaná.
• 300-399 znamená, že požiadavka zlyhala a klient musí vykonať nejakú akciu na uspokojenie požiadavky.
• 400-499 - informuje o chybách na strane klientskej aplikácie. Tieto kódy môžu tiež naznačovať, že sa od klienta vyžadujú dodatočné informácie.
• 500-599 - Informuje o chybe na strane servera, indikuje, že server narazil na chybu a pravdepodobne nebude schopný splniť požiadavku klienta.

1.2 Vyhľadávanie objektu podľa ID

Nasledujúca funkcia je určená na vyhľadávanie adresára alebo dokumentu podľa jedinečného identifikátora na serveri. Ak sa objekt nájde, funkcia vráti hodnotu reťazca identifikátora (Ref_Key), inak vráti nedefinované. Funkcii sa odovzdajú nasledujúce parametre:

• HTTPConnection – Objekt typu HTTPConnection
• PublishName – názov publikovanej databázy servera
• Element - identifikátor entity objektu, napr. Katalóg_Organizácie alebo Dokument_ - adresár organizácie.
• Identifikátor – Identifikátor objektu, ktorý sa má vyhľadať na serveri, napr. Organization.UniqueIdentifier()

Parameter Adresa zdroja sa používa na prístup k službe REST. Ak chcete skontrolovať fungovanie služby, môžete týmto spôsobom zadať zdroj v prehliadači

http://(WebServerAddress)/(PubName)/odata/standard.odata/(Item)?(Parametre) ,kde

• Adresa webového servera– Adresa webového servera, na ktorom je služba zverejnená, napríklad Localhost
• Názov Publikácie– názov infobázy zadaný pri publikovaní riešenia
• /odata/standard.odata/ – Označenie prístupu k štandardnému rozhraniu OData
• Prvok – identifikátor zdroja alebo preddefinované zdroje. Napríklad Catalog_Account(guid'value').
• Parametre– parametre zdrojov. Používa sa napríklad na výber v akceptovaných požiadavkách HTTP: ?key=value&key2=value2

1.3 Vyhľadávanie objektu podľa vyhľadávacích polí

Nasledujúca užívateľsky definovaná funkcia je určená na vyhľadávanie objektu podľa vyhľadávacích polí v prípade, že ide o objekt podľa identifikačného čísla. Reťazec objektu funkcie Ref_Key-identifikačné číslo.

Ako je vidieť z tela postupu P SearchObjectByFieldsSearch, výber začína kľúčovým slovom$filterv adrese zdroja. Formálny parameterVyhľadávacie polia -toto je korešpondencia, ktorá obsahuje názvy a hodnoty atribútov.

Všimnite si, že názov detailov niekedy nie je zrejmý. Treba mať na pamäti, že pre adresáre:

• kód - kód,
• Popis
• DeleteMark - značka vymazania,
• IsFolder - znak skupiny,
• Parent_Key je rodič.
• Ak je atribút referenčného typu, pridajte k jeho názvu príponu _Key, napríklad Contractor_Key.

Pre dokumenty:

• Číslo – číslo dokladu,
• Dátum – dátum dokumentu.

Operácie logického výberu

• eq - Rovná sa; /Catalog_Cities?$filter=Názov eq ‘Hlavný’;
• ne - nerovná sa; /Catalog_Cities?$filter=Name ne ‘Perm’;
• gt - viac; /Catalog_Products?$filter= Cena 10 gt;
• ge – väčšie alebo rovné; /Catalog_Products?$filter=Cena ge 10;
• lt - menej; /Catalog_Products?$filter=Cena lt 10;
• le - menšie alebo rovné; /Catalog_Products?$filter=Cena le 10;
• alebo - logické ALEBO; /Katalóg_ Produkty ?$filter= Cena lt 10 alebo Cena 100 gt;
• a - logické AND; / Katalóg _Produkty?$ filter =Cena g t 10 a Cena l t 100;
• nie - Negácia; /Katalóg_ Produkty ?$filter=not (cena rovná 10);

Všimnite si tiež, že hodnota skutočného parametra Prvok(alebo entity)), ktoré odovzdávam funkcii vytvorené podľa nasledujúceho pravidla:

PrefixName_ConfigurationObjectName_SuffixName.

Pomocou štandardného rozhrania OData máte prístup k nasledujúcim objektom ( Predpona mena):

• Adresár - Katalóg;
• Dokument - Dokument;
• Dokumentový denník - DocumentJournal;
• Konštantný - Konštantný;
• Výmenný plán - Výmenný plán;
• Účtová osnova - ChartOfAccounts
• Plán typu výpočtu - ChartOfCalculationTypes;
• Tabuľka typov charakteristík - ChartOfCharacteristicTypes;
• Register informácií - InformationRegister;
• Register akumulácie - Register akumulácie;
• Register výpočtov - CalculationRegister;
• Účtovný register - AccountingRegister;
• Obchodný proces - BusinessProcess;
• Úloha - Úloha.

ConfigurationObjectName- vlastnosť "Názov" konfiguračného objektu tak, ako je nastavená v konfigurátore.

Prípona mena- potrebné na zadanie názvu zdroja, voliteľné, môže mať nasledujúce hodnoty:

• Názov tabuľkovej časti objektu;
• Názov virtuálnej tabuľky objektu;
• RowType - riadok tabuľkovej časti objektu;
• RecordType je jedna položka registra.

Možnosti prístupu k zdrojom

Po vytvorení názvu zdroja je potrebné definovať parametre pre prístup k zdroju, napr. ?$filter= Význam &$ formát=json& $select= Ref_Key ,

• $filter- výber pri príjme dát
• $ formát- určuje formát vrátených údajov,
• $vybrať- vymenovanie vlastností entity, ktoré budú zahrnuté vo výsledku dotazu;
• $metadata- vráti popis štandardného rozhrania OData (používa sa bez zadania prípony názvu, príklad je na jednom z obrázkov vyššie);
• $top- obmedzenie počtu vrátených záznamov;
• $preskočiť- odstráni zadaný počet záznamov z výsledku dotazu;
• $počet- vráti počet záznamov vo výbere dotazu;
• $inlinecount=allpage(=none)- k výsledku dotazu pridá informáciu o počte záznamov
• $orderby=<Реквизит1>vzostupne,<Реквизит2>desc- výsledok triedenia dotazu
• len dovoliť- povolené iba (používa sa bez znaku "$").

1.4 Získajte pole položiek registra informácií

Pozrime sa na príklad získania poľa záznamov z registra informácií o celom mene jednotlivcov, napríklad históriu zmien v celom mene jednotlivca.

Telo funkcie GetRegisterRecordSet, ktorá sa volá v tomto príklade, je zobrazené nižšie.

Cyklus Pýtať sa = ? ( ValueFilled(QueryText), "," ","); QueryText = QueryText + Query+ K keyValue.Key + "=" + KeyValue.Value; EndCycle; Koniec Ak; ResourceAddress = PublicationName + " /odata/standard.odata/" + Prvok + "("+ Text dopytu + + ") ?$format=json"; // Volanie mojej vlastnej funkcie Štruktúra odozvy = ZavolajteHTTPMethodOnServer("GET",HTTPConnection,ResourceAddress); Ak Štruktúra odozvy.StatusCode >= 400 Potom//General PurposeClientServer.InformUser(Element+ "Error"+Response Structure.StatusCode); //General PurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUndecrypted); návrat nedefinovaný; Koniec Ak; Zápas = 0

Prehľad OData

OData je webové rozhranie API na prístup a manipuláciu s údajmi. Je podobný mini-ODBC a JDBC API, ale je špecificky zameraný na internet. Konkrétnejšie, OData umožňuje klientom zostaviť URI na pomenovanie množiny entít, filtrovanie entít, ktoré množina obsahuje, a sledovanie vzťahov so súvisiacimi entitami a kolekciami entít. Ďalšie informácie nájdete v téme Úvod OData: Prístup k údajom pre web, cloud, mobilné zariadenia a ďalšie.

Obrázok 1. Vystavenie databázy na webe pomocou univerzálneho poskytovateľa OData

Diagram na obrázku 1 ukazuje, ako môže byť zdroj, akým je databáza, vystavený internetu prostredníctvom poskytovateľa OData na všeobecné účely. Syntax OData umožňuje webovým prehliadačom manipulovať s údajmi vo vyššie uvedenej databáze na rôzne manipulácie (vytváranie, aktualizácia, mazanie, dopytovanie).

Obrázok 2. Koncepčný jazyk definície schémy (CSDL)

Obrázok 2 zobrazuje schému CSDL (Conceptual Schema Definition Language). CSDL je voliteľný nástroj, ktorý pomáha spotrebiteľským aplikáciám pochopiť štruktúru vystavených údajov. CSDL je ako metadáta v JDBC a ODBC, pomáha klientskym aplikáciám pochopiť, k čomu presne pristupujú.

Na internete sú tisíce webových API. OData je jedným z príkladov takéhoto API. Ďalšie informácie o webových rozhraniach API nájdete na webovej lokalite: Programmable Web. Štandardizácia takýchto rozhraní zlepší konsolidáciu v tejto dôležitej technologickej oblasti a pomôže inováciám držať krok s požiadavkami trhu, najmä na podporu nových dátových konštrukcií a iniciatív otvorených dát.

OData v organizácii OASIS

Návrh charty pre OData bol predložený Organizácii pre rozvoj štandardov štruktúrovaných informácií (OASIS). Nižšie je uvedený úryvok textu z tohto dokumentu.

Práca bude zameraná na dosiahnutie nasledujúcich cieľov.

• Vytvorenie dátových služieb RESTful na báze HTTP, možnosť identifikovať zdroje pomocou identifikátorov URI (Uniform Resource Identifier) ​​​​a definovať zdroje pomocou abstraktného dátového modelu, možnosť publikovať a upravovať webovými klientmi pomocou jednoduchých správ HTTP.
• Sprístupňovanie a získavanie informácií z rôznych zdrojov vrátane, ale nie výlučne, relačných databáz, súborových systémov, systémov na správu obsahu a tradičných webových stránok.

Dokumenty špecifikácie OData predložené organizácii OASIS, ako aj návrh charty, sú dostupné na nasledujúcich odkazoch.

Okrem špecifikácií OData boli organizácii OASIS predložené nasledujúce štyri dokumenty s rozšíreniami OData.

Tieto dokumenty s rozšíreniami sú určené na začatie prác na navrhovanom technickom výbore OASIS OData. Celé znenie charty OData a dokumenty s rozšíreniami si môžete prečítať na webovej stránke OASIS.

OData a produkty IBM

Nasledujúce produkty IBM podporujú OData.

• Produkt na podporu prístupu pre rôznych klientov.
• Produkty DB2 a Informix dokážu používať OData cez Microsoft Visual Studio. Viac informácií na túto tému obsahuje.

Príklady

Táto časť poskytuje niekoľko jednoduchých príkladov OData, ktoré pristupujú k službe Netflix.

Predvolené Žánre tituly . . . . . . http://odata.netflix.com/v2/Catalog/Titles/ 2012-05-23T21:41:18Z

Spevák Anthony Kiedis, basgitarista Flea, ...

2012-01-31T09:45:16Z . . . http://odata.netflix.com/v2/Catalog/Titles("13aly")

Spevák Anthony Kiedis, basgitarista Flea, bubeník Chad Smith ...

2012-01-31T09:45:16Z . . . 13aly Red Hot Chili Peppers: Funky Monks Red Hot Chili Peppers: Funky Monks Spevák Anthony Kiedis, basgitarista Flea, bubeník Chad Smith ... 3.4 1991 . . .

OData a ďalšie webové rozhrania API

V súčasnosti sa používajú tisíce webových rozhraní API. Medzi obľúbené API v tejto kategórii patria mapové služby. K júnu 2012 program Programmable Web uvádzal viac ako 6 000 webových rozhraní API (pozri poznámku s názvom: Obchodné modely s rozhraním API sa dostávajú do centra pozornosti). Nedávna štúdia Vordela zistila, že „polovica podnikov prijíma API na budovanie nových obchodných kanálov“, pričom 25 % týchto rozhraní je vyvinutých špeciálne pre mobilné aplikácie.

Jednou z oblastí záujmu je, ako OData súvisí s aktivitami v oblasti Linked Data API. Pracovná skupina W3C Linked Data Platform (LDP) a Technický výbor OASIS OData sa snažia špecifikovať rozhrania API podobné REST na získavanie a manipuláciu s údajmi na webe pomocou rôznych dátových modelov. Platforma LDP je založená na dátovom modeli, ktorý bol špecifikovaný spoločnosťou Microsoft a pochádza z modelu vzťahu entít Petra Chena sformulovaného v roku 1976 (Peter Chen). Model EDM sa stále používa pri navrhovaní relačných databáz. Model údajov EDM je založený na transformácia informácií na entity a vzťahy Tento model používa hodnoty špecifické pre danú doménu, ako sú rodné čísla, čísla faktúr, čísla položiek, na odkazovanie na zdroje a ich vlastnosti a na prepojenie informácií.

EDM prezentuje informácie spôsobom, ktorý je známy mnohým vývojárom údajov. To výrazne uľahčuje pochopenie a používanie tohto modelu vývojármi. RDF umožňuje globálne prepojenie údajov a podporuje odvodzovanie prostredníctvom odvodzovania, t. j. umožňuje odvodzovanie nových faktov z existujúcich informácií pomocou univerzálnych identifikátorov, súvisiacich definícií a vlastností.

Vytváranie adaptérov medzi heterogénnymi webovými API je úplne možné. Napríklad prototyp adaptéra na prepojenie riešení pracovných položiek získaných prostredníctvom rozhrania Linked Data API s názvom OSLC (Open Services for Life Cycle Collaboration) a dokumentov Microsoft Sharepoint získaných prostredníctvom OData možno nájsť na nasledujúcom odkaze: http://wiki.eclipse.org /Lyo/SharepointAdapter.

Ako sa trh rozširuje, objavujú sa nové API. Aj keď sa ich schopnosti môžu v rôznej miere prekrývať, niet pochýb o tom, že vývojári budú pokračovať v inováciách v tejto sľubnej technologickej oblasti, keď budú identifikované nové prípady použitia.

Vďaka

Vyjadrujem svoju hlbokú vďačnosť za spätnú väzbu a návrhy svojim kolegom: Elizabeth Cleary, Andrew Eisenberg, Diane Jordan, Arnaud Le Hors.