Skip to Content

Introduction
I have written about creating WebServices in ABAP several times in the past:

BSP – a Developer’s Journal Part XIII: Developing ABAP WebServices

Develop a Web Service that sends an Email – in ABAP

Today I want to discuss WebServices once again. However I want to focus on a topic near and dear to me: multi-language support. Since WebServices support Unicode by default, their internal processing isn’t really concerned with Codepages or System Languages so much. Elements inside the XML packet of a WebService call can be tagged to belong to a particular language. Language elements from multiple languages can be contained in a single WebService call. The question is; how does all this match up with SAP’s concept of logon language. There are many more things that depend upon the logon than just codepage, so this is a concern even for Unicode systems. You need a way to properly set language elements to the correct language as your WebService is called by an external system. The example I am going to use today is a webserivce that needs to be callable in both English and Polish – two different codepages in my MDMP R/3 system.

Now I should note that I found very little documentation on the subject of language handling in WebServices in SDN, the Service Marketplace, or OSS. In fact about all I found on SDN while searching were other people with the same question. The following are simply the solutions that worked for us. Perhaps SAP had other solutions in mind. I should also note that in all my examples given I am consuming my WebServices from Visual Studio .Net 2003 (VB.Net).

WebAS 620
Like so many things in the WebService Area, the solution is different based upon what release of WebAS you are doing it in. SAP’s implementation of WebServices is drastically different between 620 and 640. We will start off by looking at a WebService in 620. In 620 all WebServices are exposed via a single web endpoint (otherwise viewed as a single node in the SICF tree). Therefore you can’t set any settings inside SAP without effecting all WebServices in your system. As you can see from the following screen shot, even the ABAP function module you wish to call is simply an URL parameter in the Web Reference URL. Therefore we took some knowledge we had from working with BSP applications and tried passing the logon language as the SAP-LANGUAGE parameter in the URL. Sure enough this works great in 620.

image

WebAS 640
If you weren’t aware, WebService generation in 640 is very different than in 620. We have to create Virtual Interfaces and WebService Definitions. If you need a look at these new steps in detail, check out one of the weblogs that I referenced earlier. My company has recently switched to using the new 640 approach to WebServices. I thought that everything was working just fine; until someone from Poland tried to test one of the new applications we were developing. They didn’t get their configuration codes in Polish. Unfortunately it looked like the URL parameter for setting the language was having absolutely no effect for the new types of WebServices.

Well going back to the drawing board, I decided to developer a simple little RFC that I could turn into a WebService to help me test. This RFC would return the current logon language and some codepage and encoding information about this language. The following is the code for my RFC.

Of course I wanted to test my Function Module from SAP before I tried exposing it from a WebService. The following were the results I correctly received while logged on in English and Polish respectively.

English
image

Polish
image

We are now ready to create the Virtual Interface and WebService Definition for my new test RFC. I’m not going to go into great details on these steps because there is nothing special we have to do for language processing. Once again if you need details on these steps, refer to the earlier weblogs on the subject.

Test Virtual Interface
image

Now we are ready to release our WebService Definition (Transaction WSCONFIG). This is where things get interesting. After creating my first release (and the associated node in SICF). I hit the create button again to create a second release. This creates a element which I give a different name to. I added the language I am going to setup this release for as part of the name. You can see how the two releases look in WSCONFIG from the following screen shot.

WSCONFIG Releases
image

If you go into the detail display of the second release, you can see that we have a completely different URL for this one. That means that we have two different Web End Points that can be called and configured independently. That also means that we will have two completely different WSDL definitions for each endpoint. Another programming language, such as Visual Studio, will see these two releases as two completely different objects.

WSCONFIG Details
image

If we navigate from WSCONFIG to the ICF Details, we will see that our second ICF endpoint is really just an External Alias pointing to the original release. However this is enough anonymity to allow us to configure different logon requirements for our Polish Release of the WebService and override the original release settings.

ICF Details
image
image

After we are finished setting up our two releases for the test WebService, we can also navigate to the WebService Administration Transaction (WSADMIN). From here we should see both of our release represented as their own addresses. Each can then generate their own WebService Test Page or WSDL file from this transaction. We will grab the WSDL definition of each for loading into our .Net application.

WSADMIN
image

To test I created a simple .Net application that will call my ABAP service and report the results in a message box. The following is the sample coding that I used:

Don’t worry if .Net isn’t really your cup of tea, its not mine either. (I’m sure anyone really skilled in .Net can tell that from my code sample.) There isn’t much going on in here accept my call to the ABAP WebService and a little bit of code to display the results. I just wanted to make absolutely sure that this approach would work for our internal partners who would be consuming WebServices like this in their .Net Applications. With this approach I then correctly receive the following results in .Net:
image

To report this post you need to login first.

7 Comments

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

  1. Former Member
    Hi Thomas,
    This is a fascinating topic for me. I have been researching Unicode interfacing with SAP since 4.6D. In 4.6 you were fairly limited in the possibilities. Its nice to see that the improve Unicode support in 6.x.

    Thanks for exploring the link between logon languages and webservices.

    (0) 
  2. Former Member
    Another great article.  Thank you for all your helpful posts.  We are having an issue here.  We are on 640 and have walked through the Wizard to create both the virtual interface and the WSDL associated with our remotely callable Function Module.  The process is very staightforward and all elements appear to be created successfully however when we go to test the Webservice via WSADMIN and the browser is brought up we are getting the following error…

    Service cannot be reached
    HTTP 404 – Not found

    When attempting to test via WSCONFIG an error of

    SOAP processing failure, error id = 112

    is brought up…  Any suggestions.

    thank you in advance Del

    (0) 
    1. Thomas Jung Post author
      Is your system you are testing on an ABAP+J2EE?  Have you configured the administrative settings in WSADMIN?  From WSADMIN you choose Goto->Administrative Settings (at least that is the menu names in my 04s system).  Here you put in the URL that points to an SAP J2EE system.  The test tools all reside on the J2EE side.  If you are getting a 404 right away, I suspect that this configuration has not been done.

      How are you trying to test in WSCONFIG?  Are you branching in the service node (SICF) and doing a test on it directly?  I guess I would have to know a little bit more about how you encountered the error id 112 to be able to give you more details on it.

      (0) 
  3. Former Member
    Hi Thomas,
    Interesting article, this is exactly what I am trying to do after almost 2 years since you published this article. Any easier/different ways to achieve this in 7.0 ehp1?

    Regards
    Praveden

    (0) 
    1. Thomas Jung Post author
      Yes this is very different in NetWeaver 7.0 with the changes which came with SOAMANAGER.  I would strongly suggest you review these new capabilities for the later release in other sources.  This blog is only applicable to 6.20 and 6.40 release levels.
      (0) 
      1. Former Member
        Thanks,I have been searching for a way to achieve this but not successful yet. it would be helpful if you could shed some light or point in right direction.
        Regards
        Praveen
        (0) 

Leave a Reply