Manually Configuring Web Service Pack

[chulett]

Can't really help but wanted you to know I've moved your post into the 'all things services related' forum.

[eostic]

hmm. It sounds like something else I saw recently, a 301 re-direct based on a load balancer. I can't be sure, but I suspect that this can't be handled in the current WS Stages, because there's no way to "capture" the error and then perform another behavior. The error/fault is received by the job properly, but it is interpreted as a failure without any ability to act....so the job probably aborts.

I'm not sure what the expected behavior of the client is....for the 301, there is a loose expectation that the client will handle it, because the soap fault is supposed to define the alternate address....... you'd have to check the standard carefully --- it's possible that a 407 expects the same? I would have hoped that it would be transparent to the client, but it's possible that the client should have the option of controlling its own destiny.

Either way, the only solution might be to eliminate the proxy or else write your own java ws handler and use javapack.

Ernie

[djbarham]

I decided to try some alternative web services (a Google search and a weather service) to figure out where I was going wrong.

There were a few issues.

Firstly, for some reason, when providing the direct URL for the WSDL, DataStage would not see the available operations. However, if I saved the WSDL to a file, and used that, DataStage found the operations. The Glass's Guide actually had definitions for both SOAP1.1 and 1.2, so that was all good.

The catch is that as the WSDL file was on a network share, DataStage wanted to access that at run time. Once I provided a username/password that had access, it started working.

Where I finished up:
After importing the operations from the WSDL, I changed the details to point back to the original URL instead of the file.

I also needed to supply a username/password for proxy authentication.

So far, all looks good.

[djbarham]

Well, it turns out things aren't working so well after all. While I was getting a response, it was an empty response and independent tests have confirmed that this is what happens when authentication fails.

The soap envelope from our independent tests looks like this.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<AuthHeader xmlns="http://microsoft.com/webservices/">
<Username>..............</Username>
<Password>........</Password>
</AuthHeader>
</soap:Header>
<soap:Body>
<Get....._removed_...... xmlns="http://microsoft.com/webservices/">
<ModelTypeCode>A</ModelTypeCode>
</Get....._removed_......>
</soap:Body>
</soap:Envelope>

I have manually added the AuthHeader Username and Password fields to the Input Arguments sheet.

At this stage, my suspicion is that it is still the proxy server giving us the problem.

What is interesting is that the independent test was not via the proxy server. Once we added the proxy server to the mix, we also had to copy a cookie across to make it work.

Thoughts?

[eostic]

As suggested above, the proxy may indeed be the issue. Assuming you can prove that, you may need to write your own handler to deal with it, if the other server expects the client to get the response and then re-route itself from a value in the SOAP fault...

Ernie

[djbarham]

As suggested above, the proxy may indeed be the issue. Assuming you can prove that, you may need to write your own handler to deal with it, if the other server expects the client to get the response ...

Gah ... so it seems that I have to pay to see your response.

That aside, we have done some further testing.

As described above, the srevice requires username and password in the soap header. We have done a packet capture at the proxy server and DataStage is not generating a soap header in the envelope.

So, how to make it do this becomes the focus of my investigation.

[djbarham]

Aaaarrrgggghhh!!!

Don't you hate it when the answer is in the manual.

I had to read the section on adding headers 3 or 4 times before the penny finally dropped as to what it was saying.

Instead of putting a value in for a field as you do with the body of the enevlope, it requires you to enter the actual XML of the entire header content (and tick the header box).

Once I did this, DataStage started generating the header correctly.

I still don't have a successful result yet, but this is one step closer.

[djbarham]

OK, all working. Just had to sort out correct namespace references in the header.

To summarise the whole issue from start to end:
* DataStage did not recognise anything in the WSDL when loaded directly from the URL. Once I saved it as a file, then read the file with DataStage, it found the necessary information.
* SOAP headers must be hand crafted and the complete XML that appears within the header inserted into the "value" field of the input arguments (and check "header").

[eostic]

Congrats! Nice work. What I like to do is to capture a successful SOAP envelope from the owner of the service....and then work in mimicking that, even if I just hard code it at first...and as you discovered, the "header" details are just a chunk that you define on your own upstream.

Ernie

[rajadommeti]

However, if I saved the WSDL to a file, and used that, DataStage found the operations.

Hi, you said you saved WSDL to a file. What do you mean? how did you do that. I also have an issue recently that i datastage can not read one of 2 methods in a wsdl, so i want to try this option. please let me know . Thanks

[chulett]

Why not just ask in your post? I'm sure the people who suggested it would be happy to tell you how to do that if you are unsure.