Postázási kérés küldése 1-től 8.3.

Nyomtatás (Ctrl+P)

A második rész megtekinthető

Általános információ

Platform verzióban 8.3.5.1068 2015 szeptemberében megjelent egy olyan mechanizmus, amely az 1C-t külső programokkal technológián keresztül integrálja REST interfész. A platform az OData protokollt használja hozzáférési protokollként. Ez egy nyílt webprotokoll adatok lekérdezésére és frissítésére. Lehetővé teszi az adatok kezelését HTTP-parancsok kérésként történő használatával. A 8.3.5.1068-as verzióban a válaszokat csak a következő formátumban lehetett fogadni Atom/XML . A 2017. augusztusi 8.3.8.1652-es kiadástól kezdve azonban megjelent egy második lehetőség az adatok JSON formátumban való lekérésére (JavaScript Object Notation). . Az XML-hez képest könnyen olvasható az emberek számára, és kevesebb helyet foglal el. Ezenkívül minden böngésző rendelkezik beépített eszközökkel a JSON-val való együttműködéshez.

Az OData protokollal való munkavégzés az 1C: Enterprise platformon az 1C: Fejlesztői kézikönyv 17. fejezetében található. Internet szolgáltatási mechanizmusok, bekezdés 17.2.1 Szabványos OData interfész. Példákat is nézhet az OData protokoll támogatásának kiterjesztésére,

Használja ki az előnyt REST interfész. arra a következtetésre jut, hogy ahhoz, hogy egy külső alkalmazásból hozzáférjen a rendszeradatokhoz, nincs szükség az alkalmazásmegoldás kódjának módosítására (például, ha az alkalmazásmegoldás támogatott). A hozzáférés megszerzéséhez speciális módon közzé kell tennie az alkalmazást a webszerveren, és meg kell adnia, hogy mely konfigurációs objektumokat használja ily módon. Azt követően harmadik féltől származó rendszerek HTTP-kérésekkel hozzáférhet az alkalmazásához.

A szabványos OData felület közzététele a webszerver közzétételi párbeszédpaneljén történik (Adminisztráció - Közzététel ide web szerver) és az 1C: Enterprise 8.3. "Rendszergazdai útmutató".
Fontos! Ahhoz, hogy a konfigurációs objektumok elérhetővé váljanak a szabványos OData felületen keresztül, engedélyeznie kell ezt a globális kontextus módszerrel A StandardODataInterface() összetételének beállítása.
A szabványos OData interfész segítségével elérhető objektumok összetételének beállítási mechanizmusa az űrlapon végezhető el külső feldolgozás. Ez nem igényli az alkalmazott megoldás módosítását.

Az 1C:Enterprise külső REST webszerverével való interakcióhoz a HTTP-vel való munkavégzéshez a platformon elérhető eszközöket használják: objektumok HTTPConnection, HTTPRequest és HTTPResponse.

Ebben a cikksorozatban példákat mutatok be a megfelelő HTTP-módszert használó tipikus műveletekre;

Adatgyűjtés – módszer KAP;
Objektum létrehozása - Módszer POST;
Adatfrissítés: módszer TAPASZ- ebben az esetben csak azokat a tulajdonságokat adhatja meg, amelyeket frissíteni kell; módszer PUT– ebben az esetben az entitás összes tulajdonságát meg kell adni;
Adatok törlése - módszer TÖRÖL.

1. Példák adatgyűjtésre. HTTP metódus GET

A szerver a webszerveren közzétett adatbázis lesz a névvel webbuh(Demo-alap „A Vállalat könyvelése 3.0”). Adatcsere formátumként a JSON formátumot fogom használni. A JSON-nal való munkáról további információk találhatók a rendelkezésre álló dokumentációban. Ahhoz, hogy adatokat fogadjon a szerverről a GET HTTP metódussal, létre kell hoznia egy objektumot JSON olvasása JSON-adatok szekvenciális olvasásához fájlból vagy karakterláncból. Az objektumok és szövegek szekvenciális rögzítésének megszervezéséhez a szerveren a POST PATCH PUT HTTP metódussal, létre kell hoznia egy objektumot. JSON bejegyzés. Vegye figyelembe, hogy a DELETE metódus nem igényel JSON-t.

A JSON olvasási és írási streamelésének szemléltetésére a REST felület elérésekor a következő általános célú egyéni függvényt fogom meghívni Hívja a HTTPMethodOnServer-t :

&A szerveren // <Описание функции>// // Lehetőségek: // - A kérés HTTP metódusának nevét tartalmazó karakterlánc ("POST"."PATCH", "PUT" "GET","DELETE" // - HTTPConnection objektum //<АдресРесурса>- Annak a http-erőforrásnak a karakterlánca, amelyre a HTTP-kérés elküldésre kerül. //<ОтправляемыеДанные>- A megadott címre feldolgozásra küldött adatokat tartalmazó struktúra vagy levelezés // a szerverhez a megadott HTTP metódussal "POST" vagy "PATCH" vagy "PUT" // Visszatérési érték: // A szerver válaszstruktúrája a HTTP Methodtól függően// Funkció Call HTTPMethodOnServer(HTTPMethod,HTTPConnection,ResourceAddress,SubmittedData = Határozatlan ) // HTTP-kérés létrehozása headers = new match(); Címsorok.Beszúrás("Content-Type", "application/json"); HTTP-kérés = Új HTTP-kérés ( ResourceAddress, fejlécek ); // Json írása adatok létrehozásához és frissítéséhez Ha HTTPMethod="POST" vagy HTTPMethod="PATCH" vagy HTTPMethod="PUT" Akkor JSONWriter = NewJSONWriter ; JSON-paraméterek = Új Paraméterek JSON bejegyzések(Wrap JSON.Auto,"",True ); JSON Write.SetString(JSON paraméterek); WriteJSON(WriteJSON, SentData ); // SentData szükséges ebben az esetben StringForBody = WriteJSON.Close(); RequestHTTP.SetBodyFromString(StringForBody, EncodingText.UTF8, A ByteOrderMark használata.Ne használja); EndIf; // Hívja a HTTP-kapcsolati metódust ResponseHTTP = HTTPConnection.CallHTTPMethod(HTTPMethod, HTTP Request) ; Válaszstruktúra= Új szerkezet ; Válaszstruktúra.Insert ("StatusCode", HTTP Response.StatusCode); // JSON olvasása csak a GET metódushoz Ha HTTP Method="GET" Ezután megkísérelte olvasni a JSON-t = New Reading JSON ; Szerver válasz = ResponseHTTP.GetBodyAsString("UTF-8"); ReadJSON.SetString(ServerResponse); Match = ReadJSON(ReadingJSON,Igaz ); Válasz Structure.Insert("Szerver válasz",Levelezés) ; Válaszstruktúra.Insert (" Szerverválasz visszafejtetlen", ServerResponse ); Kivétel Jelentés (Hiba leírása()); Return Undefined; A kísérlet vége; vége if; Visszatérés Válaszstruktúra ; EndFunctions // Hívja a HTTPMethodOnServer()

A szerverről JSON formátumban történő fogadáshoz az alkalmazás REST felületének elérésekor meg kell adni az erőforrás címét $formátum=json. Vagy adja meg a MIME típusát alkalmazás/json a címben:

headers = new match(); Headers.Insert("Content-Type", "alkalmazás/json") ; ResourceAddress = webbuh/odata/standard.odata/ ?$format=json" HTTP-kérés = Új HTTPRequest (erőforrás címe, fejlécek);

Globális kontextus funkció ReadJSON (ReadJSON, True)

Ha a második paraméter értéke True, akkor az objektum beolvasása JSON be lesz végezve Levelezés.Ha False értékre van állítva, az objektumok egy típusú objektummá lesznek beolvasva Szerkezet.
A JSON-objektumok struktúrába történő deszerializálása során ügyeljen a struct kulcskövetelményeire. Ha egy objektum deserializálása olyan tulajdonságnevet talál, amely nem érvényes a struktúrakulcsra, kivételt dob a rendszer.

1. 1 A HTTP kapcsolat paramétereinek konfigurálása

A külső REST webszerverrel való interakció kliens részének megszervezéséhez a semmiből létrehoztam egy BSP-n alapuló ügyfélkonfigurációt. Ezen a konfiguráción létrehoztam egy könyvtárat a kapcsolati paraméterek beállítására (lásd 1. ábra)

1. ábra Használati útmutató a HTTP-kapcsolat paramétereinek konfigurálásához külső IB-hez a többi interfészen keresztül

A gomb megnyomása után Ellenőrizze a szerver válaszát egy eljárást hívunk meg, amellyel a kliens megpróbálja megkapni a szerver válaszát. Program kód az eljárás alább le van írva:

&OnClient eljárás CheckConnection(Command) Address = Object.ServerAddress; Felhasználó = Objektum.Felhasználó; Jelszó = Object.Password; Alapnév = Objektum.Név; Port = ? (Object.Port<>0,Object.Port,80); HTTPConnection = Új HTTP-kapcsolat (cím, port, felhasználó, jelszó); ResourceAddress = Alapnév + "/odata/standard.odata/ $metaadatok "; //Egyéni függvény meghívása Válaszstruktúra= B hívás HTTPMethodOnServer("KAP", HTTP Connection,ResourceAddress) ; Ha Válaszstruktúra <> Undefined Akkor General PurposeClientServer.InformUser("Állapotkód "+Válaszstruktúra.Állapotkód); vége if; Vége eljárás

Ennek az eljárásnak a célja az szervizellenőrzés és hogy a felhasználó helyesen adta-e meg a csatlakozási paramétereket. Ehhez csak küldjön egy GET kérést:
HTTPConnection.CallHTTPMethod( "KAP", HTTP kérése) ;
erőforrás cím használatával:
Erőforrás címe =BaseName+ “/odata/standard.odata/ “;
A szolgáltatás működését a böngészőben is ellenőrizheti a használatával
URL http://host/WebBuh/odata/standard.odata. Egy ilyen lekérdezés eredményeként csak az entitások listája jelenik meg. Megszerzéséért teljes leírás szabványos interfész OData (az elérhető entitások listája, azok attribútumai és funkciói XML-formátumban
dokumentum.) paraméter segítségével GET kérést kell tennie $metaadatok. URL http://host/WebBuh/odata/standard.odata/$metadata. Részletes leírás A dokumentum a http://www.odata.org/documentation/ címen érhető el (angol nyelven).
A válaszokat formátumban kaphatja meg Atom/XML vagy JSON. A HTTP-válasz állapotkódjai megtekinthetők A válaszok a következő tartományokban:

100-199 – tájékoztató válaszok, amelyek jelzik, hogy az ügyfél kérelmét elfogadták és feldolgozás alatt áll.
200-299 – azt jelenti, hogy az ügyfél kérelmét sikeresen feldolgozták.
300-399 azt jelenti, hogy a kérés meghiúsult, és az ügyfélnek tennie kell valamit a kérés teljesítéséhez.
400-499 - tájékoztat a kliens alkalmazás oldalán lévő hibákról. Ezek a kódok azt is jelezhetik, hogy további információkra van szükség az ügyféltől.
500-599 - Szerveroldali hibáról tájékoztat, jelzi, hogy a szerver hibába ütközött és valószínűleg nem tudja teljesíteni a kliens kérését.

1.2 Objektum keresése azonosító alapján

A következő funkciót arra tervezték, hogy a szerveren egyedi azonosító alapján keressen egy könyvtárat vagy dokumentumot. Ha az objektum megtalálható, akkor a függvény az azonosító karakterlánc értékét adja vissza (Ref_Key) , ellenkező esetben visszaadja határozatlan. A következő paraméterek kerülnek átadásra a függvénynek:

HTTPConnection – HTTPConnection típusú objektum
PublishName – A közzétett szerver adatbázis neve
Elem – az objektum entitásazonosítója, pl. Katalógus_Szervezetek vagy Dokumentum_ - a szervezet címtára.
Azonosító – A szerveren keresendő objektum azonosítója, pl. Organization.UniqueIdentifier()

&AtServer függvény SearchObjectBy GUID (HTTP-kapcsolat,kiadványnév,elem,egyedi azonosító) GUID = String (egyedi azonosító); // karakterláncra konvertálni ResourceAddress = + Element+ "(guid""+ GUID+ "")?$format=json" ; Válaszstruktúra = Bhívás HTTPMethodOnServer("KAP" , HTTP Connection,ResourceAddress) ; Ha Válaszstruktúra .StatusCode >= 400 Akkor //General PurposeClientServer.NotifyUser(Element+ "Error"+ResponseStructure.StatusCode+ //General PurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUndecoded); return undefined; EndIf ; Match = Válaszstruktúra. ResponseServer a; Tömb = Match["value"]; Ha Array = Undefined, akkor Return Match ["Ref_Key"] Else Return Array ["Ref_Key"]; EndIf; EndFunctions

Paraméter Erőforrás címe a REST szolgáltatás eléréséhez használható. A szolgáltatás működésének ellenőrzéséhez a böngészőben ily módon megadhatja az erőforrást

http://(WebServerAddress)/(PubName)/odata/standard.odata/(Elem)?(Paraméterek) ,Ahol

Webszerver címe– A szolgáltatás közzétételére alkalmas webszerver címe, például Localhost
NévKiadványok- Név információs bázis határozat közzétételekor meghatározott
/odata/standard.odata/ – A szabványos OData interfészhez való hozzáférés jele
Elem – erőforrásazonosító vagy előre meghatározott erőforrások. Például Catalog_Account(guid'value').
Lehetőségek– erőforrás paraméterek. Használható például a kijelöléshez a HTTP-kérelmek elfogadott részében: ?key=value&key2=value2

1.3 Objektum keresése keresőmezők alapján

A következő, felhasználó által definiált funkciót arra tervezték, hogy egy objektumot keresési mezők alapján keressen, abban az esetben, ha az objektum azonosító szám alapján történik. Funkció objektum karakterlánc Ref_Key-egy azonosító számot.

&AtServer függvény P searchObjectBySearchFields (HTTP Connection, Publication Name, Element, Search Fields) Feltétel = "" ; Minden kulcsértékhez a keresőmező hurokból Feltétel = Feltétel + KeyValue.Key+"egyenl""+ Kulcsérték.Érték+ "" és "; EndCycle; RequestText =Oroszlán (állapot, erősség (állapot)-5); // az utolsó 5 karakter eltávolítása Erőforrás címe= Kiadványnév+ "/odata/standard.odata/" +Element+ "?$filter=" + RequestText+ "&$format=json& $select=Ref_Key" ; // Egyéni függvény meghívása Válaszstruktúra= callHTTPMethodOnServer( "KAP",HTTPConnection,ResourceAddress); Ha Válaszstruktúra .StatusCode >= 400 Akkor //General PurposeClientServer.InformUser(Element+ "Error"+Response Structure.StatusCode); //General PurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUndecrypted); return undefined; EndIf; Match = Válaszstruktúra. ResponseServer a; Tömb = Match["value" ]; Ha Array = Undefined, akkor Return Match ["Ref_Key" ] Ellenkező esetben Return Array ["Ref_Key" ]; EndIf; EndFunctions

Amint az az eljárás törzséből látható P SearchObjectByFieldsSearch, a kiválasztás a kulcsszóval kezdődik$szűrőaz erőforrás címében. Formális paraméterKeresési mezők -ez egy levelezés, amely tartalmazza az attribútumok nevét és értékeit.

Vegye figyelembe, hogy a részletek neve néha nem egyértelmű. Emlékeztetni kell arra, hogy a könyvtárak esetében:

kód - kód,
Leírás
DeletionMark – törlési jel,
IsFolder - egy csoport jele,
A Parent_Key a szülő.
Ha az attribútum referencia típusú, adja hozzá a _Key utótagot a nevéhez, például Contractor_Key.

A dokumentumokhoz:

Szám – dokumentumszám,
Dátum – a dokumentum kelte.

Logikai kiválasztási műveletek

eq - egyenlő; /Catalog_Cities?$filter=Név eq 'Fő';
ne - Nem egyenlő; /Catalog_Cities?$filter=Név ne ‘Perm’;
gt - több; /Katalógus_Termékek?$filter=Ár gt 10;
ge – nagyobb vagy egyenlő; /Katalógus_Termékek?$filter=Ár 10;
lt - kevesebb; /Katalógus_Termékek?$filter=Ár lt 10;
le - Kisebb vagy egyenlő; /Katalógus_Termékek?$filter=Ár 10;
vagy - Logikai VAGY; /Katalógus_ Termékek ?$filter= Ár 10 lt vagy 100 gt;
és - Logikai ÉS; / Katalógus _Termékek?$ filter =Ár g t 10 és ár l t 100;
nem - tagadás; /Katalógus_ Termékek ?$filter=not (10. áregyenlet);

Vegye figyelembe azt is, hogy az aktuális paraméter értéke Elem(vagy entitás)) amit átadok a függvénynek a következő szabály szerint alakítják ki:

PrefixName_ConfigurationObjectName_SuffixName.

A szabványos OData interfész segítségével a következő objektumokat érheti el ( Név előtag):

Címtár - Katalógus;
Dokumentum - Dokumentum;
Dokumentumnapló - DocumentJournal;
Állandó - Állandó;
Csereterv - ExchangePlan;
Számlaterv – ChartOfAccounts
Számítási típusterv - ChartOfCalculationTypes;
Chart of CharacteristicTypes - ChartOfCharacteristicTypes;
Információs nyilvántartás - Információnyilvántartó;
Felhalmozási Nyilvántartás - Felhalmozási Nyilvántartás;
Számítási nyilvántartás - CalculationRegister;
Számviteli nyilvántartás - Számviteli Nyilvántartás;
Üzleti folyamat - BusinessProcess;
Feladat – Feladat.

ConfigurationObjectName- a konfigurációs objektum "Name" tulajdonsága, ahogy az a konfigurátorban be van állítva.

Név utótag- az erőforrás nevének megadásához szükséges, nem kötelező, a következő értékeket veheti fel:

Az objektum táblázatos részének neve;
Név virtuális asztal tárgy;
RowType - az objektum táblázatos részének sora;
A RecordType egyetlen regiszterbejegyzés.

Erőforrás hozzáférési beállítások

Az erőforrás nevének kialakítása után meg kell határoznia az erőforrás eléréséhez szükséges paramétereket, pl. ?$szűrő= Jelentése &$formátum=json& $select= Ref_Key ,

$szűrő- kiválasztás adatfogadáskor
$formátum- megadja a visszaküldött adatok formátumát,
$select- a lekérdezés eredményében szereplő entitástulajdonságok felsorolása;
$metaadatok- visszaadja a szabványos OData felület leírását (névutótag megadása nélkül használjuk, példa a fenti képek egyikén található);
$top- a visszaküldött rekordok számának korlátozása;
$skip- eltávolítja a megadott számú rekordot a lekérdezés eredményéből;
$count- visszaadja a rekordok számát a lekérdezés kiválasztásában;
$inlinecount=allpage(=nincs)- információkat ad a rekordok számáról a lekérdezés eredményéhez
$orderby=<Реквизит1>asc,<Реквизит2>desc- lekérdezés eredményének rendezése
csak engedélyezve van- csak engedélyezett ("$" jel nélkül használjuk).

1.4 Szerezzen be egy sor információs nyilvántartási bejegyzést

Nézzünk egy példát az egyének teljes nevére vonatkozó információk nyilvántartásának rekordtömbjének megszerzésére, például a teljes név megváltoztatásának történetére. Egyedi

NévKiadványok ="WebBuh"; Element = "InformációsRegisztrációs_Egyének neve"; Időszak = Undefined ; ReferenceType adatok= Új szerkezet(); D DataReferenceType.Insert("PhysicalPerson",PhysicalPerson_Key); DataNonReferenceType= Új szerkezet(); DataNonReferenceType.Insert("PhysicalPerson_Type", "StandardODATA.Catalog_PhysicalPersons") Array = GetRegisterRecordSetDetails(HTTPConnection, PublicationName, Item, Period, DimensionsReferenceType, A nem referenciatípus mérései)

A GetRegisterRecordSet függvény törzse, amelyet ebben a példában hívunk meg, az alábbiakban látható.

&AtServer függvény GetRegisterRecordSetDetails(HTTPConnection , Publikáció neve , Tétel , Időszak = Undefined , DimensionsReferenceType= meghatározatlan , A nem referenciatípus mérései= meghatározatlan ) RequestText ="" ; Ha időszak<>Undefined Akkor FormattedPeriod= Formátum(Időpont "DF=éééé-hh-nnTHH:pp:ss"); QueryText = "Időszak = dátumidő""+ FormattedPeriod + """ ; EndIf; Ha DimensionsReferenceType <>Undefined Then For Every KeyValue Of DimensionsReferenceType Tömörített ciklus = ? ( ValueFilled(QueryText ), "," ",""); QueryText = QueryText+ Powered + KeyValue.Key+ "=guid(""+ Kulcsérték.Érték+ "")"; EndCycle; EndIf; If A nem referenciatípus mérései<> Undefined Akkor Minden kulcsértékhez A nem referenciatípus mérései Ciklus Kérdez = ? ( ValueFilled(QueryText ), "," ",""); QueryText = QueryText + Lekérdezés+ K keyValue.Key + "=" + Kulcsérték.Érték; EndCycle; EndIf; ResourceAddress = Kiadványnév + " /odata/standard.odata/" + Elem + "("+ QueryText + + ") ?$format=json"; // Egyéni függvény meghívása Válaszstruktúra = Hívja a HTTPMethodOnServer-t("GET",HTTPKapcsolat,ResourceAddress); Ha Válaszstruktúra.StatusCode >= 400 Akkor//General PurposeClientServer.InformUser(Element+ "Error"+Response Structure.StatusCode); //General PurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUndecrypted); return undefined; EndIf; Match = 0

Az 1C-ről a 8.3.9.2170 platformverziójú webhelyre történő információküldési eljárás kidolgozásakor egy problémába ütköztem: a webhely fejlesztője lehetőséget adott a rögzítésre. szükséges információ csak egy HTTP kérés segítségével a PUT metódus használatával.

Kétszeri gondolkodás nélkül felvázoltam egy egyszerű kódot:

Kapcsolat = Új HTTPKapcsolat("www.mysite.ru"); Fejlécek = Új egyezés; Headers["Content-Type"] = "alkalmazás/x-www-form-urlencoded"; Request = New HTTPRequest("/api/order_items/93076?order_item=30", fejlécek); Connection.Write(Request);

A végrehajtás eredménye alapján a vevő megrendelésének megfelelő sorában a weboldalon fel kellett volna tüntetni a raktárba átvett áru mennyiségét.

Azonban, mint valószínűleg már értette, nem történt semmi. Miután megbizonyosodtam arról, hogy nincsenek hibák a webhelyen (ha hasonló kérést küldtem a Chrome beépülő modulon keresztül), futtattam a helyi számítógép webszervert, és elkezdett kísérletezni.

Azonnal egy furcsa dologra derült fény: a fenti kód nem PUT, hanem HEAD kérést generál!

Az Apache naplóiban a következőket láttam:

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

Kicsit meglepődtem (végül is a PUT kézikönyvben fekete-fehérben volt írva), de nem voltam tanácstalan - elvégre a módszert közvetlenül hívhatja:

Connection.CallHTTPMethod("PUT",Kérés);

A naplók ugyanazok:

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

– Lehet, hogy valamit rosszul csinálok? - tettem fel magamnak egy kérdést. De az interneten és a kézikönyvekben nem volt nyom. Nos, a tudományos piszkálás módszerét még senki nem mondta le. Kezdésként a következőt próbáltam tenni:

Connection.CallHTTPMethod("fwfw", Request);

A kapott naplókban:

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

Érdekes módon ez azt jelenti, hogy az 1C kifejezetten a PUT módszert váltja fel (miért nem tetszett neki az 1C?).

Néhány további próbálkozás után erre jutottam:

Connection.CallHTTPMethod("PUT", Request);

A kapott naplókban:

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

És ez a lehetőség már működött az oldalon, és mindenki elégedett volt.

Helyesebb megoldást javasolt a problémára: meg kell adni a kérés törzsét, bármilyen, akár üresen is. Például ez működne:

Valószínűleg már teljesen helyes, ha maguk a paraméterértékek kerülnek átadásra a kérés törzsében.

A következtetés a következő: az 1C platform hibásnak tekinti a törzs nélküli PUT kérést, és a metódust a HEAD-re cseréli.

Érdekes, hogy az 1C nem követi nyomon a POST kérést test nélkül, és nem alakítja át GET-be, sportérdekből ellenőrizték.

Ahogy a híres viccből jól ismert Vovochka mondaná: "Hol a logika?".

Remélem, publikációm megmenti valakinek néhány órát a válasz keresésében. =)))

A 8 platform második verziójától kezdve a felhasználóknak és a fejlesztőknek lehetőségük van közvetlenül az 1C http kérésben használni. A program két típusú kérést támogat:

POST kérések;
GET kéréseket.

Így egy meglehetősen kényelmes eszközt hoztak létre az adatok cseréjéhez, valamint a webszolgáltatásokkal és a http-n keresztül működő szolgáltatásokkal való interakcióhoz.

GET kérés

Természetesen a lekérdezések használatának legegyszerűbb példái sokkal jobban illusztrálják képességeiket, mint sok leírás. Tehát próbáljuk meg:

Szerezze meg webhelyünk főoldalának törzsét;
Dolgozzuk ki a kérés átirányítását;
A képet az oldalról készítjük.

A webhely törzsének lekérése

Kezdjük egyszerűen. ábrán..

Ennek a kódrészletnek a végrehajtásának eredménye egy meglehetősen nagy szöveg, amelynek utolsó része a 2. ábrán látható.

2. ábra

A kód első sorában létrehozunk egy kapcsolatobjektumot egy http erőforrással. Egy objektum a következő tulajdonságokat tartalmazhatja:

Szerver – a szerver címét tartalmazó kapcsolati karakterlánc;
Port - a kiszolgáló portját jelző számot tartalmaz, alapértelmezés szerint a kapcsolat típusától függően 80-at adhat meg nem biztonságos kapcsolatokhoz, vagy 443-at biztonságos SSL-hez.
Felhasználónév – megadva, ha a kiszolgálón engedély szükséges;
Jelszó – a felhasználó jelszava a megadott erőforráson;
Proxy - tartalmazhat egy InternetProxy típusú objektumot, amelyet akkor jelez, ha proxyt használnak a szerverrel való kommunikációhoz;
SecureConnection – alapértelmezés szerint HAMIS, az IGAZ értékre váltás a https protokoll használatát jelzi.

Ezenkívül a HTTPConnection objektum saját metódusokkal rendelkezik, amelyek elérése lehetővé teszi a kezelő végrehajtási algoritmusának részletesebb leírását:

CallHTTPmethod - két kötelező paramétert tartalmaz: HTTPmethod és HTTPrequest, támogatja a választörzs írásának lehetőségét a harmadik paraméterben megadott fájlba;
Write - adatokat küld a szervernek PUT kéréssel;
Módosítás – módosít egy objektumot a PATCH kérések feldolgozásával;
SendForProcessing - a POST kérés használatát jelző metódusnak, mint minden korábbi metódusnak, tartalmaznia kell a kérés szövegét, elküldheti a válaszfájl címét is adatíráshoz;
Get - erről bővebben az alábbiakban lesz szó;
A GetHeaders egy másik módszer, amelyet a cikkben végig fogunk használni;
A törlés valójában egy törlési kérés, amely eltávolítja a kérésben átadott erőforrást a szerverről.

A második sorban kérést hozunk létre a kiválasztott oldalra, kérésünk szövege egy perjelet tartalmaz, ami azt jelenti, hogy szeretnénk kezdőlap. Ha bármilyen kifejezés követi a perjelet, például "oldal2" vagy "hírek", egy másik oldalt kapunk.

A harmadik sor végrehajtja a kérésünket a szerver felé.

A negyedikben megmutatjuk az eredményt.

http kérés átirányítás kezelése

Képzeljünk el egy olyan helyzetet, amikor programozottan kell egy keresési eredményt kapnunk bármelyiken keresztül keresőmotor a "Kérések 1 mp alatt" gombbal. A GOOGLE eléréséhez szükséges kódrészlet a 3. ábrán látható

3. ábra

Itt a számunkra már ismert konstrukciókon kívül fejlécek és egy StatusCode is található. Foglalkozzunk velük.

StatusCode - a "Megjegyzéskérés" részben megadott szabványos érték, a következő értékeket veheti fel:

Ha minden rendben van, a 100-tól 299-ig tartó tartományban lévő érték kerül visszaadásra;
Átirányítás esetén 300-tól 399-ig terjedő kódot ad vissza, esetünkben a sikeres állandó átirányítást az erőforrásra a 301-es kód határozza meg;
Hibák esetén a paraméter 400 és 499 közötti értéket vesz fel;
Az 500-599 tartományba eső érték a szerverrel kapcsolatos problémákat jelez.

Minden oldalnak van egy címsora, melynek szövegében több paraméter is megkülönböztethető (4. ábra):

Bekötési rajz (minden két perjelig "//");
Kapcsolati cím karakterlánc;
Felhasználónév és jelszó;
Port és gazdagép a csatlakozáshoz.

Ezt a bontást hajtja végre a BreakAddressString függvény. Miután így megkaptuk az új címet, elmenthetjük az oldalt a számítógépünkre és megnyithatjuk az alapértelmezett böngészőben (GetPage eljárás).

5. ábra

Nincsenek új funkciók és módszerek a lekérdezések kezelésére, valójában létrehozunk Szöveges dokumentum a webhely törzséből, és indítsa el az oldalt a böngészőben.

A fájlt a D meghajtó gyökerébe helyezzük, és tesztnek nevezzük.

Kép lekérése a webhelyről

Felmerül egy természetes kérdés: ha nem a teljes oldalra van szükségünk, hanem csak annak egyes elemeire, akkor ezt megtehetjük és hogyan? Igen tudsz. Az ezt lehetővé tévő programkód a 6. ábrán látható

6. ábra

Amint az ábrán látható, a kérés törzsében megvan a webhelystruktúra elem kódja, amelyet meg kell szereznünk. Ez a rész nem szerepelt korábbi leírásunkban, és ennél a pontnál részletesebben kell foglalkoznunk.

A böngészőt használtuk Opera az oldal eléréséhez. Egyetlen fontos eszköze van számunkra, ha rákattint Jobb klikk egeret egy elemre, hívhatja helyi menü, amelynek egyik eleme az "Elemkód megtekintése".

Neki köszönhető, hogy megkapjuk a kérésben használt címet 7. ábra.

POST kérés

Az egyszerű Get kérésekkel ellentétben a POST http kéréseknek van egy szövegtörzse, amely egyszerű szöveges formában és xml, soap, json kiterjesztésű fájlként is tárolható. A hálózat számos eszközzel rendelkezik lekérdezési szövegek létrehozására, amelyek lehetővé teszik bizonyos kérések hibakeresését és végrehajtásának felügyeletét.

Az 1C-ben egy adott szövegű kérés indításához a HTTP-kérelem objektum rendelkezik egy SetBodyFromString eljárással.