Hallå!
I flera artiklar kommer jag att prata om möjligheterna att testa med hjälp av SoapUI hur 1C webbtjänster fungerar. Jag kommer också att ge exempel på returer från 1C-dokument i PDF-format och komplexa xml-filer. Vissa saker liknar här, men jag ska gå igenom mer komplexa exempel på att arbeta med webbtjänster. Men först ska jag gå igenom processen att starta webbtjänster och arbeta med SoapUI steg för steg så att det är lättare att ta reda på hur de fungerar från grunden.
1. Enkel webbtjänst
Till att börja med, låt oss ta en skelettkonfiguration utan webbtjänster och gå igenom processen att skapa dem steg för steg.
Låt oss lägga till en ny webbtjänst som heter test1 och skapa en hej-operation i den med en returtyp av sträng. Namnen på webbtjänster och verksamheter ska alltid anges på latin.
Du måste också ställa in namnutrymmes-URI och namnet på publikationsfilen:
När du klickar på förstoringsglaset i fältet "Procedurnamn" öppnas webbtjänstmodulen och du kan implementera hej-funktionen.
hello() funktion returnerar "sträng från webbtjänst 1s"; EndFunctions
2. Publicera en webbtjänst.
Nu, för att den resulterande funktionen ska vara tillgänglig via http, måste vi publicera vår tjänst på en webbserver. Apache 2.2 är lämplig för detta. Jag läste artiklar om hur du kan ställa in arbete med IIS och det verkade för mig mycket mer komplicerat. Efter att ha installerat och kört Apache 2.2 måste du gå till menyn Administration - Publicera på en webbserver. Fältet "katalog" måste fyllas i och innehålla Apache-installationskatalogen. Kom ihåg fälten "namn" och "adress" för webbtjänsten, de kommer att vara användbara för oss i nästa steg.
3. Testa med SoapUI
För att testa, låt oss skapa en separat WsUser-användare med ett enkelt lösenord och ge den fullständiga rättigheter.
Efter det, installera och kör SoapUI. Detta program är mycket praktiskt för att testa webbtjänster, det kan få deras beskrivning och göra efterförfrågningar till tjänster.
Vi går till menyn Arkiv - Nytt SOAP-projekt, ställer in projektnamnet hellotest och i fältet Initial WSDL skriver vi följande länk:
http://localhost/test_ws/ws/test1.1cws?wsdl
I den specificerades "test_ws"-delen i det sista steget i "name"-fältet och test1.1cws i "address"-fältet.
Klicka på OK och i detta skede måste du logga in genom att logga in under testanvändaren WsUser. Ett projekt och två bindande element kommer att skapas.
Soap12Binding är annorlunda genom att den fungerar på ny version SOAP 1.2 standard. Låt oss öppna elementet Request1 i test1Soap12Binding och se detta:
SoapUI visar vilken xml som kommer att skickas till vår funktion. Innan testet körs finns det ytterligare en nyans, som standard kommer SoapUI att kräva auktorisering för varje enskilt Request-element. Därför, för att inte ställa in det varje gång, måste du högerklicka på testSoap12Binding, välja Visa gränssnittsvy och i fönstret som öppnas, på fliken "Service Endpoint", ställ in namn och lösenord för webbtjänstanvändaren:
Om detta inte görs måste du för varje begäran ställa in auktorisering, klicka på Auth-knappen i den nedre panelen.
Nu kan vi äntligen göra en förfrågan till hej-funktionen och se svaret:
Jättebra, allt fungerade!
4. Skicka enkla parametrar till en funktion.
Nu ska vi göra det ny funktion med parametrar, till exempel, kommer vi att kontrollera arbetet med datum, vi kommer att göra funktionen getSaleDocNumbersByDate, som accepterar datumet för dokumentet (fakturan) och returnerar dokumentnumren för detta datum som en sträng. Låt oss lägga till datumparametern med dateTime-typen till operationen:
koden är så här:
getSaleDocNumbersByDate(date) function //StartDate = StartDay(date); slutdatum = slutDag(datum); urval av dokument = documents.Expenditure.Select(Startdatum, Slutdatum); nummer=""; while Documents selection.Next() number loop = numbers+"#"+Documents selection.Number+";"; slutet av cykeln; nummerretur; EndFunctions
Nu i SoapUI, högerklicka på testSoap12Binding-elementet och välj Uppdatera definition. Efter det kommer getSaleDocNumbersByDate-funktionen och en klar förfrågan om den att dyka upp i projektet. För att fylla i datumet måste du använda formatet "ÅÅÅÅ-MM-DDThh:mm:ss" (du kan titta på w3schools och rekommenderar STARKT att du använder denna sida för att förstå hur man arbetar med xml)
Då får vi följande förfrågan och svar:
5. XDTO-paket
Om det är nödvändigt att skicka mer komplexa parametrar till funktionerna (till exempel xml med flera fält), eller ta emot komplexa xml som svar, kan vi inte klara oss utan XDTO-paket.
Arbete med XDTO diskuteras mycket detaljerat i en serie artiklar. Faktum är att paketet definierar strukturen och typen av fält som används i xml-filer.
Jag kommer att överväga ett exempel på att skicka och ta emot en xml-fil vars typ är definierad i paketet
Och även i följande artiklar kommer jag att överväga exempel:
- överför till 1s en xml-fil som inte beskrivs i paketet i base64-format
- hämta från 1s ett pdf-dokument i base64-format och avkoda det
- hämta från 1s xml-fil med en kapslad struktur av element och bestämma deras antal
6. Överför till 1s i parametern för xml-filen, vars typ är definierad i paketet.
Uppgiften kommer att vara följande: hitta fakturadokumentet efter nummer och datum som anges i den inkommande xml-filen och returnera det hittade dokumentet. Du behöver också returnera den i form av xml med nummer, datum, motpart och dess kod och tabelldelen av varorna.
Låt oss skapa ett paket paket1 med namnområdet paket1_ns. För den inkommande xml-filen, låt oss definiera InDocSaleQuery-objekttypen med nummerfältet för strängtypen och datumfältet för dateTime-typen. För utdatafilen, låt oss först definiera typen för en rad i tabelldelen av produkterna: SaleItem med fälten namn på strängtyp, prissumma och kvantitet för decimaltypen. Och själva SaleDoc-dokumentet kommer att vara av en sammansatt typ: fälten nummer, datum, partnernamn och SaleItems-fältet som kommer att ha SaleItem-typen och det maximala antalet -1. Det är detta fält som betyder att det kan innehålla en array av flera element. Så här ser det ut i konfigurationen:
Först kommer jag att demonstrera koden för funktionen, och först då kommer jag att förklara vad som händer
Koden:
funktion getSaleDoc(incomingXML)DocNumber = incomingXML.number; DateDoc = inkommandeXML.datum; begäran = ny begäran; query.Text = "VÄLJ | ConsumableItems.Nomenclature.Name som namn, | ConsumableProducts.Pris som pris, | ConsumableProducts.Quantity as quantity, | ConsumableProducts.Montage as summa, | ConsumableProducts.Reference |FROM | Document.Consumable.Products AS Consumable.Products AS |WHERE | ConsumableProducts.Reference.Number = &Number | Och ConsumableProducts.Reference.Date = &DateDoc"; query.SetParameter("Number",doknummer); query.SetParameter("DateDoc",DateDoc); fetch = query.Execute().Select(); om fetch.Quantity()=0 så //returnerar ett errorDocumentType = FactoryXDTO.Type("paket1_ns", "SaleDoc"); DocumentPackage = XDTO Factory.Create(DocumentType); DocumentPackage.number = "Inga dokument hittades!"; Returnera PacketDocument; annars //create typesDocumentType = FactoryXDTO.Type("paket1_ns", "SaleDoc"); TablePartType = XDTO Factory.Type("paket1_ns", "SaleItem"); DocumentPackage = XDTO Factory.Create(DocumentType); //välj från tabelldelen sch=0; tills select.Next() loop om cn=0 då //fyll i dokumentdetaljer doc = selection.link; DocumentPackage.number = document.Number; DocumentPackage.date = doc.Date; DocumentPackage.partnerName = string(doc.Account); endif; //Fyll i tabellen partTablePartPackage = XDTO Factory.Create(TablePartType); FillPropertyValues(TablePartPackage, urval); //lägg till det i dokumentetDocumentPackage.SaleItems.Add(TablePartPackage); cn=cn+1; slutet av cykeln; Returnera PacketDocument; endif; EndFunctions
Det finns två huvudpunkter här. För det första: eftersom typen av inkommande parameter incomingXML ställdes in och denna typ deklarerades i paketet, är det omedelbart möjligt att komma åt fälten för denna inkommande xml. För det andra: arbeta med XDTO-fabriken. Från den erhölls typen för de resulterande utdataparametrarna och ett XDTOValue av denna typ skapades, där de nödvändiga fälten fylldes i. Det är också värt att notera att i SaleDoc-typen ska du ange ett separat fält för felet, men för teständamål kommer fel att registreras i nummerfältet.
Så här ser resultatet av denna begäran ut i SoapUI:
Som ni ser fungerar allt, men det finns fortfarande något att förbättra – till exempel skulle jag vilja veta hur många SaleItems-element vi har i dokumentet.
Jag kommer att prata om detta och mer komplexa exempel i nästa artikel.
I bifogat arkiv - urladdning av infobasen och SoapUI-projektet.
Använda Web Services Validation Tool för WSDL och SOAP
Tydligen, med tillkomsten av nya teknologier och standarder som XML och HTTP, har webbtjänster säkrat sin plats i pantheonen av internetinnovation. Men hur kom denna innovation till?
Grundkonceptet för webbtjänster kan spåras tillbaka i USA till mitten av 1960-talet. Inom transportbranschen, till exempel inom järnvägs- och rederier, nytt koncept elektroniskt datautbyte mellan datorer, vilket utvecklades vidare till EDI-teknik (Electronic Data Interchange – elektroniskt datautbyte). Jag hörde talas om EDI för första gången av en professor i handelshögskolan 1980.
1996 tillkännagav US National Institute of Standards and Technology en standard för EDI i Federal Information Processing Standards Publications (FIPS PUB 161-2). Enligt den publicerade specifikationen är EDI en standard för utbyte av starkt formaterade meddelanden mellan datorer. Behandlingen av de mottagna meddelandena utförs endast av datorn, och dessa meddelanden är vanligtvis inte avsedda för mänsklig tolkning. Det är precis vad webbtjänster gör, förutom att i mitten av 1960-talet fanns inte XML, Internet och World Wide Web.
För dem som inte är så bekanta med webbtjänster kommer jag kort att gå igenom definitionerna och huvudkomponenterna i webbtjänster.
Vad är webbtjänster
En webbtjänst är ett programvarusystem utformat för att stödja interaktioner mellan datorer mellan datorresurser över ett nätverk med SOAP-meddelanden (Simple Object Access Protocol) definierade av World Wide Web Consortium.
Simple Object Access Protocol (SOAP) är ett enkelt, utbyggbart protokoll för utbyte av strukturerade och maskinskrivna meddelanden i en decentraliserad, distribuerad nätverksmiljö. SOAP-meddelanden skrivs i formatet Extensible Markup Language (XML), ett enkelt och flexibelt textformat som kommer från Standard Generalized Markup Language (SGML) som utvecklats av International Organization for Standardization (ISO 8879:1986).
Web Services Description Language (WSDL) är ett XML-baserat språk som beskriver gränssnittet för webbtjänster.
Vad händer när felaktiga SOAP-meddelanden utbyts? Vad skulle hända om ett felaktigt SOAP-meddelande behandlades utan förvarning och till och med användes för att generera beslutsfattande information?
I praktiken är det omöjligt att avgöra om uppgifterna i ett SOAP-meddelande är korrekta eller inte. Du kan dock validera ett SOAP-meddelande för giltighet genom att titta på dess gränssnittsdefinition eller WSDL.
PÅ verkliga livet felsökningsproblem i SOAP-meddelanden är mycket svårt. Om det finns något fel i SOAP-meddelandet, mottas en HTTP-svarskod på 500 från webbtjänstservern. Webbtjänstservrar ger inte detaljerad information om vilken del av SOAP-meddelandet som har ett problem. Du kan hamna i en ännu värre situation där giltiga SOAP-svar tas emot från webbtjänstservern utan några felmeddelanden, och varken du eller dina webbtjänstservrar kan förstå problemen i dina SOAP-förfrågningar och svar. Till exempel ville du fråga den aktuella aktiekursen för företag B, men du skickade ett SOAP-meddelande med felstavade taggar till webbtjänstservern. Webbtjänstservern kan ignorera de dåliga taggarna och tillhandahålla ett standardvärde i SOAP-svarsmeddelandet, såsom aktiekursen för företag A. Om detta går obemärkt förbi kan konsekvenserna bli katastrofala.
Dessa typer av problem kan förebyggas tidigt med Web Services Validation Tool för WSDL och SOAP. Det låter dig validera SOAP-meddelanden med Web Service Definition Language (WSDL) innan du distribuerar applikationer som använder webbtjänsten. Programmet analyserar syntaxen och korrektheten för dina SOAP-meddelanden med WSDL och pekar ut problem genom att rapportera fel och radnummer i detalj. Som ett resultat får du inte längre irriterande HTTP 500-meddelanden. Är dina SOAP-meddelanden krypterade? Inga problem. Programmet kommer att dekryptera dem och kontrollera att de dekrypterade SOAP-meddelandena är korrekta.
Det här programmet skapades för att hjälpa supportpersonalen för IBM Web Services att lösa webbtjänsterrelaterade problem på IBM® WebSphere Application Server som rapporteras av kunder över hela världen. Programmet är utformat för att kontrollera riktigheten av SOAP-meddelanden. Om SOAP-meddelandet har en digital signatur kommer programmet att kontrollera det också. Med Web Services Validation Tool för WSDL och SOAP kan du till och med skicka SOAP-meddelanden till webbtjänstservrar och ta emot SOAP-svarsmeddelanden. Programmet skapades för att eliminera problem i industriell drift genom att använda det på tidiga stadier utveckling, samt för att minska tiden för att lösa problem som uppstår under drift.
Vi kommer att skapa en mycket enkel webbtjänst. Vi kommer först att skapa en enkel Java™-applikation. Efter att ha verifierat att Java-applikationen fungerar använder vi IBM Rational® Application Developer for WebSphere® Software för att skapa en webbtjänst. Vi kommer sedan att göra några ändringar i den genererade webbtjänsten. Slutligen använder vi Web Services Validation Tool för WSDL och SOAP för att skapa, validera, skicka och ta emot SOAP-meddelanden.
En enkel webbtjänst kan skapas med hjälp av IBM Rational Application Developer for WebSphere Software. Webbtjänster kan skapas på två sätt:
- Top-down utveckling Utveckling där Java-klasser som implementerar webbtjänster genereras från WSDL.
- Bottom-up-utveckling, där en webbtjänst genereras från en Java-böna eller en Java-böna för företag.
I följande exempel kommer vi att implementera en webbtjänst med hjälp av utvecklingsmetoden nedifrån och upp. Först kommer vi att skapa en enkel Java-applikation. Vi kommer sedan att generera en Java bean-webbtjänst från en Java-applikation med hjälp av programmet IBM Rational Application Developer for WebSphere Software.
Skapa en Java-applikation
Först skapar vi en Java-applikation som skickar en hälsning. Om inget namn anges kommer applikationen att returnera texten "Hej, kompis!". Om ett namn anges kommer applikationen att returnera texten "Hej" följt av det namnet. Nedan finns koden för DemoWebService Java-applikationen som finns i demopaketet. Hello()-metoden returnerar en sträng beroende på namnet.
Lista 1. DemoWebService.java
/* * @författare: Jinwoo Hwang * Copyright 2010 IBM Corporation */ paketdemo; public class DemoWebService ( public String hello(String name) ( if (name == null) returnerar "Hej, kompis!"; annars returnerar "Hej, " + namn + "!"; ) )Java-applikationstestning
Det är mycket viktigt att testa en Java-applikation innan du skapar en webbtjänst från den. För att köra ett program kan du skriva en klass med en main()-metod. Du kan också använda Universal Test Client-funktionen som tillhandahålls av IBM Rational Application Developer v7 för att snabbt testa utan att skriva testkod. Välj helt enkelt Universal Test Client från snabbmenyn för Java-klassen för att starta Test Client.
- Expandera i Universal Test Client Objekt > DemoWebService.
- Välj metod Hallå.
- Ange en sträng eller ditt namn i fältet värde och tryck på knappen Åberopa.
Du kan också testa med null-parametern och se vad som händer. Om null skickas till hello()-metoden, returneras strängen "Hello, kompis!", som förväntat.
Skapa en webbtjänst
Än så länge fungerar allt bra. Låt oss börja generera en webbtjänst från en Java-klass med hjälp av webbtjänstutvecklingsmetoden nedifrån och upp.
- Välj Java-applikationen DemoWebService och skapa en ny webbtjänst från IBM Rational Application Developer.
- Eftersom vi har skapat en Java-klass, välj Nedifrån och upp Java bean webbtjänst i listan över webbtjänsttyper. Välj Starta klient och tryck på knappen Avsluta. Om vi hade en EJB-klass skulle vi också kunna skriva en EJB (Java Enterprise bean) för att generera en webbtjänst.
Om allt gick bra kommer du att se den genererade DemoWebServiceDelegate.java i Java Resources bredvid DemoWebService.java.
När du tittar på DemoWebServiceDelegate.java kan du hitta @javax.jws.WebService Java-webbtjänstanteckningen som anger targetNamespace, serviceName och portName i klassen DemoWebServiceDelegate. En instans av DemoWebService skapas och en annan hello()-metod skapas från hello()-metoden för DemoWebService. Om du vill lära dig mer om Java-webbtjänstkommentarer, se Java Specification Request(JSR) 181, Web Services Metadata for Java Platform.
Lista 2. DemoWebServiceDelegate.java
/* * @författare: Jinwoo Hwang * Copyright 2010 IBM Corporation */ paketdemo; @javax.jws.WebService(targetNamespace = "http://demo/", serviceName = "DemoWebServiceService", portName = "DemoWebServicePort") public class DemoWebServiceDelegate ( demo.DemoWebService _demoWebService = new demo.DemoWebService(); public String hello( Strängnamn) (retur _demoWebService.hello(namn); ) )Skapa en WSDL
I ett klientprogramprojekt kan du också upptäcka att filerna DemoWebServiceService.wsdl och DemoWebService_schema1.xsd har genererats. DemoWebServiceService.wsdl innehåller information i Web Service Definition Language som beskriver nätverkstjänsterna för Java-applikationen du skapade tidigare. DemoWebServiceService_schema1.xsd innehåller ett XML-schema som beskriver strukturen för datatyper som används i SOAP-meddelanden.
När du tittar på filen DemoWebServiceService.wsdl kan du se att den har en uppsättning definitionselement i roten. Det finns 6 element i definitionselementet:
- typer (typer);
- meddelande (meddelande);
- portType (porttyp);
- bindande (bindande);
- tjänst (tjänst);
- hamn (hamn).
typer definierar de datatyper som används vid utbyte av meddelanden. I DemoWebServiceService.wsdl importerar vi DemoWebServiceService_schema1.xsd istället för att definiera datatyper i en WSDL-fil.
meddelande definierar de meddelanden som ska utbytas. Vi har 2 meddelanden: "hello" och "helloResponse". Hej-meddelandet har en del som kallas "parametrar". Den här delen har ett "tns:hello"-element. HelloResponse-meddelandet har en del som kallas "parametrar" som är samma som hej. Den här delen har ett "tns:helloResponse"-element. Hello- och helloResponse-elementen definieras i filen DemoWebServiceService_schema1.xsd. Vi kommer att granska dem inom kort.
Porttyp– Operationer som stöds av endpoints. Varje operation ger ett ingångs- och utmatningsmeddelande. Vår "hej"-operation består av ett ingångsmeddelande "tns:hej" och ett utmatningsmeddelande "tns:helloResponse". Dessa operationer motsvarar en begäran-svarsutbyte. WSDL tillhandahåller 4 olika primitiver för slutpunktsutbyte:
- enkelriktad (enkelriktad);
- begäran-svar (begäran-svar);
- begära-svar (efterfrågan-svar);
- anmälan (anmälan).
I en enkelriktad växling tar slutpunkten bara emot meddelandet. I en begäran-svarsutbyte tar en slutpunkt emot ett meddelande och skickar motsvarande meddelande. I en begäran-svarsutbyte skickar en slutpunkt ett meddelande och tar emot ett motsvarande meddelande. I ett meddelandeutbyte skickar slutpunkten bara ett meddelande.
Bindande definierar protokolldetaljer och meddelandeformatspecifikationer för operationer och meddelanden som specificeras av porttypen. För stilattributet använder vi värdedokumentet. Style-attributet ger 2 annan stil meddelanden: rpc och dokument. I rpc-stil innehåller meddelanden parametrar och returvärden. I dokumentformatet innehåller meddelanden dokument. Transportattributet anger URI:n för SOAP-transporten. Det angivna värdet http://schemas.xmlsoap.org/soap/http betyder att SOAP-specifikationen kommer att använda HTTP-bindning. URI:n för SOAPAction HTTP-huvudet för SOAP HTTP-bindningen anges i soapAction-attributet. Eftersom SOAP HTTP-bindning används krävs värdet för soapAction-attributet. För soapAction-attributet använder vi den tomma strängen "". Soap:body-elementet definierar hur meddelandedelarna är sammansatta i SOAP-meddelandets body-element. Användningsattributet ger 2 olika alternativ: bokstavlig (bokstavlig) och kodad (kodad). Vi använder bokstavlig. Det betyder att vi har valt definitionen särskilt schema, med antingen typattributet eller elementet. Den kodade varianten använder en abstrakt typ med kodningsregler.
Service definierar uppsättningen portar som ska användas.
hamn definierar kommunikationsändpunkten genom att ange nätverksadressen som ska bindas till.
nätverksadress att binda. I vårt fall är SOAP-slutpunktsadressen http://localhost:9081/HelloWorldWSProject/DemoWebServiceService .
Lista 3. DemoWebServiceService.wsdl
Schema skapande
Vi importerar DemoWebServiceService_schema1.xsd från DemoWebServiceService.wsdl. Tänk på filen DemoWebServiceService_schema1.xsd. Den är skriven i definitionsspråket XML Schema för att beskriva strukturen och begränsningarna för innehållet i XML-dokument. Vi har 2 element: hello och helloResponse. Varje element har en typ. Hello-typen har ett element "arg0" som är en sträng. Elementet "arg0" är valfritt eftersom värdet på minOccurs-attributet i dess deklaration är 0. Om minOccurs-attributet är satt till 1 eller högre måste elementet anges. Detsamma gäller för elementet "retur" i typen helloResponse.
Lista 4. DemoWebServiceService_schema1.xsd
Komma igång med Web Services Validation Tool för WSDL och SOAP
Så vi har täckt WSDL och schemat. Låt oss starta webbtjänstservern så att vi kan anropa webbtjänsten från Web Services Validation Tool för WSDL och SOAP.
För att köra valideringsverktyget för webbtjänster för WSDL och SOAP behöver du körtidsmiljön Java 6 (eller högre) och API:er för digitalisering och avkodning av XML som överensstämmer med specifikationerna för World Wide Web Consortium "XML Encryption Syntax and processing" (http:// www.w3.org/TR/xmlenc-core/).
IBM Java 6 tillhandahåller en implementering av JSR 106: XML Digital Encryption API:er. Om du har installerat IBM system Java 6 betyder att allt är klart att köra och du behöver inte installera något annat.
Om din Java 6 runtime-miljö, som Sun Microsystems™ Java 6, inte har XML Digital Encryption API:er måste du installera bibliotek som implementerar JSR 106 eller Apache™ XML Security version 1.4.3-paketet, som kan laddas ner från http :/ /santuario.apache.org/ . Ladda helt enkelt ner den binära distributionen, packa upp den i en katalog och berätta för verktyget var den katalogen är med hjälp av -vmargs och -DAXS kommandoradsalternativ.
När detta skrivs stöder Web Services Validation Tool för WSDL och SOAP JSR 106 och Apache XML Security version 1.4.3 för XML Digital Encryption and Decryption. Om du vill verifiera digitala signaturer i SOAP-meddelanden behöver du bibliotek som implementerar JSR 105: XML Digital Signature API:er. Lyckligtvis tillhandahåller virtuella Java 6-maskiner från Sun Microsystems och IBM implementeringar av JSR 105. Det är därför Java 6 valdes som minimikrav för en Java runtime-miljö. Om din Java 6-miljö inte tillhandahåller bibliotek som implementerar JSR 105 måste du hitta dem.
Web Services Validation Tool för WSDL och SOAP kan laddas ner här gratis. Dess installation är mycket enkel. Packa upp paketet i en katalog och kör wsvt.exe. Om din virtuell maskin Java är inte en standard Java 6-miljö som stöder digitala XML-signaturer och digital kryptering och dekryptering, du måste ange Java 6-platsen med alternativet -vm, till exempel:
wsvt -vm c:\IBMjava6\bin\java.exe
Återigen, om du har IBM Java 6 behöver du inte installera något annat. Allt du behöver finns redan i IBM Java 6. När du använder Java 6 från Sun Microsystems måste du tala om för programmet var Apache XML Security finns för att dekryptera krypterade SOAP-meddelanden.
Till exempel kommer följande kommando att köra ett program med Sun Java 6 och Apache XML Security-biblioteket version 1.4.3 som finns i katalogen C:\xml-security-1_4_3\libs:
wsvt –vm c:\SUNjava6\bin\java.exe –vmargs –DAXS=C:\xml-security-1_4_3\libs
Följande är en lista över Apache XML-säkerhetsbiblioteksfiler som faktiskt används av Web Services Validation Tool för WSDL och SOAP, även om Apache XML-säkerhetsversion 1.4.3 levereras med 9 burkar:
commons-logging.jar;
serializer.jar;
xalan.jar;
xmlsec-1.4.3.jar.
MANIFEST.MF för Web Services Validation Tool för WSDL och SOAP innehåller följande information:
Bundle-ActivationPolicy: lat
Bundle-ClassPath: .,
extern:$AXS$/commons-logging.jar,
extern:$AXS$/serializer.jar,
extern:$AXS$/xalan.jar,
extern:$AXS$/xmlsec-1.4.3.jar
Det är därför det var nödvändigt att specificera --vmargs --DAXS=C:\xml-security-1_4_3\libs för att Sun Java 6 skulle dekryptera krypterade SOAP-meddelanden.
Jag har ägnat en hel del tid åt att felsöka klassladdningskonflikter och inkompatibiliteter bland de XML-relaterade klasserna som finns i Sun Java Runtime Environment, Apache XML Security och några Eclipse-plugins. Att konfigurera IBM Java runtime-miljön var en bris eftersom den levereras med JSR 106-implementeringen och inte kräver Apache XML Security.
Skapa ett projekt
Nu, efter att ha ställt in och kört verktygsprogrammet, kan du skapa nytt projekt. Ett projekt kan innehålla en WSDL-fil, flera schemafiler associerade med WSDL-filen och SOAP-meddelanden i XML-filer. Om ett projekt har flera WSDL-filer används bara en av dem och de andra ignoreras när SOAP-meddelandets XML-fil valideras. För att använda en annan WSDL-fil måste du skapa ett separat projekt. Varje SOAP-meddelande måste finnas i en fil med filtillägget .xml, annars kommer det inte att behandlas som ett SOAP-meddelande.
- Högerklicka och välj Nytt > Projekt.
- Välj projekt i Allmän.
- Ange "Testprojekt" i fältet Projektnamn och tryck på knappen Avsluta.
Importera WSDL och Schema
Vi har skapat ett "Testprojekt". Nu kan du importera WSDL och XSD till den.
- Välj projektet och välj sedan från snabbmenyn Importera.
- Välj Filsystem i Allmän.
- Välj katalogen där WSDL och XSD är lagrade.
- Välj 2 filer (DemoWebServiceService.wsdl och DemoWebServiceService_schema1.xsd) och klicka på knappen Avsluta.
Översikt över WSDL och scheman
Nu har vi ett projekt med WSDL och XSD. Du kan dubbelklicka på vänster musknapp på en WSDL för att se WSDL i designläge och källläge. I designläge kan du rendera en webbtjänst med in- och utdata.
I källläge kan du visa och redigera WSDL i en textredigerare.
Om XSD-filer inte kan öppnas i XSD-editorn kan de öppnas i XML-editorn genom att välja Öppna med > XML Editor i snabbmenyn för den XSD-filen.
Vi har öppnat DemoWebServiceService_schema1.xsd i en XML-redigerare.
Skapa ett SOAP-meddelande
Så vi har WSDL och schema redo för att validera SOAP-meddelanden. Låt oss börja testa Web Services Validation Tool för WSDL och SOAP med ett SOAP-meddelande. Du måste inkludera SOAP-meddelandet i projektet. SOAP-meddelandet måste finnas i en fil med filtillägget .xml så att det kan valideras.
- Välj Nytt > XML för att skapa ett SOAP-meddelande i ett projekt.
- Välj testprojekt för den överordnade mappen för det nya SOAP-meddelandet. Om filen inte redan är markerad anger du "DemoSOAPMessage.xml" i fältet filnamn och tryck på knappen Avsluta.
Programmet anropar automatiskt XML-redigeraren med den nya XML-filen. Den innehåller inget annat än en sträng med xml-versionen och kodning. Det är bra att vi åtminstone har något innan vi börjar skapa ett SOAP-meddelande från grunden. Vet du hur man skriver ett SOAP-meddelande? Oroa dig inte. I nästa avsnitt kommer vi att gå igenom stegen för att skapa den.
För att skapa ett SOAP-meddelande kan du anropa "hej"-tjänsten med hjälp av parametern "parameters" med mitt namn - "Jinwoo". Självklart kan du använda din förnamn. Namnutrymmet http://demo/ används. Var försiktig - det stavas som http://demo/ , inte http://demo , det är viktigt.
Lista 5. HelloWorldSOAPmessage.xml
Ser du problem i det här SOAP-meddelandet? Om ja, oroa dig inte. Vi kommer att ta itu med detta senare.
Skickar ett SOAP-meddelande
Är du redo att skicka ett meddelande till webbtjänstservern?
- Välj SOAP-meddelande och välj
- I fönstret Transmit SOAP Request and Receive SOAP Response kan du fylla i Serviceadress, SOAPAction och innehållstyp. PÅ den här applikationen vi behöver inte ange SOAPAction eftersom vi använde den tomma strängen "" för soapAction-attributet i bindningsdelen av filen DemoWebServiceService.wsdl.
- Ange http://localhost:9081/HelloWorldWSProject/DemoWebServiceService i fältet Serviceadress om servern körs på den lokala maskinen på port localhost:9081. Annars måste du ange den riktiga adressen där webbtjänsten är tillgänglig.
- Välj text/html för fältet innehållstyp.
- Klicka på knappen OK för att skicka ett SOAP-meddelande till servern.
Tar emot ett SOAP-meddelande
Om servern är igång bör du få ett SOAP-svar. Om du inte får något svar, kontrollera att adressen och innehållstypen är korrekta.
SOAP-meddelandevalidering
Excellent! Vi har accepterat ett SOAP-svar. Det sparas också i projektet. Men vänta. Ser du att något är fel? Vi fick "Hej, kompis!" istället för "Hej, Jinwoo!". Något gick fel? Har ingen aning?
Tyvärr meddelade webbtjänstservern oss inte vad som var fel. Inga varningar. Situationen där oförutsägbara SOAP-svar skickas och webbtjänstservern inte har någon aning om vad som går fel kan vara mycket farlig. Även mottagare av SOAP-svar kanske inte märker problem i SOAP-meddelandet i fråga.
Valideringsverktyget för webbtjänster för WSDL och SOAP hjälper dig att avgöra vad som går fel.
Lista 6. Svar
- Välj SOAP-svarsmeddelandet och klicka på knappen Bekräfta.
Web Services Validation Tool för WSDL och SOAP hittade ett fel i SOAP-meddelandet.
Ogiltigt SOAP-meddelande:cvc-complex-type.2.4.a:Ogiltigt innehåll hittades som börjar med elementet "parametrar". En av "(arg0) förväntas.
Redigera ett SOAP-meddelande
- Programmet klagar på värdet "parametrar". Ändra det till arg0 och spara.
Lista 7. Modifierat SOAP-meddelande
- Kontrollera att det modifierade SOAP-svarsmeddelandet är korrekt. Inga fler felmeddelanden visas.
- Vi är nu redo att skicka det modifierade svarsmeddelandet till servern. Välj SOAP-meddelande och välj sedan Sänd SOAP-förfrågan och ta emot SOAP-svar.
- I fönstret Transmit SOAP Request and Receive SOAP Response anger du http://localhost:9081/HelloWorldWSProject/DemoWebServiceService i fältet Serviceadress om servern körs på port localhost:9081.
- Välj text/html för fältet innehållstyp och tryck på knappen OK.
Den här gången kommer som väntat rätt svar.
Lista 8. SOAP-svar
Upptäcker fel namnutrymme
Vad händer om du skickar ett meddelande med fel namnutrymme?
- Ändra namnutrymmet till http://demo2/ och spara meddelandet.
Lista 9. Ändra namnutrymmet
- Du kan sedan skicka en förfrågan till servern.
Du kommer att se ett IOException: Server returnerade HTTP-svarskod:500 för URI: http://localhost:9081/HelloWorldWSProject/DemoWebServiceService .
Webbtjänstservern returnerade information om IOException i svaret, men denna information är inte tillräcklig för att upptäcka felet. Kontrollera att meddelandet är korrekt med hjälp av verktyget om du vill få mer information för att lösa problemet.
Programmet säger: "Ogiltigt SOAP-meddelande:cvc-complex-type.2.4.a:Ogiltigt innehåll hittades som börjar med elementet 'ns0:hello". En av "("http://demo/":hej,"http://demo/":helloResponse)" förväntas".
Detta meddelande indikerar att http://demo/ förväntas. Det är denna, och inte 500 HTTP-svarskoden, som vi behöver veta.
Validerar krypterade SOAP-meddelanden
Vad händer om dina SOAP-meddelanden är krypterade? Inga problem om du har nycklar och lösenord. Välj bara ett SOAP-meddelande och Bekräfta på samma sätt som det görs för alla andra vanliga SOAP-meddelanden. Om ditt SOAP-meddelande är krypterat, kommer en prompt liknande den som visas i figur 35 att visas på skärmen.
När detta skrivs stöds tre typer av nyckellager (nyckellager):
- Java Key Store (JKS).
- Java Cryptography Extension Key Store (JCEKS).
- Syntaxstandard för personlig informationsutbyte (Public Key Cryptography Standards #12).
Du måste ange information om ditt nyckellager: filnamn, filtyp och lösenord. Om informationen är korrekt måste du välja nyckel och lösenord. Du kan också hitta information om dina nyckellager och listan över nycklar och certifikat i nyckellagret, till exempel nyckellagertyp, leverantörsnamn, leverantörsversion, leverantörsinformation, nyckeltyp, skapandedatum, certifikattyp, algoritm och format.
Om all information är korrekt kommer programmet att generera ett dekrypterat SOAP-meddelande och kontrollera om det är korrekt.
Stöds för närvarande följande algoritmer kryptering:
- Advanced Encryption Standard (AES) i Cipher Block Chaining-läge (CBC) med initialiseringsvektor (128/192/256 bitar).
- Advanced Encryption Standard (AES) Key Encryption (128/192/256 bitar).
- Trippel datakrypteringsalgoritm Driftlägen (trippel-DES) nyckelkryptering.
- Trippel datakrypteringsalgoritm Driftlägen (trippel-DES) Nyckelkryptering i CBC-läge (Cipher Block Chaining).
- RSA-krypteringsspecifikationer Version 1.5.
- RSA Optimal Asymmetric Encryption Padding (OAEP) är en metod med en maskgenereringsfunktion.
Validera digitalt signerade SOAP-meddelanden
Vad händer om ditt SOAP-meddelande är digitalt signerat? Välj bara SOAP-meddelandet och välj sedan SOAP Message Digital Signatur Verifiering.
Om den digitala signaturen är korrekt kommer du att se följande skärm:
Annars kommer programmet att rapportera ett fel i signaturen. Följande digitala signaturspecifikationer och algoritmer stöds för närvarande:
- Secure Hash Algorithm 1 (SHA-1)
- Hash Message Authentication Code (HMAC)
- Digital Signature Algorithm (DSA)
- Public-Key Cryptography Standards (PKCS #1)
- RSA-krypteringsalgoritm med Secure Hash Algorithm (SHA-1)
- Canonical XML version 1.0 och 1.1
- XSL Transformations (XSLT) version 1.0
- XML Path Language (XPath) version 1.0
- Bas 64
Åtkomst till US National Weather Service med ett SOAP-meddelande
Den enkla webbtjänsten vi skapade och testade fungerar bra. Är det möjligt att använda det här programmet i en "riktig" miljö? Du kan prova att arbeta med den riktiga webbtjänsten US National Weather Bureau som tillhandahålls av U.S. National Oceanic and Atmospheric Administration (NOAA).
- Skapa ett projekt.
- Skapa SOAP-meddelandet XML.
US National Weather Bureau tillhandahåller många olika webbtjänster. Du kan prova att arbeta med tjänsten NDFDgenByDay, som ger väderprognoser för en punkt med en given latitud och longitud.
För att komma åt NDFDgenByDay måste du ange följande information:
Tabell 1. NDFDgenByDay
| Tjänstens namn (tjänstens namn) | NDFDgenByDay |
|---|---|
| Slutpunkt (slutpunkt) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (SOAP action) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| encodingStyle (kodningsstil) | http://schemas.xmlsoap.org/soap/encoding/ |
| Namnområde (namnområde) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl |
| latitud (latitud) | Decimal nummer |
| longitud (longitud) | Decimal nummer |
| startdatum (startdatum) | datumet |
| antal dagar (antal dagar) | Heltal |
| format (format) | Linje |
I det här exemplet vill vi skapa en SOAP-förfrågan för att få en veckoprognos för en plats med koordinater (LAT38.9, LON-77.01) från och med 2010-07-23 i 24-timmarsformat:
Lista 10. SOAP begäran
Vi angav inte ett namnområde eftersom tjänsten fungerade utan en. Om det finns några problem med namnutrymmet, ställ in det.
Välj ett meddelande och Sänd SOAP-förfrågan och ta emot SOAP-svar i Web Services Validation Tool för WSDL och SOAP.
Tabell 2. Begäran om information
| namn | Menande |
|---|---|
| Slutpunkt (slutpunkt) | http://www.weather.gov/forecasts/xml/SOAP_server/ndfdXMLserver.php |
| SoapAction (SOAP action) | http://www.weather.gov/forecasts/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDFDgenByDay |
| Innehållstyp (innehållstyp) | text/xml; charset=utf-8 |
Nu är prognosdata mycket lättare att läsa.
Om det här rådet inte känns rätt för dig kan du använda din egen HTML-formateringsmetod. De flesta webbtjänster erbjuder resultat i XML-format, så du behöver inte använda det här tricket hela tiden.
Slutsats
Vi har skapat, konverterat, tagit emot och validerat SOAP-meddelanden med hjälp av Web Services Validation Tool för WSDL och SOAP. Detta program låter dig lokalisera problem som de flesta webbtjänstservrar inte ens kan upptäcka, vilket kan leda till allvarliga konsekvenser i verkligheten. Användningen av detta program i utvecklingsstadiet gör att du kan minska tiden för att felsöka problem under drift.
Webbtjänster i 1C
Den här artikeln kommer att överväga integrationen av 1C med befintliga webbtjänster och användningen av själva 1C som en webbtjänst.
Samtidigt kommer webbtjänster att förstås som system som fungerar på Internet och tillhandahåller interaktion med dem inte bara via SOAP (som exakt är en webbtjänst), utan även på andra sätt, inklusive vanliga HTTP (S)-förfrågningar.
Risker med att använda 1C webbtjänster
Implementeringen av webbtjänster dök upp i 1C81-plattformen.
Men deras användning är fylld med risker:
- 1C8 fungerar inte bra över HTTPS, det finns inga diagnostiska verktyg, så det är ibland omöjligt att förstå varför, om en tjänst har ett certifikat, den inte vill fungera via HTTPS. Utvägen är implementering av webbtjänster genom CURL eller höjning av en HTTPS-tunnel.
- 1C8 följer sina regler för validering av WSDL-scheman. Ibland, av oförklarliga skäl, vill WSDL-schemat inte laddas in i WS-länken. Du kan bara ta reda på orsaken på ett partnerforum från en specialist. Det finns inga diagnostiska verktyg för WSDL-schemat, inte ens en orsak eller en rad där schemaladdningen avbryts.
Regler för byggnadsförsäljningstjänster
Kunden får ett försäljningsdokument (kvitto) endast om transaktionen för tjänsten lyckades. Annars är en situation möjlig när kunden kommer att få en check och vara säker på att han fick tjänsten, men det är det faktiskt inte.
Använda externa SOAP-tjänster
SOAP-webbtjänster använder WSDL-scheman och XDTO-objekt för att representera data.
Ladda ner WSDL
För att kunna använda en extern tjänst måste du ladda dess WSDL-schema.
Kontrollera giltigheten av ett WSDL-schema
Ibland laddas inte WSDL-schemat in i 1C. Du kan kontrollera schemats giltighet (riktighet) med valfri WSDL-schemavalidator, till exempel http://www.validwsdl.com/ .
Du måste ladda upp schemat till någon http-sajt (du kan använda ftp) och ange adressen till filen där schemat laddas:
Funktioner för att ladda WSDL i 1C
Det speciella med att ladda WSDL i 1C är att giltiga scheman kanske inte laddas. Det finns ingen inbyggd validator, så du måste leta efter ett fel med den destruktiva analysmetoden, vilket successivt minskar antalet element i schemat. Du kan till exempel ta bort beskrivningen av en webbtjänst.
Bearbetning för att testa en extern webbtjänst som körs
För att testa en extern webbtjänst som körs, använd bearbetningen "TestArbitraryWebService.epf" från paketet för den här artikeln.
Testning kan användas på exemplet med Morpher-tjänsten som avvisar namn (serviceadress http://www.morpher.ru/WebServices/Morpher.asmx?WSDL):
På så sätt kan du testa vilken tjänst som helst som har enkla ingångspunkter som innehåller parametrar enkla typer: nummer, datum, sträng.
Under bearbetningen kan du också ange inloggningsnamn och lösenord som krävs för att auktorisera åtkomst till webbtjänsten.
Standardtjänstfelsökningsverktyg
För felsökning kan du använda programmet SoapUI, som kan skicka en godtycklig begäran till en webbtjänst och få ett svar från den.
SOAP och HTTPS
Tyvärr beter sig SOAP i 1C ganska nyckfullt när man arbetar genom HTTPS-protokollet, praxis visar att det är omöjligt att uppnå en HTTPS-anslutning, även om möjligheten deklareras i plattformen. Det saknas diagnostiska och felsökningsverktyg för att ta reda på orsakerna till att anslutningen inte upprättas. Därför är det bekvämt att använda SOAP via CURL.
Den inbyggda mekanismen för att använda HTTPS innebär att alla certifikat måste publiceras i en gemensam pem-fil i 1C-programkatalogen.
Använder 1C som en tjänst
Regler för att utveckla en tjänst baserad på 1C
Operation "Hej"
Det är god praxis att skapa en verksamhet i tjänsten som informerar om att tjänsten är tillgänglig. Detta gör livet lättare för integratörer, det blir lättare för dem att kontrollera om kopplingen till tjänsten är etablerad.
Till exempel kan du använda Hello-operationen utan parametrar, vilket helt enkelt returnerar det booleska värdet True.
Publicera en webbtjänst
Proceduren är väl beskriven i dokumentationen: file:///C:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81.htm#_Toc176167634 :
Uppgiften med att publicera webbtjänster är att placera konfigurationsfilerna *.1cws för webbtjänster i lämplig katalog på webbservern med lämpliga inställningar för webbservern. För att publicera webbtjänster bör du utföra menykommandot "Administration | Publicera webbtjänster.
Detta kommando öppnar fönstret Web Services Publishing.
Fönstret Web Services Publishing innehåller sökvägen till webbservern och två listor:
- "Webbtjänster" - en lista över konfigurationswebbtjänster;
- "Publicera" - en lista över webbtjänster publicerade på den angivna webbservern.
Använd knappen "Anslut..." för att ange på vilken webbserver du vill publicera webbtjänsterna.
Fönstret för val av webbserversökväg låter dig ange sökvägen på två sätt:
- på fliken "Filer" - den här metoden används när publiceringen utförs på samma dator där webbservern är installerad. Sökvägen anger den lokala katalogen som motsvarar internetsidan från vilken den publicerade webbservern kommer att anropas;
- på fliken "FTP-webbplats" - den här metoden används när du vill publicera en webbtjänst på en fjärrdator. För att utföra publiceringen måste du ange parametrarna för FTP-anslutningen med fjärrdator och katalogen där webbtjänsten kommer att publiceras.
Publiceringen av den valda webbtjänsten utförs med knappen "Publicera".
Knappen Ta bort används för att avpublicera webbtjänsten.
Du kan publicera till en lokal katalog eller via FTP. Du kan också publicera till en fjärrserver via en UNC-sökväg om fjärrservern är en del av det lokala nätverket.
Efter publicering är webbtjänsten tillgänglig på "http://localhost/test.1cws" eller "http://xxx.ru/test.1cws", där xxx.ru är adressen till fjärrservern och localhost är typisk adress för den lokala servern.
Behörighet till webbtjänsten 1C
Du måste vara autentiserad för att få tillgång till tjänsten.
Auktoriseringsfrågor diskuteras väl här: http://www.forum.mista.ru/topic.php?id=341168 och i dokumentationen file:///c:/Program%20Files/1cv81/AddDoc/RU/V8AddDoc81. htm
Vanligtvis körs en webbtjänst under en specifik användare (oftast en speciellt skapad). Du kan "koppla" en 1C-användare med Windows-autentisering till Windows IUSR_-användaren (inaktivera 1C-auktorisering för användaren). Alternativt kan du rensa listan över 1C-användare, då krävs ingen auktorisering.
Om flera användare krävs kan du skapa flera inloggningar för webbservern, binda en Windows-användare till var och en av dem och följaktligen registrera åtkomst till Windows-användare i 1C.
Användar- och lösenordsegenskaperna för WSProxy-objektet använder inte 1C-inloggningen, utan inloggningen för webbserveranvändaren.
Webbtjänsttestning 1C
För att testa 1C som en webbtjänst, använd bearbetningen "TestArbitraryWebService.epf", som beskrivs i avsnittet "Testa en fungerande extern webbtjänst".
1cws-filen är WSDL-beskrivningen av 1C-webbtjänsten.
Användning av tjänster inom detaljhandeln
I detaljhandeln används vanligtvis tjänster för att tillhandahålla olika tjänster till befolkningen - acceptera betalningar, återbetala lån, penningöverföringar, köpa programvara etc.
Samtidigt genereras ett kvitto för tjänsten som utförs i 1C, i vilket transaktionsparametrarna lagras. Därefter skrivs denna check ut till kunden med detaljerad information om den tillhandahållna tjänsten. Det är möjligt att skriva ut en preliminär kontroll för att klienten ska kunna bekräfta de uppgifter som angetts från hans ord med sin underskrift.
Tjänsten kan integreras i ett detaljhandelsprogram skrivet på 1C-språket (UT, Retail och andra) på olika sätt:
- Bearbetning eller kod kan skrivas på 1C-språk, vilket gör allt arbete med tjänsten.
- Ett program kan användas som fungerar med tjänsten, och som i 1C endast överför information för att bryta kontroller.
Organisation av tjänstedata i 1C
För att lagra information om transaktionen i kvittot måste du skapa en ytterligare tabellsektion "Komplex försäljning" med följande detaljer:
- Nomenklatur - bindande till checknomenklaturen.
- Parameter - länk till referensboken "Komplex försäljning: Parametrar".
- Värde - parametervärde, sammansatt typ. Strängrepresentationen måste vara ganska lång (1024 tecken) för att passa krysstexten.
Katalogen "Complex Sales: Parameters" innehåller en lista över transaktionsparametrar.
Det är mer lönsamt att använda den tabellformade delen än en uppsättning detaljer, eftersom en transaktion kan ha många av dem, och i andra kvitton som inte är relaterade till tjänsten kommer dessa uppgifter inte att användas och kommer att ta upp extra utrymme. Dessutom är en sådan lösning universell för alla tjänster och kräver ingen omstrukturering av data efter införandet av en ny tjänst.
Säljaren får ett separat bokmärke (eller ett tryckt formulär, för att inte ändra konfigurationen), där han kan se tabellen över transaktionsdetaljer för checken.
Använder bearbetning i 1C-språk
Tänk på exemplet med Paym-villkorstjänsten för konfigurationen "Detaljhandel".
- Låt oss komma in på 1C ett fördefinierat element i referensboken för "Paym"-nomenklaturen. I 1C:Enterprise-läge, efter uppdatering av konfigurationen, måste den tilldelas produkttypen "Service".
- I proceduren "Lägg till nomenklatur i tab. del" av formulärmodulen "Säljregistrering" kallar vi behandlingen av att arbeta med tjänsten, skriven i 1C. Vid lyckad betalning skriver vi ner och bokför checken:
- Bearbetningen bör skriva ut ett förkvitto (om det behövs), fylla i tabelldelen av komplex försäljning och förbereda texten för utskrift av ett kvitto i det fördefinierade attributet "PaymReceiptText".
- I proceduren "Boka och skriva ut en check" i checkmodulen ersätter vi produktens namn med det som sparats i detaljerna för checken. Texten ersätts endast vid försäljning, vid returer skrivs bara tjänstens namn ut, som vanligt.
En separat fråga är hur man säkerställer att transaktionen genomförs. De där. om transaktionen ägde rum i tjänsten, hur man säkerställer att den inte går förlorad i 1C. Det mest optimala sättet är avstämning av register. Men detta är föremål för en separat övervägande.
Använder program integrerade med 1C
XDTO
Ofta använder webbtjänster XDTO. Här är de flesta viktiga tips och recept för att använda XDTO i 1C.
XDTO i 1C-plattform
XDTO-paketen som beskrivs i grenen "XDTO Objects" i konfigurationen är tillgängliga för att skapa typer och objekt i den globala fabriken XDTO Factory. Detta är inte direkt uppenbart.
Vissa typer i schemat har inget namn, du måste gå igenom typhierarkin för att få dem.
Exemplet beskrev systemlistan, som innehöll XDTO-strukturer. För att skapa själva strukturen var det nödvändigt att få dess typ på följande sätt:
Typ = Factory.Type("urn:my.ru:MasterData:Business", "Business").Properties.Get("System").Type;
Täta problem med XDTO
Olika format av XSD-scheman
I vissa format kallas taggarna xs:, i vissa xsd:, men 1C förstår båda formaten säkert. En gång var det en situation att XSD normalt importerades till 1C utan fel, men skapade inte ett enda paket. Anledningen var frånvaron av ett attribut targetNamespace vid taggen, respektive, visste 1C inte i vilket paket schemat skulle placeras, men gav inga fel.
Service underhåll
Med tanke på att tjänsten är en kombination av två system - 1C och extern, kan fel finnas i båda systemen, vilket minskar den övergripande tillförlitligheten i arbetet.
För att göra det lättare att förstå orsakerna till fel i driften av tjänster, rekommenderas att använda en uppsättning åtgärder.
Begär loggning
Länkar
- XDTO
- Bra beskrivning av XDTO http://pro1c.org.ua/index.php?showtopic=214
- Gratis intressanta webbtjänster:
- Aeroflot - flygtidtabellsinformation
- Morpher - deklination av namn http://www.morpher.ru/WebServices/Morpher.aspx
- Omonterad:
- Installera och använda webbtjänster
- v8: hur ändrar man apache-konfigurationsfilen?
- v8: fortsättning på ämnet med webbtjänster - kan inte ansluta webbtjänsten
- v8: Jag söker igenom webbtjänster - jag kan inte skapa en proxy...
- Kunskapsbok: v8: Använda externa webbtjänster i 1C:Enterprise 8;
- Installera och använda webbtjänster
Sällan nuförtiden modern applikation klarar sig utan API. Detta gäller både för en enkel webbplats och för högt belastade distribuerade system. API-testning är en av huvuduppgifterna i kvalitetssäkringsprocessen. Inte överraskande ökar efterfrågan på testare som vet hur man testar API:er dag för dag. I den här kursen får du en förståelse för metoderna, verktygen och tillvägagångssätten inom API-testning, skaffar dig nödvändig kunskap, vilket utan tvekan kommer att ha en positiv effekt på ditt värde som testspecialist.
Den här kursen kommer att vara användbar för studenter som är bekanta med grunderna i mjukvarutestning och som vill växa ytterligare och förbättra sina färdigheter.
Kursprogram:
Lektion 1. Inledande. SOAP-protokoll
- Kort om föreläsaren;
- Kursens mål;
- Vad är API, WS och varför behövs de;
- API-testningens roll i kvalitetssäkringsprocessen;
- Översikt över WS testverktyg;
- Metoder som används vid WS-testning;
- SOAPs historia;
- Terminologi och huvudkoncept (XML, XSD, Endpoint, WSDL).
Lektion 2: SOAP-protokoll. REST-arkitektur
- Terminologi och huvudkoncept (UDDI, XSLT, XPath, XQuery, HTTP-metoder, HTTP-statusar);
- Struktur och huvudkomponenter i SOAP;
- Tillämpningsområde;
- Funktioner av arbete;
- Fördelar och nackdelar;
- Funktioner i REST-arkitekturen;
- Terminologi och huvudkoncept (WADL, RESTful, JSON, JSONPath);
- REST-principer;
- Statuskod och huvudstatusar;
- CRUD verb;
- Fördelar och nackdelar.
Lektion 3. Introduktion till SoapUI. Arbetar med ett REST-projekt
- Java-installation;
- SoapUI installation;
- Översikt över huvudelementen i gränssnittet;
- Koppling av utbildningsprojektet;
- Genomgång av projektmetoder;
- Skicka en förfrågan och analysera det mottagna svaret;
- Granska de tillgängliga webbtjänsterna för projektet;
- Utarbeta en testplan;
- Skriva testfall;
- Elementen "TestSuite", "TestCase", "TestSteps".
Lektion 4. Arbeta med REST-projekt (XML)
- Blockera "påståenden";
- Köra tester på olika nivåer;
- Element "Egenskaper", huvudfunktioner;
- Arbeta med egenskaper;
- Element "Fastighetsöverföring";
- Arbeta med påståenden
Lektion 5. Arbeta med ett REST-projekt (JSON)
- Villkor och grenar;
- Arbeta med påståenden;
- TestRunner, funktioner i arbetet;
- Kör TS, TC från kommandoraden;
- Arbeta med Testrunner;
- Arbeta med Groovy skript
Lektion 6. Arbeta med Groovy-manus
- Arbeta med statisk och dynamisk data;
- Vi genererar testdata;
- Vi får data från "Egenskaper";
- Dataregistrering och överföring;
- Villkor och grenar;
- Manuspåstående.
Lektion 7. Ytterligare funktioner
- Ansluta externa bibliotek och anpassade klasser;
- Spottjänster;
- Varför Mock Services behövs;
- Ett exempel på att arbeta med en Mock-tjänst;
- Men hur är det med CI?
- Installera Jenkins;
- Startar ett projekt om Jenkins.
SOAP (Simple Object Access Protocol)är ett standardiserat meddelande som skickar protokoll mellan en klient och en server. Det används vanligtvis i samband med HTTP(S), men kan också fungera med andra applikationslagerprotokoll (som SMTP och FTP).
Att testa SOAP när det gäller testteknik skiljer sig inte i grunden från att arbeta med andra API:er, men det kräver preliminära förberedelser (när det gäller protokollteori) och speciella testverktyg. I den här artikeln skulle jag vilja formulera en liten checklista med nödvändiga kunskaper och färdigheter som kommer att vara lika användbara både för en SOAP-testare (som ofta inte har en aning om "vad man ska ta tag i" efter att ha satt en uppgift), och för en chef som tvingas utvärdera testares kunskaper och ta fram planer för lärande.
Teoretisk grund
Att SOAP är ett protokoll är av stor betydelse för testning: du behöver studera själva protokollet, de "primära" standarder och protokoll som det bygger på, och (efter behov) befintliga tillägg.
XML
XML är ett märkningsspråk som liknar HTML. Alla meddelanden som skickas/mottas via SOAP är ett XML-dokument där informationen är bekvämt strukturerad och lätt att läsa, till exempel:
Glöm inte att skriva en artikel!
Du kan lära dig mer om XML på w3schools eller codenet (på ryska) . Var noga med att vara uppmärksam på beskrivningen av namnutrymmen (en metod för att lösa konflikter när du beskriver element i XML) - i SOAP är deras användning nödvändig.
XSD
När du arbetar är det alltid bekvämt att ha en standardiserad beskrivning av möjliga XML-dokument och kontrollera att de är korrekta i fyllningen. Det finns en XML Schema Definition (eller XSD för kort) för detta. De två huvudfunktionerna hos XSD för testaren är beskrivningen av datatyper och införandet av begränsningar för möjliga värden. Till exempel kan elementet från föregående exempel göras valfritt och begränsas till 255 tecken med XSD:
...
...
SOAP-förlängningar
I ditt arbete kan du också stöta på olika "tillägg" till SOAP - standarder som WS-* . En av de vanligaste är WS-Security, som låter dig arbeta med kryptering och elektroniska signaturer. Ofta används en WS-Policy med den, med vilken du kan hantera rättigheterna att använda din tjänst.
Ett exempel på användning av WS-Security:
Alla dessa tillägg räcker komplexa strukturer, används inte i alla SOAP-tjänster; att studera dem i detalj i det inledande skedet av att bemästra SOAP-testning är osannolikt relevant.
Verktyg
Som du redan förstått är SOAP en allvarlig fråga, för att arbeta med den behöver du känna till teorin och många standarder. I praktiken skulle en sådan komplexitet leda till mycket påtagliga arbetskostnader (till exempel skulle det vara nödvändigt att titta på schemat i en anteckningsbok varje gång och skicka förfrågningar med curl). Därför har verktyg skapats för att göra arbetet med SOAP enklare.
XML/XSD-redigerare
En bra testare börjar testa när du skriver dokumentation, så det är bekvämt att använda speciella redaktörer för att kontrollera scheman. De två mest kända är Oxygen (plattformsoberoende) och Altova (endast Windows); båda är betalda. Dessa är mycket kraftfulla program som analytiker aktivt använder när de beskriver tjänster.
I min praktik visade sig tre funktioner hos redaktörer vara användbara: XSD-visualisering, XML-generering baserad på XSD och XML-validering på XSD.
1. XSD-visualisering behövs för en visuell representation av schemat, så att du snabbt kan isolera de nödvändiga elementen och attributen, såväl som befintliga begränsningar. Till exempel, för en CheckTextRequest-begäran, krävs textelementet, och alla tre attributen är valfria (med optionsattributet inställt på standardvärdet noll).
Visualisering är nödvändig när det finns många typer och begränsningar i schemat. Om det är allt du behöver och inte vill betala för dedikerade redigerare, kan gratisalternativ (som JDeveloper) övervägas.
2. XML-generering baserad på XSD användbart när du vill se ett giltigt exempel på ett meddelande. Jag använder den för att snabbt experimentera med eventuellt komplettering av meddelandet och kontrollera nyanserna av hur begränsningar fungerar.
3. Efter att ha använt funktionen från punkt 2 är det användbart att XML-validering mot XSD- det vill säga, kontrollera meddelandet för korrekthet. Tillsammans låter funktionerna 2 och 3 dig fånga knepiga defekter i XSD även när själva tjänsten är under utveckling.
Testverktyg - SoapUI
SOAP-testning innebär nästan alltid att man använder SoapUI. Du kan läsa om användningen av detta verktyg i olika källor (,), men det är mest effektivt att läsa den officiella dokumentationen. Jag särskiljer 8 villkorade nivåer av SoapUI-färdighet:
Nivå 1 - Jag kan skicka förfrågningar
Lär dig hur du skapar ett projekt baserat på WSDL. SoapUI kan generera alla nödvändiga förfrågningar åt dig; du behöver bara kontrollera att deras fyllning är korrekt och klicka på knappen "Skicka". När du har bemästrat konsten att göra giltiga frågor måste du behärska konsten att göra ogiltiga frågor, orsakar utseendet fel.
Nivå 2 - Jag kan göra testsviter och testfall
Börja göra mini-autotester. Testsviter och testfall låter dig skapa API-testskript, förbereda data för förfrågningar och automatiskt kontrollera det mottagna svaret mot det förväntade. Till en början kan de enkelt användas som samlingar av frågor. Om du till exempel har en defekt och snabbt vill kontrollera den efter en åtgärd, kan du tilldela en separat testsvit specifikt för defektförfrågningar.
Nivå 3 – kan skriva påståenden
Efter att ha bemästrat testfall kommer det att vara användbart för dig att lära dig hur du gör dem automatiskt verifierbara. Därefter behöver du inte längre leta efter information om svaret med dina "ögon": om det finns en automatisk kontroll kommer fallen att markeras med grönt (om kontrollen godkänns) eller röd (om den inte godkänns) . SoapUI tillhandahåller en stor uppsättning möjliga kontroller (påståenden), men de mest bekväma och enkla är Contains och Not Contains. Med deras hjälp kan du kontrollera närvaron av en viss text i det mottagna svaret. Dessa kontroller stöder även sökningar med reguljära uttryck.
Nivå 4 - använder XPath och/eller XQuery i Assertions
För dem som är lite bekanta med UI som använder Selenium, är XPath-språket en bekant sak. Grovt sett låter XPath dig söka efter element i ett XML-dokument. XQuery är en liknande teknik som kan använda XPath internt; detta språk är mycket kraftfullare, det liknar SQL. Båda dessa språk kan användas i Assertions. Kontroller med deras hjälp är mer riktade och stabila, så dina fall blir mer trovärdiga.
Nivå 5 – kan skriva komplexa tester med hjälp av speciella steg
Testfall kan innehålla inte bara en begäran, utan också flera (till exempel när du vill emulera ett standardanvändarscenario "skapa en enhet" → "exportera en entitet"). Det kan finnas andra särskilda steg mellan förfrågningar, till exempel:
- Egenskaper och fastighetsöverföring (hjälp till att återanvända data och överföra dem mellan förfrågningar);
- JDBC Request (används för att hämta data från databasen);
- Villkorlig Goto (låter dig göra grenar eller slingor i ett testfall);
- Kör TestCase (hjälper till att placera några typiska frågor i separata testfall och anropa dem där det behövs).
Nivå 6 - med Groovy-skript
SoapUI låter dig skriva Groovy-skript i olika platser. Det enklaste fallet är att generera data i själva frågan med hjälp av $(=)-inlägg. Jag använder dessa plugins hela tiden:
- $(=new Date().format("åååå-MM-dd'T'HH:mm:ss"))– för att infoga aktuellt datum och tid i önskat format;
- $(=java.util.UUID.randomUUID())– för att infoga en välformad slumpmässig GUID.
Fullständiga skript kan användas som steg i fall och tester. Vid något tillfälle kommer du att upptäcka att flera specialsteg från den femte nivån kan ersättas med ett skript på en gång.
Nivå 7 - använder MockServices
SoapUI baserat på WSDL kan generera Mock-objekt. Ett skenobjekt är den enklaste simuleringen av en tjänst. Med hjälp av "mocks" kan du börja skriva och felsöka testfall redan innan tjänsten faktiskt är tillgänglig för testning. De kan också användas som "stubbar" för tillfälligt otillgängliga tjänster.
Nivå 8 - gud SoapUI
Vet du skillnaden mellan betald och gratisversioner SoapUI och använd SoapUI API i kod. Du använder plugins och kör fall genom kommandoraden och/eller CI. Dina testfall är enkla och lätta att underhålla. I allmänhet "äter du upp hunden" på detta instrument. Jag skulle älska att prata med någon som behärskar SoapUI på den här nivån. Om du är det, skriv gärna en kommentar!
Testa med programmeringsspråk
Jag kommer att ge ett exempel på hur en begäran till YandexSpeller API ser ut, gjord med groovy-wslite:
importera wslite.soap.*
def client = new SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def response = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") (
kropp (
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") (
text("fel")
}
}
}
hävda "error" == response.CheckTextResponse.SpellResult.error.s.text()
hävda "1" == [e-postskyddad]()
Så vitt jag vet finns det inga ramverk på hög nivå (som Rest-assured) för SOAP-testning ännu, men ett intressant verktyg har nyligen dykt upp - karate . Med den kan du beskriva fall för att testa SOAP och REST i form av scenarier som gurka/gurka. För många testare kommer referensen till karate att vara idealisk lösning, eftersom sådana scenarier, när det gäller komplexiteten i att skriva och stödjande fall, kommer att ligga någonstans i mitten mellan att använda SoapUI och att skriva ditt eget SOAP-testramverk.
Slutsats
Det är osannolikt att du någonsin kommer att vilja testa SOAP bara så, för dig själv (som du kan få med REST). Detta är ett tungviktsprotokoll som används i seriösa företagslösningar. Men dess tyngd är samtidigt en gåva till testaren: all teknik som används är standardiserad, det finns högkvalitativa verktyg för arbete. Allt som krävs av testaren är viljan att studera och använda dem.
Låt oss sätta ihop samma checklista med nödvändiga färdigheter för en testare. Så om du precis har börjat testa SOAP-tjänster måste du veta och kunna använda:
- wsdl.
- TVÅL.
- XML / XSD-redigerare (på XSD-visualiseringsnivå).
- SoapUI på nivå 1.
Som du kan se ligger huvudfokus på inlärningsstandarder, i SoapUI räcker det bara för att kunna utföra förfrågningar. När du dyker in i SOAP-testning kommer du att möta uppgifter som kommer att kräva mer seriösa färdigheter och kunskaper, men du bör inte försöka lära dig allt på en gång. Mycket viktigare är konsekvensen när det gäller att öka komplexiteten för de utförda uppgifterna. Efter denna rekommendation kommer du en dag att inse att du har blivit det en bra specialist i denna region!
