1c 8.3 posta begäran om att ta emot beställningar. Hanterar omdirigering av http-begäran
En uppgift uppstod om att överföra data mellan 1C (utveckling och konfiguration lades ut på entreprenad), som planeras användas som det huvudsakliga elektroniska dokumenthanteringssystemet (EDF) och ett B2B-system (intern utveckling), som är skrivet i PHP (Symfony) och utför funktionerna som primär informationsinmatning i företag.
Jag hade redan erfarenhet av att integrera en B2B med en annan B2B. Tanken var att överföra JSON med hjälp av cURL. Då uppstod uppgiften att integrera Borlas-systemet, baserat på Oracle, där även detta tillvägagångssätt tillämpades. På Oracle-sidan använde de dock sitt eget paket – en analog av cURL i PHP (om det finns intresse kan jag beskriva det i en ny artikel).
Som jag fick reda på kan 1C 8.2 också skicka GET- och POST-förfrågningar. Jag antog att om allt redan var konfigurerat och fungerar med andra system, så borde det fungera här också. JSON avvisades av 1C-utvecklare och sa att formatet var olämpligt och att de bara kände igen XML. Kommentarer om att detta skulle ge oss en minsta mängd dataöverföring, men att vi faktiskt fick mycket data, avvisades. Som ett resultat började vi förbereda 2 XML-baserade system.
För min del skrev jag en begäranacceptor från 1C och returnerade resultat. En funktion för att ta emot en variabel i POST, där 1Sniki var tvungen att ersätta XML.
Formatet är ungefär följande:
En hanterare som returnerar poster som redan har valts enligt villkoren och genererar XML som:
Data kan endast överföras via en HTTPS-anslutning.
Vid första anblicken verkar allt enkelt, men flera problem uppstod under processen:
1) uppdragsgivarna rapporterade att de inte var bekanta med förfrågningar av detta slag och försökte erbjuda ett gammalt beprövat system:
1. importera fil från B2B,
2. Laddar i 1C,
3. Exportera en fil som anger vad som kunde bearbetas, vad som inte var från 1C,
4. Importera till B2B,
5. och från allra första början...
Systemet avvisades eftersom det behövde göras snabbt och utan mänsklig inblandning och några "knappar".
Sedan bad de om ett kodexempel. Jag googlade följande exempel på Internet:
Server = "test.com"; Port = "443"; HTTPTry = New HTTPConnection(Server, Port, True); Else HTTP = New HTTPConnection(Server, Port); endIf; ScriptAddress = "/gateway/GetData1C/"; Försök HTTP.SendForProcessing(SendFileName, ScriptAddress, ResponseFileName, HTTPHeader); Exception Report("Anslutningsförsök misslyckades: " + ErrorDescription()); ElseLogRecord("HTTPConnection", LogLevel.Error, "Anslutningsförsök misslyckades: " + ErrorDescription()); EndIf Return; Slutförsök;
Data började komma till servern, men den var tom, det vill säga GET och POST var tomma. Jag lade till en post i loggarna och glömde bort det. Efter 4 månader fick jag en brådskande uppgift - att få integrationen till ett resultat (eftersom mycket tid har gått arbetar 1C-utvecklare och arbetar, men ingenting kommer som svar). De installerade 1C åt mig och jag började leta runt.
Först bestämde jag mig för att installera Fiddler för att förstå vad som hände. Jag märkte att anslutningen är via HTTP, och sedan omdirigerar servern till HTTPS. Jag antog att av denna anledning är uppgifterna tomma. Jag försökte återskapa det i Chrome och fick en bekräftelse på att data i POST-förfrågan försvann under omdirigeringen.
Eftersom det är omöjligt att tillåta arbete via HTTP, började jag studera varför, eftersom det indikeras att:
HTTP = New HTTPConnection(Server, Port, True); Parametern "True" betyder att använda HTTPS, och sedan kom det fram att HTTP = New HTTPConnection(Server, Port);
Som ett resultat kastades detta "Annars" ut, och jag fick ett felmeddelande om att certifikatet var felaktigt. Certifikatet var självsignerat. Integrationsutvecklingen genomfördes på interna servrar, där ett certifikat från ”Thawte SSL CA” officiellt köptes, till skillnad från PROD-servern. Att importera certifikatet till alla möjliga butiker gav inga resultat.
En sökning genom resurser ledde till att 1C har sina egna rotcertifikat, och baserat på dem kontrollerar den redan de andra. De finns i testform i filen "cacert.pem", som finns i mappen "bin", där 1C finns. Importen är inte så enkel som det visade sig.
Först måste vi exportera certifikatet vi behöver till en fil (jag hade redan det i min personliga lagring). Genom att köra "certmgr.msc", efter att ha hittat certifikatet, exporterar vi det till en *.cer-fil.
C:\OpenSSL-Win64\bin>openssl x509 -inform der -in C:\fiddler.cer -out C:\fiddler.pem -text -fingerprint -md5 VARNING: kan inte öppna konfigurationsfilen: /usr/local/ ssl/openssl.cnf MD5 Fingerprint=13:BF:73:43:BB:69:19:BA:22:5D:C7:2E:44:85:91:7F
Vi sparar MD5, vi kommer att behöva den.
Öppna sedan filen "cacert.pem".
Vi går ner till botten och lägger först till MD5, och sedan allt innehåll som kom ut i filen "fiddler.pem".
Spara filen.
Vi startar om 1C (det kanske inte är nödvändigt, men det fungerade inte för mig, så jag startade om allt.
Källfilen i 1C fick denna form:
Procedur SendRequestPress(Element) Connection = GetHTTPConnection(); If Connection = Undefined Then Report("Kunde inte ansluta till servern som anges i utbytesinställningarna! Bearbetningen avbröts!"); Annars Source = FileAddress; endIf; Filnamn = Filresultat; PostFileName = PostFile; PostFile = New File(PostFileName); SubmissionFileSize = XMLString(SubmissionFile.Size()); Headers = New Match(); Headers.Insert("Content-Type", "application/x-www-form-urlencoded"); Headers.Insert("Content-Lenght", SubmissionFileSize); Attempt Connection.SendForProcessing(PostFileName, Source, FileName, Headers); Undantagsrapport(ErrorDescription()); EndAttempts EndProcedures Funktion GetHTTPConnection() Export AttemptConnection = New HTTPConnection(HTTPServer,"443",True); Undantagsrapport(ErrorDescription()); Anslutning = Odefinierad; Slutförsök; Returanslutning; EndFunctions Procedur OnOpen() HTTPServer = "test.com"; FileAddress = "/gateway/GetData1C"; PostFile = "C:\POST_1C\post.txt"; FileResult = "C:\POST_1C\result.xml"; Slut på procedur
Efter att ha klickat på knappen skickades en förfrågan via HTTPS och rätt XML togs emot som utdata.
Jag letade efter hur 1C fungerar över HTTPS, mycket material, men jag kunde inte hitta hur jag skulle arbeta med ett självsignerande certifikat.
När jag utvecklade en procedur för att skicka information från 1C till webbplatsen med plattformsversion 8.3.9.2170 stötte jag på ett problem: webbplatsutvecklaren gav mig möjligheten att spela in nödvändig information endast med hjälp av en HTTP-förfrågan med PUT-metoden.
Utan att tänka två gånger skissade jag upp en enkel kod:
Connection = New HTTPConnection("www.mysite.ru"); Rubriker = Ny matchning; Headers["Content-Type"] = "applikation/x-www-form-urlenkodad"; Request = New HTTPRequest("/api/order_items/93076?order_item=30", Headers); Connection.Write(Request);
Baserat på resultatet av utförandet borde mängden varor som tagits emot på lagret ha angetts på motsvarande rad i köparens beställning på webbplatsen.
Men som du säkert redan förstått så hände ingenting. Efter att jag försäkrat mig om att det inte fanns några fel på webbplatsen (genom att skicka en liknande förfrågan via en Chrome-plugin) startade jag den på min lokal dator webbserver och började experimentera.
En märklig sak stod genast klart: Ovanstående kod genererar inte en PUT, utan en HEAD-begäran!
I Apache-loggarna såg jag följande:
127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"
Jag blev lite förvånad (trots allt, manualen sa PUT i svart och vitt), men jag var inte förvirrad - du kan ringa metoden direkt:
Connection.CallHTTPMethod("PUT",Request);
Loggarna visar samma sak:
127.0.0.1 - - "HEAD /api/order_items/93076?order_item=30 HTTP/1.1"
"Kanske jag gör något fel?" – Jag ställde en fråga till mig själv. Men det fanns inga tips på Internet eller i manualerna. Nåväl, ingen har ännu ställt in metoden för vetenskaplig petning. Till att börja med försökte jag göra så här:
Connection.CallHTTPMethod("fyvfyv",Request);
I loggarna jag fick:
127.0.0.1 - - "?????? /api/order_items/93076?order_item=30 HTTP/1.1"
Märkligt nog betyder det att 1C ersätter PUT-metoden specifikt (varför gillade inte 1C det?).
Efter några fler försök kom jag fram till detta:
Connection.CallHTTPMethod("PUT",Request);
I loggarna jag fick:
127.0.0.1 - - "PUT /api/order_items/93076?order_item=30 HTTP/1.1"
Och det här alternativet har redan fungerat på webbplatsen och alla var nöjda.
Han föreslog en mer korrekt lösning på problemet: du måste ange en begäran, vilken kropp som helst, till och med tom. Till exempel kommer det här alternativet att fungera:
Connection = New HTTPConnection("www.mysite.ru"); Rubriker = Ny matchning; Headers["Content-Type"] = "applikation/x-www-form-urlenkodad"; Request = New HTTPRequest("/api/order_items/93076?order_item=30", Headers); Request.SetBodyFromString("",TextEncoding.UTF8, UseByteOrderMark.NotUse); Connection.Write(Request);
Och det är förmodligen helt korrekt att skicka parametervärdena själva i förfrågan.
Slutsatsen är följande: 1C-plattformen anser att en PUT-begäran utan kropp är felaktig och ersätter metoden med HEAD.
Det är konstigt att 1C inte spårar en POST-förfrågan utan en kropp och inte förvandlar den till en GET, jag kollade det för skojs skull.
Som den välkända Vovochka skulle säga från det berömda skämtet: "Var är logiken?"
Jag hoppas att min publikation kommer att rädda någon flera timmar av sitt liv på jakt efter ett svar. =)))
Skriv ut (Ctrl+P)
Du kan se den andra delen
Allmän information
I plattformsversion 8.3.5.1068 , publicerad i september 2015, en mekanism för att integrera 1C med externa program genom teknik REST-gränssnitt. Plattformen använder OData-protokollet som ett åtkomstprotokoll. Det är ett öppet webbprotokoll för sökning och uppdatering av data. Det låter dig manipulera data med hjälp av HTTP-kommandon som förfrågningar. I version 8.3.5.1068 var det möjligt att få svar endast i formatet Atom/XML . Men från och med release 8.3.8.1652 i augusti 2017 dök ett andra alternativ upp för att ta emot data i JSON-format (JavaScript Object Notation). . Jämfört med XML är det lätt att läsa av människor och tar mindre plats. Dessutom har alla webbläsare inbyggda verktyg för att arbeta med JSON.
Att arbeta med OData-protokollet på 1C: Enterprise-plattformen finns i boken 1C: Developer's Guide i kapitel 17 Mekanismer för Internettjänster, paragraf 17.2.1 Standard OData-gränssnitt. Du kan också titta på exempel på utökat stöd för OData-protokollet,
Fördel med att använda REST-gränssnitt. drar slutsatsen att för att få tillgång till systemdata från en extern applikation krävs ingen modifiering av applikationslösningskoden (till exempel om applikationslösningen stöds). För att få denna åtkomst måste du publicera applikationen till webbservern på ett specifikt sätt och ange vilka konfigurationsobjekt som ska användas på detta sätt. Tredjepartssystem kan sedan komma åt din applikation med hjälp av HTTP-förfrågningar.
Publicering av standard OData-gränssnittet görs med hjälp av publiceringsdialogrutan på webbservern (Administration - Publicering till webbserver) och beskrivs i boken 1C:Enterprise 8.3. "Administratörsguide".
Viktig! För att konfigurationsobjekt ska vara tillgängliga via standard OData-gränssnittet måste detta vara aktiverat med den globala kontextmetoden SetComposition ofStandardInterfaceOData().
Mekanismen för att ställa in sammansättningen av objekt tillgängliga med hjälp av standard OData-gränssnitt kan göras i formuläret extern bearbetning. Detta kräver ingen modifiering av applikationslösningen.
För att interagera med en extern REST-webbserver från 1C:Enterprise använder vi de verktyg som finns på plattformen för att arbeta med HTTP:-objekt HTTPConnection, HTTPRequest och HTTPResponse.
I den här artikelserien kommer jag att visa exempel på typiska operationer som använder motsvarande HTTP-metod;
- Ta emot data - metod SKAFFA SIG;
- Skapa ett objekt - Metod POSTA;
- Uppdatera data: metod LAPPA– i det här fallet kan du endast ange de egenskaper som behöver uppdateras; metod SÄTTA– i detta fall är det nödvändigt att ange alla egenskaper hos enheten;
- Ta bort data - metod RADERA.
1. Exempel på datainsamling. HTTP GET-metoden
Servern kommer att vara en databas publicerad på webbservern med namnet WebBuh(Demodatabas "Enterprise Accounting 3.0"). Jag kommer att använda JSON-formatet som datautbytesformat. Mer information om att arbeta med JSON finns i den tillgängliga dokumentationen. För att ta emot data från servern med HTTP GET-metoden måste du skapa ett objekt Läser JSON för att läsa JSON-data sekventiellt från en fil eller sträng. För att organisera sekventiell inspelning av objekt och texter på servern med HTTP POST PATCH PUT-metoden måste du skapa ett objekt JSON-post. Observera att DELETE-metoden inte kräver JSON.
För att illustrera flödet av att läsa och skriva JSON när jag kommer åt REST-gränssnittet kommer jag att anropa följande anpassade funktion generell mening Ring HTTPMethodOnServer :
&På server // <Описание функции>// // Alternativ: //För att ta emot från servern i JSON-format när du kommer åt REST-gränssnittet för en applikationslösning måste du ange i resursadressen $format=json. Eller ange MIME-typen "applikation/json" i rubriken:
Rubriker = new Match(); Headings.Insert("Content-Type", "applikation/json") ; Resursadress = " WebBuh/odata/standard.odata/ ?$format=json" RequestHTTP = Nytt HTTPRequest(ResourceAddress, Headers);Inslag i det globala sammanhanget ReadJSON(ReadJSON, True)
- Om den andra parametern är satt till True, läs objektet JSON kommer att slutföras i Korrespondens.Om den är inställd på False kommer objekt att läsas in i ett objekt av typen Strukturera.
- När du deserialiserar JSON-objekt till en struktur måste du vara medveten om strukturnyckelkraven. Om, vid deserialisering av ett objekt, ett egenskapsnamn hittas som inte är giltigt för en strukturnyckel, kommer ett undantag att kastas.
1. 1 Konfigurera HTTP-anslutningsparametrar
För att organisera klientdelen av interaktion med en extern REST-webbserver skapade jag en klientkonfiguration baserad på BSP från grunden. Med den här konfigurationen skapade jag en referens för att ställa in anslutningsparametrar (se fig. 1)
Fig. 1 Katalog för inställning av parametrar för HTTP-anslutning till extern informationssäkerhet via restgränssnittet
Efter att ha tryckt på knappen Kontrollera serverns svar, en procedur anropas där klienten försöker ta emot ett svar från servern. Programkod Proceduren är skriven nedan:
&OnClient Procedur CheckConnection(Command) Address = Object.ServerAddress; Användare = Objekt.Användare; Lösenord = Object.Password; Databasnamn = Objekt.namn; Port = ? (Object.Port<>0,Object.Port,80); HTTPConnection = Nytt HTTPConnection (adress, port, användare, lösenord); ResourceAddress = Databasnamn + "/odata/standard.odata/ $metadata "; //Ring upp anpassad funktion Svarsstruktur= B Ring HTTPMethodOnServer("SKAFFA SIG" , HTTPConnection, ResourceAddress) ; Om Svarsstruktur <> Odefinierat då General PurposeClientServer.NotifyUser("Statuskod"+Svarsstruktur.Statuskod); Ändlös; Slut på procedurSyftet med denna procedur är kontrollera tjänsten och om användaren har angett anslutningsparametrarna korrekt. För att göra detta, utför bara en GET-begäran:
HTTPConnection.CallHTTPMethod( "SKAFFA SIG", HTTP-förfrågan);
med hjälp av resursadressen:
Resursadress
=Basnamn+ “/odata/standard.odata/
“;
Du kan också kontrollera tjänsten i din webbläsare med hjälp av
URL http://host/WebBuh/odata/standard.odata. Resultatet av en sådan fråga är bara en lista över enheter. För att få en fullständig beskrivning av standard OData-gränssnittet (lista över tillgängliga enheter, deras attribut och funktioner i form av XML-
dokument.) måste du utföra en GET-begäran med parametern $metadata.
URL http://host/WebBuh/odata/standard.odata/$metadata. Detaljerad beskrivning Dokumentet kan erhållas på http://www.odata.org/documentation/ (på engelska).
Du kan få svar i formatet Atom/XML eller JSON. HTTP-svarsstatuskoder kan ses Svar i intervallen:
- 100-199 – informationssvar som indikerar att kundens begäran har accepterats och håller på att behandlas.
- 200-299 – betyder att kundens begäran behandlades framgångsrikt.
- 300-399 innebär att begäran inte fullföljdes och kunden måste vidta några åtgärder för att tillgodose begäran.
- 400-499 – informerar om fel på klientapplikationssidan. Dessa koder kan också indikera att ytterligare information krävs från klienten.
- 500-599 - Informerar om ett fel på serversidan, vilket indikerar att servern har stött på ett fel och sannolikt inte kommer att kunna uppfylla klientens begäran.
1.2 Söka efter ett objekt med ID
Nästa funktion är utformad för att söka efter en katalog eller ett dokument med en unik identifierare på servern. Om objektet hittas returnerar funktionen strängvärdet för identifieraren (Ref_Key), annars returnerar den odefinierad. Följande parametrar skickas till funktionen:
- HTTPConnection – Objekt av typen HTTPConnection
- PublicationName – Namnet på den publicerade serverdatabasen
- Element – Identifierare av objektenhet, till exempel, Catalog_Organisations eller Document_- katalogen för organisationen.
- Identifierare – Identifieraren för objektet som ska sökas på servern, t.ex. Organization.UniqueIdentifier()
Parameter Resursadress används för att komma åt en REST-tjänst. För att kontrollera tjänstens funktion kan du ange resursen i webbläsaren så här
http://(WebServerAddress)/(PublicationName)/odata/standard.odata/(Element)?(Parametrar) ,Var
- Webserveradress– Adressen till webbservern som tjänsten publiceras på, till exempel Localhost
- NamnPublicationer- Namn informationsbas anges vid offentliggörandet av beslutet
- /odata/standard.odata/ – Tecken på åtkomst till standard OData-gränssnitt
- Element – resursidentifierare eller fördefinierade resurser. Till exempel Catalog_Account(guid'value').
- alternativ– resursparametrar. Används till exempel för urval, på det accepterade sättet för HTTP-förfrågningar: ?key=value&key2=value2
1.3 Söka efter ett objekt med hjälp av sökfält
Följande användardefinierade funktion är utformad för att söka efter ett objekt med sökfält i det fall objektet är med identifikationsnummer. Funktionsobjekt sträng Ref_Key –ett identifikationsnummer.
&OnServer-funktion P searchObjectBySearchFields(HTTPConnection,PublicationName,Element,SearchFields) Villkor = "" ; För varje nyckelvärde från sökfältsslinga Skick = Skick + KeyValue.Key+ "eq"" + KeyValue.Value+ "" och "; EndCycle; Begär text =Lev(Kondition, StrLength(Condition)-5); // ta bort de sista 5 tecknen Resursadress= Publikationsnamn+ "/odata/standard.odata/" +Element+ "?$filter=" + Begär text+ "&$format=json& $select=Ref_Key" ; //Anrop min anpassade funktion Svarsstruktur= CallHTTPMethodOnServer( "SKAFFA SIG",HTTPConnection,ResourceAddress); Om Svarsstruktur .Statuskod >= 400 Sedan //General PurposeClientServer.NotifyUser(Element+ "Error"+ResponseStructure.StatusCode); //General PurposeClientServer.NotifyUser(ResponseStructure.ServerResponseUdecrypted); Returnera odefinierat; endIf; Match = Svarsstruktur. ReplyServer a; Array = Matcha["värde" ]; Om Array = Odefinierad Returnera Match ["Ref_Key" ] Annars Returnerar Array ["Ref_Key" ]; endIf; EndFunctionSom framgår av förfarandets kropp P searchObjectBySearchFields, börjar urvalet med nyckelordet$filteri resursadressen. Formell parameterSökfält –detta är en korrespondens som innehåller namnen och värdena på detaljerna.
Observera att namnen på detaljerna ibland inte är uppenbara. Det är nödvändigt att komma ihåg att för referensböcker:
- Kod - kod,
- Beskrivning – Namn
- DeletionMark – raderingsmärke,
- IsFolder – grupptecken,
- Parent_Key – förälder.
- Om attributet är av en referenstyp ska suffixet _Key läggas till i dess namn, till exempel Account_Key.
För dokument:
- Nummer – dokumentnummer,
- Datum – dokumentdatum.
Logiska urvalsoperationer
- eq - Lika; /Catalog_Cities?$filter=Namn eq 'Main';
- ne - Inte lika; /Catalog_Cities?$filter=Namn och 'Perm';
- gt - Mer; /Catalog_Products?$filter= Pris gt 10;
- ge - Större än eller lika med; /Catalog_Products?$filter=Pris ge 10;
- lt - Mindre; /Catalog_Products?$filter=Pris lt 10;
- le - Mindre än eller lika med; /Catalog_Products?$filter=Pris le 10;
- eller - Logiskt ELLER; /Catalog_ Products ?$filter= Pris lt 10 eller pris gt 100;
- och - Logiskt OCH; / Katalog _Produkter?$ filter =Pris g t 10 och Pris l t 100;
- inte - Negation; /Catalog_ Products ?$filter=not (Pris eq 10);
Observera också att värdet på den faktiska parametern Element(eller entitet)) som jag skickar till funktionen bildas enligt följande regel:
Namn Prefix_ConfigurationObjectName_Name Suffix.
Genom att använda standard OData-gränssnittet kan du komma åt följande objekt ( Namn prefix):
- Katalog - Katalog;
- Dokument - Dokument;
- Dokumentjournal - DocumentJournal;
- Konstant - Konstant;
- Utbytesplan - ExchangePlan;
- Kontoplan - ChartOfAccounts
- Diagram över beräkningstyper - ChartOfCalculationTypes;
- Karakteristiska typer diagram - ChartOfCharacteristicTypes;
- Informationsregister - Informationsregister;
- Ackumuleringsregister - Ackumuleringsregister;
- Beräkningsregister - CalculationRegister;
- Bokföringsregister - AccountingRegister;
- Affärsprocess - Affärsprocess;
- Uppgift - Uppgift.
ConfigurationObjectName- "Name"-egenskapen för konfigurationsobjektet som det är specificerat i konfiguratorn.
Namnsuffix- som behövs för att förtydliga resursnamnet, valfritt, kan ha följande värden:
- Namnet på den tabellformade delen av objektet;
- namn virtuellt bord objekt;
- RowType - rad av den tabellformade delen av objektet;
- RecordType - en separat registerpost.
Parametrar för åtkomst till resurser
Efter att ha skapat resursnamnet måste du definiera parametrarna för åtkomst till resursen, till exempel, ?$filter= Menande &$format=json& $select= Ref_Key ,
- $filter- val vid mottagning av data
- $format- indikerar formatet för de returnerade uppgifterna,
- $select- Lista över entitetsegenskaper som kommer att inkluderas i frågeresultatet;
- $metadata- returnerar en beskrivning av OData-standardgränssnittet (används utan att ange ett namnsuffix, exempel i en av bilderna ovan);
- $top- begränsning av antalet poster som returneras;
- $hoppa över- tar bort det angivna antalet poster från frågeresultatet;
- $count- returnerar antalet poster i frågevalet;
- $inlinecount=allpage(=ingen)- lägger till information om antalet poster till frågeresultatet
- $orderby=<Реквизит1>asc,<Реквизит2>besk- sortering av frågeresultatet
- bara tillåt- endast tillåtna sådana (används utan "$"-tecknet).
1.4 Få en mängd informationsregisterposter
Låt oss titta på ett exempel på hur man skaffar en rad registerposter för information om fullständiga namn på individer, till exempel historien om ändringar i fullständiga namn enskild
NamnPublicationer = "WebBuh"; Element = "InformationRegister_Name of Individuals"; Period = Odefinierad; ReferenceType Data= new Structure(); D DataReferenceType.Insert("Individual",Individual_Key); DataNON-ReferenceType= new Structure(); DataNON-ReferenceType.Insert("Individual_Type", "StandardODATA.Catalog_Individuals") Array = GetRegisterInfoSet(HTTPConnection,PublicationName,Element,Period, DimensionsReferenceType, Non-ReferenceType Dimensions)Bollen för GetInfoRegisterRecordSet-funktionen, som anropas i det här exemplet, visas nedan
Från och med den andra versionen 8 av plattformen har användare och utvecklare möjlighet att använda http-förfrågan direkt i 1C. Programmet stöder två typer av förfrågningar:
- POST-förfrågningar;
- GET-förfrågningar.
Således skapades ett ganska bekvämt verktyg för att utbyta data och interagera med webbtjänster och tjänster som fungerar via http.
GET-förfrågan
Naturligtvis illustrerar de enklaste exemplen på att använda frågor deras kapacitet mycket bättre än många beskrivningsrader. Låt oss försöka:
- Låt oss ta del av huvudsidan på vår webbplats;
- Vi kommer att arbeta med att omdirigera begäran;
- Låt oss ta bilden från webbplatsen.
Hämta sidans kropp
Låt oss börja med något enkelt. I fig..
Resultatet av att exekvera detta avsnitt av koden är en ganska stor text, vars sista avsnitt visas i Fig. 2.
Fig.2
I den första kodraden skapar vi ett anslutningsobjekt till http-resursen. Ett objekt kan innehålla följande egenskaper:
- Server - anslutningssträng som innehåller serveradressen;
- Port – innehåller ett nummer som anger serverporten; som standard, beroende på anslutningstyp, kan du ange 80 för osäkra anslutningar eller 443 för SSL-säkrade.
- Användarnamn – anges om auktorisering på servern krävs;
- Lösenord – användarlösenord på den angivna resursen;
- Proxy – kan innehålla ett objekt av typen InternetProxy, indikerat när en proxy används för att kommunicera med servern;
- Säker anslutning – standardvärdet är FALSK, byte till TRUE indikerar användning av https-protokollet.
Dessutom har HTTPConnection-objektet sina egna metoder, anrop som låter dig beskriva hanterarexekveringsalgoritmen mer fullständigt:
- CallHTTPmethod – innehåller två nödvändiga parametrar, HTTPmethod och HTTPrequest, stöder möjligheten att skriva svarstexten till filen som anges i den tredje parametern;
- Skriv – med hjälp av en PUT-begäran skickar data till servern;
- Modifiera – ändrar ett objekt genom att bearbeta PATCH-förfrågningar;
- SendForProcessing – en metod som indikerar användningen av en POST-begäran, som i alla tidigare metoder, måste innehålla texten i begäran, och kan även överföra adressen till svarsfilen för inspelning av data;
- Ta emot - detta kommer att diskuteras mer i detalj nedan;
- GetHeadings är en annan metod som kommer att användas i artikeln;
- Ta bort är egentligen en Delete-begäran som tar bort resursen som skickas i begäran från servern.
På den andra raden skapar vi en förfrågan till den valda webbplatsen, texten i vår förfrågan innehåller ett snedstreck, vilket betyder att vi vill ta emot startsida. Om snedstrecket följdes av något uttryck, till exempel "sida2" eller "nyheter", skulle vi få en annan sida.
Den tredje raden utför vår begäran till servern.
I den fjärde visar vi resultatet.
Hanterar omdirigering av http-begäran
Låt oss föreställa oss en situation där vi måste programmatiskt få ett sökresultat genom någon sökmotor med knappen "Begäran om 1s". Kodavsnittet som krävs för att komma åt GOOGLE visas i fig. 3
Fig.3
Här, förutom de strukturer som vi redan känner till, finns Headers och Status Code. Låt oss ta itu med dem.
Statuskod – standardvärde som anges i "Begäran om kommentarer", kan ha följande värden:
- Om allt är bra kommer värdet att återgå i intervallet från 100 till 299;
- Vid omdirigering kommer en kod i intervallet från 300 till 399 att returneras, i vårt fall kommer en framgångsrik permanent omdirigering till en resurs att bestämmas av kod 301;
- Om det finns fel i begäran kommer parametern att ha ett värde från 400 till 499;
- Ett värde i intervallet 500-599 indikerar problem med servern.
Varje sida har en titel, i vilken text flera parametrar kan urskiljas (fig. 4):
- Anslutningsschema (allt som kommer före två snedstreck “//”);
- Adressfält anslutningar;
- Användarnamn och lösenord;
- Port och värd att ansluta till.
Det är denna uppdelning som utförs av SplitAddressLine-funktionen. Har alltså fått ny adress, kan vi spara sidan på vår dator och öppna den i standardwebbläsaren (GetPage-proceduren).
Fig. 5
Det finns inga nya funktioner eller sätt att arbeta med förfrågningar här, vi skapar faktiskt Textdokument från sidans brödtext och starta sidan i webbläsaren.
Vi placerar filen i roten av enhet D och kallar den test.
Vi tar bilden från sajten
En naturlig fråga uppstår: om vi inte behöver hela webbplatsen, utan bara behöver skaffa dess individuella element, kan detta göras och hur? Jo det kan du. Programkoden som låter dig göra detta visas i Fig. 6
Fig. 6
Som du kan se från figuren har vi i förfrågans brödtext koden för webbplatsstrukturelementet som vi behöver ta emot. Denna del fanns inte i vår tidigare beskrivning och vi måste uppehålla oss vid denna punkt mer i detalj.
Vi använde en webbläsare Opera för att komma åt webbplatsen. Den har ett viktigt verktyg för oss: när du högerklickar på ett element kan du ta fram en snabbmeny, vars ena är "Visa elementkod".
Det är tack vare honom som vi kan få adressen som kommer att användas i förfrågan Fig. 7.
POST-förfrågan
Till skillnad från enkla Get-förfrågningar har POST http-förfrågningar en textkropp som kan lagras som i en vanlig textform, och i form av filer med tillägget xml, soap, json. Det finns en hel del verktyg på nätverket för att skapa förfrågningstexter som låter dig felsöka och övervaka utförandet av vissa förfrågningar.
I 1C, för att starta en begäran med en specifik text, har HTTP-förfrågningsobjektet SetBodyFromString-proceduren.
