Vyvstal úkol na přenos dat mezi 1C (vývoj a konfigurace byl outsourcován), který je plánován jako hlavní systém elektronické správy dokumentů (EDF) a B2B systémem (interní vývoj), který je napsán v PHP (Symfony) a plní funkce primárního informačního vstupu do společností.

Už jsem měl zkušenosti s integrací B2B s jiným B2B. Záměrem bylo přenést JSON pomocí cURL. Poté vyvstal úkol integrovat systém Borlas, založený na Oracle, kde byl tento přístup také aplikován. Na straně Oracle ale použili vlastní balíček - obdobu cURL v PHP (v případě zájmu jej mohu popsat v novém článku).

Jak jsem zjistil, 1C 8.2 umí odesílat i požadavky GET a POST. Předpokládal jsem, že když už je vše nakonfigurováno a funguje s jinými systémy, tak by to mělo fungovat i zde. JSON vývojáři 1C odmítli s tím, že formát je nevhodný a uznávají pouze XML. Připomínky, že tím získáme minimální objem přenosu dat, ale ve skutečnosti jsme dostali hodně dat, byly zamítnuty. V důsledku toho jsme začali připravovat 2 systémy založené na XML.

Z mé strany jsem napsal příjemce žádosti od 1C a vrátil výsledky. Funkce pro příjem proměnné v POST, ve které musel 1Sniki nahradit XML.
Formát je přibližně následující:

123ABC456//autorizační klíč get_last_orders//operaci, kterou chtějí provést 4000//limit záznamů, které chtějí vybrat

Obslužná rutina, která vrací záznamy, které již byly vybrány podle podmínek, a generuje XML jako:

1 O.P.S. 4853352 01.01.2013 1 Nahráno z b2b SNILS 999999999 Celé jméno klienta Michailov Michail Evgenievich Datum aplikace 01.01.2013 ...

Data lze přenášet pouze prostřednictvím připojení HTTPS.

Na první pohled se vše zdá jednoduché, ale v procesu se objevilo několik problémů:
1) outsourcingové uvedli, že nejsou obeznámeni s požadavky tohoto druhu, a pokusili se nabídnout staré osvědčené schéma:
1. import souboru z B2B,
2. Načítání do 1C,
3. Exportujte soubor s uvedením toho, co bylo možné zpracovat, co nebylo z 1C,
4. Import do B2B,
5. a od začátku...
Schéma bylo zamítnuto, protože to bylo potřeba udělat rychle a bez lidského zásahu a jakýchkoli „tlačítek“.

Pak požádali o příklad kódu. Na internetu jsem vygoogloval následující příklad:

Server = "test.com"; Port = "443"; HTTPTry = Nové připojení HTTP (Server, Port, True); Else HTTP = Nové připojení HTTP (Server, Port); endIf; ScriptAddress = "/gateway/GetData1C/"; Attempt HTTP.SendForProcessing(SendFileName, ScriptAddress, ResponseFileName, HTTPHeader); Výjimka Report("Pokus o připojení se nezdařil: " + ErrorDescription()); ElseLogRecord("HTTPConnection", LogLevel.Error, "Pokus o připojení se nezdařil: " + ErrorDescription()); EndIf Return; EndPokus;

Data začala přicházet na server, ale byla prázdná, to znamená, že GET a POST byly prázdné. Přidal jsem záznam do logů a úspěšně na to zapomněl. Po 4 měsících jsem dostal naléhavý úkol - dovést integraci k výsledku (protože uplynulo hodně času, vývojáři 1C pracují a pracují, ale nic nereaguje). Nainstalovali mi 1C a začal jsem šťourat.

Nejprve jsem se rozhodl nainstalovat Fiddler, abych pochopil, co se děje. Všiml jsem si, že připojení je přes HTTP, a pak se server přesměruje na HTTPS. Předpokládal jsem, že z tohoto důvodu jsou data prázdná. Pokusil jsem se to reprodukovat v prohlížeči Chrome a obdržel jsem potvrzení, že data v požadavku POST jsou během přesměrování ztracena.

Protože není možné povolit práci přes HTTP, začal jsem studovat proč, protože je naznačeno, že:

HTTP = Nové připojení HTTP(Server, Port, True); Parametr „True“ znamená použít HTTPS a pak vyšlo najevo, že HTTP = New HTTPConnection(Server, Port);

V důsledku toho bylo toto „Jinak“ vyhodeno a obdržel jsem chybu, že certifikát je nesprávný. Certifikát byl podepsán sám sebou. Vývoj integrace probíhal na interních serverech, kde byl na rozdíl od PROD serveru oficiálně zakoupen certifikát od „Thawte SSL CA“. Import certifikátu do všech možných úložišť nepřinesl žádné výsledky.

Prohledávání zdrojů vedlo k tomu, že 1C má vlastní kořenové certifikáty a na jejich základě již kontroluje ostatní. Jsou v testovací formě v souboru „cacert.pem“, který se nachází ve složce „bin“, kde je umístěn 1C. Import není tak jednoduchý, jak se ukázalo.

Nejprve musíme vyexportovat certifikát, který potřebujeme, do souboru (už jsem ho měl ve svém osobním úložišti). Spuštěním „certmgr.msc“ po nalezení certifikátu jej exportujeme do souboru *.cer.

C:\OpenSSL-Win64\bin>openssl x509 -informujte der -in C:\fiddler.cer -out C:\fiddler.pem -text -fingerprint -md5 VAROVÁNÍ: Nelze otevřít konfigurační soubor: /usr/local/ ssl/openssl.cnf MD5 Fingerprint=13:BF:73:43:BB:69:19:BA:22:5D:C7:2E:44:85:91:7F
Uložíme MD5, budeme ho potřebovat.
Dále otevřete soubor „cacert.pem“.
Jdeme úplně dolů a přidáme nejprve MD5 a poté veškerý obsah, který vyšel v souboru „fiddler.pem“.
Uložte soubor.
Restartujeme 1C (možná to není nutné, ale nefungovalo to pro mě, takže jsem restartoval vše.

Zdrojový soubor v 1C dostal tento tvar:

Procedure SendRequestPress(Element) Connection = GetHTTPConnection(); If Connection = Undefined Then Report("Nelze se připojit k serveru zadanému v nastavení výměny! Zpracování bylo přerušeno!"); Jinak Zdroj = FileAddress; endIf; FileName = FileResult; PostFileName = PostFile; PostFile = Nový soubor(PostFileName); SubmissionFileSize = XMLString(SubmissionFile.Size()); Záhlaví = Nová shoda(); Headers.Insert("Content-Type", "application/x-www-form-urlencoded"); Headers.Insert("Content-Lenght", SubmissionFileSize); Attempt Connection.SendForProcessing(PostFileName, Source, FileName, Headers); Zpráva o výjimce(ErrorDescription()); EndAttempts EndProcedures Funkce GetHTTPConnection() Export AttemptConnection = New HTTPConnection(HTTPServer,"443",True); Zpráva o výjimce(ErrorDescription()); Připojení = Nedefinováno; EndPokus; Zpětné připojení; EndFunctions Procedure OnOpen() HTTPServer = "test.com"; FileAddress = "/gateway/GetData1C"; PostFile = "C:\POST_1C\post.txt"; FileResult = "C:\POST_1C\result.xml"; Konec procedury

Po kliknutí na tlačítko byl odeslán požadavek přes HTTPS a jako výstup bylo přijato správné XML.

Hledal jsem, jak funguje 1C přes HTTPS, spoustu materiálu, ale nenašel jsem, jak pracovat s certifikátem s vlastním podpisem.

Při vývoji postupu pro odesílání informací z 1C na web s verzí platformy 8.3.9.2170 jsem narazil na problém: vývojář webu mi poskytl možnost zaznamenat potřebné informace pouze pomocí HTTP požadavku pomocí metody PUT.

Bez přemýšlení jsem načrtl jednoduchý kód:

Connection = New HTTPConnection("www.mysite.ru"); Záhlaví = Nová shoda; Headers["Content-Type"] = "application/x-www-form-urlencoded"; Request = New HTTPRequest("/api/order_items/93076?order_item=30", Hlavičky); Connection.Write(Požadavek);

Na základě výsledků provedení mělo být množství zboží přijatého na sklad zadáno do odpovídajícího řádku objednávky kupujícího na webu.

Nicméně, jak jste již pravděpodobně pochopili, nic se nestalo. Poté, co jsem se ujistil, že na webu nejsou žádné chyby (odesláním podobného požadavku prostřednictvím pluginu Chrome), spustil jsem jej na svém místní počítač webový server a začal experimentovat.

Okamžitě se vyjasnila podivná věc: Výše uvedený kód negeneruje PUT, ale požadavek HEAD!

V protokolech Apache jsem viděl následující:

127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"

Byl jsem trochu překvapen (koneckonců, v manuálu bylo uvedeno PUT černobíle), ale nebyl jsem zmaten - metodu můžete zavolat přímo:

Connection.CallHTTPMetoda("PUT",Požadavek);

Protokoly ukazují to samé:

127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"

"Možná dělám něco špatně?" - položil jsem si otázku. Ale na internetu ani v příručkách nebyly žádné náznaky. No, metodu vědeckého tykání ještě nikdo nezrušil. Pro začátek jsem zkusil udělat toto:

Connection.CallHTTPMetoda("fyvfyv",Požadavek);

V protokolech, které jsem obdržel:

127.0.0.1 - - "?????? /api/order_items/93076?order_item=30 HTTP/1.1"

Kupodivu to znamená, že 1C nahrazuje konkrétně metodu PUT (proč se to 1C nelíbilo?).

Po několika dalších pokusech jsem přišel na toto:

Connection.CallHTTPMetoda("PUT",Požadavek);

V protokolech, které jsem obdržel:

127.0.0.1 - - "PUT /api/order_items/93076?order_item=30 HTTP/1.1"

A tato možnost již na webu fungovala a všichni byli spokojeni.

Navrhl správnější řešení problému: musíte zadat tělo požadavku, jakékoli tělo, dokonce i prázdné. Například tato možnost bude fungovat:

Connection = New HTTPConnection("www.mysite.ru"); Záhlaví = Nová shoda; Headers["Content-Type"] = "application/x-www-form-urlencoded"; Request = New HTTPRequest("/api/order_items/93076?order_item=30", Hlavičky); Request.SetBodyFromString("",TextEncoding.UTF8, UseByteOrderMark.NotUse); Connection.Write(Požadavek);

A pravděpodobně je zcela správné předat samotné hodnoty parametrů v těle požadavku.

Závěr je následující: platforma 1C považuje požadavek PUT bez těla za chybný a nahradí metodu HEAD.

Je zvláštní, že 1C nesleduje požadavek POST bez těla a neproměňuje ho v GET, zkontroloval jsem to pro zábavu.

Jak by řekl známý Vovochka ze slavného vtipu: "Kde je logika?"

Doufám, že moje publikace někomu ušetří několik hodin života při hledání odpovědi. =)))

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, mechanismus pro integraci 1C s externí 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 získání přístupu k systémovým datům z externí aplikace není nutná úprava kódu aplikačního řešení (například pokud je aplikační řešení podporováno). 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 ve formuláři 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í vlastní funkci obecný účel 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. Chcete-li získat úplný popis standardního 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

Další funkce je určena k vyhledávání adresáře nebo dokumentu podle jedinečného identifikátoru 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 informační základna uvedeno při zveřejnění rozhodnutí
• /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í stůl objekt;
• 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í řady záznamů rejstříku pro informace o celých jménech jednotlivců, například historii změn celých jmen individuální

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

Počínaje druhou verzí platformy 8 mají uživatelé a vývojáři možnost používat požadavek http přímo v 1C. Program podporuje dva typy požadavků:

• požadavky POST;
• požadavky GET.

Vznikl tak celkem pohodlný nástroj pro výměnu dat a interakci s webovými službami a službami fungujícími přes http.

požadavek GET

Nejjednodušší příklady použití dotazů samozřejmě ilustrují jejich možnosti mnohem lépe než mnoho řádků popisu. Tak zkusme:

1. Pojďme získat tělo hlavní stránky našeho webu;
2. Budeme pracovat na přesměrování požadavku;
3. Vezměme si obrázek z webu.

Získání těla webu

Začněme něčím jednoduchým. Na Obr.

Výsledkem provádění této části kódu je poměrně rozsáhlý text, jehož závěrečná část je na obr. 2.

Obr.2

V prvním řádku kódu vytvoříme objekt připojení k prostředku http. Objekt může obsahovat následující vlastnosti:

• Server - připojovací řetězec obsahující adresu serveru;
• Port – obsahuje číslo označující port serveru, standardně lze v závislosti na typu připojení zadat 80 pro nezabezpečená připojení nebo 443 pro zabezpečená SSL.
• Uživatelské jméno – uvádí se, pokud je vyžadována autorizace na serveru;
• Heslo – heslo uživatele na zadaném zdroji;
• Proxy – může obsahovat objekt typu InternetProxy, indikovaný při použití proxy pro komunikaci se serverem;
• Secure Connection – výchozí hodnota je FALSE, přepnutí na TRUE znamená použití protokolu https.

Kromě toho má objekt HTTPConnection své vlastní metody, jejichž volání vám umožňuje úplněji popsat algoritmus provádění handleru:

• CallHTTPmethod – obsahuje dva požadované parametry, HTTPmethod a HTTPrequest, podporuje možnost zapsat tělo odpovědi do souboru specifikovaného ve třetím parametru;
• Write – pomocí požadavku PUT odešle data na server;
• Modify – modifikuje objekt zpracováním požadavků PATCH;
• SendForProcessing – metoda indikující použití požadavku POST, stejně jako všechny předchozí metody, musí obsahovat text požadavku a může také přenášet adresu souboru odpovědí pro záznam dat;
• Příjem - to bude podrobněji probráno níže;
• GetHeadings je další metoda, která bude v článku použita;
• Odstranit je ve skutečnosti požadavek na odstranění, který odstraní zdroj předaný v požadavku ze serveru.

Ve druhém řádku vytvoříme požadavek na vybraný web, text našeho požadavku obsahuje jedno lomítko, což znamená, že chceme obdržet domovská stránka. Pokud by za lomítkem následoval jakýkoli výraz, například „stránka2“ nebo „novinky“, dostali bychom jinou stránku.

Třetí řádek provede náš požadavek na server.

Ve čtvrtém ukazujeme výsledek.

Zpracování přesměrování požadavku http

Představme si situaci, kdy potřebujeme programově získat výsledek hledání přes libovolný vyhledávač tlačítkem „Požadavky za 1s“. Část kódu potřebná pro přístup k GOOGLE je znázorněna na obr. 3

Obr.3

Zde jsou kromě nám již známých struktur hlavičky a stavový kód. Pojďme se s nimi vypořádat.

Stavový kód – standardní hodnota uvedená v „Žádosti o komentáře“, může nabývat následujících hodnot:

1. Pokud je vše v pořádku, hodnota se vrátí v rozsahu od 100 do 299;
2. V případě přesměrování bude vrácen kód v rozsahu od 300 do 399, v našem případě bude úspěšné trvalé přesměrování na zdroj určeno kódem 301;
3. Pokud jsou v požadavku chyby, parametr bude mít hodnotu od 400 do 499;
4. Hodnota v rozsahu 500-599 označuje problémy se serverem.

Každá stránka má nadpis, v jehož textu lze rozlišit několik parametrů (obr. 4):

1. Schéma zapojení (vše, co je před dvěma lomítky „//“);
2. Adresní řádek připojení;
3. Uživatelské jméno a heslo;
4. Port a hostitel, ke kterému se chcete připojit.

Právě toto rozdělení provádí funkce SplitAddressLine. Takto přijaté nová adresa, můžeme si stránku uložit na svůj počítač a otevřít ji ve výchozím prohlížeči (postup GetPage).

Obr.5

Nejsou zde žádné nové funkce ani způsoby práce s požadavky, my vlastně tvoříme Textový dokument z těla webu a spusťte stránku v prohlížeči.

Soubor umístíme do kořenového adresáře jednotky D a nazveme jej test.

Obrázek bereme z webu

Nabízí se přirozená otázka: pokud nepotřebujeme celý web, ale potřebujeme získat pouze jeho jednotlivé prvky, lze to udělat a jak? Ano můžeš. Programový kód, který vám to umožňuje, je uveden na obr. 6

Obr.6

Jak můžete vidět z obrázku, v těle požadavku máme kód prvku struktury webu, který potřebujeme obdržet. Tato část nebyla v našem předchozím popisu a musíme se u tohoto bodu zastavit podrobněji.

Použili jsme prohlížeč Opera pro přístup na stránky. Má pro nás jeden důležitý nástroj: kliknutím pravým tlačítkem myši na prvek lze vyvolat kontextové menu, jehož jednou z položek je „Zobrazit kód prvku“.

Právě díky němu můžeme získat adresu, která bude použita v požadavku obr. 7.

POST požadavek

Na rozdíl od jednoduchých požadavků Get mají požadavky POST http textové tělo, které lze uložit jako běžný textová forma, a ve formě souborů s příponou xml, soap, json. Nástrojů pro vytváření textů požadavků, které umožňují ladit a sledovat provádění určitých požadavků, je na síti poměrně hodně.

V 1C má objekt požadavku HTTP za účelem spuštění požadavku se specifickým textem proceduru SetBodyFromString.