Skip to Content
Author's profile photo Former Member

How-To Create Dynamic & Configurable Web Services Easily With Netweaver Development Components (Part II)

h2. PART



  the first part


said that (How-To Create Dynamic & Configurable Web Services Easily With Netweaver Development Components (Part I)) we can create dynamic

web services with Netweaver Developer

Studio, and without code modification

we will change the configurations

on the fly. For doing this we

should first create web service



do this;+


the ejb project, double click

on the web service configurations,

create to configuration by clicking

the add button.


  one was standard, named Config1,

  and it was added when we first

  create the web service.


second will be used for reaching

the web service via basic authentication

with username and password. Create

the new configuration by clicking

web service configurations, click

the web service name and click

the add button. After creating

the configuration choose security;

select HTTP Authentication for

Authentication mechanism and Basic +Use

SAP Logon Ticket +from

below. Choose operations(your

ejb methods) for web service and

save. Save it and your configurations

look like the below one :


this, add the ejb project to ear

project and deploy the ear project

to server.


we want to see how it looks like

from the server side, go to the

visual administrator on your j2ee

server, choose +server > services >


  services container+;

  in the endpoints&wsdl tab

  you see your web service, and

  2 config ports, with different

  addresses. Now we will point to

  these two ports declaratively

  without coding after making a

  few adjustments.


time to generate the parts in

our proxy project and call them

from our servlet in the web project.


created the server proxy project

and generated a logical port.

Here target address is our destination

and logical port name is our reference

for reaching the service. Your

project is like the one below



  public parts


order for other DCs to call our

proxy we should add the parts

to our public parts both as *API

and SDA*.

To do this go to Proxy Project,

select your proxy, right click

on it and create a new public

part by selecting add proxy to

public part and choose type API.

Do the steps again and add an

SDA public part. Build and deploy

the project. Then we will use

these references in our web project


  we start to fill our web project.

  First we create a servlet by right

  clicking on the web project and

  choose new servlet. Remove the

  doPost method therefore our servlet

  is only callable from URL. Then

  add the following code to our

  doGet method. Dont panic, at first

  it cannot find the Test2WS and

  some other class .


code is like the one below :


void doGet(HttpServletRequest

request, HttpServletResponse response)


ServletException,IOException {



    InitialContext ic = new InitialContext();


testWS = (Test2WS) ic.lookup( “java:comp/env/DepProxy1” );

    Test2WSViDocument vi = testWS.getLogicalPort();

    String s = vi.getDateAndTime( “baris” );


  } catch (Exception e) {





that we should add our proxy reference

from used DCs. To do this we go

to DC metadata, choose DC definitions,

right click on used DC and add

our previously generated public

parts to project like the below

image. Choose build time and runtime

and choose strong for dependency



  should also add web services from


  under used +DCs > Local

  Development+ and

  webservices_lib from SAP-JEE for

  using the web service related




  then have to map our servlet to

  a URL from web.xml. Look below,

  its as easy as seen in the picture.

  Double click web.xml, choose mapping

  tab, click ServletMappings, add

  a servlet and create mapping with

  a URL pattern by starting with

  a slash(/WSClientServlet).

  Save and you can use it.To

  determine the application root,

  enter application.xml;

  go to modules tab, select the

  web project, and change the context

  root for your preference by clicking

  get context root… By this way

  your servlet is callable via URL

  : http:// <yourserver>:<yourport>/<yourcontextroot>/<yourservletmappingpath>


  we have to add the proxy reference

  to application-j2ee-engine.xml for

  using in runtime. In the general

  tab choose references, create

  new and add the related information.

  See the image below for this :



  deploying our project, our servlet(therefore

  our web service) is callable from

  URL : /bb/WSClientServlet.

  Bingo!! And here is the response




the switching without the code

part :


said that we can switch configurations

without any coding effort. To

do this we will use our logical

ports from the proxy project.

We will switch to our second config

port, which makes authentication

therefore our web module calls

the authenticated web service

proxy without any code change.


we want to change the address

in our project just change the

target address in the logical

port and point to other port.

See the image below :


we call the authenticated web

service and get an unauthorized



back your changes in the proxy



comes the magical part ..


deployment just go to the visual

administrator, go to web service

security > web

service clients and find the application.

At first it look like the one

below :


change the URL and point your

proxy target and bingo again!!

You can call the application (call

the service without authentication)

again, and no exception. Upps,

no, just apply the basic rule

: Restart first(just the application)



to deploy service, choose application,

choose your proxy, stop and start

it, now you can call the service.


you have changed the destination

to basic authentication web service,

but this time without changing

your project code.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Hüseyin Bilgen
      Hüseyin Bilgen
      Is it your restriction or SAP's restriction that you cannot create a generic Web Service URL?
      If we have more than 3 system do we really have to edit the link on each system.
      Like Vendor SQL Usage for JDBC Database Access, isn't there any solution?
      Author's profile photo Former Member
      Former Member

      Huseyin,<br/>In fact I couldn't get what you mean by restriction..<br/>If you leave your proxy logical port target as  localhost:<port>/bla/bla then its already generic. Deploy it whatever server you want with your proxy. However if you want to switch the authentication method on the fly, without code change, then it's configuration feature can be seen.<br/>

      Author's profile photo Former Member
      Former Member

      i used your blog to learn more about Web Service and Deployable Proxies and it is a good starting point.

      I'm right now consuming a Web Service from a Groupware. This groupware webservice contains an object called LoginRequest. I call the Web Service according to your example in the blog. But when i make a cast like "LoginRequest logReq = (LoginRequest) webservice.getLogicalPort(LoginRequest.class)". I get a classcastexception. The object, i get, is a  
      BindingStub Object that i cannot cast.

      If you have hint, i would be very happy (and lucky). I don't have a clue how to solve this problem...

      Best Regards

      Author's profile photo Former Member
      Former Member
      When you make a getLogicalPart() call you have to get a ViDocument object extending the Stub class.. Is your LoginRequest class listed in the proxy's SEI's list in project's list? Please check this, and  send me the complete code to make a review.
      Author's profile photo Former Member
      Former Member
      I'm using a deployable proxy like you and I would like to ask you some questions:

      Have you ever had caching problems or "no working problem" after deploying the ejb (and so the ear proj) which uses the proxy? I have a stateless session bean which uses the logical port of the proxy; if I just add (for exempl) a private method (for other purpose) in the session without modify enything abuot the proxy, and then build the session, build the ear, deploy the ear, testing in the WebService Navigator (or with the WebDyn App), I see the proxy doesn't work anymore -> error: The root message element is definitions{} but it should be SOAP:Envelope! But two second before it worked!!!
      To solve the problem I described, sometimes I tried to "stir" the situation re-deploying the proxy or going to Visual Administrator and clicking the "Save" button in the destination or something else like that! But now this procedure doesnt work anymore! Have you ever had problem like that, maybe about caching or working after other "foreign" changes?
      Often, the proxy doesn't work after a code transport from Development to Consolidation environnement.
      Attention: when I created the Logical Port, in the wsdl url target I inserted a link to an ABAP service (with authentication of course) deployed in another server; then I went to Visual Admin to change the default link in the Destination with my ABAP service link -> result: the proxy seems to work but if I make some change in the session (fo exmpl) and deploy, the proxy seems to be not working anymore! So, the proxy works sometime yes and sometimes no!