Publishing and discovering Web Services from SAP NetWeaver Exchange Infrastructure
People frequently have questions about the Integration Repository of SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI). Specifically, they want to know whether or not the Integration Repository is UDDI-compliant (it is not). Though this is baffling to some people, the Integration Repository is intended as an internal development repository, not as a public yellow pages. In this blog I'll talk about the function of the Integration Repository, how it differs from a UDDI registry, and how to publish web service defintions (WSDL) from the Integration Builder.
As you know, interfaces in the Integration Repository describe the message(s) exchanged at runtime, the mode (synchronous or asynchronous), and the direction (inbound or outbound) of the exchange. These interfaces are accesible as WSDL documents, it is true, and they are in a central store (the IR) so that they can be discovered and reused when possible. But these interface descriptions lack some important features of a WSDL document - namely, address and binding information.
This doesn't mean that the WSDL document created in the Integration Repository has no useful purpose. It can be used to generate proxies, the programming stubs that can be completed to provide client or server applications based on the interface. This is known as "outside-in" programming - start with the interface description in a language that is platform- and vendor-neutral (WSDL), then use it to implement the functionality in whatever language you want. For the SAP NetWeaver Application Server, ABAP and Java proxies can be generated from the WSDL descriptions stored in the Integration Repository. One benefit to this approach is that the amount of hand-coding to be done with a proxy application is minimal. A further benefit is that you can web service-enable any functionality that makes sense to service-enable - not just those that have pre-defined interfaces (BAPI or IDOC).
But of course, in order to actually consume or serve that service-enabled functionality, you must configure the scenario in the Integration Directory (this blog is concerned only with interfaces that are called through SAP NetWeaver XI - you can actually service-enable directly from the SAP NetWeaver Application Server, but we can leave that for another blog). In the configuration you specify the actual Interfaces, Systems, and Mappings that will be used in an integration scenario, together with the technical details to make it happen - endpoint URL, security settings, communication channels, etc. Only when this configuration is complete can fully-specified WSDL, including bindings and endpoints, be created.
There is a wizard interface in the Integration Directory for creating these WSDL documents. You start the wizard by choosing "Tools » Define Web Service..." from the main menu of the Integration Builder Configuration tool (Integration Directory). You will see the following start screen of the wizard:
The steps that you must perform in the wizard are:
- Specify the URL of the Web Server
- Specify the Interface
- Specify the Sender
- Generate the WSDL
When you specify the URL of the Web Server to process the service, the wizard will propose the URL of the Integration Server as it is entered in the System Landscape Directory. This is because the WSDL document that results from the wizard contains URL information that allows to send directly to the input channel of the Integration Server without having to go through the sender SOAP adapter. Obviously, the WSDL Port Type and Operation will be based on the Interface specified in the wizard. And the Sender information is used to specify the keys that will be used to route the runtime SOAP message in the pipeline (remember that Sender, Sender Interface, and Sender Interface Namespace are the three keys required for selecting a valid configuration at runtime); this allows the message to bypass the SOAP adapter and be processed directly at the Integration Server. After the wizard is complete, you will see a screen similar to the following:
To complete the process click on the "save" button (
). This will save the WSDL file to whatever location you specify. You can now give this file to your business partner so that they can, for instance, generate a client application to your web service.
Of course, when you want to let a partner access the web service, you still must have all of the configuration completed in the Integration Directory. But the main point here is that you now have a fully-specified WSDL document that is shareable with a partner. Is it publishable to a UDDI registry? Well, probably not, at least as it stands; the problem here is that the generated WSDL is specific to a particular sender. This makes it appropriate for giving to a partner with whom you already know you want to have an electronic trading relationship. If you want to advertise your web service more generally, to be accessed by arbitrary SOAP clients, you would probably want to specify the URL of the SOAP adapter (http://host:port/XISOAPAdapter/MessageServlet?channel=party:service:channel) in the wizard. And you would remove the sender information from the WSDL before publishing to a UDDI registry. That makes it more generic - but remember, for any given partner, you must still configure message exchange for that partner in the Integration Directory.
So, in summary, the Integration Repository is not meant to be a public yellow pages for arbitrary clients to find available web services, and is meant to be an internal development repository only. Once you have completed the web service defintion, you can generate a WSDL file and publish it to a registry. The SAP NetWeaver Application Server includes a UDDI-compliant registry, or of course you can publish to a public or third-party registry.
1 Comment
