I have written about creating WebServices in ABAP several times in the past:
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).
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.
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.
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.
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.
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.
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.
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.
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: