SOAP 1.2 support added

Very useful feature. However, I don't need to set an actor and so when I attempt to make an api call, I get this warning 3 times:

SoapHeader::SoapHeader(): Invalid actor wsclient_soap.module:85

Happens regardless of whether I set the actor to empty string or NULL, in the code. The attached patch re-roll fixes that by only setting the argument in the SoapHeader call if not empty.

I couldn't apply the patch.

$ git apply -v 2065037-4-soap_1_2_support.patch
Checking patch wsclient_soap/wsclient_soap.module...
Checking patch wsclient_ui/wsclient_ui.inc...
Checking patch wsclient_ui/wsclient_ui.module...
Checking patch wsclient_tester.inc...
error: wsclient_tester.inc: No such file or directory

However wsclient_tester/wsclient_tester.inc does exist. It doesn't appear to be looking in the subdirectory.

We have a need for nested headers. This is possible with SOAP headers, see this example. The $data parameter is mixed data type.

The UI would be the trickiest part for this I think, but as dman mentioned, we could use the structured-input-field-renderer code from the wsclient_tester.

Patch in #8 applies ok but there's no "add more" button for additional headers. To gain an extra row, enter data into the first one the click save and re-edit.

I also tested it for my specific situation to see if it work would without nesting headers, to no avail.

As the headers may be a string or an array or other, the UI could get interesting.

The header requirements for each method are actually defined in the WSDL I'm working with. Is this a normal approach?

http://ws.idssasp.com/Members.asmx?wsdl

For e.g. do a search for "GetMemberList" including the quotes.

<wsdl:operation name="GetMemberList">
  <soap:operation soapAction="http://ws.idssasp.com/Members.asmx/GetMemberList" style="document"/>
  <wsdl:input>
    <soap:body use="literal"/>
    <soap:header message="tns:GetMemberListAuthorizeHeader" part="AuthorizeHeader" use="literal"/>
  </wsdl:input>
  <wsdl:output>
    <soap:body use="literal"/>
  </wsdl:output>
</wsdl:operation>

The parameters are also defined, but these don't show up automatically in the method configuration. I suspect there may not be a standard for this.

I just realised the significance of this:

This is available on a per-operation config. If needed, it's likely we should add global ones too, but I've not done that today.

With auth headers and lots of methods this would be very useful.

Understood. It's not a huge priority anyway. Nested and global headers probably are, and I could potentially take a look at this sometime.

I also think the parameters for each method are being found but not recognised automatically as their Drupal generated machine name is different to their value. Again, not a big issue.

That thing saying 'parameters' is just a reflection of how wsclient analyses the WSDL. the actual machine name is moot AFAIK, it's the datatype that counts (and works)

It does indeed. I was getting confused by the name, which was integer and string where required, and "parameters" otherwise. Also, the WSDL I'm working with involves a single parameter, which is an array of other parameters. So these are all nested too! Much UI fun to be had.

I do understand job priorities. I won't be able to work on this as a patch at the moment but will hopefully have a better understanding and code to share by the end of it.

Semi related: after further reading, I see WSDL is a very well defined and structured language. Pretty much everything can be defined in it so I can see how complete auto-configuration would be possible with the right data in the endpoints.

I have one form on my site for which I need to submit up to 3 SOAP operations, one after the other (I know, ugh!). The SoapHeaders need to be different for each operation, but the __setSoapHeaders() call doesn't overwrite the existing headers unless you set them to NULL first, like this: $client->__setSoapHeaders(NULL);

Same as patch #8, against latest git in case anyone wants to play.

Clear your cache after patching.

Is there something similar for REST header?

Never mind the url was broken.

It just so happens that I rerolled this myself and was going to upload it now. I noticed you made an extra change? Here's the output from a simple diff:

> @@ -113,7 +113,7 @@ function wsclient_tester_prepare_request_callback($form, $form_state) {
>      $args = $form_state['values']['parameters'];
>    }
> 
> -  if ($service->type == 'soap') {
> +  if ($service->type == 'soap' || $service->type == 'soap 1.2') {
>      // The service will have an endpoint that will have a SOAPClient.
>      // Settings on the service->options may be passed to the SOAPClient.
>      // @see WSClientSOAPEndpoint::client()

I know you want to put this to bed, but I have a suggestion, yet not necessarily the time to commit to it myself:

Specific SOAP endpoint sets Authetnication in the Header, and the WSDL provides the an Authentication data structure, but this patch doesn't implement the ability to define a data structure or attach data to the header, plain text only.

I'm not sure how common this practice would be, if it's just something specific to his particular endpoint, but I could see it being useful.

Additionally, I would see it being useful to change the Header values on subsequent Rules, but it appears the header values can only be set via the service definition (and code I assume).

Just my 2c.

In addition to the last comment, it appears that I can't do what I need to via the UI with the current approach, which is:

    <Authentication xmlns="https://...">
      <UserName>...</UserName>
      <Password>...</Password>
    </Authentication>

I am able to set the header via code though which is a step forward.

Additionally, while #8 does visually reduce the code for the Actor check, it does re-introduce the error #4 sought to fix, which is regardless of $actor being NULL or an empty string, the error message continues to be set. The argument can not be set at all if it doesn't have a value, and as such there has to be two calls to the function instead of one with a nested conditional.

Re-roll attached.

Can someone explain the use of additions mentioned in this thread?

I am trying to add the following header to my SOAP request:

  <soap:Header>
    <HTNGHeader xmlns="http://htng.org/1.1/Header/">
      <From>
        <systemId>string</systemId>
        <Credential>
          <userName>string</userName>
          <password>string</password>
        </Credential>
      </From>
      <To>
        <systemId>string</systemId>
      </To>
      <timeStamp>dateTime</timeStamp>
      <echoToken>string</echoToken>
      <transactionId>string</transactionId>
      <action>string</action>
    </HTNGHeader>
  </soap:Header>

is this possible with this patch? Is it possible in code?

even before this patch i could see terms shown in this header listed in the data types under each Operation: http://screencast.com/t/X1sn5X5VH0X0 but have no idea how to utilize this.

@liquidcms

I had essentially the same scenario, and I can confirm that the patch does not cater for it via the UI. Your header is far more complicated than mine was, which may make it tricky to do via code, but the general concept is this:

function HOOK_wsclient_invoke_arguments_alter(&$arguments, $operation, $service) {
  switch ($service->name) {
    case 'SERVICE_NAME':
      $service->operations[$operation]['header'] = array(
        'HTNGHeader' => array(
          'namespace' => 'http://htng.org/1.1/Header/',
          'name'      => 'From',
          'data'      => array(
            ...
          )
        ),
      );
      break;
  }
}

Although, I might have that slightly wrong. Play with it, and xdebug/debug it further down the line so you can see the xml that is generated.

Ideally the patch needs to be re-worked to allow for structured data to be applied to the header.

thanks deciphered, dman had shown me how to do this a couple nights ago.. he ended up with this using the same hook you mention:

    $htngheader = array(
      'namespace' => 'http://htng.org/1.1/Header/',
      'name' => 'HTNGHeader',
      'data' => array(
        'From' => array(
          'systemId' => 'systemid value',
          'Credential' => array(
            'userName' => 'username',
            'password' => 'password',
          ),
        ),
        'To' => array(
          'systemId' => 'string',
        ),
        'timeStamp' => date('c'),
        'echoToken' => 'string',
        'transactionId' => 'string',
        'action' => 'our action',
      ),
      'mustunderstand' => '',
    );

    $client->operations[$operation]['header'] = array($htngheader);

I tried applying the patch in #26 and #30, and both give me a white screen of death. (I'm running the latest Drupal 7, with Web service client 7.x-1.x-dev.)

I really need to create a soap header like this:

<soap:Header>
    <AuthHeader xmlns="http://www.example.com/">
        <username>USERNAME</username>
        <password>PASSWORD</password>
        <tpaid>TPAID</tpaid>
        <AdviceProviderCd>Foo</AdviceProviderCd>
    </AuthHeader>
</soap:Header>

Ultimately what I'm trying to do is retrieve data via SOAP web service and display it on a drupal page (possibly with wsclient-feeds), but I haven't been able to get past this header issue. I do see some people have developed code for a custom module that will add the headers, but then they provide some PHP to "call" it ...thats where I'm getting confused. Would love to just have the same header sent with every request. Any help is greatly appreciated!

Thanks!

Just wondering if that works!
I will be trying it in a next shot!

@TheWrench, you'd need to extend WSClientSOAPEndpoint. Add the headers in the call() method. See the code in wsclient I think for an example.

e.g.

/**
 * Overrides WSClientSOAPEndpoint
 *
 * A remote endpoint type for invoking SOAP services.
 */
class WSClientSOAPEndpointWithHeader extends WSClientSOAPEndpoint {
 /**
   * Calls the SOAP service.
   *
   * @param string $operation
   *   The name of the operation to execute.
   * @param array $arguments
   *   Arguments to pass to the service with this operation.
   */
  public function call($operation, $arguments) {
  /* Do your thing here */
  }
}

It works smoothly!

Reroll against latest dev.