HTTP szolgáltatások azoknak, akik nem értenek semmit a WEB-hez. Webszolgáltatások (SOAP), HTTP szolgáltatások, oData (automatikus REST szolgáltatás) Új kurzus 1c szolgáltatás paraméterei

Ha nem értesz semmit a webes technológiákhoz és az olyan szavakhoz, mint a json, a get, a post és így tovább nem jelentenek neked semmit, és te csak lelkes 1C felhasználó vagy, de meg kell barátkoznod az 1C-vel harmadik féltől származó alkalmazások vagy webhely. Akkor ez a cikk neked szól.

Hadd kezdjem azzal a ténnyel, hogy egykor kénytelen voltam egyedül foglalkozni a webszolgáltatásokkal. Aztán valahogy, apránként sikerült úrrá lenni ezen a dolgon, és megértettem, mit és hol kell nyomni, hogy minden működjön. Szerencsére a konfiguráció, amivel dolgoznom kellett, már tele volt webszolgáltatásokkal, és analógiával lehetett kukucskálni, megcsinálni, és az interneten is sikerült elég cikket találnom erről a témáról. És így példákkal (számomra ez a legjobb tanulási mód) elsajátítottam ezt a kérdést, és most már nem ijesztenek meg.

ÍGY. Minden integráció fő feladata, legyen szó CD-ről, webszolgáltatásról vagy HTTP-szolgáltatásról, hogy valamit átvigyünk valahonnan, csináljunk vele valamit, és visszaküldjünk egy választ. Ez az a formátum, amelyben figyelembe vesszük az új technológiát.

A metaadatfában a HTTP-szolgáltatások az Általános ágban találhatók:

Egy új HTTP-szolgáltatás ugyanúgy hozzáadódik, mint bármely más metaadat-objektum. Név és szinonimája tetszés szerint. Itt csak a „Root URL” a fontos - valójában ez a HTTP szolgáltatás azonosítója ebben az adatbázisban, azaz. pontosan amit ebben a tulajdonságban ír, azt egy harmadik fél fejlesztőnek (vagy magának) továbbítja a szolgáltatás linkjeként.

Nem tudom, hogy lehet-e itt cirill betűvel írni, de hogy ne röhögjenek ki a progresszív világban, írj latinul).

Maga a Template tulajdonság itt fontos:

Egy sablon segítségével később hivatkozhat az Önnek átvitt adatokra. SO: az összes kívülről fogadni kívánt adat 2 blokkra osztható - kötelező és opcionális.

A szükséges adatokat/paramétereket betoljuk a sablonba, így ha a szolgáltatást igénybe vevő nem tölti ki, akkor a szolgáltatás eleve hibát generál, és a kezelő modul szövegének kialakítása során Ön biztos lesz abban, hogy ezek az adatok van. Hogyan történik ez: a Pattern sorba göndör zárójelben „()”, a „/” jellel váltakozva írjuk a változók nevét. Például feltétlenül szükségünk van egy cikkre - akkor írunk /(artikul). Ha meg kell szereznünk a cikket, nevet és felhasználónevet, akkor a sablon karakterlánc így fog kinézni: /(artikul)/(név)/(felhasználó), stb. A kezelőmodul szövegében szereplő paraméterek mindegyike a következőképpen érhető el: Request.ParametersURL["<имя параметра>"]. Ha nincsenek kötelezők, akkor a sablon így néz ki: /*.

A sablonban NINCS leírva, hogy a szolgáltatáson keresztül milyen opcionális adatokat szeretnénk kapni. A szolgáltatás eléréséhez szükséges hivatkozás létrehozása során a hivatkozás végén a "?" jel után szerepelnek, és az "&" karakter választja el, és a szerkezetük a következő.<имя параметра>=<значение параметра>. A kezelő modul szövegében a következő konstrukcióval érhetők el: Request.RequestParameters.Get("<имя параметра>"). DE: fontos megjegyezni, hogy mivel nem kötelezőek, előfordulhat, hogy nem léteznek; ennek megfelelően ellenőrizzük az Undefined értékét.

Ezután hozzáadunk egy új módszert a sablonunkhoz. A HTTP metódus tulajdonság itt fontos. Nagyon sok van belőlük, DE nem megyünk bele minden részletbe. Bármelyik feladat végrehajtásához mindössze kettőre van szüksége: GET és POST.

Hogyan válassz: Ha az előző két bekezdésben leírtak elegendőek a munkájához, pl. Magának a kérésnek a kötelező és választható paraméterei segítségével minden szükséges adatot megkaphat, majd a GET-et vesszük. Ebben az esetben bármely böngészőben, ha helyesen adja meg a címsort, látni fogja HTTP szolgáltatásának eredményét - PROFIT! Ha hirtelen a szolgáltatása működéséhez bonyolultabb formátumú adatokra van szüksége (például xml, vagy valami más), olyasmire, amit nem lehet egy egyszerű címsorba betömni, akkor használja a POST-ot. Hátránya, hogy egy ilyen egyszerű ellenőrzés a böngésző címsorán keresztül, mint a GET esetében, nem fog működni, de az interneten könnyen találhat néhány oldalt, ahol a POST módszerrel ellenőrizheti a szolgáltatásokat (például a https:/ webhelyet). /www.hurl.it) . Ha a POST metódus van kiválasztva, akkor az URL-en (címen) kívül a kérésnek van egy törzse, amibe bármit bele lehet rakni, amit csak akarunk, és a metóduskezelőben a Request.GetBodyAsString() konstrukción keresztül érhetjük el. Bármely sablonnak lehet GET és POST metódusa is. Ennek megfelelően különböző kezelőkkel rendelkeznek, és az 1C a kérés elküldésének módjától függően választ egy vagy másik módszert.

A HTTP szolgáltatáskezelő egy olyan függvény, amely mindig HTTPServiceResponse típusú értéket ad vissza, amelyet a New HTTPServiceResponse( konstruktor épített fel<КодСостояния>). <КодСостояния>- ez egy szám, hogy ne kelljen törődni azzal, hogy mit írjunk, ezt írjuk: 200 - ha minden rendben van, és valamilyen logikai értéket ad vissza, 400 - ha hiba van, és visszaküldi a hiba leírását . Ennek a típusnak különféle módszerei vannak (a szintaktikai asszisztensben olvasható, ott minden egyértelműen le van írva). Ismét mindig mindent visszaadhat, amire szüksége van karakterláncként – a SetBodyFromString() metódussal. (egy kis trükk: ha visszaadja a html-t, és azt szeretné, hogy a böngésző gyönyörűen jelenítse meg a képernyőn, amikor beírja a szolgáltatás címét a címsorba, akkor a válasz Headings tulajdonságába írja be: Answer.Headers.Insert("Content-Type ","text/html; charset=utf-8") - ezzel jelzi, hogy ez nem csak egy karakterkészlet, hanem HTML, és ennek megfelelően kell megjeleníteni)

Miután mindent megtett, a HTTP szolgáltatást közzé kell tenni. Ez egy webszerverrel felszerelt számítógépen történik (a beállításokról nem írok, rengeteg cikk van) a menün keresztül:

Adminisztráció – Közzététel webszerveren.

Van egy HTTP-szolgáltatások lap. Jelölje be a négyzeteket, és kattintson a "Közzététel" gombra




Azzal szembesültem, hogy meg kell szereznem a jelenlegi konfigurációs állapotot. Meg kell kapnia:

  • Bizonyos kijelölésű dokumentumok száma;
  • A termék utoljára rögzített árának időszaka;
  • A felhasználó által az elmúlt 10 percben feldolgozott dokumentumok száma.

Figyelembe véve a mobilalkalmazás projektekben való megvalósításának tapasztalatait, először felvillant a gondolat, hogy írjak konfigurációt Androidra. Az összes pro és kontra mérlegelés után arra a következtetésre jutottam, hogy ez a megközelítés nem lenne alkalmas a problémám megoldására. Ezután a tanfolyamon a http szolgáltatás használatára került sor. Ehhez a konfigurációban regisztráltuk a „Statisztika” http szolgáltatást, és hozzáadtuk az AnyURL URL-sablont, amelyhez egy get metódus is került.


A konfigurációs fa objektumainak generálása után elkezdjük írni a válasz generálására szolgáló algoritmust. A metódus HTTPServiceResponse típusú választ ad vissza:

A válaszkód megírása után közzétesszük a http szolgáltatást a konfigurátorból és elérjük a böngészőből. A http szolgáltatás eléréséhez kapcsolatba kell lépnie a webes kliensben található címmel a „/hs/statistic/” hozzáadásával. A hs közli a platformmal, hogy egy http szolgáltatás elérése folyamatban van, a statisztika pedig a szolgáltatásunk neve.

Véleményem szerint a http szolgáltatások a következő esetekben lehetnek hasznosak:
— Konfigurációs statisztikák generálása;
— Funkció a megrendelés állapotának a szám alapján történő lekéréséhez;
— Adatok előkészítése más rendszerekbe történő importáláshoz.

Az 1C 8.3 és 8.2 webszolgáltatása egy metaadat objektum, amely lehetővé teszi az 1C platform integrálását más információs rendszerekkel szolgáltatásorientált architektúrát (SOA) használva.

Nézzük meg egy olyan webszolgáltatás létrehozását és konfigurálását, amely lehetővé teszi az 1C 8 adatbázisok közötti kétirányú adatcserét SOAP segítségével.

Először nézzük meg a lapot Egyéb:

Szerezzen ingyen 267 videóleckét 1C-n:

  • A terepen Névtér URI leírja az erőforrás-azonosító helyét.
  • — azoknak a típusoknak a leírása, amelyekkel a jövőbeli webszolgáltatás képes lesz dolgozni.
  • Kiadványfájl neve— a webszerveren elhelyezett *.1CWS fájl neve

Az 1C webszolgáltatás felépítése

Nézzük a webszolgáltatás felépítését:

A DataExchange maga a webszolgáltatás. UnloadData, LoadData - műveletek, lényegében a SOAP protokollon keresztül meghívható függvények leírása. ExchangePlanName, NodeCode stb. - a webszolgáltatásba továbbított értékek.

Webszolgáltatás modul

A modul tartalmazza a legérdekesebbet - a leendő webszolgáltatás funkcióinak leírását. Esetünkben olyan funkciókat írunk le, amelyek lehetővé teszik az adatok fogadását és küldését szabványos 1C cseremechanizmusok segítségével. Mert A csere egy platform - 1C között történik, akkor nincs szükség adatsorosításra.

Az 1C http szolgáltatás működésének ellenőrzése egy webszerveren

Hadd kezdjem azzal a ténnyel, hogy egykor kénytelen voltam egyedül foglalkozni a webszolgáltatásokkal. Aztán valahogy, apránként sikerült úrrá lenni ezen a dolgon, és megértettem, mit és hol kell nyomni, hogy minden működjön. Szerencsére a konfiguráció, amivel dolgoznunk kellett, már megtelt Webszolgáltatások segítségével meg lehetett nézni, és analógiával meg lehetett csinálni, az interneten pedig elég cikket találtam erről a témáról. És így példákkal (számomra ez a legjobb tanulási mód) elsajátítottam ezt a kérdést, és most már nem ijesztenek meg.

ÍGY. Minden integráció fő feladata, legyen szó CD-ről, webszolgáltatásról vagy HTTP-szolgáltatásról, hogy valamit átvigyünk valahonnan, csináljunk vele valamit, és visszaküldjünk egy választ. Ez az a formátum, amelyben figyelembe vesszük az új technológiát.

A metaadatfában a HTTP-szolgáltatások az Általános ágban találhatók:

Egy új HTTP-szolgáltatás ugyanúgy hozzáadódik, mint bármely más metaadat-objektum. Név és szinonimája tetszés szerint. Itt csak a „Root URL” a fontos – ez valójában az azonosító HTTP szolgáltatás ebben az adatbázisban, pl. pontosan amit ebben a tulajdonságban ír, azt egy harmadik fél fejlesztőnek (vagy magának) továbbítja a szolgáltatás linkjeként.

Nem tudom, hogy lehet-e itt cirill betűvel írni, de hogy ne röhögjenek ki a progresszív világban, írj latinul).

Maga a Template tulajdonság itt fontos:

Egy sablon segítségével később hivatkozhat az Önnek átvitt adatokra. ÍGY: az összes kívülről fogadni kívánt adat 2 blokkra osztható - kötelező és opcionális.

Szükséges adatok/paraméterek betoljuk a sablonba, így ha a szolgáltatást igénybe vevő nem tölti ki, akkor a szolgáltatás eleve hibát generál, és a kezelő modul szövegének kialakításakor biztos lesz benne, hogy ezek az adatok ott vannak. Hogyan történik ez: a Pattern sorba göndör zárójelben „()”, a „/” jellel váltakozva írjuk a változók nevét. Például feltétlenül szükségünk van egy cikkre - akkor írunk /(artikul). Ha meg kell szereznünk a cikket, nevet és felhasználónevet, akkor a sablon karakterlánc így fog kinézni: /(artikul) /(név)/(felhasználó), stb. A kezelőmodul szövegében szereplő paraméterek mindegyike a következőképpen érhető el: Request.ParametersURL["<имя параметра>"]. Ha nincsenek kötelezők, akkor a sablon így néz ki: /*.

Nem kötelező adatok, amelyeket a szolgáltatáson keresztül szeretnénk megkapni, NINCS leírva a sablonban. A szolgáltatás eléréséhez szükséges hivatkozás létrehozása során a hivatkozás végén a "?" jel után szerepelnek, és az "&" karakter választja el, és a szerkezetük a következő.<имя параметра>=<значение параметра>. A kezelő modul szövegében a következő konstrukcióval érhetők el: Request.RequestParameters.Get("<имя параметра>"). DE: fontos megjegyezni, hogy mivel nem kötelezőek, előfordulhat, hogy nem léteznek; ennek megfelelően ellenőrizzük az Undefined értékét.

Ezután hozzáadunk egy új módszert a sablonunkhoz. A HTTP metódus tulajdonság itt fontos. Nagyon sok van belőlük, DE nem megyünk bele minden részletbe. Bármelyik feladat végrehajtásához mindössze 2-re van szüksége: KAPÉs POST.

Hogyan válassz: Ha az előző két bekezdésben leírtak elegendőek a munkájához, pl. Magának a kérésnek a kötelező és választható paraméterei segítségével minden szükséges adatot megkaphat, majd a GET-et vesszük. Ebben az esetben bármelyik böngészőben, ha helyesen adja meg a címsort, látni fogja HTTP szolgáltatásának eredményét - PROFIT! Ha hirtelen a szolgáltatása működéséhez bonyolultabb formátumú adatokra van szüksége (például xml, vagy valami más), olyasmire, amit nem lehet egy egyszerű címsorba betömni, akkor használja a POST-ot. Hátránya, hogy egy ilyen egyszerű ellenőrzés a böngésző címsorán keresztül, mint a GET esetében, nem fog működni, de az interneten könnyen találhat néhány oldalt, ahol a POST módszerrel ellenőrizheti a szolgáltatásokat (például a https:/ webhelyet). /www.hurl.it) . Ha a módszert választjuk POST, majd a kérés mellett URL (címek) megjelenik egy törzs, amibe bármit bele lehet rakni, és a metóduskezelőben a Request.GetBodyAsString() konstrukción keresztül érheti el. Bármely sablonnak lehet GET és POST metódusa is. Ennek megfelelően különböző kezelőik lesznek, és az 1C a kérés elküldésének módjától függően választ egy vagy másik módszert.

A HTTP szolgáltatáskezelő egy olyan függvény, amely mindig HTTPServiceResponse típusú értéket ad vissza, amelyet a New HTTPServiceResponse( konstruktor épített fel<КодСостояния>). <КодСостояния>- ez egy szám, hogy ne kelljen törődni azzal, hogy mit írjunk, ezt írjuk: 200 - ha minden rendben van, és valamilyen logikai értéket ad vissza, 400 - ha hiba van, és visszaküldi a hiba leírását . Ennek a típusnak különféle módszerei vannak (a szintaktikai asszisztensben olvasható, ott minden egyértelműen le van írva). Ismét mindig mindent visszaadhat, amire szüksége van karakterláncként – a SetBodyFromString() metódussal. (egy kis trükk: ha visszaadja a html-t, és azt szeretné, hogy a böngésző gyönyörűen jelenítse meg a képernyőn, amikor beírja a szolgáltatás címét a címsorba, akkor a válasz Headings tulajdonságába írja be: Answer.Headers.Insert("Content-Type ","text/html; charset=utf-8") - ezzel jelzi, hogy ez nem csak egy karakterkészlet, hanem HTML, és ennek megfelelően kell megjeleníteni)

Miután mindent megtett, a HTTP szolgáltatást közzé kell tenni. Ez egy webszerverrel felszerelt számítógépen történik (a beállításokról nem írok, rengeteg cikk van) a menün keresztül:

Adminisztráció – Közzététel webszerveren.

Van egy HTTP-szolgáltatások lap. Jelölje be a négyzeteket, és kattintson a "Közzététel" gombra

Így, kaptunk egy kész HTTP szolgáltatást. HOGYAN lehet vele kapcsolatba lépni? Ha a GET metódust használjuk, akkor a böngésző címsorába ezt írjuk: http://<имя веб сервера>/<имя базы>/hs/<корневой URL>/<обязательный параметр1>/<обязательный параметр2> <имя не обязательного параметра 1>=<значение не обязательного параметра 1>&<имя не обязательного параметра 2> =<значение не обязательного параметра 2> .

És végül még egyszer képekben))):

Figyelem! A tanfolyam most is este 18:30-tól 21:30-ig kerül megrendezésre merülő formában.

A tanfolyam során gyakorlati készségeket szerezhet az 1C:Enterprise 8 platform következő mechanizmusainak használatában:

  • WEB szolgáltatások (SOAP protokoll)
  • JSON formátum
  • oData interfész (automatikusan REST szolgáltatás)
  • HTTP szolgáltatások

FONTOS!!! A tanfolyam azoknak a programozóknak készült, akik jártasak az XDTO-mechanizmussal való munkavégzésben, vagy már korábban elvégezték a tanfolyamot.

A tanfolyam leírása és programja:

A WEB tanfolyam ára tartalmazza:

  • 2 hét tanfolyam, 2 webinárium tanárral
  • 1C Oktatóközpont 3. számú bizonyítványa (gyakorlati képzéstől függően)

A teljes idejű merítési tanfolyam költsége tartalmazza:

  • 2 nap 10:00-17:00 vagy 16:00 18:30-21:30
  • jegyzetek, fejhallgatók
  • ebédek, kávészünetek
  • hozzáférhet a frissített videó anyagokhoz a tanfolyam elvégzése után 2 évig
  • 1C-Training Center 3. számú bizonyítványa

Képzési formátumok

WEB képzés

Mi ez a formátum:A javasolt formátum a távoktatás számos előnyét ötvözi a videoanyagok és online konzultációk által képviselt személyes komponenssel.
A WEB-tanfolyam videókból, gyakorlati feladatokból és tanárokkal tartott webináriumokból áll. Minden tananyag a nap 24 órájában elérhető az interneten keresztül, így az Ön számára megfelelő időpontban tanulhat. A tanfolyam osztályokra oszlik. Az óra során az aktuális témával kapcsolatos anyagokat tanulmányozzák, workshopokat tartanak, kérdéseket tesznek fel a tanárnak. Minden óra végén webináriumot tartanak, amely során a tanár megvizsgálja az összes beérkezett kérdést, a tipikus hibákat, és elmagyarázza a helyes megoldást. A webináriumok felvételei elérhetők a portálon. Ily módon több óra kerül megrendezésre egymás után. A végén egy záró önálló munka és egy záró webinárium következik.

Időtartam: 2 hét

Mi ez a formátum:


Időtartam:16 akadémiai óra

Mi ez a formátum:A teljes idejű merítési tanfolyam egy olyan formátum, amely egyesíti a nappali képzés, a távoktatás és az egyéni képzés minden előnyét. Az órákat felszerelt tanteremben tartjuk, Ön önállóan tanulmányozza a tananyagot (lépésről lépésre videók), és műhelymunkákat végez. Ugyanakkor a hallgatóság sorában ott van egy tanár, aki bármikor készen áll a kérdések megválaszolására és a gyakorlati problémák megoldásában való segítségnyújtásra, illetve azok megvalósításának helyességének ellenőrzésére.
Előnyök – egyéni konzultáció a tanártól a kérdéseivel kapcsolatban, az anyag kitöltésének üteme személyesen Önnek megfelelő.
Mindez a tananyag elmélyültebb tanulmányozását teszi lehetővé.
Ezt a kurzust a munkahelyedről is el tudod venni, a tanár teljes jelenlétével ott, ahol a tanuló tartózkodik! Ha felkeltette érdeklődését ez a lehetőség, hívjon minket!

Időtartam:16 akadémiai óra



Kapcsolódó kiadványok