Բարեւ Ձեզ!
Մի քանի հոդվածներում ես կխոսեմ SoapUI-ի միջոցով փորձարկելու հնարավորությունների մասին, թե ինչպես են աշխատում 1C վեբ ծառայությունները: Ես կտամ նաև 1C փաստաթղթերից PDF ձևաչափով և բարդ xml ֆայլերով վերադառնալու օրինակներ։ Որոշ բաներ նման են այստեղ, բայց ես կանդրադառնամ վեբ ծառայությունների հետ աշխատելու ավելի բարդ օրինակներին: Բայց նախ, ես քայլ առ քայլ կուղեկցեմ ձեզ վեբ ծառայություններ սկսելու և SoapUI-ի հետ աշխատելու գործընթացով, որպեսզի ավելի հեշտ լինի պարզել, թե ինչպես են դրանք աշխատում զրոյից:
1. Պարզ վեբ ծառայություն
Սկսենք, եկեք վերցնենք կմախքի կոնֆիգուրացիա առանց վեբ ծառայությունների և քայլ առ քայլ քայլենք դրանց ստեղծման գործընթացում:
Եկեք ավելացնենք նոր վեբ ծառայություն, որը կոչվում է test1 և դրանում ստեղծենք hello օպերացիա՝ տողի վերադարձի տեսակով: Վեբ ծառայությունների և գործառնությունների անվանումները միշտ պետք է դրվեն լատիներեն:
Դուք նաև պետք է սահմանեք անվանատարածքի URI և հրապարակման ֆայլի անունը.
«Ընթացակարգի անվանումը» դաշտում խոշորացույցի վրա սեղմելիս կբացվի վեբ ծառայության մոդուլը, և դուք կարող եք իրականացնել «Hello» գործառույթը:
hello() ֆունկցիան վերադարձնում է «string from web service 1s»; EndFunctions
2. Վեբ ծառայության հրապարակում։
Այժմ, որպեսզի ստացված ֆունկցիան հասանելի լինի http-ի միջոցով, մենք պետք է հրապարակենք մեր ծառայությունը վեբ սերվերի վրա: Apache 2.2-ը հարմար է դրա համար: Ես կարդացի հոդվածներ այն մասին, թե ինչպես կարող եք կարգավորել աշխատանքը IIS-ի հետ, և ինձ թվում էր, որ դա շատ ավելի դժվար է: Apache 2.2-ը տեղադրելուց և գործարկելուց հետո դուք պետք է գնաք մենյու Administration - Publishing վեբ սերվերի վրա: «տեղեկատու» դաշտը պետք է լրացվի և պարունակի Apache-ի տեղադրման գրացուցակը: Հիշեք վեբ ծառայության «անուն» և «հասցե» դաշտերը, դրանք մեզ օգտակար կլինեն հաջորդ քայլում։
3. Փորձարկում SoapUI-ով
Փորձարկման համար եկեք ստեղծենք առանձին WsUser օգտատեր՝ պարզ գաղտնաբառով և նրան լիարժեք իրավունքներ տանք։
Դրանից հետո տեղադրեք և գործարկեք SoapUI: Այս ծրագիրը շատ հարմար է վեբ ծառայությունների փորձարկման համար, այն կարող է ստանալ դրանց նկարագրությունը և կատարել հետհարցումներ ծառայություններին։
Մենք գնում ենք մենյու File - New SOAP project, սահմանում ենք նախագծի անունը hellotest և Initial WSDL դաշտում գրում ենք հետևյալ հղումը.
http://localhost/test_ws/ws/test1.1cws?wsdl
Դրանում «test_ws» մասը նշված էր վերջին փուլում «անուն» դաշտում, իսկ test1.1cws «հասցե» դաշտում։
Սեղմեք OK և այս փուլում դուք պետք է մուտք գործեք՝ մուտք գործելով WsUser թեստային օգտվողի տակ: Կստեղծվի նախագիծ և երկու պարտադիր տարր:
Soap12Binding-ը տարբերվում է նրանով, որ այն աշխատում է նոր տարբերակ SOAP 1.2 ստանդարտ. Եկեք բացենք Request1 տարրը test1Soap12Binding-ում և տեսնենք սա.
SoapUI-ն ցույց է տալիս, թե ինչ xml կփոխանցվի մեր ֆունկցիային: Նախքան թեստը գործարկելը, կա ևս մեկ նրբերանգ, լռելյայնորեն SoapUI-ը թույլտվություն կպահանջի յուրաքանչյուր առանձին Request տարրի համար: Հետևաբար, ամեն անգամ այն չկարգավորելու համար հարկավոր է աջ սեղմել testSoap12Binding-ի վրա, ընտրել Ցուցադրել ինտերֆեյսի տեսքը և բացվող պատուհանում «Ծառայության վերջնակետ» ներդիրում սահմանել վեբ ծառայությունների օգտագործողի անունը և գաղտնաբառը.
Եթե դա արված չէ, ապա յուրաքանչյուր Հարցման համար պետք է սահմանեք թույլտվություն, ներքևի վահանակում սեղմեք «Auth» կոճակը:
Այժմ մենք կարող ենք վերջապես հարցում կատարել hello ֆունկցիային և տեսնել պատասխանը.
Հիանալի, ամեն ինչ աշխատեց:
4. Պարզ պարամետրերի փոխանցում գործառույթին:
Հիմա եկեք անենք նոր առանձնահատկությունպարամետրերով, օրինակ, մենք կստուգենք աշխատանքը ամսաթվերով, կդարձնենք getSaleDocNumbersByDate ֆունկցիան, որը կընդունի փաստաթղթի (հաշիվ-ապրանքագրի) ամսաթիվը և կվերադարձնի այս ամսաթվի փաստաթղթերի համարները որպես տող։ Գործողությանը ավելացնենք ամսաթիվը պարամետրը dateTime տեսակի հետ.
կոդը այսպիսին է.
getSaleDocNumbersByDate(ամսաթիվ) ֆունկցիա //StartDate = StartDay(ամսաթիվ); ավարտի ամսաթիվ = endDay (ամսաթիվ); Փաստաթղթերի ընտրություն = փաստաթղթեր.Ծախսեր.Ընտրեք(Սկիզբի ամսաթիվ, ավարտի ամսաթիվ); համարներ=""; իսկ Փաստաթղթերի ընտրություն.Հաջորդ() թվային հանգույց = թվեր+"#"+Փաստաթղթերի ընտրություն.Թիվ+";"; ցիկլի ավարտ; համարի վերադարձ; EndFunctions
Այժմ SoapUI-ում աջ սեղմեք testSoap12Binding տարրի վրա և ընտրեք «Թարմացնել սահմանումը»: Դրանից հետո նախագծում կհայտնվի getSaleDocNumbersByDate ֆունկցիան և դրա համար պատրաստի հարցումը։ Ամսաթիվը լրացնելու համար դուք պետք է օգտագործեք «ՏՏՏՏ-ՄՄ-ՕՕՏժ:մմ:սս» ձևաչափը (կարող եք նայել w3schools-ը և ԽԻՍՏ խորհուրդ տալ օգտագործել այս կայքը՝ հասկանալու համար, թե ինչպես աշխատել xml-ի հետ):
Այնուհետև մենք ստանում ենք հետևյալ հարցումը և պատասխանը.
5. XDTO փաթեթներ
Եթե անհրաժեշտ է ավելի բարդ պարամետրեր փոխանցել ֆունկցիաներին (օրինակ՝ xml մի քանի դաշտերով), կամ ի պատասխան ստանալ բարդ xml, ապա մենք չենք կարող անել առանց XDTO փաթեթների։
XDTO-ի հետ աշխատանքը մանրամասնորեն քննարկվում է մի շարք հոդվածներում: Փաստորեն, փաթեթը սահմանում է xml ֆայլերում օգտագործվող դաշտերի կառուցվածքը և տեսակը:
Ես կքննարկեմ xml ֆայլ փոխանցելու և ստանալու օրինակ, որի տեսակը սահմանված է փաթեթում
Եվ նաև հետևյալ հոդվածներում ես կքննարկեմ օրինակներ.
- փոխանցեք 1s xml ֆայլ, որը նկարագրված չէ փաթեթում base64 ձևաչափով
- 1-ից ստանալ pdf փաստաթուղթ base64 ձևաչափով և վերծանել այն
- ստանալ 1s xml-ֆայլից՝ տարրերի ներդիր կառուցվածքով և որոշել դրանց թիվը
6. Փոխանցել 1-ին xml ֆայլի պարամետրում, որի տեսակը սահմանված է փաթեթում։
Առաջադրանքը լինելու է հետևյալը՝ գտնել հաշիվ-ապրանքագրի փաստաթուղթը մուտքային xml-ում նշված համարով և ամսաթվով և վերադարձնել գտնված փաստաթուղթը։ Այն պետք է վերադարձվի նաև xml-ի տեսքով՝ նշելով համարը, ամսաթիվը, կոնտրագենտը և դրա ծածկագիրը և ապրանքի աղյուսակային մասը:
Եկեք ստեղծենք փաթեթ packet1 packet1_ns անվանատարածքով: Մուտքային xml ֆայլի համար եկեք սահմանենք InDocSaleQuery օբյեկտի տեսակը տողի տեսակի թվային դաշտով և dateTime տեսակի ամսաթվի դաշտով։ Ելքային ֆայլի համար նախ սահմանենք արտադրանքի աղյուսակային մասի մեկ տողի տեսակը՝ SaleItem՝ տողի տեսակի, գնի գումարի և տասնորդական տիպի դաշտերի անվանումով: Իսկ SaleDoc փաստաթուղթն ինքնին լինելու է կոմպոզիտային տիպի` համարը, ամսաթիվը, partnerName դաշտերը և SaleItems դաշտը, որը կունենա SaleItem տեսակը և առավելագույն թիվը -1: Հենց այս դաշտը նշանակում է, որ այն կարող է պարունակել մի քանի տարրերից բաղկացած զանգված։ Ահա թե ինչ տեսք ունի կազմաձևում.
Սկզբում ես կցուցադրեմ ֆունկցիայի կոդը, և միայն դրանից հետո կբացատրեմ, թե ինչ է տեղի ունենում
Կոդը՝
ֆունկցիան getSaleDoc(incomingXML)DocNumber = incomingXML.number; DateDoc = incomingXML.date; հարցում = նոր հարցում; query.Text = "Ընտրել | ConsumableItems.Nomenclature.Name as name, | ConsumableProducts.Price as price, | ConsumableProducts.Quantity as quantity, | ConsumableProducts.Amount assum, | ConsumableProducts.Reference |FROM | Document.ProductsAconsumable. |WHERE | ConsumableProducts.Reference.Number = &Number | And ConsumableProducts.Reference.Date = &DateDoc"; query.SetParameter("Number",docnumber); query.SetParameter ("DateDoc",DateDoc); fetch = query.Execute().Select(); եթե fetch.Quantity()=0 ապա //վերադարձրեք սխալDocumentType = FactoryXDTO.Type("packet1_ns", "SaleDoc"); DocumentPackage = XDTO Factory.Create(DocumentType); DocumentPackage.number = "Փաստաթղթեր չեն գտնվել!"; Վերադարձի փաթեթի փաստաթուղթ; հակառակ դեպքում //ստեղծել տեսակներDocumentType = FactoryXDTO.Type("packet1_ns", "SaleDoc"); TablePartType = XDTO Factory.Type ("packet1_ns", "SaleItem"); DocumentPackage = XDTO Factory.Create(DocumentType); //ընտրել աղյուսակային մասից sch=0; մինչև ընտրությունը.Հաջորդ() հանգույց, եթե cn=0 ապա //լրացրեք փաստաթղթի մանրամասները doc = selection.link; DocumentPackage.number = document.number; DocumentPackage.date = doc.Date; DocumentPackage.partnerName = string (doc.Account); endif; //Լրացրեք աղյուսակը partTablePartPackage = XDTO Factory.Create(TablePartType); FillPropertyValues (TablePartPackage, ընտրություն); //ավելացրեք այն documentDocumentPackage.SaleItems.Add(TablePartPackage); cn=cn+1; ցիկլի ավարտ; Վերադարձի փաթեթի փաստաթուղթ; endif; EndFunctions
Այստեղ երկու հիմնական կետ կա. Նախ. քանի որ incomingXML մուտքային պարամետրի տեսակը սահմանվել է և այս տեսակը հայտարարվել է փաթեթում, անմիջապես հնարավոր է մուտք գործել այս մուտքային xml-ի դաշտերը: Երկրորդ. աշխատել XDTO գործարանի հետ: Դրանից ստացվեց ստացված ելքային պարամետրերի տեսակը և ստեղծվեց այս տեսակի XDTOValue, որում լրացվեցին անհրաժեշտ դաշտերը։ Հարկ է նաև նշել, որ SaleDoc տիպի դեպքում պետք է մուտքագրել սխալի առանձին դաշտ, սակայն թեստավորման նպատակով սխալները կգրանցվեն թվի դաշտում։
Ահա թե ինչպիսին է այս հարցման արդյունքը SoapUI-ում.
Ինչպես տեսնում եք, ամեն ինչ աշխատում է, բայց դեռ ինչ-որ բան կա բարելավելու, օրինակ, ես կցանկանայի իմանալ, թե քանի SaleItems տարրեր ունենք փաստաթղթում:
Այս և ավելի բարդ օրինակների մասին կխոսեմ հաջորդ հոդվածում։
Կից արխիվում՝ բեռնաթափել ինֆոբազը և SoapUI նախագիծը։
Օգտագործելով վեբ ծառայությունների վավերացման գործիքը WSDL-ի և SOAP-ի համար
Ըստ երևույթին, նոր տեխնոլոգիաների և ստանդարտների հայտնվելով, ինչպիսիք են XML-ը և HTTP-ն, վեբ ծառայություններն ապահովել են իրենց տեղը ինտերնետի նորարարության պանթեոնում: Բայց ինչպե՞ս հայտնվեց այս նորամուծությունը:
Վեբ ծառայությունների հիմնական հայեցակարգը կարելի է գտնել ԱՄՆ-ում մինչև 1960-ականների կեսերը: Տրանսպորտային ոլորտում, օրինակ, երկաթուղային և նավագնացության ընկերություններում, նոր հայեցակարգԷլեկտրոնային տվյալների փոխանակում համակարգիչների միջև, որը հետագայում վերածվեց EDI տեխնոլոգիայի (Electronic Data Interchange - էլեկտրոնային տվյալների փոխանակում): Ես առաջին անգամ լսել եմ EDI-ի մասին բիզնես դպրոցի պրոֆեսորից 1980 թվականին:
1996թ.-ին ԱՄՆ Ստանդարտների և տեխնոլոգիաների ազգային ինստիտուտը հայտարարեց EDI-ի չափանիշը Դաշնային տեղեկատվության մշակման ստանդարտների հրապարակումներում (FIPS PUB 161-2): Համաձայն հրապարակված ճշգրտման՝ EDI-ն համակարգիչների միջև խիստ ձևաչափված հաղորդագրությունների փոխանակման ստանդարտ է։ Ստացված հաղորդագրությունների մշակումն իրականացվում է միայն համակարգչի միջոցով, և այդ հաղորդագրությունները սովորաբար նախատեսված չեն մարդու մեկնաբանության համար։ Դա հենց այն է, ինչ անում են վեբ ծառայությունները, բացառությամբ, որ 1960-ականների կեսերին XML-ը, ինտերնետը և համաշխարհային ցանցը գոյություն չունեին:
Նրանց համար, ովքեր այնքան էլ ծանոթ չեն վեբ ծառայություններին, ես համառոտ կանդրադառնամ վեբ ծառայությունների սահմանումներին և հիմնական բաղադրիչներին:
Ինչ են վեբ ծառայությունները
Վեբ ծառայությունը ծրագրային համակարգ է, որը նախատեսված է ցանցի միջոցով համակարգչային ռեսուրսների միջև մեքենա-մեքենա փոխազդեցություններին աջակցելու համար և օգտագործում է SOAP (Simple Object Access Protocol) հաղորդագրությունները, որոնք սահմանված են Համաշխարհային ցանցի կոնսորցիումի կողմից:
Simple Object Access Protocol-ը (SOAP) պարզ, ընդարձակելի արձանագրություն է կառուցվածքային և տպագրված հաղորդագրությունների փոխանակման համար ապակենտրոնացված, բաշխված ցանցային միջավայրում: SOAP հաղորդագրությունները գրված են Extensible Markup Language (XML) ձևաչափով, որը պարզ և ճկուն տեքստային ձևաչափ է, որը բխում է Ստանդարտացման միջազգային կազմակերպության կողմից մշակված Ստանդարտ ընդհանրացված նշման լեզվից (SGML) (ISO 8879:1986):
Վեբ ծառայությունների նկարագրության լեզուն (WSDL) XML-ի վրա հիմնված լեզու է, որը նկարագրում է վեբ ծառայությունների միջերեսը:
Ի՞նչ է տեղի ունենում, երբ սխալ SOAP հաղորդագրություններ են փոխանակվում: Ի՞նչ կլիներ, եթե սխալ SOAP հաղորդագրությունը մշակվեր առանց նախազգուշացման և նույնիսկ օգտագործվեր որոշումներ կայացնելու մասին տեղեկատվություն ստեղծելու համար:
Գործնականում անհնար է ասել, թե արդյոք SOAP հաղորդագրության տվյալները ճիշտ են, թե ոչ: Այնուամենայնիվ, դուք կարող եք վավերացնել SOAP հաղորդագրությունը վավերականության համար՝ նայելով դրա ինտերֆեյսի սահմանմանը կամ WSDL-ին:
AT իրական կյանք SOAP հաղորդագրություններում վրիպազերծման խնդիրները շատ դժվար է: Եթե SOAP հաղորդագրության մեջ սխալ կա, 500 HTTP պատասխանի կոդը ստացվում է վեբ ծառայությունների սերվերից: Վեբ ծառայությունների սերվերները մանրամասն տեղեկատվություն չեն տրամադրում այն մասին, թե SOAP հաղորդագրության որ մասում խնդիր կա: Դուք կարող եք բախվել նույնիսկ ավելի վատ իրավիճակի, երբ վավեր SOAP պատասխանները ստացվում են Վեբ ծառայությունների սերվերից՝ առանց սխալի հաղորդագրությունների, և ոչ դուք, ոչ էլ ձեր վեբ ծառայությունների սերվերները չեն կարող հասկանալ ձեր SOAP հարցումների և պատասխանների խնդիրները: Օրինակ, դուք ցանկանում էիք հարցնել B ընկերության ընթացիկ բաժնետոմսերի գինը, սակայն SOAP հաղորդագրություն ուղարկեցիք սխալ գրված պիտակներով վեբ ծառայությունների սերվերին: Վեբ ծառայությունների սերվերը կարող է անտեսել վատ պիտակները և SOAP-ի պատասխան հաղորդագրության մեջ տրամադրել լռելյայն արժեք, օրինակ՝ A ընկերության բաժնետոմսերի արժեքը: Եթե դա աննկատ մնա, հետևանքները կարող են աղետալի լինել:
Այս տեսակի խնդիրները կարելի է վաղաժամ կանխել WSDL-ի և SOAP-ի համար Web Services Validation Tool-ի միջոցով: Այն թույլ է տալիս վավերացնել SOAP հաղորդագրությունները՝ օգտագործելով Web Service Definition Language (WSDL) նախքան վեբ ծառայությունն օգտագործող հավելվածները տեղակայելը: Ծրագիրը վերլուծում է ձեր SOAP հաղորդագրությունների շարահյուսությունն ու ճշգրտությունը WSDL-ով և մատնանշում խնդիրները՝ մանրամասնորեն հաղորդելով սխալների և տողերի համարների մասին: Արդյունքում, դուք այլևս չեք ստանում նյարդայնացնող HTTP 500 հաղորդագրություններ: Ձեր SOAP հաղորդագրությունները կոդավորված են: Ոչ մի խնդիր. Ծրագիրը կվերծանի դրանք և կստուգի ձեզ համար վերծանված SOAP հաղորդագրությունների ճիշտությունը:
Այս ծրագիրը ստեղծվել է, որպեսզի օգնի IBM Web Services-ի աջակցող անձնակազմին լուծել IBM® WebSphere Application Server-ի վեբ ծառայությունների հետ կապված խնդիրները, որոնք հաղորդվում են հաճախորդների կողմից ամբողջ աշխարհում: Ծրագիրը նախատեսված է SOAP հաղորդագրությունների ճշգրտությունը ստուգելու համար: Եթե SOAP հաղորդագրությունն ունի թվային ստորագրություն, ծրագիրը նույնպես կստուգի այն: WSDL-ի և SOAP-ի համար Web Services Validation Tool-ի միջոցով դուք կարող եք նույնիսկ ուղարկել SOAP հաղորդագրություններ վեբ ծառայությունների սերվերներին և ստանալ SOAP պատասխան հաղորդագրություններ: Ծրագիրը ստեղծվել է արդյունաբերական շահագործման հետ կապված խնդիրները վերացնելու համար՝ օգտագործելով այն վաղ փուլերըմշակում, ինչպես նաև շահագործման ընթացքում ծագած խնդիրների լուծման ժամանակը կրճատելու նպատակով։
Մենք կստեղծենք շատ պարզ վեբ ծառայություն: Մենք նախ կստեղծենք պարզ Java™ հավելված: Java հավելվածը փորձարկելուց հետո մենք օգտագործում ենք IBM Rational® Application Developer WebSphere® Software-ի համար՝ վեբ ծառայություն ստեղծելու համար: Այնուհետև մենք որոշ փոփոխություններ կկատարենք ստեղծված վեբ ծառայության մեջ: Վերջապես, մենք օգտագործում ենք Web Services Validation Tool-ը WSDL-ի և SOAP-ի համար՝ SOAP հաղորդագրություններ ստեղծելու, վավերացնելու, ուղարկելու և ստանալու համար:
Պարզ վեբ ծառայություն կարող է ստեղծվել WebSphere Software-ի համար IBM Rational Application Developer-ի միջոցով: Վեբ ծառայությունները կարող են ստեղծվել երկու եղանակով.
- Վերևից վար մշակում Զարգացում, որտեղ Java դասերը, որոնք իրականացնում են վեբ ծառայություններ, ստեղծվում են WSDL-ից:
- Ներքևից վեր մշակում, որի դեպքում վեբ ծառայությունը ստեղծվում է Java bean-ից կամ ձեռնարկության Java bean-ից:
Հետևյալ օրինակում մենք կիրականացնենք վեբ ծառայություն՝ օգտագործելով ներքևից վեր մշակման մեթոդը: Նախ, մենք կստեղծենք պարզ Java հավելված: Այնուհետև մենք կստեղծենք Java Bean Web ծառայություն Java հավելվածից՝ օգտագործելով IBM Rational Application Developer for WebSphere Software ծրագիրը:
Java հավելվածի ստեղծում
Նախ, մենք կստեղծենք Java հավելված, որը թողարկում է ողջույններ: Եթե անուն չտրամադրվի, հավելվածը կվերադարձնի «Բարև, ընկեր»: Եթե անուն է տրվում, հավելվածը կվերադարձնի «Բարև» տեքստը, որին հաջորդում է այդ անունը: Ստորև ներկայացված է DemoWebService Java հավելվածի կոդը, որը գտնվում է ցուցադրական փաթեթում: Hello() մեթոդը վերադարձնում է տող՝ կախված անունից։
Ցուցակում 1. DemoWebService.java
/* * @հեղինակ՝ Jinwoo Hwang * Հեղինակային իրավունք 2010 IBM Corporation */ փաթեթի ցուցադրություն; հանրային դասի DemoWebService ( public String hello (String name) (եթե (անուն == null) վերադարձրեք «Բարև, ընկեր», այլապես վերադարձեք «Բարև, « + անուն + «!»; )Java հավելվածի փորձարկում
Շատ կարևոր է ստուգել Java հավելվածը, նախքան դրանից վեբ ծառայություն ստեղծելը: Հավելվածը սկսելու համար կարող եք դաս գրել main() մեթոդով: Դուք կարող եք նաև օգտագործել IBM Rational Application Developer v7-ի կողմից տրամադրված Universal Test Client գործառույթը՝ արագ փորձարկելու համար՝ առանց թեստային կոդ գրելու: Պարզապես ընտրեք Universal Test Client Java դասի համատեքստային ընտրացանկից՝ Test Client-ը գործարկելու համար:
- Universal Test Client-ում ընդլայնել Օբյեկտներ > DemoWebService.
- Ընտրեք մեթոդ Բարեւ Ձեզ.
- Մուտքագրեք տողը կամ ձեր անունը դաշտում արժեքըև սեղմեք կոճակը Կանչել.
Կարող եք նաև փորձարկել null պարամետրով և տեսնել, թե ինչ է տեղի ունենում: Եթե null-ը փոխանցվում է hello() մեթոդին, «Բարև, բարեկամ!» տողը կվերադարձվի, ինչպես և սպասվում էր:
Վեբ ծառայության ստեղծում
Առայժմ ամեն ինչ լավ է աշխատում։ Եկեք սկսենք վեբ ծառայություն ստեղծել Java դասից՝ օգտագործելով վեբ ծառայության ներքևից վերև մշակման մեթոդը:
- Ընտրեք Java հավելվածը DemoWebService և ստեղծեք նոր վեբ ծառայություն IBM Rational Application Developer-ից:
- Քանի որ մենք ստեղծել ենք Java դաս, ընտրեք Ներքևից վեր Java Bean վեբ ծառայությունվեբ ծառայության տեսակների ցանկում: Ընտրել սկսել հաճախորդըև սեղմեք կոճակը Ավարտել. Եթե մենք ունենայինք EJB դաս, մենք կարող էինք նաև գրել EJB (Java Enterprise bean)՝ վեբ ծառայություն ստեղծելու համար:
Եթե ամեն ինչ լավ ընթանա, դուք կտեսնեք ստեղծված DemoWebServiceDelegate.java-ն Java Resources-ում DemoWebService.java-ի կողքին:
DemoWebServiceDelegate.java-ին նայելիս կարող եք գտնել @javax.jws.WebService Java վեբ ծառայության ծանոթագրությունը, որը նշում է targetNamespace-ը, serviceName-ը և portName-ը DemoWebServiceDelegate դասում: DemoWebService-ի օրինակ է ստեղծվում, իսկ DemoWebService-ի hello() մեթոդից ստեղծվում է մեկ այլ hello() մեթոդ: Եթե ցանկանում եք ավելին իմանալ Java վեբ ծառայության ծանոթագրությունների մասին, տես Java Specification Request (JSR) 181, Web Services Metadata for Java Platform:
Ցուցակում 2. DemoWebServiceDelegate.java
/* * @հեղինակ՝ Jinwoo Hwang * Հեղինակային իրավունք 2010 IBM Corporation */ փաթեթի ցուցադրություն; @javax.jws.WebService(targetNamespace = "http://demo/", serviceName = "DemoWebServiceService", portName = "DemoWebServicePort") հանրային դասի DemoWebServiceDelegate ( demo.DemoWebService _demoWebService (ՀանրայինՎեբՍերվիս (նոր Սերվիս); Տողերի անուն) ( return _demoWebService.hello(name); ) )WSDL-ի ստեղծում
Հաճախորդի ծրագրի նախագծում դուք կարող եք նաև պարզել, որ ստեղծվել են DemoWebServiceService.wsdl և DemoWebService_schema1.xsd ֆայլերը: DemoWebServiceService.wsdl-ը պարունակում է տեղեկատվություն Web Service Definition Language-ում, որը նկարագրում է ցանցային ծառայությունները Java հավելվածի համար, որը դուք ստեղծել եք ավելի վաղ: DemoWebServiceService_schema1.xsd-ը պարունակում է XML սխեման, որը նկարագրում է SOAP հաղորդագրություններում օգտագործվող տվյալների տեսակների կառուցվածքը:
DemoWebServiceService.wsdl ֆայլը դիտելիս կարող եք տեսնել, որ այն իր արմատում ունի սահմանումների մի շարք տարր: Սահմանումների տարրում կա 6 տարր.
- տեսակներ (տեսակներ);
- հաղորդագրություն (հաղորդագրություն);
- portType (պորտի տեսակը);
- պարտադիր (պարտադիր);
- ծառայություն (ծառայություն);
- նավահանգիստ (նավահանգիստ):
տեսակներըսահմանում է հաղորդագրությունների փոխանակման համար օգտագործվող տվյալների տեսակները: DemoWebServiceService.wsdl-ում մենք ներմուծում ենք DemoWebServiceService_schema1.xsd՝ WSDL ֆայլում տվյալների տեսակները սահմանելու փոխարեն:
հաղորդագրությունսահմանում է փոխանակման ենթակա հաղորդագրությունները: Մենք ունենք 2 հաղորդագրություն՝ «բարև» և «բարև արձագանք»: Ողջույնի հաղորդագրությունն ունի մի մաս, որը կոչվում է «պարամետրեր»: Այս մասն ունի «tns:hello» տարր: HelloResponse հաղորդագրությունն ունի «պարամետրեր» կոչվող մաս, որը նույնն է, ինչ բարևը: Այս մասն ունի «tns:helloResponse» տարր: hello և helloResponse տարրերը սահմանված են DemoWebServiceService_schema1.xsd ֆայլում: Մենք շուտով կվերանայենք դրանք:
Նավահանգստի տեսակը- Գործողություններ, որոնք աջակցվում են վերջնակետերով: Յուրաքանչյուր գործողություն ապահովում է մուտքային և ելքային հաղորդագրություն: Մեր «բարև» գործողությունը բաղկացած է «tns:hello» մուտքային հաղորդագրությունից և «tns:helloResponse» ելքային հաղորդագրությունից: Այս գործողությունները համապատասխանում են հարցում-պատասխան փոխանակմանը: WSDL-ն տրամադրում է 4 տարբեր վերջնակետի փոխանակման պրիմիտիվներ.
- միակողմանի (միակողմանի);
- հարցում-պատասխան (խնդրանք-պատասխան);
- խնդրանք-պատասխան (պահանջ-պատասխան);
- ծանուցում (ծանուցում).
Միակողմանի փոխանակման դեպքում վերջնակետը ստանում է միայն հաղորդագրությունը: Հարցում-պատասխան փոխանակման դեպքում վերջնակետը ստանում է հաղորդագրություն և ուղարկում համապատասխան հաղորդագրություն: Հարցում-պատասխան փոխանակման դեպքում վերջնակետը ուղարկում է հաղորդագրություն և ստանում համապատասխան հաղորդագրություն: Ծանուցումների փոխանակման դեպքում վերջնակետը միայն հաղորդագրություն է ուղարկում:
Պարտադիրսահմանում է արձանագրության մանրամասները և հաղորդագրության ձևաչափի առանձնահատկությունները պորտի տեսակի կողմից նշված գործողությունների և հաղորդագրությունների համար: Style հատկանիշի համար մենք օգտագործում ենք արժեքի փաստաթուղթը: Style հատկանիշը ապահովում է 2 տարբեր ոճհաղորդագրություններ՝ rpc և փաստաթուղթ: Rpc ոճով հաղորդագրությունները պարունակում են պարամետրեր և վերադարձնող արժեքներ: Փաստաթղթի ոճով հաղորդագրությունները պարունակում են փաստաթղթեր: Transport հատկանիշը սահմանում է URI-ը SOAP-ի փոխադրման համար: Նշված http://schemas.xmlsoap.org/soap/http արժեքը նշանակում է, որ SOAP հատկորոշումը կօգտագործի HTTP կապ: SOAPAction HTTP վերնագրի URI-ը SOAP HTTP կապի համար նշված է soapAction հատկանիշում: Քանի որ օգտագործվում է SOAP HTTP binding, soapAction հատկանիշի արժեքը պահանջվում է: soapAction հատկանիշի համար մենք օգտագործում ենք «» դատարկ տողը: Soap:body տարրը սահմանում է, թե ինչպես են հաղորդագրության մասերը հավաքվում SOAP հաղորդագրության մարմնի տարրում: Use հատկանիշը ապահովում է 2 տարբեր տարբերակներբառացի (բառացի) և կոդավորված (կոդավորված): Մենք օգտագործում ենք բառացի. Սա նշանակում է, որ մենք ընտրել ենք սահմանումը կոնկրետ սխեմա, օգտագործելով կամ տեսակի հատկանիշը կամ տարրը: Կոդավորված տարբերակն օգտագործում է վերացական տեսակ՝ կոդավորման կանոններով։
Ծառայությունսահմանում է օգտագործվող նավահանգիստների հավաքածուն:
նավահանգիստսահմանում է կապի վերջնակետը՝ նշելով ցանցի հասցեն, որին պետք է կապվի:
ցանցի հասցեն կապելու համար: Մեր դեպքում, SOAP-ի վերջնակետի հասցեն է՝ http://localhost:9081/HelloWorldWSProject/DemoWebServiceService:
Ցուցակ 3. DemoWebServiceService.wsdl
Սխեմայի ստեղծում
Մենք ներմուծում ենք DemoWebServiceService_schema1.xsd DemoWebServiceService.wsdl-ից: Դիտարկենք DemoWebServiceService_schema1.xsd ֆայլը: Այն գրված է XML Schema-ի սահմանման լեզվով` նկարագրելու XML փաստաթղթերի բովանդակության կառուցվածքն ու սահմանափակումները: Մենք ունենք 2 տարր՝ hello և helloResponse: Յուրաքանչյուր տարր ունի իր տեսակը. Hello տեսակն ունի «arg0» տարր, որը տող է: «arg0» տարրը պարտադիր չէ, քանի որ դրա հայտարարագրում minOccurs հատկանիշի արժեքը 0 է: Եթե minOccurs հատկանիշը սահմանված է 1 կամ ավելի, տարրը պետք է նշվի: Նույնը վերաբերում է helloResponse տեսակի «վերադարձի» տարրին:
Ցուցակ 4. DemoWebServiceService_schema1.xsd
Ինչպես սկսել WSDL-ի և SOAP-ի համար վեբ ծառայությունների վավերացման գործիքի հետ
Այսպիսով, մենք լուսաբանել ենք WSDL-ն և սխեման: Եկեք գործարկենք Վեբ ծառայությունների սերվերը, որպեսզի կարողանանք կանչել վեբ ծառայությունը Web Services Validation Tool-ից WSDL-ի և SOAP-ի համար:
WSDL-ի և SOAP-ի համար Web Services Validation Tool-ը գործարկելու համար ձեզ հարկավոր է Java 6 (կամ ավելի բարձր) գործարկման միջավայր և XML թվայնացնող և վերծանող API-ներ, որոնք համապատասխանում են Համաշխարհային ցանցի կոնսորցիումի «XML ծածկագրման շարահյուսություն և մշակում» բնութագրերին (http:// www. w3.org/TR/xmlenc-core/):
IBM Java 6-ն ապահովում է JSR 106. XML թվային գաղտնագրման API-ների ներդրում: Եթե դուք տեղադրել եք IBM համակարգ Java 6-ը նշանակում է, որ ամեն ինչ պատրաստ է, և դուք այլ բան տեղադրելու կարիք չունեք:
Եթե ձեր Java 6 գործարկման միջավայրը, ինչպիսին է Sun Microsystems™ Java 6-ը, չունի XML թվային գաղտնագրման API, դուք պետք է տեղադրեք գրադարաններ, որոնք ներդրում են JSR 106 կամ Apache™ XML Security տարբերակ 1.4.3 փաթեթը, որը կարելի է ներբեռնել http: //santuario.apache.org/. Պարզապես ներբեռնեք երկուական բաշխումը, բացեք այն գրացուցակի մեջ և ասեք գործիքին, որտեղ այդ գրացուցակը օգտագործում է -vmargs և -DAXS հրամանի տող տարբերակները:
Այս գրելու պահին Վեբ ծառայությունների վավերացման գործիքը WSDL-ի և SOAP-ի համար աջակցում է JSR 106 և Apache XML Security 1.4.3 տարբերակը XML թվային գաղտնագրման և ապակոդավորման համար: Եթե ցանկանում եք ստուգել թվային ստորագրությունները SOAP հաղորդագրություններում, ձեզ անհրաժեշտ են գրադարաններ, որոնք ներդնում են JSR 105: XML Digital Signature API-ներ: Բարեբախտաբար, Java 6 վիրտուալ մեքենաները Sun Microsystems-ից և IBM-ից ապահովում են JSR 105-ի իրականացում: Ահա թե ինչու Java 6-ն ընտրվեց որպես Java-ի գործարկման միջավայրի նվազագույն պահանջ: Եթե ձեր Java 6 միջավայրը չի տրամադրում գրադարաններ, որոնք իրականացնում են JSR 105, դուք պետք է գտնեք դրանք:
WSDL-ի և SOAP-ի համար Web Services Validation Tool-ը կարելի է անվճար ներբեռնել այստեղ: Դրա տեղադրումը շատ պարզ է. Փաթեթը բացեք գրացուցակի մեջ և գործարկեք wsvt.exe: Եթե ձեր վիրտուալ մեքենա Java-ն լռելյայն Java 6 միջավայր չէ, որն աջակցում է XML թվային ստորագրություններին և թվային գաղտնագրմանը և վերծանմանը, դուք պետք է նշեք Java 6-ի գտնվելու վայրը -vm տարբերակով, օրինակ.
wsvt -vm c:\IBMjava6\bin\java.exe
Կրկին, եթե ունեք IBM Java 6, ապա ձեզ հարկավոր չէ որևէ այլ բան տեղադրել: Այն ամենը, ինչ ձեզ հարկավոր է, արդեն ներառված է IBM Java 6-ում: Sun Microsystems-ից Java 6-ն օգտագործելիս դուք պետք է ծրագրին տեղեկացնեք Apache XML Security-ի գտնվելու վայրը՝ կոդավորված SOAP հաղորդագրությունները վերծանելու համար:
Օրինակ, հետևյալ հրամանը կգործարկի ծրագիր Sun Java 6-ով և Apache XML Security գրադարանի 1.4.3 տարբերակով, որը գտնվում է C:\xml-security-1_4_3\libs գրացուցակում:
wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs
Ստորև ներկայացված է Apache XML անվտանգության գրադարանի ֆայլերի ցանկը, որոնք իրականում օգտագործվում են Web Services Validation Tool-ի կողմից WSDL-ի և SOAP-ի համար, թեև Apache XML անվտանգության 1.4.3 տարբերակը առաքվում է 9 բանկաներով.
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.
WSDL-ի և SOAP-ի համար Web Services Validation Tool-ի MANIFEST.MF-ը պարունակում է հետևյալ տեղեկությունները.
Bundle-ActivationPolicy:ծույլ
Bundle-ClassPath: .,
արտաքին՝$AXS$/commons-logging.jar,
արտաքին՝$AXS$/serializer.jar,
արտաքին՝$AXS$/xalan.jar,
արտաքին՝$AXS$/xmlsec-1.4.3.jar
Ահա թե ինչու անհրաժեշտ էր նշել --vmargs --DAXS=C:\xml-security-1_4_3\libs, որպեսզի Sun Java 6-ը վերծաներ կոդավորված SOAP հաղորդագրությունները:
Ես բավական քիչ ժամանակ եմ ծախսել Sun Java Runtime Environment-ում, Apache XML Security-ում և Eclipse-ի որոշ պլագիններում հայտնաբերված XML-ի հետ կապված դասերի միջև դասերի բեռնման կոնֆլիկտների և անհամատեղելիությունների վերացման վրա: IBM Java-ի գործարկման ժամանակի միջավայրի ստեղծումը հեշտ էր, քանի որ այն առաքվում է JSR 106-ի ներդրմամբ և չի պահանջում Apache XML Security:
Ստեղծեք նախագիծ
Այժմ գործիքի ծրագիրը կարգավորելուց և գործարկելուց հետո կարող եք ստեղծել նոր նախագիծ. Նախագիծը կարող է պարունակել WSDL ֆայլ, բազմաթիվ սխեմայի ֆայլեր՝ կապված WSDL ֆայլի հետ և SOAP հաղորդագրություններ XML ֆայլերում: Եթե նախագիծն ունի բազմաթիվ WSDL ֆայլեր, դրանցից միայն մեկն է օգտագործվում, իսկ մյուսներն անտեսվում են SOAP հաղորդագրության XML ֆայլը վավերացնելիս: Մեկ այլ WSDL ֆայլ օգտագործելու համար դուք պետք է ստեղծեք առանձին նախագիծ: Յուրաքանչյուր SOAP հաղորդագրություն պետք է պարունակվի .xml ընդլայնմամբ ֆայլում, հակառակ դեպքում այն չի դիտարկվի որպես SOAP հաղորդագրություն:
- Աջ սեղմեք և ընտրեք Նոր > Նախագիծ.
- Ընտրել նախագիծըմեջ Գեներալ.
- Մուտքագրեք «Թեստային նախագիծ» դաշտում նախագծի անունև սեղմեք կոճակը Ավարտել.
Ներմուծեք WSDL և Schema
Մենք ստեղծել ենք «Թեստային նախագիծ»։ Այժմ դուք կարող եք ներմուծել WSDL և XSD դրա մեջ:
- Ընտրեք նախագիծը և այնուհետև համատեքստի ընտրացանկից ընտրեք Ներմուծում.
- Ընտրել Ֆայլային համակարգմեջ Գեներալ.
- Ընտրեք գրացուցակը, որտեղ պահվում են WSDL-ը և XSD-ը:
- Ընտրեք 2 ֆայլ (DemoWebServiceService.wsdl և DemoWebServiceService_schema1.xsd) և սեղմեք կոճակը Ավարտել.
WSDL-ի և սխեմաների ակնարկ
Այժմ մենք ունենք նախագիծ WSDL-ով և XSD-ով: Դուք կարող եք կրկնակի սեղմել մկնիկի ձախ կոճակի վրա WSDL-ի վրա՝ WSDL-ը Դիզայնի և Աղբյուրի ռեժիմում դիտելու համար: Դիզայնի ռեժիմում դուք կարող եք վեբ ծառայություն մատուցել մուտքերով և ելքերով:
Աղբյուրի ռեժիմում դուք կարող եք դիտել և խմբագրել WSDL-ը տեքստային խմբագրիչում:
Եթե XSD ֆայլերը հնարավոր չէ բացել XSD խմբագրիչում, ապա դրանք կարող են բացվել XML խմբագրիչում՝ ընտրելով Բացեք > XML խմբագրիչովայդ XSD ֆայլի համատեքստում:
Մենք բացել ենք DemoWebServiceService_schema1.xsd-ը XML խմբագրիչում:
SOAP հաղորդագրության ստեղծում
Այսպիսով, մենք ունենք WSDL և սխեման պատրաստ՝ վավերացնելու SOAP հաղորդագրությունները: Եկեք սկսենք փորձարկել Web Services Validation Tool-ը WSDL-ի և SOAP-ի համար SOAP հաղորդագրությամբ: Դուք պետք է ներառեք SOAP հաղորդագրությունը նախագծում: SOAP հաղորդագրությունը պետք է պարունակվի .xml ընդլայնմամբ ֆայլում, որպեսզի այն կարողանա վավերացվել:
- Ընտրել Նոր > XMLնախագծում SOAP հաղորդագրություն ստեղծելու համար:
- Ընտրել թեստային նախագիծնոր SOAP հաղորդագրության մայր թղթապանակի համար: Եթե ֆայլն արդեն ընտրված չէ, դաշտում մուտքագրեք «DemoSOAPMessage.xml»: ֆայլի անունըև սեղմեք կոճակը Ավարտել.
Ծրագիրը ավտոմատ կերպով կանչում է XML խմբագրիչը նոր XML ֆայլով: Այն պարունակում է ոչ այլ ինչ, քան xml տարբերակով և կոդավորման տող: Լավ է, որ մենք գոնե ինչ-որ բան ունենք՝ նախքան զրոյից SOAP հաղորդագրություն ստեղծելը: Գիտե՞ք ինչպես գրել SOAP հաղորդագրություն: Մի անհանգստացիր. Հաջորդ բաժնում մենք կանցնենք այն ստեղծելու քայլերով:
SOAP հաղորդագրություն ստեղծելու համար կարող եք կանչել «բարև» ծառայությունը՝ օգտագործելով «պարամետրեր» պարամետրը իմ անունով՝ «Jinwoo»: Իհարկե, դուք կարող եք օգտագործել ձեր տրված անուն. Օգտագործվում է http://demo/ անվանումների տարածքը: Զգույշ եղեք. այն գրված է որպես http://demo/, ոչ թե http://demo, դա էական է:
Ցուցակ 5. HelloWorldSOAPmessage.xml
Խնդիրներ տեսնու՞մ եք այս SOAP հաղորդագրության մեջ: Եթե այո, մի անհանգստացեք: Սրանով կզբաղվենք ավելի ուշ:
SOAP հաղորդագրություն ուղարկելը
Պատրա՞ստ եք հաղորդագրություն ուղարկել վեբ ծառայությունների սերվերին:
- Ընտրեք SOAP հաղորդագրություն և ընտրեք
- Transmit SOAP Request and Receive SOAP Response պատուհանում կարող եք լրացնել Ծառայության հասցեն, SOAPActionև բովանդակության տեսակը. AT այս հավելվածըմենք կարիք չունենք նշելու SOAPAction, քանի որ մենք օգտագործել ենք «» դատարկ տողը soapAction հատկանիշի համար DemoWebServiceService.wsdl ֆայլի պարտադիր բաժնում:
- Մուտքագրեք http://localhost:9081/HelloWorldWSProject/DemoWebServiceService դաշտում Ծառայության հասցենեթե սերվերը աշխատում է տեղական մեքենայի վրա, localhost նավահանգստում: 9081: Հակառակ դեպքում, դուք պետք է մուտքագրեք իրական հասցեն, որտեղ հասանելի է վեբ ծառայությունը:
- Ընտրել տեքստ/htmlդաշտի համար բովանդակության տեսակը.
- Սեղմեք կոճակը լավսերվերին SOAP հաղորդագրություն ուղարկելու համար:
SOAP հաղորդագրություն ստանալը
Եթե սերվերը աշխատում է և աշխատում է, դուք պետք է ստանաք SOAP պատասխան: Եթե պատասխան չեք ստանում, ստուգեք, որ հասցեն և բովանդակության տեսակը ճիշտ են:
SOAP հաղորդագրության վավերացում
Գերազանց! Մենք ընդունել ենք SOAP-ի պատասխանը: Այն նաև պահպանված է նախագծում։ Բայց սպասիր։ Տեսնու՞մ եք, որ ինչ-որ բան այն չէ։ Մենք ստացանք «Բարև, ընկեր»: «Բարև, Ջինվու» փոխարեն: Ինչ որ բան այնպես չգնաց? Գաղափար չունե՞ք:
Ցավոք, վեբ ծառայությունների սերվերը մեզ չհայտնեց, թե ինչն է սխալ: Ոչ մի նախազգուշացում: Իրավիճակը, երբ ուղարկվում են անկանխատեսելի SOAP պատասխաններ, և վեբ ծառայությունների սերվերը չի պատկերացնում, թե ինչն է սխալ, կարող է շատ վտանգավոր լինել: Նույնիսկ SOAP պատասխանների ստացողները կարող են խնդիրներ չնկատել խնդրո առարկա SOAP հաղորդագրության մեջ:
Վեբ ծառայությունների վավերացման գործիքը WSDL-ի և SOAP-ի համար օգնում է ձեզ որոշել, թե ինչն է սխալ:
Ցուցակում 6. Պատասխան
- Ընտրեք SOAP-ի պատասխան հաղորդագրությունը և սեղմեք կոճակը Վավերացնել.
WSDL-ի և SOAP-ի համար Web Services Validation Tool-ը սխալ է գտել SOAP հաղորդագրության մեջ:
Անվավեր SOAP հաղորդագրություն.cvc-complex-type.2.4.a:Գտնվել է անվավեր բովանդակություն՝ սկսած տարրի «պարամետրերով»: «(arg0)-ից մեկը սպասվում է.
SOAP հաղորդագրության խմբագրում
- Ծրագիրը դժգոհում է «պարամետրերի» արժեքից։ Փոխիր այն arg0-ի և պահպանիր:
Ցուցակ 7. Փոփոխված SOAP հաղորդագրություն
- Ստուգեք փոփոխված SOAP պատասխանի հաղորդագրության ճիշտությունը: Այլևս սխալի հաղորդագրություններ չեն հայտնվում:
- Այժմ մենք պատրաստ ենք փոփոխված պատասխանի հաղորդագրությունն ուղարկել սերվերին: Ընտրեք SOAP հաղորդագրություն և այնուհետև ընտրեք Փոխանցեք SOAP-ի հարցումը և ստացեք SOAP-ի պատասխանը.
- Transmit SOAP Request and Receive SOAP Response պատուհանում մուտքագրեք http://localhost:9081/HelloWorldWSProject/DemoWebServiceService դաշտում: Ծառայության հասցենեթե սերվերը աշխատում է localhost նավահանգստում:9081.
- Ընտրել տեքստ/htmlդաշտի համար բովանդակության տեսակըև սեղմեք կոճակը լավ.
Այս անգամ, ինչպես և սպասվում էր, գալիս է ճիշտ պատասխանը։
Ցուցակում 8. SOAP արձագանք
Սխալ անվանատարածքի հայտնաբերում
Ի՞նչ կլինի, եթե հաղորդագրություն ուղարկեք սխալ անվանատարածքով:
- Անվանատարածքը փոխեք http://demo2/ և պահպանեք հաղորդագրությունը:
Ցուցակ 9. Անվանատարածքի փոփոխություն
- Այնուհետև կարող եք հարցում ուղարկել սերվերին:
Դուք կտեսնեք IOException. սերվերը վերադարձրեց HTTP պատասխանի կոդը՝ 500 URI-ի համար՝ http://localhost:9081/HelloWorldWSProject/DemoWebServiceService:
Վեբ ծառայությունների սերվերը պատասխանում վերադարձրեց տեղեկատվություն IOException-ի մասին, սակայն այս տեղեկատվությունը բավարար չէ սխալը հայտնաբերելու համար: Ստուգեք հաղորդագրության ճշգրտությունը գործիքի միջոցով, եթե ցանկանում եք ավելի շատ մանրամասներ ստանալ խնդիրը լուծելու համար:
Ծրագրում ասվում է. «Սխալ SOAP հաղորդագրություն:cvc-complex-type.2.4.a:Գտնվել է անվավեր բովանդակություն՝ սկսած «ns0:hello» տարրով: «("http://demo/":hello,"http://demo/":helloResponse)"-ից մեկը սպասվում է»։
Այս հաղորդագրությունը ցույց է տալիս, որ սպասվում է http://demo/: Սա է, և ոչ թե 500 HTTP պատասխանի կոդը, որ մենք պետք է իմանանք:
Կոդավորված SOAP հաղորդագրությունների վավերացում
Իսկ եթե ձեր SOAP հաղորդագրությունները կոդավորված են: Խնդիր չկա, եթե ունեք բանալիներ և գաղտնաբառեր: Պարզապես ընտրեք SOAP հաղորդագրություն և Վավերացնելնույն կերպ, ինչպես դա արվում է ցանկացած այլ սովորական SOAP հաղորդագրությունների համար: Եթե ձեր SOAP հաղորդագրությունը գաղտնագրված է, էկրանին կհայտնվի Նկար 35-ում ցուցադրվածի նման հուշում:
Այս գրելու պահին աջակցվում են 3 տեսակի բանալիների պահեստներ (keystore).
- Java Key Store (JKS):
- Java Cryptography Extension Key Store (JCEKS):
- Անձնական տեղեկատվության փոխանակման շարահյուսական ստանդարտ (Հանրային բանալիների կրիպտոգրաֆիայի ստանդարտներ #12):
Դուք պետք է տեղեկատվություն տրամադրեք ձեր keystore-ի մասին՝ ֆայլի անունը, ֆայլի տեսակը և գաղտնաբառը: Եթե տեղեկատվությունը ճիշտ է, դուք պետք է ընտրեք բանալի և գաղտնաբառ: Կարող եք նաև գտնել ձեր բանալիների պահոցների և բանալիների և վկայագրերի ցանկի մասին տեղեկությունները, ինչպիսիք են՝ keystore տեսակը, մատակարարի անունը, մատակարարի տարբերակը, մատակարարի տեղեկությունները, բանալու տեսակը, ստեղծման ամսաթիվը, վկայագրի տեսակը, ալգորիթմը և ձևաչափը:
Եթե բոլոր տեղեկությունները ճիշտ են, ծրագիրը կստեղծի վերծանված SOAP հաղորդագրություն և կստուգի, արդյոք այն ճիշտ է:
Ներկայումս աջակցվում է հետևյալ ալգորիթմներըգաղտնագրում:
- Ընդլայնված գաղտնագրման ստանդարտ (AES) «Cipher Block Chaining» (CBC) ռեժիմում՝ սկզբնավորման վեկտորով (128/192/256 բիթ):
- Ընդլայնված գաղտնագրման ստանդարտ (AES) բանալիների գաղտնագրում (128/192/256 բիթ):
- Եռակի տվյալների գաղտնագրման ալգորիթմ Գործողության եղանակները (եռակի-DES) Բանալինների գաղտնագրում:
- Տվյալների գաղտնագրման եռակի ալգորիթմ Գործողության եղանակները (եռակի-DES) Բանալինների կոդավորումը ծածկագրման բլոկների շղթայով (CBC) ռեժիմում:
- RSA գաղտնագրության բնութագրեր 1.5 տարբերակ:
- RSA Optimal Asymmetric Encryption Padding-ը (OAEP) դիմակի ստեղծման գործառույթով մեթոդ է:
Թվային ստորագրված SOAP հաղորդագրությունների վավերացում
Իսկ եթե ձեր SOAP հաղորդագրությունը թվային ստորագրված է: Պարզապես ընտրեք SOAP հաղորդագրությունը և ընտրեք SOAP հաղորդագրության թվային ստորագրության ստուգում.
Եթե թվային ստորագրությունը ճիշտ է, կտեսնեք հետևյալ էկրանը.
Հակառակ դեպքում ծրագիրը կհայտնի ստորագրության սխալի մասին: Ներկայումս աջակցվում են թվային ստորագրության հետևյալ բնութագրերը և ալգորիթմները.
- Ապահով հեշ ալգորիթմ 1 (SHA-1)
- Հեշ հաղորդագրությունների նույնականացման կոդ (HMAC)
- Թվային ստորագրության ալգորիթմ (DSA)
- Հանրային բանալիների կրիպտոգրաֆիայի ստանդարտներ (PKCS #1)
- RSA կոդավորման ալգորիթմ անվտանգ հեշ ալգորիթմով (SHA-1)
- Canonical XML տարբերակ 1.0 և 1.1
- XSL փոխակերպումներ (XSLT) Տարբերակ 1.0
- XML Path Language (XPath) Տարբերակ 1.0
- Հիմք 64
Մուտք գործել ԱՄՆ Ազգային Եղանակային Ծառայություն՝ օգտագործելով SOAP հաղորդագրություն
Մեր ստեղծած և փորձարկված պարզ վեբ ծառայությունը լավ է աշխատում: Հնարավո՞ր է օգտագործել այս ծրագիրը«իրական» միջավայրո՞ւմ։ Դուք կարող եք փորձել աշխատել ԱՄՆ Եղանակի ազգային բյուրոյի իրական վեբ ծառայության հետ, որը տրամադրվում է ԱՄՆ-ի կողմից: Ազգային օվկիանոսային և մթնոլորտային վարչություն (NOAA):
- Ստեղծեք նախագիծ.
- Ստեղծեք SOAP հաղորդագրություն XML:
ԱՄՆ Եղանակի ազգային բյուրոն տրամադրում է բազմաթիվ տարբեր վեբ ծառայություններ: Կարող եք փորձել աշխատել NDFDgenByDay ծառայության հետ, որը տրամադրում է եղանակի կանխատեսումներ տվյալ լայնություն և երկայնություն ունեցող կետի համար:
NDFDgenByDay մուտք գործելու համար դուք պետք է տրամադրեք հետևյալ տեղեկատվությունը.
Աղյուսակ 1. NDFDgenByDay
| Ծառայության անվանումը (ծառայության անվանումը) | NDFDgenByDay |
|---|---|
| Վերջնակետ (վերջնական կետ) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (SOAP գործողություն) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| encodingStyle (կոդավորման ոճ) | http://schemas.xmlsoap.org/soap/encoding/ |
| Անվանատարածք (անունների տարածություն) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl |
| լայնություն (լայնություն) | Տասնորդական թիվ |
| երկայնություն (երկայնություն) | Տասնորդական թիվ |
| մեկնարկի ամսաթիվ (մեկնարկի ամսաթիվ) | ամիսը, ամսաթիվը |
| numDays (օրերի քանակը) | Ամբողջ թիվ |
| ձևաչափ (ձևաչափ) | Գիծ |
Այս օրինակում մենք ցանկանում ենք ստեղծել SOAP հարցում՝ շաբաթական կանխատեսում ստանալու համար տեղանքի համար կոորդինատներով (LAT38.9,LON-77.01) սկսած 2010-07-23-ից՝ 24-ժամյա ձևաչափով.
Ցուցակում 10. SOAP հարցում
Մենք չենք նշել անվանատարածք, քանի որ ծառայությունն աշխատում էր առանց դրա: Եթե անունների տարածքի հետ կապված խնդիրներ կան, սահմանեք այն:
Ընտրեք հաղորդագրություն և Փոխանցեք SOAP-ի հարցումը և ստացեք SOAP-ի պատասխանըՎեբ ծառայությունների վավերացման գործիքում՝ WSDL-ի և SOAP-ի համար:
Աղյուսակ 2. Տեղեկատվության հարցում
| Անուն | Իմաստը |
|---|---|
| Վերջնակետ (վերջնական կետ) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (SOAP գործողություն) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| Բովանդակության տեսակ (բովանդակության տեսակ) | տեքստ / xml; charset=utf-8 |
Այժմ կանխատեսման տվյալները շատ ավելի հեշտ է կարդալ:
Եթե այս խորհուրդը ձեզ ճիշտ չի թվում, կարող եք օգտագործել ձեր սեփական HTML ձևաչափման մեթոդը: Վեբ ծառայությունների մեծ մասն առաջարկում է արդյունքներ XML ձևաչափով, այնպես որ դուք ստիպված չեք լինի անընդհատ օգտագործել այս հնարքը:
Եզրակացություն
Մենք ստեղծել, փոխակերպել, ստացել և վավերացրել ենք SOAP հաղորդագրություններ՝ օգտագործելով Web Services Validation Tool-ը WSDL-ի և SOAP-ի համար: Այս ծրագիրը թույլ է տալիս մատնանշել այն խնդիրները, որոնք վեբ ծառայությունների սերվերների մեծ մասը նույնիսկ չեն կարողանում հայտնաբերել, ինչը կարող է հանգեցնել լուրջ հետևանքների իրական կյանքում: Այս ծրագրի օգտագործումը զարգացման փուլում թույլ է տալիս նվազեցնել շահագործման ընթացքում խնդիրները լուծելու ժամանակը:
Վեբ ծառայություններ 1C-ում
Այս հոդվածը կքննարկի 1C-ի ինտեգրումը գոյություն ունեցող վեբ ծառայությունների հետ և հենց 1C-ի օգտագործումը որպես վեբ ծառայություն:
Միևնույն ժամանակ, վեբ ծառայությունները կհասկանան որպես Ինտերնետում գործող համակարգեր և նրանց հետ փոխազդեցություն ապահովող ոչ միայն SOAP-ի միջոցով (որը հենց վեբ ծառայություն է), այլ նաև այլ ձևերով, ներառյալ սովորական HTTP (S) հարցումները:
1C վեբ ծառայությունների օգտագործման ռիսկերը
Վեբ ծառայությունների ներդրումը հայտնվել է 1C81 հարթակում։
Բայց դրանց օգտագործումը հղի է ռիսկերով.
- 1C8-ը լավ չի աշխատում HTTPS-ով, չկան ախտորոշիչ գործիքներ, ուստի երբեմն անհնար է հասկանալ, թե ինչու, եթե ծառայությունն ունի վկայական, այն չի ցանկանում աշխատել HTTPS-ի միջոցով: Ելքը վեբ ծառայությունների իրականացումն է CURL-ի կամ HTTPS թունելի բարձրացման միջոցով։
- 1C8-ը հավատարիմ է WSDL սխեմաների վավերացման իր կանոններին: Երբեմն, անհասկանալի պատճառներով, WSDL սխեման չի ցանկանում բեռնվել WS հղման մեջ: Պատճառը կարող եք պարզել միայն գործընկեր ֆորումում մեկ մասնագետից: WSDL սխեմայի համար ախտորոշիչ գործիքներ չկան, նույնիսկ պատճառ կամ տող չկա, որի դեպքում սխեմայի բեռնվածությունը ընդհատվում է:
Շենքերի վաճառքի ծառայությունների կանոններ
Հաճախորդին տրվում է վաճառքի փաստաթուղթ (անդորրագիր) միայն այն դեպքում, երբ ծառայության գործարքը հաջող է եղել: Հակառակ դեպքում հնարավոր է մի իրավիճակ, երբ հաճախորդը կստանա կտրոն և վստահ կլինի, որ ստացել է ծառայությունը, իսկ իրականում դա այդպես չէ։
Օգտագործելով արտաքին SOAP ծառայություններ
SOAP վեբ ծառայություններն օգտագործում են WSDL սխեմաներ և XDTO օբյեկտներ՝ տվյալների ներկայացման համար:
Ներբեռնեք WSDL
Արտաքին ծառայությունից օգտվելու համար անհրաժեշտ է բեռնել դրա WSDL սխեման:
WSDL սխեմայի վավերականության ստուգում
Երբեմն WSDL սխեման չի բեռնվում 1C-ում: Դուք կարող եք ստուգել սխեմայի վավերականությունը (ճշտությունը) ցանկացած WSDL սխեմայի վավերացնողի միջոցով, օրինակ՝ http://www.validwsdl.com/:
Դուք պետք է վերբեռնեք սխեման որոշ http կայք (կարող եք օգտագործել ftp) և նշեք այն ֆայլի հասցեն, որտեղ բեռնված է սխեման.
WSDL 1C-ում բեռնելու առանձնահատկությունները
1C-ում WSDL-ի բեռնման առանձնահատկությունն այն է, որ վավեր սխեմաները կարող են չբեռնվել: Ներկառուցված վավերացուցիչ չկա, այնպես որ դուք պետք է սխալ փնտրեք՝ օգտագործելով կործանարար վերլուծության մեթոդը՝ հաջորդաբար նվազեցնելով սխեմայի տարրերի քանակը: Դուք կարող եք, օրինակ, հեռացնել վեբ ծառայության նկարագրությունը:
Գործող արտաքին վեբ ծառայության փորձարկման գործընթաց
Գործող արտաքին վեբ ծառայությունը փորձարկելու համար օգտագործեք «TestArbitraryWebService.epf» մշակումը այս հոդվածի փաթեթից:
Թեստավորումը կարող է օգտագործվել Morpher ծառայության օրինակով, որը մերժում է անունները (ծառայության հասցե http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):
Այսպիսով, դուք կարող եք ստուգել ցանկացած ծառայություն, որն ունի պարամետրեր պարունակող պարզ մուտքի կետեր պարզ տեսակներհամարը, ամսաթիվը, տողը:
Մշակման ընթացքում կարող եք նաև նշել մուտքն ու գաղտնաբառը, որոնք անհրաժեշտ են վեբ ծառայություն մուտք գործելու համար:
Ստանդարտ ծառայության կարգաբերման գործիքներ
Վրիպազերծման համար կարող եք օգտագործել SoapUI ծրագիրը, որը կարող է կամայական հարցում ուղարկել վեբ ծառայությանը և ստանալ պատասխան:
SOAP և HTTPS
Ցավոք, SOAP-ը 1C-ում բավականին քմահաճ է վարվում HTTPS արձանագրության միջոցով աշխատելիս, պրակտիկան ցույց է տալիս, որ անհնար է հասնել HTTPS կապի, չնայած դրա հնարավորությունը հայտարարված է հարթակում: Ախտորոշման և վրիպազերծման գործիքների պակաս կա՝ պարզելու կապը չհաստատելու պատճառները: Հետեւաբար, հարմար է օգտագործել SOAP-ը CURL-ի միջոցով:
HTTPS-ի օգտագործման ներկառուցված մեխանիզմը ենթադրում է, որ բոլոր վկայագրերը պետք է հրապարակվեն ընդհանուր pem ֆայլում 1C ծրագրի գրացուցակում:
Օգտագործելով 1C որպես ծառայություն
1C-ի վրա հիմնված ծառայության մշակման կանոններ
«Բարև» գործողություն
Լավ պրակտիկա է ծառայությունում ստեղծել գործողություն, որը տեղեկացնում է ծառայության հասանելիության մասին: Սա հեշտացնում է ինտեգրատորների կյանքը, նրանց համար ավելի հեշտ կլինի ստուգել, թե արդյոք կապը ծառայության հետ հաստատված է:
Օրինակ, դուք կարող եք օգտագործել Hello օպերացիան առանց պարամետրերի, որը պարզապես վերադարձնում է բուլյան արժեքը True:
Վեբ ծառայության հրապարակում
Գործընթացը լավ նկարագրված է փաստաթղթերում. file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634:
Վեբ ծառայությունների հրապարակման խնդիրն է վեբ ծառայությունների *.1cws կոնֆիգուրացիայի ֆայլերը տեղադրել վեբ սերվերի համապատասխան գրացուցակում՝ վեբ սերվերի համար համապատասխան կարգավորումներով: Վեբ ծառայությունները հրապարակելու համար դուք պետք է կատարեք մենյուի հրամանը «Կառավարում | Վեբ ծառայությունների հրապարակում.
Այս հրամանը կբացի Web Services Publishing պատուհանը:
Web Services Publishing պատուհանը պարունակում է վեբ սերվեր տանող ուղին և երկու ցուցակ.
- «Վեբ ծառայություններ» - կոնֆիգուրացիայի վեբ ծառայությունների ցանկ;
- «Հրապարակել» - նշված վեբ սերվերում հրապարակված վեբ ծառայությունների ցանկ:
Օգտագործեք «Միացեք...» կոճակը՝ նշելու վեբ սերվերը, որի վրա ցանկանում եք հրապարակել վեբ ծառայությունները:
Վեբ սերվերի ուղու ընտրության պատուհանը թույլ է տալիս նշել ուղին երկու եղանակով.
- «Ֆայլեր» ներդիրում - այս մեթոդը օգտագործվում է, երբ հրապարակումը կատարվում է նույն համակարգչում, որտեղ տեղադրված է վեբ սերվերը: Ուղին սահմանում է ինտերնետային էջին համապատասխան տեղական գրացուցակը, որտեղից կկանչվի հրապարակված վեբ սերվերը.
- «FTP կայք» ներդիրում - այս մեթոդն օգտագործվում է, երբ ցանկանում եք վեբ ծառայություն հրապարակել հեռավոր համակարգչի վրա: Հրապարակումը կատարելու համար դուք պետք է նշեք FTP կապի պարամետրերը հեռավոր համակարգիչև այն գրացուցակը, որտեղ կհրապարակվի վեբ ծառայությունը:
Ընտրված վեբ ծառայության հրապարակումն իրականացվում է «Հրապարակել» կոճակի միջոցով
Ջնջել կոճակն օգտագործվում է վեբ ծառայությունը չհրապարակելու համար:
Դուք կարող եք հրապարակել տեղական գրացուցակում կամ FTP-ի միջոցով: Դուք կարող եք նաև հրապարակել հեռավոր սերվերի վրա UNC ուղու միջոցով, եթե հեռավոր սերվերը տեղական ցանցի մի մասն է:
Հրապարակումից հետո վեբ ծառայությունը հասանելի է «http://localhost/test.1cws» կամ «http://xxx.ru/test.1cws», որտեղ xxx.ru-ն հեռավոր սերվերի հասցեն է, իսկ localhost-ը՝ տեղական սերվերի բնորոշ հասցեն:
1C վեբ ծառայության թույլտվություն
Ծառայություն մուտք գործելու համար դուք պետք է վավերացված լինեք:
Թույլտվության հարցերը լավ քննարկված են այստեղ՝ http://www.forum.mista.ru/topic.php?id=341168 և փաստաթղթերի ֆայլում:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81: htm
Սովորաբար, վեբ ծառայությունն աշխատում է մեկ կոնկրետ օգտագործողի ներքո (ավելի հաճախ՝ հատուկ ստեղծված): Դուք կարող եք «կցել» 1C օգտատեր՝ օգտագործելով Windows նույնականացումը Windows IUSR_ օգտագործողին (անջատել 1C թույլտվությունը օգտագործողի համար): Որպես այլընտրանք, դուք կարող եք մաքրել 1C օգտագործողների ցուցակը, ապա թույլտվություն չի պահանջվում:
Եթե պահանջվում է մի քանի օգտատեր, ապա դուք կարող եք ստեղծել մի քանի մուտք վեբ սերվերի համար, կապել Windows-ի օգտվողին նրանցից յուրաքանչյուրին և, համապատասխանաբար, գրանցել մուտք դեպի Windows օգտատերեր 1C-ում:
WSProxy օբյեկտի Օգտագործողի և գաղտնաբառի հատկությունները օգտագործում են ոչ թե 1C մուտք, այլ վեբ սերվերի օգտագործողի մուտք:
Վեբ ծառայության փորձարկում 1C
1C-ը որպես վեբ ծառայություն փորձարկելու համար օգտագործեք «TestArbitraryWebService.epf» մշակումը, ինչպես նկարագրված է «Աշխատող արտաքին վեբ ծառայության փորձարկում» բաժնում:
1cws ֆայլը 1C վեբ ծառայության WSDL նկարագրությունն է:
Ծառայությունների օգտագործումը մանրածախ առևտրում
Սովորաբար, մանրածախ առևտրում ծառայություններն օգտագործվում են բնակչությանը տարբեր ծառայություններ մատուցելու համար՝ վճարումների ընդունում, վարկերի մարում, դրամական փոխանցումներ, գնումներ։ ծրագրային ապահովումև այլն:
Միևնույն ժամանակ, 1C-ում մատուցված ծառայության համար գեներացվում է անդորրագիր, որում պահվում են գործարքի պարամետրերը։ Դրանից հետո այս կտրոնը տպագրվում է հաճախորդին` տրամադրված ծառայության մասին մանրամասն տեղեկություններով: Հնարավոր է տպել նախնական ստուգում, որպեսզի հաճախորդն իր ստորագրությամբ հաստատի իր խոսքերից մուտքագրված տվյալները։
Ծառայությունը կարող է ինտեգրվել 1C լեզվով գրված մանրածախ ծրագրին (UT, Մանրածախ և այլն) տարբեր ձևերով.
- Մշակումը կամ ծածկագիրը կարող է գրվել 1C լեզվով, որն էլ կատարում է ծառայության հետ ամբողջ աշխատանքը։
- Ծրագիրը կարող է օգտագործվել, որն աշխատում է ծառայության հետ, իսկ 1C-ում փոխանցում է միայն տեղեկատվություն՝ չեկերը կոտրելու համար։
Ծառայությունների տվյալների կազմակերպում 1C-ում
Գործարքի մասին տեղեկությունները անդորրագրում պահելու համար անհրաժեշտ է ստեղծել լրացուցիչ աղյուսակային բաժին «Համալիր վաճառք» հետևյալ մանրամասներով.
- Անվանակարգ - պարտադիր է չեկային նոմենկլատուրայի համար:
- Պարամետր - հղում դեպի «Համալիր վաճառք. Պարամետրեր» տեղեկատու գրքին:
- Արժեք - պարամետրի արժեք, կոմպոզիտային տեսակ: Լարի ներկայացումը պետք է լինի բավականին երկար (1024 նիշ), որպեսզի համապատասխանի չեկի տեքստին:
«Համալիր վաճառք. Պարամետրեր» գրացուցակը պարունակում է գործարքների պարամետրերի ցանկ:
Ավելի շահավետ է օգտագործել աղյուսակային մասը, քան մանրամասների հավաքածուն, քանի որ գործարքը կարող է ունենալ դրանցից շատերը, իսկ ծառայության հետ չկապված այլ անդորրագրերում այդ մանրամասները չեն օգտագործվի և լրացուցիչ տեղ կզբաղեցնեն: Բացի այդ, նման լուծումը ունիվերսալ է ցանկացած ծառայության համար և չի պահանջում տվյալների վերակառուցում նոր ծառայության ներդրումից հետո:
Վաճառողին տրվում է առանձին էջանիշ (կամ տպագիր ձև՝ կոնֆիգուրացիան չփոխելու համար), որում նա կարող է տեսնել չեկի գործարքի մանրամասների աղյուսակը։
Օգտագործելով մշակումը 1C լեզվով
Դիտարկենք Paym պայմանական ծառայության օրինակը «Մանրածախ» կոնֆիգուրացիայի համար:
- Եկեք մտնենք 1C-ում «Paym» անվանացանկի տեղեկատուի նախապես սահմանված տարրը: 1C:Enterprise ռեժիմում, կոնֆիգուրացիան թարմացնելուց հետո, անհրաժեշտ է նրան հատկացնել «Ծառայություն» արտադրանքի տեսակը:
- Ընթացակարգում «Ավելացնել նոմենկլատուրա ներդիրում. մաս» «Վաճառքի գրանցում» ձևի մոդուլի, մենք անվանում ենք ծառայության հետ աշխատելու վերամշակում, որը գրված է 1C-ով: Հաջող վճարման դեպքում չեկը գրում և փակցնում ենք.
- Մշակումը պետք է տպի նախնական ստուգում (անհրաժեշտության դեպքում), լրացնի համալիր վաճառքի աղյուսակային մասը և պատրաստի տեքստը չեկ տպելու համար «PaymCheckText» նախապես սահմանված հատկանիշով:
- Չեկի մոդուլի «Չեկի տեղադրում և տպում» ընթացակարգում ապրանքի անվանումը փոխարինում ենք չեկի համար մանրամասներում պահպանվածով։ Տեքստը փոխարինվում է միայն վաճառքի համար, վերադարձի համար, պարզապես ծառայության անվանումը տպված է, ինչպես միշտ։
Առանձին հարց է՝ ինչպես ապահովել գործարքի ավարտը։ Նրանք. եթե գործարքը տեղի է ունեցել ծառայության մեջ, ինչպես համոզվել, որ այն չի կորցրել 1C-ում: Ամենաօպտիմալ ճանապարհը ռեգիստրների հաշտեցումն է։ Բայց սա առանձին քննարկման առարկա է։
1C-ի հետ ինտեգրված ծրագրերի օգտագործում
XDTO
Հաճախ վեբ ծառայություններն օգտագործում են XDTO: Ահա ամենաշատը կարևոր խորհուրդներև XDTO-ի օգտագործման բաղադրատոմսեր 1C-ում:
XDTO 1C հարթակում
Կազմաձևման «XDTO Objects» մասնաճյուղում նկարագրված XDTO փաթեթները հասանելի են XDTO Factory համաշխարհային գործարանում տեսակներ և օբյեկտներ ստեղծելու համար: Սա անմիջապես ակնհայտ չէ:
Սխեմայի որոշ տեսակներ անուն չունեն, դրանք ստանալու համար դուք պետք է անցնեք տիպի հիերարխիա:
Օրինակը նկարագրում էր System ցուցակը, որը պարունակում էր XDTO կառուցվածքներ: Կառույցն ինքնին ստեղծելու համար անհրաժեշտ էր ստանալ դրա տեսակը հետևյալ կերպ.
Type = Factory.Type("urn:my.ru:MasterData:Business", "Business").Properties.Get("System").Type;
Հաճախակի խնդիրներ XDTO-ի հետ
XSD սխեմաների տարբեր ձևաչափեր
Որոշ ձևաչափերում պիտակները կոչվում են xs:, որոշ xsd:, բայց 1C-ն ապահով կերպով հասկանում է երկու ձևաչափերը: Մի անգամ այնպիսի իրավիճակ եղավ, որ XSD-ը սովորաբար ներմուծվում էր 1C առանց սխալների, բայց մեկ փաթեթ չէր ստեղծում: Պատճառը ատրիբուտի բացակայությունն էր թիրախ անունների տարածությունպիտակի վրա, համապատասխանաբար, 1C-ն չգիտեր, թե որ փաթեթում տեղադրի սխեման, բայց սխալներ չտվեց:
Ծառայությունների սպասարկում
Հաշվի առնելով, որ ծառայությունը երկու համակարգերի համադրություն է՝ 1C և արտաքին, սխալներ կարող են լինել երկու համակարգերում, ինչը նվազեցնում է աշխատանքի ընդհանուր հուսալիությունը:
Ծառայությունների շահագործման խափանումների պատճառները ավելի հեշտ հասկանալու համար խորհուրդ է տրվում օգտագործել մի շարք միջոցառումներ:
Պահանջել գրանցում
Հղումներ
- XDTO
- XDTO-ի լավ նկարագրություն http://pro1c.org.ua/index.php?showtopic=214
- Անվճար հետաքրքիր վեբ ծառայություններ.
- «Աերոֆլոտ» - թռիչքների ժամանակացույցի տեղեկատվություն
- Morpher - անունների անկում http://www.morpher.ru/WebServices/Morpher.aspx
- Չհավաքված:
- Վեբ ծառայությունների տեղադրում և օգտագործում
- v8: Ինչպե՞ս փոխել apache կազմաձևման ֆայլը:
- v8. թեմայի շարունակություն վեբ ծառայությունների հետ - հնարավոր չէ միացնել վեբ ծառայությունը
- v8. Ես սողում եմ վեբ ծառայությունների միջոցով. չեմ կարող ստեղծել պրոքսի...
- Գիտելիքների գիրք՝ v8. Արտաքին վեբ ծառայությունների օգտագործում 1C:Enterprise 8-ում;
- Վեբ ծառայությունների տեղադրում և օգտագործում
Այս օրերին հազվադեպ ժամանակակից կիրառությունանում է առանց API-ի: Սա ճիշտ է ինչպես պարզ կայքի, այնպես էլ բարձր բեռնված բաշխված համակարգերի համար: API-ի թեստավորումը որակի ապահովման գործընթացի հիմնական խնդիրներից մեկն է: Զարմանալի չէ, որ փորձարկողների պահանջարկը, ովքեր գիտեն, թե ինչպես փորձարկել API-ները, օրեցօր ավելանում է: Այս դասընթացի ընթացքում դուք կհասկանաք API թեստավորման մեթոդները, գործիքներն ու մոտեցումները, ձեռք կբերեք անհրաժեշտ գիտելիքներ, որոնք, անկասկած, դրականորեն կազդեն ձեր՝ որպես թեստավորման մասնագետի արժեքի վրա:
Այս դասընթացը օգտակար կլինի այն ուսանողների համար, ովքեր ծանոթ են ծրագրային ապահովման թեստավորման հիմունքներին, ովքեր ցանկանում են հետագայում աճել և կատարելագործել իրենց հմտությունները:
Դասընթացի ծրագիր.
Դաս 1. Ներածական. SOAP արձանագրություն
- Համառոտ դասախոսի մասին;
- Դասընթացի նպատակները;
- Ինչ է API-ն, WS-ը և ինչու են դրանք անհրաժեշտ.
- API-ի թեստավորման դերը որակի ապահովման գործընթացում;
- WS փորձարկման գործիքների ակնարկ;
- WS թեստավորման ժամանակ օգտագործվող մեթոդներ;
- SOAP-ի պատմությունը;
- Տերմինաբանություն և հիմնական հասկացություններ (XML, XSD, Endpoint, WSDL):
Դաս 2. SOAP արձանագրություն. ՀԱՆԳՍՏԻ ճարտարապետություն
- Տերմինաբանություն և հիմնական հասկացություններ (UDDI, XSLT, XPath, XQuery, HTTP մեթոդներ, HTTP կարգավիճակներ);
- SOAP-ի կառուցվածքը և հիմնական բաղադրիչները;
- Կիրառման շրջանակը;
- Աշխատանքի առանձնահատկությունները;
- Առավելություններն ու թերությունները;
- REST ճարտարապետության առանձնահատկությունները;
- Տերմինաբանություն և հիմնական հասկացություններ (WADL, RESTful, JSON, JSONPath);
- REST սկզբունքները;
- Կարգավիճակի կոդը և հիմնական կարգավիճակները;
- CRUD բայեր;
- Առավելություններն ու թերությունները.
Դաս 3. Ներածություն SoapUI-ին: Աշխատանք REST նախագծի հետ
- Java տեղադրում;
- SoapUI տեղադրում;
- Ինտերֆեյսի հիմնական տարրերի ակնարկ;
- Ուսումնական նախագծի միացում;
- Ծրագրի մեթոդների վերանայում;
- Հարցում ուղարկելը և ստացված պատասխանի վերլուծությունը.
- Նախագծի հասանելի վեբ ծառայությունների ուսումնասիրություն;
- Փորձարկման պլանի կազմում;
- Թեստային դեպքեր գրելը;
- «TestSuite», «TestCase», «TestSteps» տարրեր:
Դաս 4. Աշխատանք REST նախագծի հետ (XML)
- Արգելափակել «Պնդումները»;
- Փորձարկումներ տարբեր մակարդակներում;
- «Հատկություններ» տարր, հիմնական հատկանիշներ;
- Աշխատանք Properties-ի հետ;
- «Գույքի փոխանցում» տարրը;
- Աշխատեք պնդումների հետ
Դաս 5. Աշխատանք REST նախագծի հետ (JSON)
- Պայմաններ և մասնաճյուղեր;
- Պնդումների հետ աշխատելը;
- TestRunner, աշխատանքի առանձնահատկությունները;
- Գործարկեք TS, TC հրամանի տողից;
- Աշխատեք Test runner-ի հետ;
- Աշխատեք Groovy սկրիպտների հետ
Դաս 6. Աշխատանք Groovy սկրիպտների հետ
- Աշխատեք ստատիկ և դինամիկ տվյալների հետ;
- Մենք ստեղծում ենք թեստային տվյալներ;
- Մենք տվյալներ ենք ստանում «Հատկություններ»-ից;
- Տվյալների գրանցում և փոխանցում;
- Պայմաններ և մասնաճյուղեր;
- Սցենարի պնդում.
Դաս 7. Լրացուցիչ առանձնահատկություններ
- Արտաքին գրադարանների և մաքսային դասերի միացում;
- Ծաղրական ծառայություններ;
- Ինչու են անհրաժեշտ ծաղրական ծառայություններ;
- Mock ծառայության հետ աշխատելու օրինակ;
- Բայց ինչ վերաբերում է CI-ին:
- Տեղադրեք Jenkins;
- Ջենքինսի վերաբերյալ նախագիծ սկսելը։
SOAP (Պարզ օբյեկտի մուտքի արձանագրություն)Հաճախորդի և սերվերի միջև հաղորդագրությունների փոխանցման ստանդարտացված արձանագրություն է: Այն սովորաբար օգտագործվում է HTTP(S) հետ համատեղ, բայց կարող է աշխատել նաև կիրառական շերտի այլ արձանագրությունների հետ (օրինակ՝ SMTP և FTP):
SOAP-ի փորձարկումը թեստավորման տեխնիկայի տեսանկյունից սկզբունքորեն չի տարբերվում այլ API-ների հետ աշխատելուց, սակայն այն պահանջում է նախնական պատրաստում (արձանագրության տեսության առումով) և փորձարկման հատուկ գործիքներ: Այս հոդվածում ես կցանկանայի ձևակերպել անհրաժեշտ գիտելիքների և հմտությունների մի փոքրիկ ստուգաթերթ, որը հավասարապես օգտակար կլինի և՛ SOAP-ի փորձարկողի համար (հաճախ չունենալով գաղափար, թե «ինչի վրա բռնել» առաջադրանքը դնելուց հետո), և՛ մենեջեր, ով ստիպված է գնահատել թեստավորողների գիտելիքները և մշակել ուսման պլաններ:
Տեսական հիմք
Այն, որ SOAP-ը արձանագրություն է, մեծ նշանակություն ունի թեստավորման համար. անհրաժեշտ է ուսումնասիրել հենց արձանագրությունը, «առաջնային» ստանդարտներն ու արձանագրությունները, որոնց վրա հիմնված է, և (անհրաժեշտության դեպքում) առկա ընդլայնումները:
XML
XML-ը նշագրման լեզու է, որը նման է HTML-ին: SOAP-ի միջոցով ուղարկված/ստացված ցանկացած հաղորդագրություն XML փաստաթուղթ է, որտեղ տվյալները հարմար են կառուցվածքային և հեշտ ընթեռնելի, օրինակ.
Մի մոռացեք հոդված գրել:
Դուք կարող եք ավելին իմանալ XML-ի մասին w3schools-ում կամ codenet-ում (ռուսերեն): Համոզվեք, որ ուշադրություն դարձրեք անունների տարածքների նկարագրությանը (կոնֆլիկտների լուծման մեթոդ XML-ում տարրերը նկարագրելիս) - SOAP-ում դրանց օգտագործումը անհրաժեշտ է:
XSD
Աշխատելիս միշտ հարմար է ունենալ հնարավոր XML փաստաթղթերի ստանդարտացված նկարագրություն և ստուգել դրանք լրացման ճշգրտության համար: Դրա համար կա XML Schema Definition (կամ կարճ XSD): Փորձարկողի համար XSD-ի երկու հիմնական առանձնահատկություններն են տվյալների տեսակների նկարագրությունը և հնարավոր արժեքների վրա սահմանափակումների սահմանումը: Օրինակ, նախորդ օրինակի տարրը կարող է ընտրովի լինել և սահմանափակվել 255 նիշով՝ օգտագործելով XSD:
...
...
SOAP ընդլայնումներ
Ձեր աշխատանքում դուք կարող եք նաև հանդիպել SOAP-ի տարբեր «ընդլայնումների»՝ WS-* ստանդարտների նման: Ամենատարածվածներից մեկը WS-Security-ն է, որը թույլ է տալիս աշխատել կոդավորման և էլեկտրոնային ստորագրությունների հետ: Հաճախ դրա հետ օգտագործվում է WS-Policy, որով դուք կարող եք կառավարել ձեր ծառայությունից օգտվելու իրավունքները:
WS-Security-ի օգտագործման օրինակ.
Այս բոլոր ընդլայնումները բավական են բարդ կառուցվածքներ, չի օգտագործվում յուրաքանչյուր SOAP ծառայության մեջ; SOAP թեստավորման սկզբնական փուլում դրանք մանրամասն ուսումնասիրելը դժվար թե տեղին լինի:
Գործիքներ
Ինչպես արդեն հասկացաք, SOAP-ը լուրջ խնդիր է, դրա հետ աշխատելու համար անհրաժեշտ է իմանալ տեսությունը և բազմաթիվ չափանիշներ: Գործնականում նման բարդությունը կհանգեցնի շատ շոշափելի աշխատուժի ծախսերի (օրինակ, անհրաժեշտ կլինի ամեն անգամ սխեման նայել նոթատետրում և ուղարկել ոլորման հարցումներ): Հետևաբար, ստեղծվել են գործիքներ SOAP-ի հետ աշխատանքը հեշտացնելու համար:
XML/XSD խմբագիրներ
Լավ փորձարկողը սկսում է փորձարկումներ փաստաթղթեր գրելու փուլում, ուստի հարմար է օգտագործել հատուկ խմբագիրներ սխեմաները ստուգելու համար: Երկու ամենահայտնիներն են Oxygen-ը (cross-platform) և Altova-ն (միայն Windows-ի համար); երկուսն էլ վճարովի են։ Սրանք շատ հզոր ծրագրեր են, որոնք վերլուծաբաններն ակտիվորեն օգտագործում են ծառայությունները նկարագրելիս:
Իմ պրակտիկայում խմբագիրների երեք առանձնահատկություններ պարզվեցին, որ օգտակար էին.
1. XSD վիզուալիզացիաանհրաժեշտ է սխեմայի տեսողական ներկայացման համար, որը թույլ է տալիս արագորեն մեկուսացնել պահանջվող տարրերն ու ատրիբուտները, ինչպես նաև առկա սահմանափակումները: Օրինակ, CheckTextRequest հարցման համար տեքստային տարրը պահանջվում է, և բոլոր երեք ատրիբուտները կամընտիր են (ընտրությունների հատկանիշը սահմանված է զրո լռելյայն արժեքով):
Վիզուալիզացիան անհրաժեշտ է, երբ սխեմայում կան բազմաթիվ տեսակներ և սահմանափակումներ: Եթե դուք միայն դրա կարիքն ունեք և չեք ցանկանում վճարել նվիրված խմբագիրների համար, ապա կարելի է դիտարկել անվճար այլընտրանքներ (օրինակ՝ JDeveloper):
2. XML-ի սերունդ՝ հիմնված XSD-ի վրաօգտակար է, երբ ցանկանում եք տեսնել հաղորդագրության վավեր օրինակ: Ես օգտագործում եմ այն արագ փորձարկելու հաղորդագրության հնարավոր ավարտը և ստուգելու այն նրբությունները, թե ինչպես են գործում սահմանափակումները:
3. 2-րդ կետի հնարավորությունն օգտագործելուց հետո օգտակար է XML վավերացում XSD-ի դեմ- այսինքն ստուգեք հաղորդագրությունը ճիշտ լինելու համար: Միասին 2-րդ և 3-րդ գործառույթները թույլ են տալիս բացահայտել XSD-ի բարդ թերությունները, նույնիսկ երբ ծառայությունն ինքնին մշակման փուլում է:
Փորձարկման գործիք - SoapUI
SOAP-ի փորձարկումը գրեթե միշտ ներառում է SoapUI-ի օգտագործումը: Դուք կարող եք կարդալ այս գործիքի օգտագործման մասին տարբեր աղբյուրներում (,), բայց առավել արդյունավետ կլինի կարդալ պաշտոնական փաստաթղթերը: Ես առանձնացնում եմ SoapUI-ի իմացության 8 պայմանական մակարդակ.
Մակարդակ 1 - Ես կարող եմ հարցումներ ուղարկել
Իմացեք, թե ինչպես ստեղծել նախագիծ՝ հիմնված WSDL-ի վրա: SoapUI-ն կարող է առաջացնել բոլոր անհրաժեշտ հարցումները ձեզ համար. պարզապես պետք է ստուգել դրանց լրացման ճիշտությունը և սեղմել «Ուղարկել» կոճակը։ Վավեր հարցումներ կատարելու արվեստին տիրապետելուց հետո դուք պետք է տիրապետեք անվավեր հարցումներ կատարելու արվեստին, առաջացնելով տեսքըսխալներ.
Մակարդակ 2 - Ես կարող եմ անել թեստային հավաքածուներ և թեստային դեպքեր
Սկսեք մինի-ավտոփորձարկումներ անել: Թեստային փաթեթները և թեստային դեպքերը թույլ են տալիս ստեղծել API թեստային սկրիպտներ, պատրաստել տվյալներ հարցումների համար և ավտոմատ կերպով ստուգել ստացված պատասխանը ակնկալվողի դիմաց: Սկզբում դրանք կարող են օգտագործվել պարզապես որպես հարցումների հավաքածու: Օրինակ, եթե դուք ունեք թերություն և ցանկանում եք արագ ստուգել այն շտկելուց հետո, կարող եք հատկացնել առանձին թեստային փաթեթ՝ հատուկ թերության հարցումների համար:
Մակարդակ 3 – կարող է գրել պնդումներ
Թեստի դեպքերը յուրացնելուց հետո ձեզ համար օգտակար կլինի սովորել, թե ինչպես դրանք ավտոմատ կերպով ստուգելի դարձնել: Դրանից հետո դուք այլևս կարիք չեք ունենա ձեր «աչքերով» պատասխանի մասին տեղեկատվություն փնտրել. եթե ավտոմատ ստուգում կա, դեպքերը կնշվեն կանաչ (եթե ստուգումն անցնի) կամ կարմիր (եթե այն չանցնի) . SoapUI-ն ապահովում է հնարավոր ստուգումների (պնդումների) մեծ փաթեթ, սակայն ամենահարմարն ու պարզը Պարունակում է և Չպարունակում: Նրանց օգնությամբ դուք կարող եք ստուգել ստացված պատասխանում որոշակի տեքստի առկայությունը: Այս ստուգումները նաև աջակցում են սովորական արտահայտությունների որոնումներին:
Մակարդակ 4 - XPath-ի և/կամ XQuery-ի օգտագործումը պնդումներում
Նրանց համար, ովքեր մի փոքր ծանոթ են UI-ին՝ օգտագործելով Selenium, XPath լեզուն ծանոթ բան է: Կոպիտ ասած՝ XPath-ը թույլ է տալիս տարրեր որոնել XML փաստաթղթում։ XQuery-ն նմանատիպ տեխնոլոգիա է, որը կարող է օգտագործել XPath-ը ներսից; այս լեզուն շատ ավելի հզոր է, այն նման է SQL-ին: Այս երկու լեզուներն էլ կարող են օգտագործվել պնդումներում: Նրանց օգնությամբ ստուգումները ավելի նպատակային և կայուն են, ուստի ձեր գործերն ավելի վստահելի կլինեն:
Մակարդակ 5 – կարող է գրել բարդ թեստեր՝ օգտագործելով հատուկ քայլեր
Փորձարկման դեպքերը կարող են պարունակել ոչ միայն մեկ հարցում, այլև մի քանիսը (օրինակ, երբ ցանկանում եք ընդօրինակել օգտվողի ստանդարտ սցենարը «ստեղծել կազմակերպություն» → «արտահանել կազմակերպություն»): Հարցումների միջև կարող են լինել այլ հատուկ քայլեր, ինչպիսիք են՝
- Հատկություններ և գույքի փոխանցում (օգնեք վերօգտագործել տվյալները և փոխանցել դրանք հարցումների միջև);
- JDBC Request (օգտագործվում է տվյալների բազայից տվյալներ ստանալու համար);
- Պայմանական Goto (թույլ է տալիս ճյուղեր կամ օղակներ պատրաստել փորձարկման դեպքում);
- Գործարկեք TestCase-ը (օգնում է որոշ տիպիկ հարցումներ տեղադրել առանձին թեստային դեպքերի մեջ և զանգահարել դրանք անհրաժեշտության դեպքում):
Մակարդակ 6 - օգտագործելով Groovy սցենարներ
SoapUI-ն թույլ է տալիս գրել Groovy սկրիպտներ տարբեր վայրեր. Ամենապարզ դեպքը ինքնին հարցման մեջ տվյալների ստեղծումն է՝ օգտագործելով $(=) ներդիրները: Ես անընդհատ օգտագործում եմ այս պլագինները.
- $(=new Date().format("yyyy-MM-dd'T'HH:mm:ss"))- անհրաժեշտ ձևաչափով մուտքագրել ընթացիկ ամսաթիվը և ժամը.
- $(=java.util.UUID.randomUUID())– տեղադրեք լավ ձևավորված պատահական GUID:
Ամբողջական սցենարները կարող են օգտագործվել որպես քայլեր գործերում և թեստերում: Ինչ-որ պահի դուք կտեսնեք, որ հինգերորդ մակարդակից մի քանի հատուկ քայլեր կարող են փոխարինվել միանգամից մեկ սցենարով:
Մակարդակ 7 - օգտագործելով MockServices
SoapUI-ն, որը հիմնված է WSDL-ի վրա, կարող է ստեղծել Mock օբյեկտներ: Ծաղրական օբյեկտը ծառայության ամենապարզ մոդելավորումն է: «Ծաղրումների» օգնությամբ դուք կարող եք սկսել գրել և կարգաբերել թեստային դեպքերը նույնիսկ նախքան ծառայությունն իրականում հասանելի լինել թեստավորման համար: Դրանք կարող են օգտագործվել նաև որպես ժամանակավոր անհասանելի ծառայությունների համար որպես «անավարտներ»:
Մակարդակ 8 - աստված SoapUI
Գիտե՞ք տարբերությունը վճարովի և անվճար տարբերակներ SoapUI և օգտագործեք SoapUI API կոդով: Դուք օգտագործում եք հավելումներ և գործարկում եք գործերը հրամանի տողի և/կամ CI-ի միջոցով: Ձեր փորձարկման դեպքերը պարզ են և հեշտ է պահպանել: Ընդհանրապես այս գործիքի վրա «շանը կերել ես»։ Ես կցանկանայի զրուցել մեկի հետ, ով տիրապետում է SoapUI-ին այս մակարդակում: Եթե դուք եք, խնդրում ենք թողնել մեկնաբանություն:
Թեստավորում ծրագրավորման լեզուներով
Ես օրինակ կբերեմ, թե ինչպես է նման հայտը YandexSpeller API-ին, որը կատարվել է groovy-wslite-ի միջոցով.
ներմուծել wslite.soap.*
def հաճախորդ = նոր SOAPClient ("http://speller.yandex.net/services/spellservice?WSDL")
def answer = client.send (SOAPAction. «http://speller.yandex.net/services/spellservice/checkText») (
մարմին (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
տեքստ («սխալ»)
}
}
}
հաստատեք «սխալ» == answer.CheckTextResponse.SpellResult.error.s.text()
հաստատեք «1» == [էլփոստը պաշտպանված է]()
Որքան ես գիտեմ, դեռևս չկան բարձր մակարդակի շրջանակներ (ինչպես Rest-assured) SOAP թեստավորման համար, բայց վերջերս հայտնվել է հետաքրքիր գործիք՝ կարատե ։ Դրանով դուք կարող եք նկարագրել SOAP-ի և REST-ի փորձարկման դեպքերը այնպիսի սցենարների տեսքով, ինչպիսին է Վարունգը / Գերկինը: Շատ փորձարկողների համար հղումը կարատեին կլինի իդեալական լուծում, քանի որ նման սցենարները, գրելու և աջակցող դեպքերի բարդության առումով, կլինեն ինչ-որ տեղ միջինում SoapUI-ի օգտագործման և ձեր սեփական SOAP թեստավորման շրջանակը գրելու միջև:
Եզրակացություն
Քիչ հավանական է, որ դուք երբևէ ցանկանաք փորձարկել SOAP-ը հենց այնպես, ինքներդ ձեզ համար (ինչպես կարող եք ստանալ REST-ով): Սա ծանր քաշային արձանագրություն է, որն օգտագործվում է ձեռնարկության լուրջ լուծումներում: Բայց դրա ծանրությունը նույնպես նվեր է փորձարկողին՝ բոլոր օգտագործվող տեխնոլոգիաները ստանդարտացված են, կան աշխատանքի համար բարձրորակ գործիքներ։ Փորձարկողից պահանջվում է միայն դրանք ուսումնասիրելու և օգտագործելու ցանկությունը։
Եկեք միասին հավաքենք փորձարկողի համար անհրաժեշտ հմտությունների նույն ստուգաթերթը: Այսպիսով, եթե դուք նոր եք սկսում փորձարկել SOAP ծառայությունները, դուք պետք է իմանաք և կարողանաք օգտագործել.
- wsdl.
- Օճառ.
- XML / XSD խմբագիրներ (XSD վիզուալիզացիայի մակարդակում):
- SoapUI 1-ին մակարդակում:
Ինչպես տեսնում եք, հիմնական շեշտը դրված է ուսուցման ստանդարտների վրա, SoapUI-ում բավական է միայն հարցումները կատարել կարողանալու համար: Երբ դուք սուզվում եք SOAP թեստավորման մեջ, դուք կբախվեք խնդիրների, որոնք կպահանջեն ավելի լուրջ հմտություններ և գիտելիքներ, բայց չպետք է փորձեք ամեն ինչ սովորել միանգամից: Շատ ավելի կարևոր է կատարվող առաջադրանքների բարդության մակարդակի բարձրացման հետևողականությունը: Հետևելով այս առաջարկին՝ մի օր կհասկանաք, որ դարձել եք լավ մասնագետայս տարածաշրջանում!
