WSDL of ABAP Webservice correct?

[Former Member]

I created a Web Service Definition by the inside out approach and referring to an RFC function group.

Generation worked fine and I also could configure the service via SOAMANAGER.

The generated WSDL (portType and binding) was sent to a client who tried to evaluate the WSDL.

Unfortunately it was not evaluated successfully.

Several error messages were thrown like:

Cause of error: Element <wsp:Policy> is not allowed under element <wsdl:portType>

Other causes: Following elements are expected under this position:

<wsdl:operation>

Error path wsdl:definitions / wsdl:portType / wsp:Policy

So, I am not quite sure if the generated WSDL is syntactically correct or if the client evaluation is wrong. What does the standard say?

Thanks,

Michael

[Former Member]

As far as I know, soapUI doesn't understand most policies.

Obviously, the WSDL contains a policy attachment, which is an extension of WSDL 1.1. But I suppose the generated content is alright. The problem seems to be the client side's SOAP engine (or however you call the middleware which invokes the service for you), doesn't support a specific assertion inside the policy or does not understand policies at all. If you use Java a newer version of JAX-WS RI & JAX-WS should do the job.

[Former Member]

Perhaps the problem is with the software your client is using. I have had good success consuming WSDLs from R/3 using a product called soapUI but somewhat less success using Stylus Studio. Try downloading the free version of soapUI from www.soapui.org and see if you get any luck calling your service using a different tool.

Sorry, this doesn't directly answer you question but might help to point where your problem lies.

Ralph

[Former Member]

Hi michael,

Web Services

Business processes consist of individual process steps that can vary in how extensive they are. One or more functions are then assigned to these steps; an executing software component is then assigned to each function. Clearly, the heterogeneous nature of system landscapes in enterprises makes it impossible to implement all the necessary functions associated with a complete process using the same technology on the same component. A modern software infrastructure must be in the position to integrate functions, implemented on widely differing software components, in one effective complete process. Until now, the combination of different applications has largely been based on manually declared interfaces, message formats, and agreements between business partners.

Web services simplify this process. They are based on open, generally accepted standards. They enable you to combine functions in a single process, even if they are implemented in widely differing software components. Web services are standalone, executable entities that can be published, searched for, and called, across a network.

Introduction

The SAP Web Application Server implements the following basic Web services standards: eXtensible Markup Language (XML); Simple Object Access Protocol (SOAP); Web Service Definition Language (WSDL); and Universal Description, Discovery, and Integration (UDDI).

In the documentation that follows, we assume that the reader is familiar with Web service standards and techniques. You will find a general introduction to the Web Services topic under Sun Microsystems, in the pages of W3C, and in the general explanations for standardization organization OASIS under the topic UDDI.

Integration

ABAP and Java Web Services

Enterprises can extend their solutions by using Java or ABAP Web services, or both. If your priority in programming an application is the selection of data, the integration of an ABAP Web Service could be appropriate. Conversely, if you are implementing processes that involve different business partners and systems, it may be beneficial to program in Java and integrate Java Web Services.

The Web Service Framework consists of:

· The development environment for the ABAP Engine

· The development environment for the J2EE Engine

· Tools that support UDDI registration

· A distributed, interoperable SOAP runtime (ABAP and J2EE Engine)

Processing of SOAP requests using the Internet Communication Framework

·

Web Services and the SAP Exchange Infrastructure

The SAP Exchange Infrastructure is a key area in SAP NetWeaver. The Exchange Infrastructure provides an open, process-oriented integration infrastructure for the unhindered flow of information and for XML-based message exchanges. Systems integrated using SAP XI exchange messages over the Integration Server.

The programming model for XI ABAP proxies and Web services has been unified. The advantage of this is that both technologies can be implemented so that they complement one another. Messages can be sent and received either using the XI runtime or the Web service runtime.

Additional proxy runtime services can be controlled using protocols that you request using a proxy method. The features you have available depend on whether you are using the Web Service Framework or the Exchange Infrastructure for communication.

Features

The ABAP Workbench offers an environment where you can publish, search for, and call Web services. It enables the SAP Web Application Server to act both as a server and client for Web services.

The Web service infrastructure enables developers to:

· Publish independent function that were implemented as RFC-enabled function modules, function groups, BAPIs, or XI message interfaces. This includes functions available as part of mySAP.com solutions, or functions developed by customers or partners. The Web service can be used across the entire Internet using standard protocols and can easily be added to any development environment. (See also Creating a Web Service).

· Consume Web services, regardless of where they are stored or how they are implemented. Business processes can be implemented across several systems, either within an enterprise or across several enterprises. (See also Consuming Web Services.)

Service Provider

After the functions have been implemented, a Web service interface must be created that provides a representation of the Web service for the user. This interface offers an abstraction layer and thus independence from the specific implementation used. Based on this interface, the Web service is configured and can be called at runtime. Publishing Web services in a UDDI Registry is supported by the UDDI client functions in the SAP Web AS.

Service Directory

You can store Web service definitions and released Web Services in a UDDI Registry. WSDL documents provide the basis of the Web service client, which can then be searched for in the UDDI using either a browser or the standard UDDI APIs. Web services can be published and searched for in all registries that conform to the standard. SAP also offers a public UDDI Business Registry under uddi.sap.com.

Service Requestor

The SAP Web AS allows you to integrate Web services. It can generate Web service clients from WSDL files.

Standardization and Extensibility

Web services and Web service standards develop quickly; new standards are being presented continually at standardization committees. However, these extended standards – such as security standards or additional protocols – can easily be integrated in the Web Service Framework using SAP.

Creating Web Service Physical Destinations Use

This procedure enables you to create and configure a Web service physical destination. More information: Configuration of Several Web Service Clients

You have to create and configure a Web service physical destination for every Web service logical destination available in the consumer application. You can create only one physical destination for every logical destination.

You create Web service physical destinations on the system where the client application is running. This system can be only SAP NetWeaver Application Server (AS) Java. You can create physical destinations that point to Web services available on AS ABAP, AS Java, or any external systems.

Prerequisites

&#9679; You have access to the SAP NetWeaver Administrator of your AS Java.

&#9679; The client application is deployed.

&#9679; The Web service logical destinations are available in the client application and you know their names.

&#9679; Web services are deployed and configured on the provider system.

&#9679; You know the way in which the client application is to find Web services on the provider system: by using WSDL, WSIL, or SR. When you use WSDL or WSIL, you have to know the correct URL to the WSDL or WSIL on the provider system.

&#9679; If you want the client application to discover a Web service by querying the Service Registry (SR), a connection to the SR has to be configured. More information: Configuring the Services Registry.

Procedure

...

1. Log on to the SAP NetWeaver Administrator.

2. Choose SOA Management ® Technical Configuration ® Destination Template Management.

Alternatively, you can use the quick link /DestinationTemplates as follows:

http:// of the provider system.

c. In the Hostname field, enter the name of the database host of the provider system.

d. If for System, you chose ABAP, the following additional fields are available:

i. In the Installation Number field, enter the installation number.

To check the installation number, in AS ABAP of the provider system start transaction SLICENSE.

ii. In the Client field, enter the number of the AS ABAP client in which the Web services are available.

8. Set the security settings for the connection.

For more information, see Recommended WS Security Scenarios.

HTTP Authentication

Option

Description

User ID/Password (Basic)

Authentication with user ID and password in HTTP header

More Information: HTTP Transport Level Authentication

User ID/Password (Digest)

Username and password based authentication, in which the password is encrypted.

More Information: Basic Authentication (User ID and Password)

X.509 Client Certificate

Authentication with an X.509 certificate using Secure Sockets Layer (SSL).

More Information: HTTP Transport Level Authentication

Logon Ticket

Authentication with SAP authentication assertion ticket in the HTTP header, which authenticates the identity of the user.

More Information: HTTP Transport Level Authentication

Message Authentication

Option

Description

User ID/Password (Basic)

Authentication with a WS-Security Username Token in the security header of the SOAP message.

More Information: WS-Security UsernameToken

User ID/Password (Digest)

Username and password based authentication, in which the password is encrypted.

More Information: Basic Authentication (User ID and Password)

X.509 Client Certificate

Authentication with an X.509 certificate using Secure Sockets Layer (SSL).

More Information: HTTP Transport Level Authentication

SAML Assertion

Authentication with a signed SAML 1.1 assertion in the message header, which authenticates the identity of the user.

More Information: SAML Token Profile

9. Choose Save.

Result

The destination is created and saved. You can see all destinations in the Destinations area of the Web Services Configuration: WS Destinations screen.

thanks

karthik

reward me points if usefull

[Former Member]

I am sorry, but do you think just copying a standard text from some book or website answers my question? I think the question was very specific, and so I am looking for a specific answer.

No reward points, sorry!

[Former Member]

hi michael,

can you pls a bit clear.

cheers

sagar.

Edited by: sagar reddy on Apr 30, 2008 8:01 PM