Har lite frågor kring Python och SOAPpy, ifall någon här har kört det.
I så fall kommer det lite mer detaljer, men det handlar om SOAP-headers...
Någon här som har kört SOAPpy tillsammans med Python ?
OK. 
För det första är lite lite svårt att hålla isär vad som är SOAPpy,
"Zolera SOAP Infrastructure (ZSI)", "wstools" o.s.v. Dock ser det ut
som allt håller på att integreras under namnet "ZSI". Se :
http://pywebsvcs.sourceforge.net/
I SOAPpy/ZSI ingår ett verktyg (wsdl2py.py) som används för att
generera Python objekt och metoder samt data definitioner från
ett WSDL dokument (t.ex via en URL).
Allt ser ganska OK ut, men problemet är att wsdl2py inte fixar
definitioner, objekt och metoder för att hantera det som kallas
"SOAP-header". D.v.s där man ofta lägger "inloggning" och liknande.
Själva "SOAP-body" fungerar nog OK, så vitt jag kan förstå, jag har inte
till 100% än förstått hur man accessar variabler som ligger flera nivåer ner
i en objekt hirarki, men det är en senare fråga...
Den som har en en Python/ZSI installation kan prova :
Detta ska ge tre filer varav "client" och "types" är de intressanta.
Hur som helst, problemet är alltså att man måste skicka SOAP-header
med "low-level" SOAP verktyg, wsdl2py fixar inget för det.
Så, frågan är, har någon något exempel på generering av SOAP-headers ?
[Avbrott på EF servern...........
]
Så, under avbrottet så har jag hittat en del kod där man använder
SOAP anrop på lite lägre nivå för att skapa SOAP-headers, ska
köra lite tester så får vi se.
Hur som helst, det vore trevligt att höra om det finns någon mer
som har labbat med SOAPpy / ZSI.
För det första är lite lite svårt att hålla isär vad som är SOAPpy,
"Zolera SOAP Infrastructure (ZSI)", "wstools" o.s.v. Dock ser det ut
som allt håller på att integreras under namnet "ZSI". Se :
http://pywebsvcs.sourceforge.net/
I SOAPpy/ZSI ingår ett verktyg (wsdl2py.py) som används för att
generera Python objekt och metoder samt data definitioner från
ett WSDL dokument (t.ex via en URL).
Allt ser ganska OK ut, men problemet är att wsdl2py inte fixar
definitioner, objekt och metoder för att hantera det som kallas
"SOAP-header". D.v.s där man ofta lägger "inloggning" och liknande.
Själva "SOAP-body" fungerar nog OK, så vitt jag kan förstå, jag har inte
till 100% än förstått hur man accessar variabler som ligger flera nivåer ner
i en objekt hirarki, men det är en senare fråga...
Den som har en en Python/ZSI installation kan prova :
Kod: Markera allt
wsdl2py complexType http://api.tradera.com/v1/publicservice.asmx?WSDLHur som helst, problemet är alltså att man måste skicka SOAP-header
med "low-level" SOAP verktyg, wsdl2py fixar inget för det.
Så, frågan är, har någon något exempel på generering av SOAP-headers ?
[Avbrott på EF servern...........
]Så, under avbrottet så har jag hittat en del kod där man använder
SOAP anrop på lite lägre nivå för att skapa SOAP-headers, ska
köra lite tester så får vi se.
Hur som helst, det vore trevligt att höra om det finns någon mer
som har labbat med SOAPpy / ZSI.
-
Dust Storm
- Inlägg: 1
- Blev medlem: 18 februari 2008, 01:23:46
- Ort: Lund
Vad har du för alias på Tradera ?
Japp, det stämmer, jag håller på och tittat på lite Tradera verktyg för säljare.
Fick just igång SOAP-header hanteringen i går kväll (d.v.s i natt).
Så nu gick mitt första anrop mot Tradera från Python igenom (hämtar bara
officiellt klockslag från Tradera). Nu återstår att se hur man tolkar retur-
datat.
Här är ett exempel (kört mot riktigt data från en säljare). I detta fall är
auktionsdatat hämtat med ett C program och gSOAP. När jag gör
"print resp" på returvärdet från anropet så får jag bara:
> <PublicService_types.GetOfficalTimeResponse_Holder object at 0xE44CC8>
Jag antar att det bryder att "resp" är ett objekt, på något sätt...
Japp, det stämmer, jag håller på och tittat på lite Tradera verktyg för säljare.
Fick just igång SOAP-header hanteringen i går kväll (d.v.s i natt).
Så nu gick mitt första anrop mot Tradera från Python igenom (hämtar bara
officiellt klockslag från Tradera). Nu återstår att se hur man tolkar retur-
datat.
Här är ett exempel (kört mot riktigt data från en säljare). I detta fall är
auktionsdatat hämtat med ett C program och gSOAP. När jag gör
"print resp" på returvärdet från anropet så får jag bara:
> <PublicService_types.GetOfficalTimeResponse_Holder object at 0xE44CC8>
Jag antar att det bryder att "resp" är ett objekt, på något sätt...
Kod: Markera allt
help (resp)
Help on GetOfficalTimeResponse_Holder in module PublicService_types object:
class GetOfficalTimeResponse_Holder(__builtin__.object)
| Methods defined here:
|
| __init__(self)
|
| get_element_GetOfficalTimeResult(self)
|
| set_element_GetOfficalTimeResult(self, value)
|
| ----------------------------------------------------------------------
| Data descriptors defined here:
|
| GetOfficalTimeResult
| property for element (http://api.tradera.com,GetOfficalTimeResult), minOccurs="1" maxOccurs="1" nillable="False"
|
| __dict__
| dictionary for instance variables (if defined)
|
| __weakref__
| list of weak references to the object (if defined)
|
| ----------------------------------------------------------------------
| Data and other attributes defined here:
|
| __metaclass__ = <class 'ZSI.generate.pyclass.pyclass_type'>
| Stability: Unstable
|
| type for pyclasses used with typecodes. expects the typecode to
| be available in the classdict. creates python properties for accessing
| and setting the elements specified in the ofwhat list, and factory methods
| for constructing the elements.
|
| Known Limitations:
| 1)Uses XML Schema element names directly to create method names,
| using characters in this set will cause Syntax Errors:
|
| (NCNAME)-(letter U digit U "_")
|
| typecode = <PublicService_types.GetOfficalTimeResponse_Dec object at 0...
print resp
<PublicService_types.GetOfficalTimeResponse_Holder object at 0xE44B78>
$
Update...
För stora överföringar visar det sig att Python är väldigt slött. Antagligen
har det med den interna hanteringen av datastrukturer att göra...
Att hämta ett par 100 auktioner i samma SOAP transaktion är ganska OK,
men när det passerar ca 1000 auktioner så går performance i botten.
Samma sak fast med gSOAP/C har inga problem upp till i alla fall 30-40.000
auktioner i samma SOAP transaktion. Det är bara ADSL-linan som begränsar
prestandan.
Så det blir gSOAP/C för de större överföringarna. Kommer dock att behålla
Python p.g.a modulerna GdChart (diagramgenerering) och ReportLab (skapa
PDF filer). Samt databas interfacet...
För stora överföringar visar det sig att Python är väldigt slött. Antagligen
har det med den interna hanteringen av datastrukturer att göra...
Att hämta ett par 100 auktioner i samma SOAP transaktion är ganska OK,
men när det passerar ca 1000 auktioner så går performance i botten.
Samma sak fast med gSOAP/C har inga problem upp till i alla fall 30-40.000
auktioner i samma SOAP transaktion. Det är bara ADSL-linan som begränsar
prestandan.
Så det blir gSOAP/C för de större överföringarna. Kommer dock att behålla
Python p.g.a modulerna GdChart (diagramgenerering) och ReportLab (skapa
PDF filer). Samt databas interfacet...
Vid små volymer är det mest själva uppstarten av Python som
spelar in. Förrutom det inga större skillnader.
Vid något 100-tal auktioner är C lösning 2-3 gånger snabbare.
Vid ca 1000 auktioner eller mer avbröt jag Python transaktionen efter
10-15 minuter med CPU'n i 100%. Jag gav upp.
30-40.000 auktioner med C lösningen tar 5-6 minuter. Enbart begränsat
av ADSL linan (2Mb), men CPU'n i 5-10 % under tiden.
spelar in. Förrutom det inga större skillnader.
Vid något 100-tal auktioner är C lösning 2-3 gånger snabbare.
Vid ca 1000 auktioner eller mer avbröt jag Python transaktionen efter
10-15 minuter med CPU'n i 100%. Jag gav upp.
30-40.000 auktioner med C lösningen tar 5-6 minuter. Enbart begränsat
av ADSL linan (2Mb), men CPU'n i 5-10 % under tiden.
