Thought I’d start sharing the notes I’ve collected over the years of working with the Web Services Pack. This is the ability for DataStage to be a SOAP Client; for a DataStage Job to reach out and invoke a Web Service located “out there in the ether.” This is a reference to the benefits of Web Services and the fact that you don’t have to know where the Service is located, what machine its on, who wrote it, or what language it’s written in — doesn’t mean it’s not a good idea, especially if your business is relying on it, but I think you get the point. Give me a WSDL document, and that should be enough to invoke some type of remote function [this is what you might call the opposite of WISD, or RTI, which allow you to publish a DataStage Job or other Information Server asset "as" a Web Service].
Before you get started with it, ask yourself how comfortable you are with Web Services technology. I speaking here about SOAP over HTTP in particular, the protocol supported by WS Pack, but it would be wise to get yourself a good intro to all of SOA. There are good books out there, but also 1000’s of great resources here on the web. Just search in your favorite browser for something like “Web Services Introduction XML,” and poke around. You’ll find something for everyone.
Then you need the software. If you are a release 8 user, it’s just “there.” If 7.5, you have to speak with your account team about downloading it, but it won’t cost you anything. The installation is simple, although be reminded that there is a client side and server side component.
Once installed, you’ll have two new Stages, the WSClient Stage and the WSTransformer Stage. WSClient is for Web Services that will be a source or target to your Job, and the WSTransformer is for those Services that you expect to invoke on a row-by-row basis.
I have to put in a plug for the documentation. The WSPack documentation is very thorough. It has some very easy to understand graphics that do their own nice job of introducing Web Services in general, as well how WSDL, SOAP, SOAP Envelopes and SOAP Bodies come into play. What I’d like to add in these entries are some other points to consider as you prepare to include Web Services in your jobs to help you be more successful.
A stand alone Web Services testing tool is a good idea too, unless you are already comfortable using Web Services from a common IDE for Java, C#, .NET, etc.
Finally, find yourself a good Web Service to start with, just to learn the mechanics. There are some great ones out at www.xmethods.net . You can test them there to see how the function, and get a solid idea of what their input and output requirements are. There’s a nice mix of publicly available services there; some are free, others are part of a business. The free ones are sponsored by folks who are making known their expertise. Some very solid consulting firms and companies with Web Services expertise are represented there. I’ve seen many of the services hosted at that site continue to function and be supported for more than five years. For your first foray into Web Services pack, pick one that has very few input and output arguments, accepts and returns one row (a perfect candidate for WSTransformer) and doesn’t require you to pay anything or come up with an access code.
This entry is getting long. Next time I’ll walk you thru access to the Service and then discuss how to prepare for a more complex one that you might find inside your enterprise.
