SOAP Library - More

Mark Wieder mwieder at
Mon Oct 8 18:30:38 EDT 2007


Well, the library stack wasn't really written to be released into the wild 
like that. I do what Mark Smith does: put templates into custom properties 
and then retrieve them and replace parameters.

constant kWSURL= ""
constant kWSNamespace= ""

ON PerformAction pAction
    local tPartnerKey
    local tRegCode
    local tParams
    local tHeader

    put empty into field "fldResults"
    put empty into field "fldResponse"
    put empty into field "fldSOAP"

    put field "fldPartnerKey" into tPartnerKey
    put field "fldRegCode" into tRegCode

    put PackageParameters("Key", tPartnerKey, "string") into tHeader
    put PackageParameters("AuthenticationHeader", tHeader, "", kWSNamespace) 
into tHeader
    put PackageParameters("ActivationCode", tRegCode, "string", 
kWSNamespace) into tParams

        put SOAP.RPCRequest(kWSURL, \
                pAction, \
                kWSNamespace, \
                tParams, \
                "" & pAction, \
                tHeader \
                ) into field "fldResponse"
        put SOAP.Response() into field "fldResults"
        put SOAP.Envelope() into field "fldSOAP"
    CATCH e
        -- this is here for timeouts
        answer e
END PerformAction

where the custom property uSOAPEnvelope of the library stack ($HEADER, 
$METHOD, and $PARAMS will be replaced in the call to SOAP.RPCRequest by the 
appropriate parameters) is:

<?xml version="1.0" encoding="UTF-8"?>

(...and obviously you'll need to know the proper parameters from the 
wsdl...) Hope this helps. For me the hardest part was figuring out the 
proper authentication header format, and I only got that right by ngrepping 
the network traffic.

 Mark Wieder
 mwieder at

More information about the use-livecode mailing list