Skip to Content

h2. PART

    II

In

  the first part

We

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

configurations.

+To

do this;+

Open

the ejb project, double click

on the web service configurations,

create to configuration by clicking

the add button.

First

  one was standard, named Config1,

  and it was added when we first

  create the web service.

The

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 :

After

this, add the ejb project to ear

project and deploy the ear project

to server.

If

we want to see how it looks like

from the server side, go to the

visual administrator on your j2ee

server, choose +server > services >

web

  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.

Its

time to generate the parts in

our proxy project and call them

from our servlet in the web project.

We

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

:

Adding

  public parts

In

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

Then

  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 .

Our

code is like the one below :

protected

void doGet(HttpServletRequest

request, HttpServletResponse response)

  throws

ServletException,IOException {

  try

{

    InitialContext ic = new InitialContext();

    Test2WS

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

    Test2WSViDocument vi = testWS.getLogicalPort();

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

    response.getWriter().write(s);

  } catch (Exception e) {

    response.getWriter().write(e.toString());

  }

}

After

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

type.

We

  should also add web services from

  the SAP_JTECHS SD

  under used +DCs > Local

  Development+ and

  webservices_lib from SAP-JEE for

  using the web service related

  libraries.

Adjustments

We

  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>

Lastly

  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 :

Testing

After

  deploying our project, our servlet(therefore

  our web service) is callable from

  URL : /bb/WSClientServlet.

  Bingo!! And here is the response

  :

!https://weblogs.sdn.sap.com/weblogs/images/251782120/image015.jpg|height=251|width=404|src=https://weblogs.sdn.sap.com/weblogs/images/251782120/image015.jpg!

Now

the switching without the code

part :

We

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.

If

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 :

Therefore

we call the authenticated web

service and get an unauthorized

exception.

Revert

back your changes in the proxy

project.

Now

comes the magical part ..

Without

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 :

Just

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)

!https://weblogs.sdn.sap.com/weblogs/images/251782120/image019.jpg|height=237|width=555|src=https://weblogs.sdn.sap.com/weblogs/images/251782120/image019.jpg!

Go

to deploy service, choose application,

choose your proxy, stop and start

it, now you can call the service.

Again

you have changed the destination

to basic authentication web service,

but this time without changing

your project code.

!https://weblogs.sdn.sap.com/weblogs/images/251782120/image017.jpg|height=197|width=449|src=https://weblogs.sdn.sap.com/weblogs/images/251782120/image017.jpg!</body>

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. 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?
    (0) 
    1. Baris Buyuktanir Post author

      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/>

      (0) 
  2. Philipp Kostyra
    Hello,

    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
    Philipp

    (0) 
    1. Baris Buyuktanir Post author
      Philipp,
      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.
      (0) 
  3. Enrico Caddeo
    Hi,
    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{http://schemas.xmlsoap.org/wsdl/} 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!

    Thanks
    Enrico

    (0) 

Leave a Reply